kubernetes高可用架构

在之前的实验中，kubernetes集群都是一台master和两台node组成的小集群，在实际的生产环境中需要考虑到集群的高可用。

在node节点实际已经实现了高可用，pod分布在不同的节点上，当一个节点宕机的时候，其上的pod会漂移到正常的节点上。所以，重点的高可用重心就要放在master上。

官方的master节点高可用架构

---

图中可以看出，用户通过kubectl发送命令经过LB进行负载均衡到后端的master上的apiserver，再由具体的某一个master进行向集群内部的节点的转发。

同理，节点也是通过LB进行负载均衡连接到master上的apiserver，去获取到apiserver中配置的信息。

其他高可用集群架构

---

图中可以看到，每一台node上都部署了 nginx做负载均衡到master的apiserver，而kube-scheduler和controller-manager不需要做高可用，因为它们默认会通过选举产生，可以通过下面的命令查看：

实现过程

master节点扩展

将master节点扩展至2个，新增加的master的ip为：10.10.99.240

在原先的master上的server-csr.json中增加新增额度master的ip：

{
    "CN": "kubernetes",
    "hosts": [
      "127.0.0.1",
      "10.10.10.1",
      "10.10.99.225",
      "10.10.99.233",
      "10.10.99.228",
      "10.10.99.240",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Guangzhou",
            "O": "k8s",
            "OU": "System"
        }
    ]
}

重新生成server证书：

cfssl gencert -ca=ca.pem -ca