我们之前描述了常用 IDP 的组件以及如何加快平台构建流程。现在让我们创建您的 GitOps 平台
译自 Build an Open Source Kubernetes GitOps Platform, Part 2，作者 John Dietz。
贵公司内部开发者平台 (IDP) 是您最宝贵的资产之一。这个复杂的由基础设施和软件构成的架构，是您构建、托管、交付和运行公司软件的方式。在本教程的第一部分中，我们描述了常见 IDP 的组件以及如何加快平台构建流程。现在让我们逐步创建您的新平台。
您的平台将需要一些机器人帐户来管理您的云资源、git 设置和 (域名服务) DNS 记录。您需要为每个功能创建新的帐户并为每个机器人生成 API 密钥。当您在下一步开始引导集群时，这些密钥将支持您的应用程序配置。我们建议使用电子邮件分发列表（例如 platformteam@domain.com）来管理接收系统通知的团队。
您的管理集群是在大多数以 Kubernetes 为中心的云架构中都能找到的集中式集群。管理您的 GitOps、基础设施即代码 (IaC)、CI/CD、密钥、用户和安全的工具通常是管理集群的理想选择。
无论使用哪种云或 IaC 工具，目标都是相同的。使用您已创建的 IaC（步骤 4），创建一个状态存储、网络、防火墙和Kubernetes集群。此步骤的结果是成功连接到您新的空管理集群。
平台工程主管大厨，闪耀时刻到了，只需添加您即时 GitOps 魔法的秘密一匙，然后等待 Kubernetes 烤箱发出提示音，您的新平台就完成了。
什么是即时 GitOps 魔法？
还记得我们让您构建的gitops存储库吗？（我们第一篇文章中的步骤 5）。无论您选择哪种工具或服务，您的管理集群都会使用它自己专用的目录。集群目录包含一组文件，用于表示进入新集群的每个应用程序，并指定安装顺序。
如果您选择将 Argo 或 Flux 安装到新集群，只需将任一工具指向该魔法目录即可。您的 GitOps 引擎会自动按照所需的精确顺序安装所有应用程序，从而无缝解决所有“先有鸡还是先有蛋”的依赖关系。
几分钟内，所有应用程序都将安装完毕，新的 DNS 记录将为您的新平台服务进行传播。单点登录已通过所有应用程序配置预先配置。您的基础设施现在由您的 IaC 和 GitOps期望状态驱动。平台上的每一个密钥都位于单一权威的真相来源，所有这些都在平台上永久循环地持续同步。🎉
但是如何创建 GitOps 文件？
大多数公司都需要花费大量时间和投资才能找到合适的的一组文件。这就是 GitOps 商店中许多平台工程纪律发生的地方。您可以选择自己设计、编写、测试和构建所有这些内容。或者，您可以利用一些现有的令人惊叹的开源工作。
在 Konstruct，我们认为您应该尝试我们的GitOps 文件，并从此开始。Kubefirst 生成一个完全填充的gitops存储库，该存储库会自动为您提供我们在上一篇文章中描述的流行开源技术栈。
您可以保留gitops存储库，并将我们的任何观点更改为您的观点。对您的新gitops存储库进行拉取请求更改，它将在为您创建的管理集群中更新。如果您破坏了某些东西，只需回滚 git 提交并重试即可，没什么大不了的。如果您选择独自完成，我们邀请您至少参考我们的答案——我们将它们放在我们的上游 gitops-template 存储库的书后。作为交换，如果您认为我们的免费午餐并不完全适合您，我们很乐意收到您的反馈。
既然您已经建立了管理集群，您就有了一个存放用户、组和密钥的地方，并且您有了一种自动化方式来运行您的 IaC 和 GitOps。这实际上是您开始创建第一个工作负载集群所需的一切。
工作负载集群只是一个设计用于运行您的软件工作负载的集群。例如，一个普通的项目可能需要一个development、staging和production工作负载集群来运行他们正在构建的软件的预发布和已发布版本。
工作负载集群与管理集群在以下几个方面有所不同：
- 它们可以轻松依赖于管理集群工具（没有先有鸡还是先有蛋的问题）。
- 它们不需要与管理集群完全相同的工具（例如，您的工作负载集群不需要CI工具）。
- 需要在集群之间保持工具版本的一致性（以便
production-east和production-west相同，或者staging真正代表生产环境体验）。
与您可以从上游gitops-template仓库创建gitops仓库的方式大致相同，您也可以从工作负载集群模板创建工作负载集群。如果您决定试用Kubefirst平台，您将在新的gitops仓库中直接获得这些集群模板的示例。
工作负载集群模板目录只不过是一个GitOps目录，其中包含为集群及其应用程序定义的YAML，但允许使用您希望不同的细节的变量。
例如，如果production-east和production-west是您理想基础架构的两个工作负载集群，您希望它们使用相同的IaC模块并具有相同版本的平台工具，例如external-dns、cert-manager、reloader等。但是您也希望它们位于不同的云区域，具有不同的集群名称，并且可能需要将其服务绑定到不同的DNS主机名。参数化不同的部分，以便您可以在集群配置时提示用户输入值。
在gitops仓库中指定不同的目录空间以将平台工具与正在开发的应用程序分开，这很有帮助。
将您构建的应用程序保存在不同的环境驱动目录结构中，允许您从最新的工作负载集群模板构建集群，因此您可以获得所有平台工具的所有新版本，但您可以通过简单地将环境链接添加到您的gitops仓库中的集群来将您的开发环境应用程序后期绑定到新集群。
将您的环境详细信息保存在一个静态空间中，该空间不会随着集群进出您的基础架构而波动，这有助于您的开发人员和持续集成（CI）工程。使用GitOps交付软件需要您在特定位置更新应用程序版本，当此位置不会随着您的基础架构变化而移动时，这很有帮助。
现在是时候创建一个工作负载集群，使用您的模板工具引导它，并将您的环境应用程序复制到它上面。
工作负载集群可以是虚拟集群或物理集群。虚拟集群不需要为其创建任何新的物理基础架构。相反，借助vcluster的功能，您可以创建新的Kubernetes集群，以便它们存在于您现有的集群中。vcluster的行为类似于完全隔离的集群，但无需在云中额外控制平面的成本。
在Kubefirst上，您可以使用我们的默认模板向现有集群添加一个全新的、完全填充的vcluster，它们仅使用其主机集群的约1GB内存和约1个CPU核心。这是一个非常轻量级且廉价的完全集群隔离层。
由于您使用自动化的IaC管理您的git仓库，因此向您的gitops仓库发出一个新的git仓库的拉取请求。您的拉取请求将向您显示一个新的计划，该计划会在批准后添加您的仓库并应用它。
有了新的仓库，添加您的源代码、图表、Dockerfile和一些CI来构建并将应用程序交付到您的环境。
这是宗教形成的地方，每个人都有不同的CI宗教。我不想告诉您CI的“正确方法”，因为有很多正确的方法可以做到这一点。
无论您选择什么工具，CI需要完成的任务是：
- 构建容器，最好不要使用root或特权pod
- 将容器发布到您的容器托管提供商
- 将容器镜像标签设置为Helm chart的默认镜像
- 发布Helm chart
- 使用CI的渐进式流水线阶段，为每个应用程序环境中的应用程序实例设置Helm chart的所需版本
- 添加测试以防止/促进您的版本发布到下一个环境
在Kubefirst平台中，我们使用所有平台配置生成gitops仓库，以及一个示例应用程序（隐喻）仓库，以演示如何使用GitOps构建和交付微服务仓库。
CI 就绪后，您可以启动作业来构建应用程序容器和图表，并一次一个环境地将应用程序实例的所需状态设置为应用程序的新版本。
现在是时候建立 Day 2 操作的组件了，或者说是永无止境的任务：更多应用程序、更多技术、更多考虑因素、更多监控。
我们喜欢的一些工具包括：
对于 Kubernetes 策略执行，我们非常喜欢 Kyverno，因为它具有 Kubernetes 原生配置和简单的入门体验。
对于日志记录、监控和可观察性，我们喜欢 Datadog，因为它具有即时的 Kubernetes 可观察性功能、可靠性和客户支持。这与我们自托管免费工具的理念大相径庭，但我们发现这个 SaaS 产品非常丰富，大多数项目都严重依赖可观察性。Datadog 提供的自托管替代方案通常包括 Prometheus、Grafana、Elasticsearch、Fluentbit、Kibana 和 Jaeger 与 OpenTelemetry 的组合。
对于容器扫描，我们喜欢开源的 Trivy，但是安全领域有很多产品允许您在不同的深度层面上进行防御，选择适合您公司的安全模型是公司平台构建计划中的一个战略组成部分。平台工程成熟度模型 可以帮助您深入考虑许多不同的垂直领域。
对于最成功的公司来说，平台构建的最后阶段永无止境。当公司拥抱变化、速度和交付，但必须遵守任务的质量、可靠性和安全要求时，减少摩擦的愿望将始终存在。
创建一个绝对期望这样的环境，在这个环境中，您必须根据这一期望采访您的平台用户以了解他们的体验。当用户的需求出现时，将其优先考虑在平台路线图上，并庆祝其使用。
通过健康的反馈、透明度和共享所有权文化，您将能够应对软件行业接下来抛给您的任何挑战。我希望这份演练能帮助您创建满足您需求的完美的云原生平台。