为 GKE 生成安全可上生产的 Kubernetes…

当你需要创建或修改 GKE 部署清单（命名空间、ServiceAccount、资源限制、安全上下文、探针、Secret/卷挂载、Gateway API 路由、Spot VM、AI 推理负载）时，用这套规则生成合规且省成本的 YAML。

适用场景

解决思路

1. 在每个资源（Deployment、Service、ConfigMap、Secret、PVC、Role、绑定）的 metadata 中显式声明 namespace: {namespace}，映射到 SETTINGS.md 中配置的命名空间，绝不省略。
2. 不要使用命名空间的 default ServiceAccount，为每个微服务创建并引用专用 ServiceAccount（如 devteam-agent-sa）。
3. 为所有容器指定 CPU 和内存的 requests 与 limits：GKE Autopilot 下 requests 直接决定 Pod 计费且必须与 limits 相等（不等时 Autopilot 会把 requests 上调到 limits，显著增加成本）；GKE Standard 下 requests 保证调度与装箱稳定，limits 防止资源饥饿和吵闹邻居问题。
4. GKE Standard 上无状态应用或 sidecar 默认使用保守 requests（如 requests.cpu: "100m" 或 "200m"，requests.memory: "256Mi" 或 "512Mi"）并配可突发的 limits，超卖比例控制在 2x–4x（如 limits.cpu: "400m" 到 "800m"，limits.memory: "512Mi" 到 "1Gi"）；避免过度超卖（如 100m request 配 limits.cpu: "4"），否则在重调度负载下会出现严重 CPU 节流和延迟劣化。
5. 对非生产工作负载（命名空间含 -test、-dev、-staging）或用户要求成本优化时，自动指向 GKE Spot VM：同时注入 nodeSelector（cloud.google.com/gke-spot: "true"）和对应 toleration（key: cloud.google.com/gke-spot，operator: Equal，value: "true"，effect: NoSchedule）；GKE Standard 下需已配置 Spot 节点池。
6. 在 Pod 级（必要时容器级覆盖）配置 securityContext 以非 root 运行：runAsNonRoot: true、runAsUser: 10000、runAsGroup: 10000、fsGroup: 10000；这是 GKE Autopilot 强制要求，也是 Standard 的关键安全基线。
7. 始终设置 allowPrivilegeEscalation: false 和 seccompProfile: {type: RuntimeDefault} 以最小化权限。
8. 设置 readOnlyRootFilesystem: true 防止修改容器镜像文件系统；若启用，则挂载本地 emptyDir 卷到 /tmp 或 /var/run/，让 Java/Nginx 等应用能写临时文件而不崩溃。
9. 优先把 Secret 以只读文件方式挂载（在 volumes 中配置 defaultMode: 0400），而不是映射为环境变量，除非应用框架只支持环境变量配置，以避免密钥泄漏到应用日志。
10. 每个 Deployment 容器都必须定义 livenessProbe 和 readinessProbe：Web/API 用 httpGet，TCP 服务用 tcpSocket，数据库/缓存用基于命令的 exec（如 exec.command: ["redis-cli", "ping"]）。
11. 对启动慢的应用（Java Spring Boot、复杂 Python 脚本、LLM 模型服务器）必须额外定义 startupProbe；定义后 liveness 和 readiness 探针会在其成功前禁用，防止 Pod 在启动期间被过早杀死，例如 httpGet path: /healthz、port: 8080、failureThreshold: 30、periodSeconds: 10。
12. 根据启动时间设置合理的 initialDelaySeconds: 5 到 15（Java 需要比 Go/Nginx 更长的延迟）。
13. 内部微服务默认使用 type: ClusterIP；除非工作负载明确需要从公网访问，否则不要用 type: LoadBalancer 或 NodePort。
14. 为服务和容器端口指定清晰标准的名称（如 name: http-web 或 name: grpc-api），以支持自动协议发现、追踪和 Web App 路由。
15. 对外暴露 API 时优先使用 GKE Gateway API（Gateway 和 HTTPRoute 资源）而非旧版 Ingress，以启用高级 L7 路由和安全特性（如 Cloud Armor）。
16. 把 ConfigMap 或 Secret 挂载到包含其他文件的应用目录（如 Nginx 公共目录）时，始终用 subPath 只覆盖特定文件；注意使用 subPath 的容器不会在底层 ConfigMap/Secret 变更时自动更新配置，必须手动重启 Pod 才能生效。
17. 在 PersistentVolumeClaim 中使用正确的 GKE 存储类：CSI 驱动集群（Autopilot 和现代 Standard）用 standard-rwo（默认均衡 PD）或 premium-rwo（SSD PD）；旧版 Standard 集群在未配置 standard-rwo/premium-rwo 时用 standard（默认 PD）或 premium（SSD PD）；仅当提示明确要求高 IOPS、低延迟或数据库存储时才用 SSD 存储类（premium-rwo 或 premium）。
18. 副本数大于 1 的 Deployment 使用 podAntiAffinity 或 topologySpreadConstraints（topologyKey: "kubernetes.io/hostname"）把 Pod 分散到不同 GKE 节点和可用区。
19. 副本数大于 1 的 Deployment 声明 PodDisruptionBudget，保证 GKE 节点升级和维护期间的最小副本可用性。
20. 在 Kubernetes Server-Side Apply（SSA）下，关联列表（volumes、volume mounts、ports、容器定义）按唯一标识键（通常是 name）匹配合并；修改已有列表项属性时必须保持 name 键稳定，重命名 name 会导致 SSA 新建条目并遗留旧条目（孤儿）而非修改。
21. 只做被请求的改动，严格遵循现有标签、注解和约定，保持最小 diff。
22. AI/模型推理负载优先使用 GKE Inference Quickstart 等优化工具；手动生成时：在 requests 和 limits 中都申请 nvidia.com/gpu，并添加 nodeSelector 或节点亲和性指向目标 GKE 加速器标签（如 cloud.google.com/gke-accelerator: nvidia-l4）。
23. 模型服务器需要高共享内存（/dev/shm）做进程间通信，始终声明并挂载 medium: Memory 的 emptyDir 卷到 /dev/shm。
24. 用 GKE GCS Fuse CSI 驱动（csi.storage.gke.io）以 readOnly: true 挂载模型权重目录（如 GCS 桶），优化冷启动。
25. 安装 Google Cloud SDK；对所有 AI/LLM 推理负载优先用 gcloud CLI 的 GKE Inference Quickstart 命令生成优化清单而非手写：gcloud container ai profiles manifests create --model={model_name} --model-server={server_name} --accelerator-type={accelerator_type} --output=manifest --output-path={output_file_path}；必须包含该命令返回的所有资源（Deployments、Services、PodMonitoring 等），不得过滤。
26. 对 GKE 特定功能、API 默认值、清单示例或安全上下文，必须查询 Google 开发者知识库获取官方 GKE 文档：用 answer_query 提直接问题（如 "How to configure GCS Fuse CSI driver in GKE"，通用查询首选）；没有具体问题时用 search_documents 搜索相关 GKE 指南或示例；有具体文档 ID 时用 get_document 获取完整内容。
27. 参考生产级模板：references/basic-workload.md（含专用 ServiceAccount、安全上下文、探针、反亲和性和 PodDisruptionBudget 的加固 Nginx 工作负载）、references/network-policy.md（默认拒绝入站网络策略及对特定应用的选择性放行）、references/ai-inference.md（GPU 资源分配、Workload Identity、GCS FUSE CSI 驱动挂载、/dev/shm 共享内存增强和启动探针）、references/gateway-api.md（用 GKE L7 Gateway API 的 Gateway 和 HTTPRoute 暴露工作负载）。

适用边界 · 注意事项

• 不用于实时集群操作或 Pod 故障排查（应使用 gke-workload-troubleshooting）。
• 不用于集群基础设施的创建与配置（应使用 gke-cluster-creation）。