手册

为平台团队建立核心原则，以确保平台被采用并减少开发者摩擦。

→将内部平台视为产品。将内部开发者视为客户，进行用户研究，收集反馈，并迭代功能以减轻他们的认知负荷。

原因: 这种思维转变将重心从构建基础设施转向交付价值，确保平台解决真实的开发者问题，而不是被绕过（“影子IT”）。

为所有基础设施和应用程序的期望状态建立单一事实来源。

→使用Git仓库作为单一事实来源。部署一个集群内代理（ArgoCD, Flux），运行持续协调循环，将集群状态与Git进行比较。

原因: 这提供了完整的审计跟踪，支持轻松回滚，并通过自动恢复带外更改来防止配置漂移。

参考↗

防止配置漂移，并确保所有环境中部署工件的一致性。

→将基础设施视为不可变的。永远不要修改正在运行的资源。相反，创建新的、版本化的工件（容器镜像、VM镜像）并替换旧的。通过只读容器文件系统（`readOnlyRootFilesystem: true`）强制执行此操作。

原因: 不可变性消除了配置漂移，并使部署可预测和可重复。“替换，而非修复。”

选择安全的GitOps部署模型，特别是在多集群或受限网络环境中。

→实施拉取式模型。一个在集群内部运行的代理（ArgoCD, Flux）从Git拉取清单。避免外部CI系统推送到Kubernetes API的推送式模型。

原因: 拉取式模型更安全，因为它不需要外部暴露Kubernetes API服务器，也不需要在CI中为多个集群管理凭据。

在不过度限制经验丰富团队的情况下，加速开发并确保最佳实践。

→定义“黄金路径”（或铺好的道路）：为常见任务（例如，创建新的微服务）提供预配置、支持良好的模板和工作流。

原因: 黄金路径减轻了80%情况下的认知负荷和决策疲劳，但仍应为具有独特需求的专家团队提供“逃生舱口”。

在共享的Kubernetes平台上提供多租户，并具有适当的隔离级别。

→为了最强的隔离，使用独立的集群。为了在强隔离和效率之间取得平衡，使用虚拟集群（vClusters）。对于基本的、软多租户，使用带有RBAC、NetworkPolicies和ResourceQuotas的命名空间级别隔离。

原因: 选择取决于安全性和“吵闹邻居”风险。虚拟集群提供了控制平面隔离，而无需承担完整物理集群的成本。

定义平台团队与流对齐（产品）团队之间的主要交互模式。

→平台团队应主要以“X即服务”模式运行，提供自助服务工具、API和文档。

原因: 在大规模情况下，平台团队无法与每个团队使用高接触协作模式。即服务模式实现了规模化和开发者自主性。

为分布式系统实施全面的可观测性策略。

→收集并关联三大支柱：Metrics（通过Prometheus获取的数值时间序列数据）、Logs（通过Fluent Bit获取的结构化事件）和Traces（通过OpenTelemetry获取的请求流）。

原因: 任何单一支柱都不足。关联它们（例如，在日志中嵌入trace ID）对于在复杂的微服务架构中快速诊断问题至关重要。

自动在所有Kubernetes集群中强制执行安全和组织策略。

→使用像OPA/Gatekeeper或Kyverno这样的策略引擎，将其集成作为验证/修改准入控制器。将策略存储在Git中并通过GitOps同步。

原因: 这提供了自动化的预防性护栏，使开发者在其CI/CD流水线中获得快速反馈，而非缓慢的手动审查关卡。

根据团队技能和策略复杂性为Kubernetes选择策略引擎。

→对于可以用熟悉的Kubernetes风格YAML表达的策略，使用Kyverno。对于需要更强大、专用语言（Rego）和外部数据集成的复杂策略，使用OPA/Gatekeeper。

原因: Kyverno对于Kubernetes实践者来说学习曲线较低。OPA/Rego更强大，但需要学习一门新语言。

确保部署到生产环境的容器镜像的完整性和真实性。

→在CI流水线中使用Sigstore/Cosign实现镜像签名。使用策略控制器（Kyverno, Gatekeeper）创建准入策略，在允许创建Pod之前验证镜像签名。

原因: 这确保了只有由受信任的CI流水线构建且未经篡改的镜像才能在集群中运行，从而防止未经授权的代码执行。

参考↗

使用零信任方法保护集群内所有服务到服务的通信。

→部署服务网格（例如，Istio, Linkerd），并为所有网格内流量启用严格的相互TLS (mTLS)。

原因: mTLS既提供了传输中的加密，又为客户端和服务器提供了强大的、可密码验证的身份，从而防止了集群内部的欺骗和中间人攻击。

对集群中运行的所有工作负载强制执行安全最佳实践。

