Google ACE: 容器、应用托管和无服务器平台 — 学习指南
属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.
概述
Google Cloud 提供了一系列用于运行容器和应用的平台，从完全托管的无服务器平台到可配置的 Kubernetes 集群。选择和运维合适的平台需要深入理解控制平面、扩缩模型、发布机制、网络和安全。本节整合了 Google Kubernetes Engine (GKE)、Artifact Registry、Cloud Run、App Engine 和 Cloud Functions 的运维指南，以及关于密钥、安全发布和诊断的最佳实践模式。
Kubernetes Engine：集群、工作负载和网络
GKE 集群提供了一个托管的 Kubernetes 控制平面，以及由您来确定规模和保障安全的节点池。若要最小化运维开销并采用预设的最佳实践默认值，请选择 Autopilot 模式；若需要对节点、网络和附加组件进行精细化控制，请选择 Standard 模式。使用发布渠道和节点自动升级来实现可预测的安全升级；启用节点自动修复功能。优先选择 Container-Optimized OS 以获得强化的节点，除非特定软件包需要 Ubuntu。
节点池和调度
- 按工作负载类别（例如，通用、GPU、Spot）分离节点池，并使用污点/容忍 (taints/tolerations) 来引导 Pod 的调度。
- 启用集群自动扩缩器，并为每个节点池配置 min/max。请注意，如果资源请求超出了可用节点规格，PodDisruptionBudgets 和资源请求可能会阻止缩容或导致 Pod 处于 pending 状态。
- Spot/抢占式节点可降低成本，但会引入被驱逐的风险；可结合 Deployment 的峰值预算 (surge budgets) 和 Pod 拓扑约束来增强弹性。
命名空间和多租户
- 使用命名空间 (namespaces) 来划分配额、策略和 RBAC。应用 NetworkPolicies 来限制东西向流量。在命名空间范围内强制执行 Pod 安全标准，以避免特权工作负载。
工作负载
- Deployment 通过滚动更新、峰值/不可用预算以及快速回滚来管理无状态的 Pod。使用就绪探针 (readiness probes) 来控制流量准入，使用存活/启动探针 (liveness/startup probes) 来实现自动修复。配置错误的就绪探针可能导致流量黑洞；请在生产环境部署前进行测试。
- StatefulSet 为数据库和基于法定数量的系统提供稳定的身份标识和有序的伸缩。使用无头服务 (headless Service) 和支持动态置备的 StorageClass；规划好可用区级 PV 的局部性。
- DaemonSet 在每个节点上调度一个 Pod（例如，日志/监控代理）。它们会遵循自动扩缩和节点排空 (drain) 事件，是实现节点级遥测的理想选择。
Service 和 Ingress
- ClusterIP 提供集群内部的 DNS 和负载均衡。NodePort 主要用于故障排查。LoadBalancer 会置备一个 Google Cloud 外部或内部 TCP/UDP 负载均衡器；对私有服务请使用内部类型。
- GKE Ingress 可配置全局 HTTP(S) 负载均衡，并带有托管证书、URL 映射和 Cloud Armor。对于现代流量管理，优先选择容器原生负载均衡 (NEG)，以实现对单个 Pod 的健康检查和更快的收敛速度。确保就绪端点能反映应用的真实健康状况；否则后端会变为不健康状态，导致 502 错误。
自动扩缩
- Horizontal Pod Autoscaler (HPA) 根据 CPU 等指标或通过 Cloud Monitoring 提供的自定义指标来扩缩副本数量；请确保 Metrics Server 处于健康状态。
- Vertical Pod Autoscaler (VPA) 可以合理调整资源请求的大小；为避免与 HPA 冲突，请对 HPA 管理的工作负载将 VPA 用于“推荐”模式，或谨慎使用 HPA+VPA 兼容模式。
- 集群自动扩缩器通过增删节点来容纳 Pod。如果 Pod 请求的资源超过了任何可用节点规格，它们将永远无法被调度；请将请求/限制 (requests/limits) 与节点池的规格对齐。
简短示例：
回滚一个损坏的发布版本：
undefined
快速检查另一个上下文：
undefined
工件管理、供应链安全和安全发布
Artifact Registry 按区域托管容器镜像，并支持 VPC Service Controls。为不同环境采用独立的仓库（或前缀）并强制使用不可变标签；通过摘要 (digest) 进行部署以消除歧义。集成 Cloud Build 或您的 CI 工具，在构建和推送镜像时附带来源元数据。
漏洞管理
- 启用 Artifact Analysis 来扫描镜像中的操作系统和语言包 CVE。当发现高危漏洞时，中断构建或阻止晋级。结合使用 Binary Authorization，要求在准入 GKE 之前必须具有签名/证明（例如，通过漏洞策略检查、具备 SLSA 来源证明）。
镜像晋级
- 通过将镜像摘要从开发仓库复制到预发/生产仓库，或在晋级专用仓库中重新打标签的方式来晋级镜像；避免使用可变的 “latest” 标签。使用 Cloud Build 触发器，根据测试和扫描结果来自动化此过程。
密钥和配置
- 优先使用具有最小权限访问的 Secret Manager。在 GKE 上，将 Secret Manager CSI 驱动与 Workload Identity 结合使用，这样节点就永远不会接触到长期有效的密钥。对于 KRM 配置，将 ConfigMap（非敏感）与 Secret（敏感）分开，并以只读方式挂载。
- 对于无服务器平台，通过直接的 Secret Manager 绑定来挂载密钥；除非绝对必要，否则避免将密钥嵌入环境变量中。
回滚和发布模式
- Kubernetes：使用滚动更新，设置 maxUnavailable=0 实现零停机，并根据容量调整 maxSurge；通过在同一个 Service 后面部署两个 Deployment 来实现金丝雀发布，或使用服务网格 (Service mesh) 进行按百分比的渐进式发布。使用 PodDisruptionBudgets 和 minReadySeconds 保护关键工作负载。
- Cloud Run 和 App Engine：使用修订版本/版本和流量拆分来实现金丝雀发布和蓝绿部署。保持先前的修订版本处于就绪状态，以减少回滚延迟。
- 故障模式：可变标签漂移、扫描时间间隙以及错误的就绪探针配置是导致服务中断的常见原因。应使用镜像摘要、部署前检查和综合健康探测来防范。
无服务器应用平台
Cloud Run 提供容器原生、请求驱动的计算，具有自动缩容至零和按请求强制执行身份验证的特性。
Cloud Run 服务和作业
- 服务处理 HTTP；并发性控制每个实例的并发请求数（调整以平衡延迟与效率）。作业处理非 HTTP 的批处理/定时任务，并且可以并行化。
- 修订版本是不可变的快照。流量拆分可实现按百分比的金丝雀部署。设置最小实例数以减少冷启动；如果需要后台工作，请在空闲期间使用 CPU 分配。
- 身份：为每个服务/修订版本分配一个具有最小权限的专用服务账号。通过 IAM (Cloud Run Invoker) 限制调用，或在必要时设为公开。对于最终用户身份验证，请使用签名的 IAP 令牌或 Cloud Run 与 Identity Platform 的内置身份验证。
网络
- 使用无服务器 VPC 连接器访问私有 VPC 资源。选择出站流量策略：所有流量通过连接器，或仅限私有 RFC1918 范围。注意连接器的吞吐量配额；扩展连接器的大小并使其与服务在同一区域。对于仅有私有 IP 的资源需要访问出站互联网，请与 Cloud NAT 结合使用。
- Private Service Connect 可以私密地使用生产者服务或暴露内部端点。对于通过外部 HTTP(S) 的入口流量，请使用带有无服务器 NEG 的 Cloud Load Balancing。
App Engine 提供两种环境：
- 标准环境 (Standard)
- 沙盒化，可快速扩缩，支持自动、基本或手动扩缩。使用 min_idle_instances 的自动扩缩可提供预热容量。冷启动快，部署模型简单；操作系统级别的自定义受限，且运行时集合固定。
- 柔性环境 (Flexible)
- 在 Compute Engine 虚拟机上运行 Docker，对系统库和网络有更多控制权。实例生命周期较慢，基线成本较高；适用于需要自定义运行时或原生库的场景。
- 服务和版本
- 按版本拆分流量（随机、Cookie 或 IP）。每个服务都可以独立扩缩。使用渐进式发布并保留前一个版本以便即时回滚。
Cloud Functions 提供事件驱动的单一用途函数。
- 触发器：Pub/Sub、Cloud Storage、HTTP、用于多种来源的 Eventarc。使处理程序具有幂等性；某些触发器在失败时会重试，导致重复处理。
- 运行时配置：环境变量、Secret Manager 绑定、最大实例数、内存/CPU。控制 HTTP 函数的并发以平衡延迟和成本。
- 常见陷阱：无限制的并发或非幂等的副作用会导致数据重复；确保为 Pub/Sub 设置 DLQ；设置适当的超时。
平台选择、网络与运维所有权
根据所需的控制权、扩缩特性、可移植性需求和运维预算来选择平台。
控制权与开销的权衡
- 最高控制权：GKE Standard（节点操作系统、网络、安全附加组件），但有相应的运维开销。
- 均衡型：GKE Autopilot（无节点管理，带有固定主张的安全配置）。
- 最低开销：Cloud Run、App Engine、Cloud Functions（无节点，托管式扩缩），但受限于运行时和请求模型。
扩缩与工作负载适配
- 突发性请求工作负载：Cloud Run/App Engine Standard 表现出色；Functions 适用于事件驱动的处理程序。
- 有状态或自定义网络：使用 GKE 及其 StatefulSets 和 CNI 功能。
- 可移植性：GKE/Cloud Run 上的容器；由于 FaaS 模型，Functions 的可移植性较差。
无服务器网络、出站流量与私有服务
- 使用 VPC 连接器进行私有访问；监控连接器利用率以避免限流。仅在必要时将出站流量设置为“全部”；否则应限制在私有地址范围以降低成本和风险。
- 对于私有入站流量，可考虑使用内部 HTTP(S) 负载均衡搭配无服务器 NEG 或使用 Private Service Connect。
- 为控制数据渗漏，可在支持的情况下搭配使用 VPC Service Controls，并通过防火墙和 Cloud NAT 限制出站路由。
诊断与运维所有权
- 标准化使用 Cloud Logging，采用结构化日志 (JSON) 并在各服务间使用跟踪/跨度 ID 进行关联。使用 Cloud Monitoring 仪表盘、正常运行时间检查、SLO 和提醒政策。
- 对于 GKE：启用 Cloud Ops for GKE，通过 Prometheus 或 Cloud Monitoring 抓取应用指标，并使用 DaemonSets 进行节点级遥测。
- 对于无服务器：利用内置的请求日志、Error Reporting、Trace 和 Profiler。针对延迟、错误率和饱和度（并发、实例 CPU）设置各服务的 SLO 和提醒。
- 所有权模型：明确由谁负责运行时参数（扩缩、并发）、IAM 和发布流水线。定期测试回滚和灾难场景。
实际问题场景
Acme Retail 计划在实现内部服务现代化的同时，对外暴露一个新的结账 API。需求包括：一个支持金丝雀部署的公共低延迟 API、对 VPC 内的内部库存数据库的私有访问、供应链强制执行，以及运维开销最小的清晰回滚机制。
- 为公共 API 选择 Cloud Run，为内部库存服务选择 GKE Autopilot。
- 理由：Cloud Run 为无状态 HTTP 服务最小化了运维开销，并支持版本和流量拆分；GKE Autopilot 为有状态/内部服务提供了 Kubernetes 功能，且无需管理节点。
- 在 Artifact Registry 中构建、扫描和存储带有来源信息的镜像。
- 理由：Cloud Build 生成容器镜像；Artifact Analysis 扫描 CVE。存储摘要和来源信息使得 Binary Authorization 能够强制执行策略，确保只有经过扫描和签名的镜像才能运行。
- 强制执行准入策略。
- 理由：在 GKE 集群上启用 Binary Authorization，要求提供签名和策略证明。对于 Cloud Run，配置部署自动化流程，以漏洞策略通过作为升级的门控条件。
- 使用 Serverless VPC connector 和 Cloud NAT 配置网络。
- 理由：Cloud Run API 必须能私下访问库存服务和 Cloud SQL。VPC 连接器允许私有的 RFC1918 出站流量；Cloud NAT 为私有资源在没有外部 IP 的情况下下载依赖项提供出站互联网访问。请将连接器和服务保持在同一区域，并合理调整其吞吐量。
- 保护身份和权限。
- 理由：为 Cloud Run 服务分配一个专用服务账号，并遵循最小权限原则（例如，授予 Cloud SQL Client 角色，以及在需要时调用内部端点的权限）。对于 GKE，使用 Workload Identity，使 Pod 可以在没有节点级凭据的情况下模拟服务账号。
- 实现安全发布与回滚。
- 理由：将 API 部署为新的 Cloud Run 版本，并拆分 5% 的流量进行金丝雀测试。监控延迟、错误率和饱和度；然后逐步将流量提升至 100%，或通过将流量恢复到先前版本来即时回滚。在 GKE 中，使用带有就绪探针的 Deployment 滚动更新，并在同一个 Service 后面部署一个小的金丝雀 Deployment，在全面发布前进行验证。
- 配置可观测性与 SLO。
- 理由：从两个平台向 Cloud Logging 发送带有跟踪 ID 的结构化 JSON 日志。基于 p95 延迟和 5xx 错误率创建 SLO，并附加提醒政策。使用 Error Reporting 和 Trace 进行根本原因分析。对于 GKE，部署一个 DaemonSet 用于收集节点指标，并启用 Cloud Ops for GKE。
- 验证故障模式与容量。
- 理由：进行负载测试以验证 VPC 连接器吞吐量、Cloud Run 并发能力和 GKE HPA 的行为。确认就绪探针的准确性以防止流量黑洞。测试 Binary Authorization 的拒绝路径和通过摘要进行镜像回滚，以确保在供应链强制执行下的可恢复性。
此方法提供了一个运维成本低、安全的公共 API，受控的内部服务，私有网络，可强制执行的供应链安全以及快速回滚能力，完全符合 Google Cloud 的运维最佳实践。
← Compute Engine 和虚拟机操作 · 所有领域 · VPC 网络、连接性和流量管理 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →