GKE 应用上线实战指南容器化、清单生成与安全部署全流程gke-app-onboarding【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本指南基于开源仓库skills29/skills中的 gke-app-onboarding 技能文档编写系统讲解如何将应用首次容器化并部署到 Google Kubernetes EngineGKE涵盖应用评估、容器化、镜像管理、Kubernetes 清单生成与部署验证五大工作流并给出生产级黄金路径上线检查清单。读完本文你将掌握一套可复制的 GKE 应用上线方法论——从编写非 root 用户的多阶段构建 Dockerfile到产出带探针、资源配额与安全上下文的加固 Deployment 清单再到通过 MCP 工具或 kubectl 完成部署与验证。适用范围说明本技能聚焦首次将应用容器化并部署到 GKE不适用于通用 GKE 集群管理或升级场景此类需求应使用 gke-basics 或 gke-upgrades。一、工作流总览五大步骤GKE 应用上线不是一个孤立动作而是一条从评估到部署验证的完整流水线。原文档将其拆解为五个阶段App Assessment应用评估上线前摸清应用的技术栈与运行特征。Containerization容器化将应用打包为容器镜像。Image Management镜像管理构建、推送镜像并做漏洞扫描。Manifest Generation清单生成编写 Kubernetes 部署清单。Deploy部署应用清单并验证滚动发布。本技能在运行时依赖以下 MCP 工具完成实际集群操作MCP Tools:apply_k8s_manifest、get_k8s_resource、get_k8s_rollout_status、get_k8s_logs、describe_k8s_resource下文按这五个阶段逐一展开。二、第一步App Assessment应用评估容器化之前先对应用做一次系统评估。评估的目的不是走形式而是为后续的 Dockerfile、探针与资源配额决策提供事实依据。原文档列出的评估维度包括Language Framework语言与框架确认技术栈这决定了基础镜像选型Node、Go、Python 等以及是否适合多阶段构建。Dependencies依赖列出所需的第三方库与外部服务判断是否需要 lockfile 固定依赖版本如package-lock.json、go.sum。Configuration配置方式应用如何读取配置——环境变量、配置文件还是 Secret这直接影响 ConfigMap/Secret 的挂载方案。Statefulness有状态性是否需要持久化存储数据库、文件存储有状态应用需要额外设计 PV/PVC 或外部托管数据库无状态应用则相对简单。Networking网络端口映射与协议类型HTTP、gRPC、TCP这决定 Service 的端口命名与探针类型。Health endpoints健康检查端点应用是否暴露健康检查端点这是配置 liveness/readiness 探针的前提。从仓库配套示例看评估结论会直接体现在代码里仓库的 assets/index.js 就是一个为此专门实现了/healthz与/readyz双端点的 Node.js 应用下文第四节详述也就是说评估阶段确认健康端点这一步在上线前就要完成代码层面的准备。三、第二步Containerization容器化评估完成后进入容器化阶段。原文档给出两条路径编写 Dockerfile推荐尤其是多阶段构建与Cloud Native Buildpacks无需手写 Dockerfile 的自动检测方案。3.1 容器化最佳实践使用多阶段构建multi-stage build在构建阶段安装编译工具与依赖最终阶段仅拷贝产物让生产镜像保持最小体积。使用 distroless 或精简基础镜像distroless 镜像不包含 shell 与包管理器可显著缩小攻击面。以非 root 用户运行生产容器应通过USER指令或securityContext指定非 root 用户。日志输出到stdout/stderrGKE 的 Cloud Logging 会自动采集容器标准输出应用不要自己写日志文件。3.2 仓库配套示例一Node.js 多阶段镜像与健康端点实现仓库在 assets/ 目录下提供了一套完整的可运行 Node.js 上线示例。先看 Dockerfile# Use official lightweight Node.js image FROM node:22-slim # Set working directory WORKDIR /app # Copy package files and install dependencies using lockfile COPY package*.json ./ RUN npm ci --omitdev # Copy the application code COPY index.js . # Expose the application port EXPOSE 8080 # Run the application as a non-root user for security. # The official images define node as uid/gid 1000 — keep this in sync with # runAsUser/runAsGroup in deployment.yaml. USER node # Start the application CMD [ node, index.js ]这段 Dockerfile 体现了前面提到的多条最佳实践依赖锁定使用npm ci --omitdev按 package-lock.json 精确安装生产依赖npm ci要求 lockfile 存在且必须与package.json一致避免构建产物漂移。非 root 运行USER node切换到官方镜像内置的node用户uid/gid 1000。注释特别强调——该 uid 必须与 deployment.yaml 中的runAsUser/runAsGroup保持一致这是安全上下文与镜像内用户 ID 的联动约束。最小化直接使用node:22-slim精简镜像且COPY只拷贝运行所需的index.js与依赖清单。配套的 package.json 非常简单仅声明应用入口与启动脚本{ name: simple-node-app, version: 1.0.0, main: index.js, scripts: { start: node index.js } }应用本身 index.js 用原生http模块实现了三个路由其中最核心的是将 liveness 与 readiness 语义分离的健康检查实现const http require(http); const port process.env.PORT || 8080; // Flipped once the server is listening; gate readiness on any startup work. let ready false; const server http.createServer((req, res) { if (req.url /healthz) { // Liveness: the process is up and able to serve requests res.statusCode 200; res.setHeader(Content-Type, text/plain); res.end(OK); } else if (req.url /readyz) { // Readiness: only accept traffic once startup is complete res.statusCode ready ? 200 : 503; res.setHeader(Content-Type, text/plain); res.end(ready ? READY : NOT READY); } else { res.statusCode 200; res.setHeader(Content-Type, text/plain); res.end(Hello, World!\n); } }); server.listen(port, () { ready true; console.log(Server running on port ${port}); });这段代码值得注意的实践要点/healthz只要进程存活就返回 200代表liveness存活探针——进程活着、能处理请求即可/readyz在server.listen回调把ready置为true前返回503代表readiness就绪探针——只有启动工作真正完成、可以接收流量后才返回 200。如果应用有更长的初始化逻辑连接数据库、加载模型等应把相应完成标志接入ready避免进程活着但还没就绪时被提前路由流量。3.3 仓库配套示例二Go 多阶段 distroless 镜像对于 Go 等可编译为静态二进制的语言仓库在 references/go-example.md 中给出了多阶段构建 distroless的完整示例# Multi-stage build for smaller, more secure images FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 go build -o server . FROM gcr.io/distroless/static:nonroot COPY --frombuilder /app/server /server USER nonroot:nonroot EXPOSE 8080 ENTRYPOINT [/server]要点解析阶段一builder使用golang:1.22作为构建环境CGO_ENABLED0关闭 cgo 以产出纯静态二进制确保它能跑在无 glibc 的 distroless 镜像上阶段二final以gcr.io/distroless/static:nonroot为基础镜像——它不含 shell 与包管理器攻击面极小且内置nonroot用户最终镜像只包含一个可执行文件/server体积显著小于完整工具链镜像同时以非 root 身份运行。3.4 不写 Dockerfile 的方案Cloud Native Buildpacks如果团队不希望维护 Dockerfile原文档推荐使用Cloud Native Buildpacks构建器会自动检测应用语言与框架并生成容器镜像。pack build image --builder gcr.io/buildpacks/builder:latestpack是 CNB 生态的 CLI 工具--builder指定构建器镜像Google 维护的gcr.io/buildpacks/builder:latest支持常见语言Java、Node.js、Go、Python、.NET 等的自动检测与依赖安装无需手写任何 Docker 配置。四、第三步Image Management镜像管理镜像构建完成后需要推送到镜像仓库并做安全扫描。原文档推荐使用Artifact Registry作为镜像仓库。4.1 构建与推送# Configure Docker for Artifact Registry gcloud auth configure-docker REGION-docker.pkg.dev --quiet # Build and push docker build -t REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG . docker push REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG两个命令说明gcloud auth configure-docker为 Docker 客户端配置 Artifact Registry 的认证凭据按区域执行后续docker push才能通过认证镜像地址遵循 Artifact Registry 的标准格式REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG其中REGION为仓库区域如us、asiaPROJECT为 GCP 项目 IDREPO为 Artifact Registry 仓库名。4.2 漏洞扫描在 Artifact Registry 中启用自动漏洞扫描可检测基础镜像与依赖中的已知漏洞。扫描完成后通过如下命令查看结果# Check scan results gcloud artifacts docker images describe \ REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG \ --show-package-vulnerability \ --quiet--show-package-vulnerability标志会在输出中附带镜像的包漏洞扫描结果。仓库的示例镜像如 assets/deployment.yaml 中引用的us-docker.pkg.dev/.../node-appsha256:...正是 Artifact Registry 地址格式。五、第四步Manifest Generation清单生成镜像就绪后进入 Kubernetes 清单编写阶段。这是整个上线流程中工程含量最高的一步。5.1 清单检查清单Checklist原文档要求每个清单至少满足设置资源 requests 和 limitsGKE Autopilot 下为强制项配置 liveness 与 readiness 探针生产环境至少 2 个副本replicasService 类型选择恰当——内部访问用ClusterIP外部暴露使用Gateway API。5.2 基线示例Go Deployment ClusterIP Servicereferences/go-example.md 给出了一个起点级baseline的 Deployment Service 清单作为任何应用上线的默认模板apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: my-app # Replace with your namespace spec: replicas: 2 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG ports: - containerPort: 8080 resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 512Mi livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 --- apiVersion: v1 kind: Service metadata: name: my-app spec: selector: app: my-app ports: - port: 80 targetPort: 8080 type: ClusterIP该基线的关键设计replicas: 2满足生产环境至少 2 副本的可用性要求资源配额requests 与 limits 分离250m/256Mi 与 500m/512Mi保证调度确定性同时限制单 Pod 资源占用双探针liveness 探/healthzreadiness 探/readyz与前面示例应用的健康端点一一对应ClusterIP Serviceport: 80对集群内暴露targetPort: 8080转发到容器端口。5.3 生产加固版示例Node.js 完整清单assets/deployment.yaml 提供了比基线更进一步的生产加固版清单包含完整的 Pod 安全上下文、资源配额、探针以及配套的 ClusterIP ServiceapiVersion: apps/v1 kind: Deployment metadata: name: node-app-deployment namespace: my-app # Replace with your namespace labels: app: node-app spec: replicas: 3 selector: matchLabels: app: node-app template: metadata: labels: app: node-app spec: automountServiceAccountToken: false securityContext: runAsNonRoot: true # Matches the node user (uid/gid 1000) set via USER in the Dockerfile runAsUser: 1000 runAsGroup: 1000 seccompProfile: type: RuntimeDefault containers: - name: node-app # Replace with your actual Artifact Registry image path and real digest, # e.g., us-docker.pkg.dev/PROJECT_ID/REPO/node-appsha256:DIGEST image: us-docker.pkg.dev/my-project/my-repo/node-appsha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef ports: - containerPort: 8080 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: node-app-service namespace: my-app # Replace with your namespace spec: selector: app: node-app ports: - protocol: TCP port: 80 targetPort: 8080 # ClusterIP for internal access; for external exposure use the Gateway API — # see the gke-service-networking skill type: ClusterIP该清单与 Dockerfile 形成完整的安全闭环逐项对照如下安全项配置位置作用非 root 运行Pod 级runAsNonRoot: truerunAsUser/runAsGroup: 1000与 DockerfileUSER nodeuid 1000严格对应杜绝容器以 root 运行只读根文件系统容器级readOnlyRootFilesystem: true防止运行时篡改镜像文件系统若应用需写临时文件应挂载 emptyDir 到/tmp禁止提权allowPrivilegeEscalation: false阻止进程通过 setuid 等方式提权丢弃全部能力capabilities.drop: [ALL]移除 Linux capabilities最小化权限面Seccomp 限制seccompProfile: {type: RuntimeDefault}启用运行时默认 seccomp 策略禁用自动挂载 SA TokenautomountServiceAccountToken: false除非 Pod 确实需要访问 Kubernetes API 并说明理由否则不挂载服务账号令牌镜像摘要锁定image: ...sha256:DIGEST用 digest 而非 tag 引用镜像保证部署内容不可变、可审计探针liveness 探/healthz、readiness 探/readyz均设initialDelaySeconds与periodSeconds与 index.js 的健康端点严格对齐资源配额requests 100m/128Milimits 200m/256Mi显式声明资源需求满足 Autopilot 强制要求原文档特别强调生产加固版 Pod spec 必须包含以上 ALL 全部项——runAsNonRoot: true、readOnlyRootFilesystem: true、allowPrivilegeEscalation: false、capabilities.drop: [ALL]、seccompProfile: {type: RuntimeDefault}、automountServiceAccountToken: false除非 Pod 确实需要该 token 并说明原因、资源 requests、digest 锁定的镜像以及 ClusterIP Service。这份清单就是本技能产出的任何 Pod spec 的基线。5.4 超出基线的场景交给 gke-manifest-generation原文档明确划定了本技能的边界如果需要生成超出上述基线的清单——例如 Gateway API 路由、GCS FUSE 与 Secret 卷挂载、subPath覆盖、Spot VM 定向调度或 AI/推理服务vLLM、TGI、Gemma规格——应转向 gke-manifest-generation 技能。从该技能的源码可见其覆盖的进阶能力包括nodeSelector toleration 定向 Spot VM、startupProbe处理慢启动应用、emptyDirmedium: Memory提升/dev/shm、csi.storage.gke.io挂载模型权重等。六、第五步Deploy部署与验证清单就绪后执行部署。原文档推荐优先使用MCP 工具kubectl 作为回退方案。6.1 MCP 方式推荐# MCP (preferred) apply_k8s_manifest(parentprojects/PROJECT/locations/REGION/clusters/CLUSTER, yamlManifestmanifest) # Verify get_k8s_rollout_status(parent..., resourceTypedeployment, namemy-app) get_k8s_resource(parent..., resourceTypepod, labelSelectorappmy-app)apply_k8s_manifest以 Server-Side Apply 方式应用清单parent参数指明目标集群格式为projects/PROJECT/locations/REGION/clusters/CLUSTERget_k8s_rollout_status查询 Deployment 的滚动发布状态确认my-app发布完成get_k8s_resource按labelSelector列出 Pod例如用appmy-app筛选应用 Pod 并核对运行状态。6.2 kubectl 回退方式kubectl apply -f manifests/ kubectl rollout status deployment/my-app kubectl get pods -l appmy-app三个命令依次完成应用清单 → 阻塞等待滚动发布完成 → 按标签查看 Pod。注意kubectl方式需要已配置好 kubeconfig 与目标集群上下文若在非默认命名空间操作需追加-n namespace。七、Golden Path Onboarding Checklist生产上线黄金路径清单对每一个上线到 GKE 的生产应用原文档要求逐项核对以下五条黄金路径容器安全Container Security非 root 用户运行runAsNonRoot: true、使用 lockfile 安装依赖如npm ci、go.sum、采用 minimal/distroless 基础镜像。资源请求Resource Requests显式声明 CPU 与内存 requests——GKE Autopilot 下为强制要求因为 Autopilot 直接按 requests 计费。健康探针Health Probes同时配置 liveness 探针livenessProbe与 readiness 探针readinessProbe。可靠性与可用性Reliability Availability至少 2 个副本并配置PodDisruptionBudgetminAvailable: 1或2保证集群维护或节点升级期间不中断服务。IAM 与 Workload IdentityIAM Workload Identity使用 Workload Identity通过iam.gke.io/gcp-service-account注解绑定 GSA替代静态服务账号密钥让 Pod 以安全、可轮换的方式访问 Google Cloud API。关于第 4 点的进一步说明PDB 与拓扑分布的具体配置范式在 gke-reliability 技能中有完整定义包括maxSurge: 1的滚动升级策略、区域集群等多可用区要求第 5 点的 Workload Identity 配置实操KSA/GSA 绑定、Pod 注解详见 gke-workload-security。八、Next Steps上线之后应用在 GKE 上稳定运行后原文档推荐按需继续深化以下方向配置自动扩缩容查看 gke-workload-scaling 技能——该技能覆盖手动扩缩、HPAHorizontal Pod Autoscaler与 VPAVertical Pod Autoscaler并给出先跑 24 小时 VPA Off 模式看推荐值再按 P95 × 1.2 缓冲落地的 right-sizing 工作流同时提醒避免 HPA 与 VPA 抢同一指标典型模式是 HPA 管 CPU、VPA 管内存。搭建可观测性查看 gke-observability 技能为工作负载配置指标、日志与链路追踪。加固安全查看 gke-workload-security 技能进一步落实安全审计、Network Policy默认拒绝 白名单放行、Pod Security Standards 与 Secret Manager 挂载。配置可靠性查看 gke-reliability 技能完善 PDB、拓扑分布约束topology spread constraints等高可用配置。九、小结一套可复用的上线方法论回到本技能的核心价值gke-app-onboarding将首次把应用搬上 GKE这一高认知负担任务拆解为评估 → 容器化 → 镜像管理 → 清单生成 → 部署验证五步并为每一步配齐了可直接复用的仓库资产assets/Dockerfile assets/index.js assets/package.json可直接构建运行的 Node.js 示例含/healthz与/readyz双健康端点assets/deployment.yaml生产加固版 Deployment ClusterIP Service 全量清单references/go-example.mdGo 多阶段 distroless Dockerfile 与基线 Deployment 模板。实际落地时建议按评估驱动决策的顺序推进评估结论决定基础镜像与探针设计探针设计与镜像用户 ID 决定清单中的安全上下文与健康检查配置清单经apply_k8s_manifest或kubectl apply落地后用get_k8s_rollout_status/kubectl rollout status确认发布完成最后逐条核对黄金路径五要素非 root lockfile、资源 requests、双探针、≥2 副本 PDB、Workload Identity即可完成一次符合生产标准、可审计、可复现的 GKE 应用上线。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考