→启用内置的Pod安全准入控制器。配置命名空间，对工作负载强制执行`restricted`配置文件，对平台组件强制执行`baseline`配置文件。

原因: `restricted`配置文件强制执行关键安全强化（例如，以非root用户运行，放弃所有功能，禁止权限升级），是一项基础性安全措施。

参考↗

在操作系统层面检测正在运行容器内的异常或恶意行为。

→部署使用eBPF的运行时安全工具，例如Falco或Tetragon。定义规则以检测可疑的系统调用、文件访问和进程执行。

原因: 传统的安全工具无法感知容器内部的活动。eBPF提供了对内核级事件的深度、低开销可见性，从而能够检测其他工具遗漏的威胁。

构建可扩展且弹性的可观测性数据流水线。

→使用OpenTelemetry (OTel) Collector。链接处理器以转换数据（例如，`attributes`处理器用于移除PII，`batch`处理器用于提高效率）。在流水线早期使用`memory_limiter`处理器以防止OOM。

原因: Collector将仪器化与后端解耦，并提供了一种灵活的、供应商中立的方式来在导出前处理、过滤和路由遥测数据。

参考↗

将新应用程序版本部署到生产环境，同时最大程度地降低风险和影响范围。

→使用Flagger或Argo Rollouts等工具实现自动化金丝雀部署。逐渐将流量切换到新版本，同时自动分析关键指标（成功率、延迟）。在违反SLO时自动回滚。

原因: 自动化金丝雀分析通过真实的生产流量验证新版本，比简单的滚动更新提供了更高的安全性。

部署新版本的应用程序，并能够执行即时回滚。

→维护两个相同的生产环境（“蓝”和“绿”）。将新版本部署到非活动的（绿）环境。验证后，切换负载均衡器，将所有流量路由到绿环境。保持蓝环境空闲以进行即时回滚。

原因: 这种模式提供了零停机部署和最快的可能回滚，但通常需要两倍的基础设施资源。

在GitOps工作流中以声明方式管理秘密，而不在Git中存储明文凭证。

→使用专用的秘密操作器。要么在提交前加密秘密（Bitnami Sealed Secrets, Mozilla SOPS），要么从外部保险库引用秘密（External Secrets Operator）。

原因: 这在将敏感数据排除在Git之外的同时，允许秘密与应用程序配置一起以声明方式管理，从而维护了GitOps工作流。

在多个环境（开发、测试、生产）中管理应用程序配置，而无需重复。

→使用像Kustomize这样的工具，采用基础-叠加结构，或者使用带有环境特定值文件的Helm。通过更新目标环境的叠加/值文件中的镜像标签或配置来推广更改，通常通过拉取请求。

原因: 这种“不要重复自己”（DRY）方法可以防止环境之间的配置漂移，并使差异变得明确和可审计。

在大规模、动态的集群机队中管理同一应用程序的部署。

→使用带有集群生成器的ArgoCD ApplicationSets。生成器根据标签动态发现集群，并使用模板为每个匹配的集群生成一个Application资源。

原因: 这自动化了新集群的应用程序引导，并大规模管理配置，避免了手动创建数百个Application资源的需要。

参考↗

实现持续部署到生产环境，同时控制向用户发布新功能。

→集成一个功能开关系统。在禁用功能开关的情况下将新代码部署到生产环境。通过为特定用户群体启用开关来发布功能，从而将部署与发布解耦。

原因: 这将技术风险（部署）与业务风险（发布）分离，实现了高速部署、A/B测试和“紧急停止开关”功能。

一旦新的容器镜像被推送到注册表，就自动部署它们。

→使用FluxCD的镜像自动化组件。`ImageRepository`扫描注册表，`ImagePolicy`选择新的标签（例如，基于semver），`ImageUpdateAutomation`将标签更改提交回Git仓库。

原因: 这为全自动GitOps工作流关闭了从CI（镜像推送）到CD（部署）的循环，而无需CI系统访问集群。

为开发者提供统一的声明式API，以自助服务方式供应Kubernetes和云基础设施资源（例如，数据库、消息队列）。

→使用Crossplane。安装云提供商插件，并为开发者定义高级CompositeResourceDefinitions (XRDs)（例如，`kind: PostgresSQLInstance`）。使用Compositions将这些映射到底层云资源。

原因: 这将Kubernetes控制平面扩展到管理外部资源，允许开发者为所有应用程序依赖项使用熟悉的`kubectl`和GitOps工作流，并受平台定义的模式管理。

参考↗

以Kubernetes原生方式自动化复杂的、有状态的应用程序生命周期管理（例如，安装、升级、备份、故障恢复）。

→构建一个Kubernetes Operator。为您的应用程序定义一个Custom Resource Definition (CRD)，并实现一个运行协调循环来管理应用程序状态的自定义控制器。

