手册

使用 Kubernetes 原生声明式 API 预置和管理多云基础设施。

→使用 Crossplane。安装云提供商 CRD（例如，provider-aws）。使用 Composition 和 CompositeResourceDefinition (XRD) 定义平台抽象。

原因: 将应用和基础设施管理统一到单个控制平面和 GitOps 工作流下，使开发人员无需关心特定提供商的细节。

以声明式方式管理跨不同提供商的多个 Kubernetes 集群的生命周期（创建、升级、删除）。

→使用相关的基础设施提供商（例如，AWS 的 CAPA，Azure 的 CAPZ）实现 Cluster API (CAPI)。在管理集群中将集群定义为 Kubernetes 资源。

原因: 将集群生命周期视为代码，为集群本身启用 GitOps。CAPI MachineHealthChecks 提供自动节点修复。

参考↗

在共享 Kubernetes 平台上为租户工作负载提供强隔离。

→结合专用节点池（计算）、NetworkPolicies（网络）、RBAC（API）、ResourceQuotas（资源）和 Pod Security Standards（安全）。考虑使用虚拟集群 (vCluster) 进行控制平面隔离。

原因: 需要纵深防御策略。没有单一功能可以提供完全隔离。每个层都解决了租户的不同方面。

从中心点管理大量下游集群的配置和工作负载。

→指定一个“中心”集群来托管平台控制平面工具（ArgoCD、Flux、Crossplane、策略引擎）。“辐射”集群运行工作负载，并从中心集群进行管理。

原因: 集中管理、策略实施和可观测性，简化多集群操作并确保一致性。

为开发团队提供隔离的、类似集群管理员的环境，而无需物理集群的开销。

→使用 vCluster。每个 vCluster 在宿主集群命名空间内作为 Pod 运行一个独立的 K8s 控制平面，共享宿主工作节点。

原因: 以低于完整集群的成本提供强大的 API 级别隔离。vCluster 同步器在宿主集群上实例化必要的资源。

参考↗

确保具有低 RPO/RTO 的有状态工作负载的灾难恢复。

→使用支持同步或异步跨区域/跨集群数据复制的 CSI 驱动程序（例如，Rook-Ceph、Portworx）。

原因: 复制对于区域故障中的数据可用性至关重要。本地快照或高性能层无法解决跨站点灾难恢复问题。

通过在故障域之间分布副本，提高应用程序可用性。

→在工作负载规范中使用 Pod Topology Spread Constraints。定义 `topologyKey`（例如，`topology.kubernetes.io/zone`）和 `whenUnsatisfiable: ScheduleAnyway` 或 `DoNotSchedule`。

原因: 防止服务的所有副本调度到单个区域或单个节点上，从而减轻局部基础设施故障的影响。

为具有分层组织结构的团队管理策略和 RBAC。

→实现分层命名空间控制器 (HNC)。创建父子命名空间关系以传播 RBAC、NetworkPolicies 和 ResourceQuotas。

原因: HNC 通过允许平台管理员在团队/组织级别（父命名空间）设置策略来简化管理，这些策略会自动被所有子命名空间继承。

实现基于度量分析和回滚的先进自动化部署策略，如金丝雀或蓝绿部署。

→使用 Argo Rollouts。定义一个 Rollout 资源，其中包含策略（例如，金丝雀）以及流量路由配置（用于服务网格）和一个引用 Prometheus 等指标提供商的 AnalysisTemplate。

原因: 将部署与应用程序逻辑解耦。自动化流量转移和分析，安全地提升发布版本并在失败时自动回滚，从而降低部署风险。

参考↗

在 GitOps 工作流中管理密钥，而不在 Git 中存储明文凭据。

→使用 Sealed Secrets（为特定集群加密密钥）或 External Secrets Operator（从 Vault、AWS/GCP/Azure 密钥管理器同步）。只将加密的密钥或引用资源提交到 Git。

原因: 将敏感数据保存在 Git 之外，同时允许将密钥作为 GitOps 工作流的一部分进行声明式管理，维护单一事实来源。

为多个集群、环境或微服务自动化 ArgoCD Applications 的创建和管理。

