设计高可用的Kubeadm架构
master节点中除了etcd还有三个组件。
- API Server: 集群控制的唯一入口，封装了资源的生命周期管理命令，是Kubernetes控制前端。所有组件的通信和数据交换都要走API，身份验证也归他。
- Controller Manager:集群内部各种资源controller的核心管理者，每个资源对应一致controller，它们确保资源处于期望值。
- Scheduler: API传来信息之后，它负责调度一个node进行资源创建，支持自定义调度算法同时提供多种预选和优选策略。
在设计高可用的架构时，API Server、Etcd一定要加入高可用框架的。
- controller-manager和scheduler也可以部署多个，但只有一个处于活跃状态，以保证数据一致性。因为它们会改变集群状态。
- 集群各组件都是松耦合的，如何高可用就有很多种方式了。
- kube-apiserver有多个，那么apiserver客户端应该连接哪个了，因此就在apiserver前面加个传统的类似于haproxy+keepalived方案漂个VIP出来，apiserver客户端，比如kubelet、kube-proxy连接此VIP。
- Etcd有多个，我们也需要haproxy+keepalived方案漂个VIP出来给apiserver客户端使用。
kubeadm初始化文件
kubeadm配置单机版本集群与配置高可用集群所不同的是，高可用集群给kubeadm一个配置文件，kubeadm根据此文件在多台节点执行init初始化。
kubeadm_init.yaml
apiVersion: kubeadm.k8s.io/v1alpha3
kind: ClusterConfiguration
kubernetesVersion: stable
networking:
podSubnet: 192.168.0.0/16
serviceSubnet: 172.10.0.0/16
apiServerCertSANs:
- master1
- master2
- master3
- 172.16.2.224
- 172.16.2.226
- 172.16.2.227
- 127.0.0.1
etcd:
external:
endpoints:
- http://172.16.2.224:2379
- http://172.16.2.226:2379
- http://172.16.2.227:2379
- apiServerCertSANs：填写所有kube-apiserver节点的hostname、IP、VIP
- etcd：external表示使用外部etcd集群，后面写上etcd节点IP
这个文件是在kubeadm init时使用。例如我在master1节点使用了kubeadm_init.yaml做初始化。
# master1节点先执行
export KUBECONFIG=/etc/kubernetes/admin.conf
kubeadm init --config kubeadm_init.yaml
将生成的pki复制到其他master节点
\scp -r /etc/kubernetes/pki 172.16.2.226:/etc/kubernetes/
\scp -r /etc/kubernetes/pki 172.16.2.227:/etc/kubernetes/
依次在master2、master3节点上初始化
# master2节点执行
export KUBECONFIG=/etc/kubernetes/admin.conf
kubeadm init --config kubeadm_init.yaml
# master3节点执行
export KUBECONFIG=/etc/kubernetes/admin.conf
kubeadm init --config kubeadm_init.yaml
结束语
Kubeadm 实现高可用架构，重点就是在于etcd集群和多api-service的高可用。归纳到最后就是kubeadm_init.yaml文件。
当然肯定有读者会问：你的kubeadm是如何搭建的？其实你要是一直关注我，肯定可以从之前的博文中收获你想要的答案，如果你还是不太清楚kubeadm如何搭建整个高可用架构，不要急，过年前我会把整个部署流程写出文档与大家分享的。
分享到:
閱讀更多 崔格拉斯 的文章