原因: Operator将人类的运维知识编码到软件中，实现强大的自动化，并将复杂的应用程序视为一等Kubernetes资源。

确保操作器在其关联的Custom Resource从Kubernetes中删除之前，能够执行外部资源（例如，云负载均衡器）的清理工作。

→向Custom Resource元数据添加一个finalizer。当用户删除CR时，它会进入`Terminating`状态。操作器的协调逻辑会检测到这一点，执行清理，然后移除finalizer，允许K8s API服务器完成删除。

原因: 如果没有finalizer，CR可能会在操作器有时间清理外部资源之前被删除，导致出现孤立、昂贵的基础设施。

使用声明式、GitOps友好的工具管理Kubernetes集群本身的生命周期。

→使用Cluster API (CAPI)。管理集群运行CAPI控制器，协调`Cluster`和`Machine`资源，以在各种云提供商上供应和配置工作负载集群。

原因: CAPI将集群管理转化为声明式的Kubernetes工作流，实现了整个集群的一致、自动化和版本控制的供应和升级。

参考↗

演进平台API（定义为CRD），而不会破坏现有用户或需要“大爆炸”式迁移。

→在CRD定义中支持多个版本（例如，v1beta1, v1）。实现一个转换Webhook，用于在版本之间进行转换，允许新客户端使用v1，而旧客户端继续对相同的存储对象使用v1beta1。

原因: 转换Webhook是Kubernetes原生机制，用于实现非破坏性API演进，这对于稳定的平台产品至关重要。

通过集中工具、文档和软件资产，减少开发者的认知负荷并提高可发现性。

→使用CNCF Backstage等框架实现内部开发者门户 (IDP)。填充其软件目录，提供用于构建新服务的软件模板，并集成TechDocs以实现“代码即文档”。

原因: IDP充当开发者的“单一管理平台”，提供黄金路径和自助服务功能，抽象平台复杂性，加速入职和开发。

参考↗

提供组织中所有软件的单一、可靠清单，包括所有权、依赖关系和运行状态。

→实现一个软件目录（例如，Backstage软件目录），通过Git仓库中的`catalog-info.yaml`文件填充。这创建了一个集中、可搜索的服务、库、API等注册表。

原因: 目录解决了可发现性（“存在哪些服务？”）和所有权（“我应该和谁讨论这项服务？”）的问题，这对于扩展微服务架构至关重要。

使开发者能够在几分钟内创建符合组织标准的新型生产就绪服务。

→使用像Backstage软件模板这样的脚手架工具。定义模板，生成一个具有标准项目结构、CI/CD流水线配置、可观测性仪表板和`catalog-info.yaml`的新Git仓库。

原因: 模板将最佳实践编码化，并为开发者提供“铺好的道路”，大大减少了首次提交的时间，并确保新服务在创建时内置了安全性、可观测性和合规性。

确保技术文档是最新的、有版本控制的，并与它所描述的软件共同存放。

→采用“代码即文档”的方法。将文档存储在服务Git仓库的Markdown文件中。使用Backstage TechDocs等工具在IDP中自动构建和渲染这些文档。

原因: 这种模型将文档视为代码——可以在拉取请求中进行审查，并与它所描述的功能一起进行版本控制，从而防止文档过时或失效。

衡量平台的有效性及其对软件交付性能的影响。

→跟踪DORA的四个指标：部署频率（速度）、变更前置时间（速度）、变更失败率（稳定性）和恢复服务时间（MTTR，稳定性）。

原因: DORA指标是行业标准、以结果为导向的衡量标准，已被证明与组织绩效相关。它们提供了速度和稳定性的平衡视角。

参考↗

为使用共享Kubernetes平台的团队提供准确、细致的成本可见性。

→部署像OpenCost或Kubecost这样的FinOps工具。根据工作负载随时间的实际资源消耗来分配成本。按比例分配共享集群成本（例如，系统组件、节点开销）。

原因: 准确的费用分摊/展示促进了问责制，并鼓励团队优化资源使用。否则，共享平台成本将不透明且难以管理。

衡量平台是否真正提供价值并被开发团队使用。

→跟踪关键平台功能的采用率，特别是黄金路径模板和共享CI/CD流水线。辅以开发者满意度调查（NPS式）。

原因: 可选的、有主见的平台功能的高采用率是一个强烈的信号，表明平台正在解决实际问题。低采用率则表明与开发者需求不匹配。

评估平台的当前状态并制定改进路线图。

→使用平台成熟度模型，从多个维度评估能力：例如，自助服务、可观测性、安全性、可靠性和治理。定义从临时/手动到完全自动化和优化的级别。

原因: 成熟度模型提供了一个结构化的自我评估框架，有助于识别薄弱环节，并使团队在平台演进的战略愿景上保持一致。