→使用 ApplicationSet。为 Application 定义一个模板，并使用生成器（例如，cluster、git、matrix）根据集群列表、Git 目录或其他来源动态创建 Application。

原因: 消除了手动创建 Application 的麻烦，从而能够从单个定义扩展管理数百个应用程序或集群。

为开发人员提供临时预览环境，以测试拉取请求中的更改。

→将 ArgoCD ApplicationSet 与 Pull Request 生成器结合使用。当 PR 打开时，它会自动创建一个 Application；当 PR 关闭/合并时，则删除该 Application。

原因: 使开发人员能够在合并之前在实时环境中验证更改，从而提高代码质量并减少集成问题，而无需手动管理环境。

使用 ArgoCD 以结构化方式管理大量复杂的应用程序和平台组件。

→实现 App-of-Apps 模式。一个根 Application 管理其他子 Application，这些子 Application 又可以管理其他 Application，从而创建分层结构。

原因: 为引导集群或环境提供单一入口点，同时允许对单个应用程序集进行模块化、基于团队的管理。

确保资源按正确顺序部署（例如，CRD 在 CR 之前，基础设施在应用程序之前）。

→在 ArgoCD 中，使用 Sync Waves 和资源健康检查。在 Flux 中，在 Kustomization 或 HelmRelease 资源中使用 `dependsOn`。

原因: 声明式系统默认并行应用资源。需要明确的排序机制来管理资源之间的依赖关系。

使用 Flux 实现完整的 GitOps 流水线。

→结合 Flux 控制器：Source Controller（用于 Git/Helm/OCI 源）、Kustomize Controller（用于应用 manifests）和 Helm Controller（用于 HelmReleases）。使用 Notification Controller 进行警报。

原因: Flux 是一组可组合的专用控制器。理解每个控制器的作用是构建和故障排除基于 Flux 的持续交付的关键。

参考↗

确保实时集群状态持续与 Git 中期望的状态匹配，并还原任何手动更改。

→将 ArgoCD Application 配置为 `syncPolicy.automated.selfHeal: true`。ArgoCD 将检测漂移并自动同步以还原未经授权的更改。

原因: 自我修复是 GitOps 的核心原则，它强制将 Git 作为单一事实来源，并防止配置漂移，这对于合规性和稳定性至关重要。

通过适当的审计和审批门将应用程序版本跨环境（开发 -> 预发 -> 生产）提升。

→在 Git 中为每个环境使用单独的目录或分支。通过创建拉取请求（例如，从预发到生产分支/目录）来提升更改。强制执行 PR 审查。

原因: 利用 Git 进行审计追踪和审批。PR 过程成为正式的提升门，确保更改在达到生产环境之前经过审查。

在共享 ArgoCD 实例中实现多租户，将团队限制在其自己的资源范围内。

→为每个团队创建 ArgoCD Project。配置项目以限制源 Git 仓库、目标集群/命名空间以及允许的资源类型。与 SSO 集成并将组映射到项目角色。

原因: Project 是 ArgoCD 中多租户隔离和 RBAC 的主要机制，可实现安全的自助服务应用程序部署。

设计一个自助服务 API，使开发人员无需了解云特定知识即可预置基础设施。

→使用 CompositeResourceDefinition (XRD) 定义高级 API。通过 Composition 实现该 API，将高级字段映射到底层托管资源。开发人员与简单的 Composite Resource Claim (XRC) 交互。

原因: 这种三层模型（Claim -> Composition -> Managed Resource）将面向用户的 API 与实现分离，提供清晰的抽象并实现平台治理。

使开发人员能够以声明式方式引导新项目、微服务或基础设施，并符合组织标准。

→创建 Backstage Software Template。模板定义输入参数（表单 UI）和一系列脚手架操作（例如，获取骨架、创建 Git 仓库、在目录中注册）。

原因: 自动化“黄金路径”工作流，减少开发人员的认知负担，确保一致性，并将项目设置时间从几分钟缩短到几秒钟。

参考↗

创建一个单一的、集中的地方，用于发现组织内的所有软件、服务、API 及其所有权。

→实现 Backstage Software Catalog。从 Git 仓库摄取 `catalog-info.yaml` 实体描述符，以构建可搜索的软件组件及其关系图。

