After enabling E2E testing of FluxCD powered GitOps continuous deployment, the feedback of new commits are quite slow. Because you have to wait for the E2E testing result, lots of time cost on setuping the environment and provisioning your development from scrath.

Inspired by E2E testing in Github actions, the DevOps …

背景

密钥的管理对于使用 GitOps 方式做持续发布是一个挑战，特别是当目标部署平台是 Kubernetes 的时候。 K8S 使用声明式配置管理最终状态，而K8S中的密钥仅仅是将密钥内容做了base64格式的编码。 在基于 Flux 的 GitOps 实战介绍了使用Bitnami Sealed Secrets加密密钥内容， 可以安全的将加密后的Kubernetes Manifest文件提交到Git代码仓库，由Sealed Secrets发现这些SealedSecret的密码， 并解密后动态的创建K8S原生Secrets对象。

背景

在Flux 部署实战的总结展望中有一个方向是如何将云上基础设施资源同Kubernetes内资源统一管理， 而Crossplane提供了一个高度可扩展的后端，使用声明式程序同时编排应用程序和基础设施，不用关心它们在哪里运行。

近期 AWS 官方博客宣布了 AWS Blueprints for Crossplane，为客户提供了在 Amazon EKS 上应用 Crossplane 的参考实现。

在上篇介绍基于 CNCF 下的 GitOps 工具 FluxCD v2 实现了管理多账户的 Kubernetes 集群的共享组件，Secrets 使用的最佳实践， GitOps 流水线事件同 IM(Slack) 的集成，以及对 GitOps 代码的 CI 流程。

本文将围绕如何使用 Flux 的多租户管理最佳实践，打造基于 GitOps 工作流程的共享服务平台， 实现租户(业务/应用团队)可自助的持续部署。

今天 Kuberentes 已经成为IT基础设施的重要玩家，容器编排领域的事实标准。写于3年前的文章不要自建 Kuberentes 的观点已经被绝大多数的企业所认可和接受。

然而同众多企业接触中发现，企业有很高的意愿采用 Kuberentes 管理工作负载，并且已有大量的企业已经将 Kuberentes 用于生产环境。 但如何对多套不同阶段的 Kuberentes 集群来做持续部署，做到高安全性、权限分离、可审计、保证业务团队的敏捷等需求感到困惑。 目前客户实现方式非常多样，并没有很好的遵循业界的最佳实践。

Github/Gitlab已经成为众多开发者非常熟悉的代码协作平台，通过他们参与开源项目或实施企业内部项目协作。

AWS也提供了托管的、基于Git、安全且高可用的代码服务CodeCommit。CodeCommit主要针对企业用户场景，所以他并没有社交功能以及代码仓库fork功能，是否CodeCommit就无法实现Github基于Pull Request的协同工作模式呢？