本文通过对Google近期发布的Anthos混合云产品的核心组件 Anthos Config Management进行分析，探究其背后设计的核心理念——Infrastructure as Code 是如何推动业内一直以来非标准的混合云慢慢走向标准化、供应商无锁定化。
0. Anthos Config Management是什么？
Hello World Demo
大家可以看Arctiq公司搞的修改node数量Demo：https://www.arctiq.ca/our-blog/2019/4/9/gke-on-prem-and-anthos-config-management/
简单说，当你修改某个git管理下的yaml配置文件，里面描述了某个GKE私有集群某个cluster的node数量，然后Anthos Config Management会帮你自动的发命令并让节点数量变成你想要的那个。
Anthos是啥？
是Google发布的混合云多云平台
大家可以看到，在这8大组件里面，大概只有4和5是最近推出的，其他的早就投入生产并有不少企业在用了，这些组件到底是什么关系？我们把这些组件放到一张图上，就排着这个样子（原谅我忽略了可怜的StackDriver和Marketplace，我假定读者对这2个东西很熟悉）
acm
也就是说，Anthos Config Management是一瓶胶水，把混合云里面应用的配置工作给自动化了。
且慢，什么叫做配置自动化？
这个词过于宽泛，所以在这里提几个常见的k8s用户场景
是的，Anthos Config Management就是用来解决这些问题的，并且，是按照Infrastructure as code的理念来做这个事情的
继续问另外一个问题，为什么配置这么重要？
众所周知，在传统的Unix/Linux环境下，在/etc下有不少配置文件，大部分苦逼的运维工程师每天的工作就是修改这些文件，并且通过重启进程或者给进程发信号让这些配置生效，并且要修改上百台机器；过去几年有了ansible或者salt这类批处理工具，把登陆几百台机器的工作量给省了；而k8s除了解决集群的批量问题，还引入了一个新的理念，就是声明式配置，运维工程师不需要苦逼的重启进程，这些“进程”会自动按照你的配置达到期望的状态（当然，由于这是在一个集群内，所以需要一定的时间），也就是说
声明式配置 = 面向终态
所以，你写的配置和传统的配置文件，那种静态的文本配置已经完全不一样了，最后这些配置会变成生产系统的某个状态，并且，如果使用了合理的工具链，这一系列工作都是自动化的。
那么现在这些“配置文件”还是配置吗？运维工程师的工作流程就变成了
- git pull
- read, think, modify
- git push // all things done automatically
是的，你会发现运维工程师的工作流程就和开发工程师一样了！
这些配置，无论是什么语言写的，本质上变成了源代码，只是没有通过编译工具链而是通过运维工具链达到了鲁棒性，这样就把传统运维的重复劳动工作从大部分人手中拿出来交给少部分的运维工具链专家去维护。
1. 内部设计
关于这点，Google并没有放出这个东西的源代码，但是有一张图
acm2
是的，这张图在组件上画的非常清晰，Anthos Config Management，在运行形态上是一个k8s的operator，部署在多个集群里面，并且应该可以从同一个远程git repo里面读取配置，从这个demo库里面，我们可以看到这个operator读取git库的配置
apiVersion: addons.sigs.k8s.io/v1alpha1
kind: ConfigManagement
metadata:
name: config-management
spec:
git:
syncRepo: [email protected]:GoogleCloudPlatform/csp-config-management.git
syncBranch: "0.1.0"
syncWait: 5
secretType: ssh
policyDir: foo-corp
这里几个参数清晰的标明，Anthos Config Management会去每5秒钟读取一次git repo的0.1.0分支，并按照这个分支上的配置来进行后续的操作。那么，这些操作具体能干啥，怎么干呢？官方文档实在是太可怜了，就几句话就想打发我们，不过，从Demo里面我们可以试图寻找这些功能和配置的对应关系。读者可以把demo库 git clone下来，比对着看。
官方的功能描述是：
- 从单一代码库衍生的真实，控制和管理
- 允许使用代码审查，验证和回滚工作流程。
- 避免阴影操作，由于手动更改导致的Kubernetes集群之间不同步。
- 允许使用CI / CD管道进行自动化测试和部署。
- 跨所有集群的一步式部署
- Anthos Config Management将单个Git提交转换为跨所有集群的多个kubectl命令。
- 只需还原Git中的更改即可回滚。 然后，大规模自动部署恢复。
- 丰富的继承模型，简化修改
- 使用命名空间，您可以为所有集群，某些集群，某些命名空间甚至自定义资源创建配置。
- 使用命名空间继承，您可以创建一个分层的命名空间模型，该模型允许跨repo文件夹结构进行配置继承。
这是demo的树形目录结构
.
├── cluster
│ ├── namespace-reader-clusterrole.yaml
│ ├── namespace-reader-clusterrolebinding.yaml
│ ├── pod-creator-clusterrole.yaml
│ └── pod-security-policy.yaml
├── namespaces
│ ├── audit
│ │ └── namespace.yaml
│ ├── online
│ │ └── shipping-app-backend
│ │ ├── pod-creator-rolebinding.yaml
│ │ ├── quota.yaml
│ │ ├── shipping-dev
│ │ │ ├── job-creator-role.yaml
│ │ │ ├── job-creator-rolebinding.yaml
│ │ │ ├── namespace.yaml
│ │ │ └── quota.yaml
│ │ ├── shipping-prod
│ │ │ └── namespace.yaml
│ │ └── shipping-staging
│ │ └── namespace.yaml
│ ├── sre-rolebinding.yaml
│ ├── sre-supported-selector.yaml
│ └── viewers-rolebinding.yaml
└── system
├── config-management.yaml
└── resourcequota-hierarchy.yaml
我相信应该是anthos的工作流应该是读取cluster里面的一些安全配置，并且在所有集群上都创建这里的namespace目录所描述的命名空间。
在一些demo视频里面我们还看到了clusterregistry目录，应该是用来修改集群的一些属性，达到动态修改节点数量的目的。
但如何让一个应用在多个集群的多个namespace流转，当前还没能看到痕迹，从namespace的嵌套目录来看，应用WorkLoad会经过这些目录的层级，然后动态的修改自己的一些配置。这些细节还有待研究。
2. 结语
核心洞察
Anthos是在多k8s集群的场景下，想到了这两点
遗留问题
- Anthos Config Management可以替代Federation吗？
- Anthos Config Management和Knative是啥关系？
参考
- Anthos深度分析，看懂谷歌云的三级火箭：https://www.tmtpost.com/3895215.html
- 关于Anthos：https://toutiao.io/posts/2a1ymm/preview
- Anthos Config Management官方文档：https://cloud.google.com/anthos/docs/concepts/anthos-overview#centralized_config_management
- 产品主页：https://cloud.google.com/anthos-config-management/
- 官方Demo：https://github.com/GoogleCloudPlatform/csp-config-management
- Arctiq公司搞的修改node数量Demo：https://www.arctiq.ca/our-blog/2019/4/9/gke-on-prem-and-anthos-config-management/
- 另一个Demo：https://www.youtube.com/watch?v=00f7aE8cfY0
