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

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

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

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

As a builder in cloud, you might feel confused about which resources cost mostly in your account.

In AWS, you can quickly find out which services even functionality cost a lot via AWS Billing or AWS Cost Explorer. However sometimes it sucks on finding out which functions cost mostly if you have hundreds of Lambda …

Though you're administrator of your AWS account, you probably see below warnings when viewing your cluster in EKS console.

Your current user or role does not have access to Kubernetes objects on this EKS cluster.

混沌工程是一种帮助系统满足弹性需求的技术，它起源于Netflix的工程实践，著名的猴子军团。

AWS一直提倡架构的完善(AWS Well-Architected)，混沌工程正是卓越运营和可靠性支柱的实践。 因此在 re:Invent 2020 AWS发布了Fault Injection Simulator服务来简化开发者在AWS上的混动工程实践。