原因: 目录是 IDP 的核心，提供可发现性，并为 TechDocs、API 文档和 CI/CD 状态可见性等其他功能奠定基础。

当 Custom Resource 被删除时，Kubernetes Operator 需要清理外部资源（例如，云存储、DNS 记录）。

→使用 finalizers。在控制器中，创建 CR 时为其添加 finalizer。在协调循环中，如果设置了 `deletionTimestamp`，则执行清理逻辑，然后移除 finalizer。

原因: Finalizers 阻止 Kubernetes 删除资源，直到控制器成功完成其清理任务，从而防止外部资源成为孤儿。

为 Kubernetes 工作负载提供安全、短期的云提供商 API 访问，而无需管理静态凭据。

→使用云提供商的工作负载身份解决方案（AWS IRSA、GCP Workload Identity、Azure Workload Identity）。这会将 Kubernetes ServiceAccount 链接到云 IAM 角色，允许 Pod 获取临时凭据。

原因: 消除了长期静态凭据的风险。这是为 Pod 授予云权限最安全的模式。

将自定义资源协调的状态和进度反馈给用户和自动化工具。

→在 CRD 定义中启用 status 子资源。控制器应使用条件（例如，`Type: Ready`，`Status: True`）和观察到的状态更新 status。

原因: 将期望状态 (spec) 与观察到的状态 (status) 分离。为客户端提供了一种标准的、可观察的机制，以了解资源的健康状况和就绪状态。

在不破坏现有客户端或用户的情况下，演进平台 API (CRD)。

→遵循 Kubernetes API 版本控制约定（v1alpha1 -> v1beta1 -> v1）。当引入重大更改时，创建新版本并实现转换 Webhook 以在存储版本和提供版本之间进行转换。

原因: 转换 Webhook 允许 API 服务器同时提供多个版本的资源，同时保持单一存储版本，从而实现优雅的 API 演进。

根据服务可靠性目标创建可操作的警报，以平衡灵敏度并避免警报疲劳。

→定义 SLO 并计算错误预算。实现多窗口、多燃烧率警报，当错误预算消耗速率威胁到 SLO 时触发。

原因: 基于错误预算燃烧的警报比简单的阈值警报更有意义。它直接将警报与面向用户的影响和 SLO 违规联系起来。

参考↗

实现一个供应商中立的统一流水线，用于收集、处理和导出可观测性信号（traces、metrics、logs）。

→部署 OpenTelemetry Collector。使用接收器（例如，OTLP、Jaeger）、处理器（例如，batch、attributes）和导出器（例如，Prometheus、Loki、Tempo、供应商后端）配置流水线。

原因: 将仪器与可观测性后端解耦，允许平台切换或添加后端而无需重新仪器化应用程序。提供了一个集中处理和丰富数据的点。

参考↗

声明式地配置 Prometheus，以发现和抓取 Kubernetes 工作负载的指标。

→使用 Prometheus Operator。创建 `ServiceMonitor` 或 `PodMonitor` Custom Resources，它们使用标签选择器来定义 Prometheus 应该抓取哪些服务或 Pod。

原因: 提供了一种 Kubernetes 原生方式来管理抓取配置，与应用程序部署和 GitOps 工作流无缝集成。

在事件调查期间，从异常指标（例如，延迟峰值）快速导航到导致该异常的特定请求。

→使用 Prometheus exemplars。在应用程序中添加仪器以将 trace ID 附加到指标观测值。配置 Prometheus 和 Grafana 以显示 exemplars，提供从指标到 Tempo 或 Jaeger 等追踪后端中的 trace 的直接链接。

原因: 通过将“什么”（指标）与“为什么”（trace）直接关联，大大减少 MTTR，消除了手动关联的努力。

为任何面向用户或关键服务的健康状况建立监控基线。

→监控四个“黄金信号”：延迟 (response time)、流量 (requests per second)、错误 (rate of failed requests) 和饱和度 (resource utilization)。

原因: 这四个信号提供了服务健康和用户体验的全面、高层次视图，适用于几乎任何类型的服务。

参考↗

为团队提供对其 Kubernetes 工作负载成本的可见性，以用于成本分摊或成本展示。

