Kubernetes简介
众所周知，Kubernetes是一款面向容器化应用管理的开源平台，支持自动部署和扩展。它的核心设计理念是容器化应用，并将其分组为逻辑单元，以便管理和发现。
Kubernetes的核心功能有：
- 自动binpack
- 水平扩展
- 自修复
- 自动发布更改和回滚
- 存储编排
- 服务发现和负载均衡
- 密钥和配置管理
- 批处理
总架构如下：
其中关键组件如下：
- kube-apiserver 负责提供Kubernetes API服务
- etcd 负责集群管理
- kube-controller-manager 负责资源的控制管理
- kube-scheduler 负责资源调度
- kubelet Node agent
- kube-proxy 负责通过网络抽象和暴露Service
而Kubernetes的Node分为两种：master和worker。master负责运行管理相关的组件，比如kube-apiserver、etcd、kube-controller-manager或kube-scheduler等。worker则负责提供Kubernetes runtime环境，比如kubelet、kube-proxy或一些容器相关的runtime，docker、rkt、hyperd等。所以说worker node（以下简称Node）为Kubernetes提供实际的workload。
Kubernetes Node
Node作为Kubernetes的Worker Machine，是容器运行的实际载体，Node可以是物理机也可是虚拟机。
在Kubernetes中，Node的创建方式有两种：
- Self-Registration
将kubelet flag的
--register-node设置为true，Node上的kubelet就可将自身注册到Node Manager - Manual Node Administration 集群管理员可手动创建和修改Node
但这两种方式都有一个弊端，那就是必须先有资源，然后通过Self-Registration或Manual Node Administration方式将资源注册进集群。而我们则期望可以使用公有云作为Kubernetes的node资源池，只在需要时才为集群创建和分配资源。
Kubernetes On Cloud
在Kubernetes v1.6之前，官方只为上述需求提供了一种蹩脚的实现 - Cloud Provider：
显然，这种方式对kube-controller-manager、kube-apiserver、kubelet等核心组件都有一定侵入，不利于功能和代码的解耦。幸运的是，在v1.6之后，Kubernetes将cloud-specific control loop相关的功能都offload到了一个新的模块cloud-controller-manager中。cloud-controller-manager基于插件化设计，所有想接入Kubernetes的Cloud Provider只需实现cloudprovider.Interface即可。
A Sample: Kubernetes On AWS
结合以上思路，我们可以设想如何通过cloud-controller-manager实现Kubernetes连接AWS：
以上过程分为三步：
1. 创建nodes
用户向Kubernetes发起创建service的请求，kube-apiserver收到请求后，调用aws-controller-manager创建nodes。随后，aws-controller-manager调用aws sdk创建ec2实例，成功后aws-controller-manager初始化nodes，并打上特定的label。
2. 创建pods
在aws ec2实例相关的nodes注册成功后，Kubernetes开始创建pods，kube-scheduler通过nodeSelector将pods调度到aws ec2实例的nodes中。
3. 创建service
最后，Kubernetes定义service，通过selector和pods关联，并最后最终调用kube-proxy暴露service endpoint。
最后
由于目前Cloud Controller Manager在Kubernetes v1.8中还处于alpha阶段，所以还未实现完整的KCM功能。另外，Kubernetes和AWS也未有官方实现的aws-controller-manager可供使用。
后续我会尝试先实现一个私有的td-aws-controller-manager，只提供有限的基础功能，以供验证设计思路。