Controller Manager作为集群内部的管理控制中心，主要负责集群内的资源管理，包括Node、Pod、命名空间、额定资源等。比如当某个Node意外宕机，Controller Manager会及时发现并执行自动化修复。
一、部署k8s Controller Manager
确保controller-manager-key.pem 和 controller-manager.pem存在，我这里在前面的文章中已经创建好相关私钥。执行如下操作：
cd /etc/kubernetes export KUBE_APISERVER="https://192.168.15.200:6443"
配置 cluster
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/ssl/ca.pem --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=controller-manager.conf
配置 credentials
kubectl config set-credentials system:kube-controller-manager --client-certificate=/etc/kubernetes/ssl/controller-manager.pem --embed-certs=true --client-key=/etc/kubernetes/ssl/controller-manager-key.pem --kubeconfig=controller-manager.conf
配置 context
kubectl config set-context system:kube-controller-[email protected] --cluster=kubernetes --user=system:kube-controller-manager --kubeconfig=controller-manager.conf
配置 default context
kubectl config use-context system:[email protected]es --kubeconfig=controller-manager.conf
controller-manager.conf 文件生成后将这个文件分发到各个 Master 节点的 /etc/kubernetes 目录下。
scp controller-manager.conf k8s-master02:/etc/kubernetes/ scp controller-manager.conf k8s-master03:/etc/kubernetes/
创建 kube-controller-manager的systemd服务启动文件，如下：
export KUBE_APISERVER="https://192.168.15.200:6443"
cat > /usr/lib/systemd/system/kube-controller-manager.service << EOF
[Unit]
Description=kube-controller-manager
After=network.target
After=kube-apiserver.service
[Service]
EnvironmentFile=-/etc/kubernetes/controller-manager
ExecStart=/usr/local/bin/kube-controller-manager --logtostderr=true --v=0 --master=https://192.168.15.200:6443 \
--kubeconfig=/etc/kubernetes/controller-manager.conf --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.pem --cluster-signing-key-file=/etc/kubernetes/ssl/ca-key.pem --service-account-private-key-file=/etc/kubernetes/ssl/ca-key.pem --root-ca-file=/etc/kubernetes/ssl/ca.pem --insecure-experimental-approve-all-kubelet-csrs-for-group=system:bootstrappers --use-service-account-credentials=true --service-cluster-ip-range=10.96.0.0/12 --cluster-cidr=10.244.0.0/16 --allocate-node-cidrs=true --leader-elect=true --controllers=*,bootstrapsigner,tokencleaner
Restart=on-failure
Type=simple
LimitNOFILE=65536
EOF
分发到其他主机：
scp /usr/lib/systemd/system/kube-controller-manager.service k8s-master02://usr/lib/systemd/system/ scp /usr/lib/systemd/system/kube-controller-manager.service k8s-master03://usr/lib/systemd/system/
在各节点启动服务：
systemctl daemon-reload systemctl enable kube-controller-manager systemctl start kube-controller-manager systemctl status kube-controller-manager
查看服务状态，是否正常启动；
提示：请确保 apiserver-csr.json 定义的证书授权 IP 内容里把 VIP 填写进去，如果未填写进去，请重新使用 cfssl 生成证书后放入各个 master 节点的 /etc/kubernetes/pki 上，并重启 kube-apiserver.service 服务。最后，关于k8s apiserver高可用还有一些问题需要这里做一些总结，我们这里通过 corosync + pacemaker 软件使得某种 apiserver 服务高可用，这是因为apiserver是无状态服务允许同时存在不同的节点。而scheduler，controller-manager在集群中只能在一台主机开启，这里我们可以在启动controller-manager和scheduler 只要加上 --leader-elect=true 参数就可以同时启动，系统会自动选举leader。具体来说，如果有多台master node，上面都安装了scheduler，controller-manager, apiserver：
- 对于schduler服务，同一时间只在一台master 节点上运行；
- 对于controller-manager，同一时间只在一台master 节点上运行；
- 对于apiserver，同一时间只在一台master 节点上运行；
在整套环境中，我们又将引入一个新的问题。pacemaker + corosync 的高可用性谁来保证？因为高可用集群都存在脑裂或者管理员误操作的情况，一旦高可用集群出现脑裂，多台master会出现抢占VIP以及在多个节点上同时启动了scheduler或者controller-manager，就会造成系统故障。