→部署 OpenCost 或 Kubecost 等开源工具。这些工具根据资源请求和使用情况，将云成本分配给 Kubernetes 资源（pod、命名空间、标签）。

原因: 将基础设施账单转换为有意义的、以应用程序为中心的成本数据，使团队能够了解并优化其资源消耗。

通过抑制症状性警报，减少大规模中断期间的警报噪音。

→在 Alertmanager 中配置 `inhibit_rules`。例如，如果“ClusterUnreachable”警报已触发，则抑制特定集群的所有警报。

原因: 通过压制作为更高优先级、根本原因警报症状的低优先级警报，防止“警报风暴”，让值班人员专注于真正的问题。

通过受控地注入故障，主动测试平台和应用程序的弹性。

→使用 Chaos Mesh 或 Litmus 等混沌工程工具。定义具有有限爆炸半径（例如，特定命名空间或标签）和基于 SLO 或关键指标的自动化停止条件的实验。

原因: 从被动的事件响应转变为主动发现系统中的弱点，以防止它们导致生产中断。

为 Kubernetes 平台选择一个策略引擎来实施防护措施。

→对于 Kubernetes 原生基于 YAML 的策略，选择 Kyverno；对于更强大、通用策略语言 (Rego)，选择 OPA/Gatekeeper。

原因: Kyverno 对 Kubernetes 工程师的入门门槛较低。OPA/Gatekeeper 更灵活，可以在 Kubernetes 之外使用，但学习曲线更陡峭。

实施平台策略，可以阻止不合规资源、添加默认值或自动创建相关资源。

→使用 Kyverno 等策略引擎。使用 `validate` 规则进行阻止/审计，`mutate` 规则添加默认值（例如，securityContext、labels），以及 `generate` 规则创建资源（例如，默认 NetworkPolicy）。

原因: 不同类型的策略服务于不同的目的。将它们结合起来可以形成一个健壮的、多方面的治理策略，既能强制执行又能帮助用户遵守。

参考↗

为平台上运行的所有 Pod 强制执行基线安全强化。

→通过内置的 Pod Security Admission 控制器使用 Pod Security Standards (PSS)。使用 `pod-security.kubernetes.io/enforce=baseline` 或 `restricted` 标签标记命名空间。

原因: PSS 提供了一种标准化的内置机制，可以防止常见的安全问题，如权限提升和宿主命名空间访问，从而形成基础安全层。

参考↗

确保只有官方 CI/CD 流水线构建的可信容器镜像才能部署到集群中。

→在 CI 中使用 Sigstore/Cosign 实现镜像签名。使用策略引擎（Kyverno、Gatekeeper）作为准入控制器，在允许创建 Pod 之前，根据可信密钥验证镜像签名。

原因: 密码验证提供了关于镜像来源和完整性的强有力保证，防止部署被篡改或未经授权的镜像。

实现零信任安全模型，其中服务到服务的通信通过加密工作负载身份进行认证，而非网络位置。

→使用 SPIFFE/SPIRE 为工作负载颁发短期、可轮换的加密身份 (SVID)。使用服务网格强制执行相互 TLS (mTLS)，该服务网格在每个请求上验证 SVID。

原因: 将安全性从网络边界控制转移到以工作负载为中心的身份，即使对于内部流量也提供强认证，并限制受损节点或 Pod 的爆炸半径。

在网络层面隔离工作负载，强制执行“默认拒绝”姿态，并且只允许必要的通信路径。

→实施 Kubernetes NetworkPolicies。对每个命名空间应用默认拒绝策略，然后添加基于 Pod/命名空间标签允许流量的特定入口/出口策略。

原因: 减少横向移动攻击面。一个 Pod 的受损不会自动授予对集群中所有其他服务的网络访问权限。

为安全和合规性，创建对 Kubernetes API 服务器上执行的所有操作的全面且防篡改的审计追踪。

→在 API 服务器上启用 Kubernetes 审计日志记录。配置审计策略以记录相关事件（例如，所有写入请求）。将审计日志发送到安全、不可变的存储后端或 SIEM。

原因: 审计日志对于事件调查、合规性报告（例如，PCI-DSS、SOC2）以及检测异常 API 活动至关重要。