网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

部署高可用 kubernetes 集群

2020-06-10 11:36:08 admin 801

kubernetes 虽然具有故障自愈和容错能力，但生产环境中将其高可用部署还是非常有必要的，本文会介绍如何构建一个高可用的 Kubernetes
集群。kuber-controller-manager 和 kube-scheduler 的高可用官方已经实现了，都是通过 etcd
全局锁进行选举实现的，etcd 是一个分布式，强一致的（满足 CAP 的 CP）KV 存储系统，其天然具备高可用。而 apiserver
作为整个系统的核心，所有对数据的修改操作都是通过 apiserver 间接操作 etcd 的，所以 apiserver 的高可用实现是比较关键的。

#### kube-apiserver 的高可用配置

apiserver 本身是无状态的，可以横向扩展，其借助外部负载均衡软件配置高可用也相对容易，实现方案比较多，但一般会采用外部组件 LVS 或
HAProxy 的方式实现，我们生产环境是通过 LVS 实现的。apiserver 的高可用可以分为集群外高可用和集群内高可用。集群外高可用指对于直接调用
k8s API 的外部用户（例如 kubectl 、kubelet），客户端需要调用 apiserver 的 VIP 以达到高可用，此处 LVS 的部署以及
VIP 的配置不再详细说明。

集群内的高可用配置是指对于部署到集群中的 pod 访问 kubernetes，kubernetes 集群创建完成后默认会启动一个`kubernetes`的
service 供集群内的 pod 访问，service 的 ClusterIP 默认值为 `172.0.0.1` ，每一个 service
对象生成时，都会生成一个用于暴露该对象后端对应 pod 的对象 endpoints，endpoints 中可以看到 apiserver 的实例。访问
kubernetes 的 service，service 会将请求转发到 endpoints 中的 ip 上，此时若 service 中的
endpoints 中没有 IP，则表示 apiserver 无法访问。

$ kubectl get svc kubernetes
    NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
    kubernetes   ClusterIP   172.0.0.1    <none>        443/TCP   21d
    
    $ kubectl get endpoints kubernetes
    NAME         ENDPOINTS                       AGE
    kubernetes   10.0.2.15:6443, 10.0.2.16:6443  21d

kubernetes v1.9 之前 kube-apiserver service 的高可用也就是 master ip 要加入到 kubernetes
service 的 endpoints 中必须要在参数中指定 `--apiserver-count` 的值，v1.9 出现了另外一个参数
`--endpoint-reconciler-type` 要取代以前的 `--apiserver-count`，但是此时该参数默认是禁用的（Alpha
版本），v1.10 也是默认禁用的。v1.11 中 `--endpoint-reconciler-type` 参数默认开启了，默认值是
`lease`。`--apiserver-count` 参数会在 v1.13 中被移除。v1.11 和 v1.12 中还可以使用 `--apiserver-
count`，但前提是需要设置 `--endpoint-reconciler-type=master-count`。也就是说在 v1.11 以及之后的版本中
apiserver 中不需要进行配置了，启用了几个 apiserver 实例默认都会加到 对应的 endpoints 中。

#### kube-controller-manager 和 kube-scheduler 的高可用配置

kube-controller-manager 和 kube-scheduler 是由 leader election 实现高可用的，通过向
apiserver 中的 endpoint 加锁的方式来进行 leader election， 启用 leader election
需要在组件的配置中加入以下几个参数：

--leader-elect=true
     --leader-elect-lease-duration=15s
     --leader-elect-renew-deadline=10s
     --leader-elect-resource-lock=endpoints
     --leader-elect-retry-period=2s

组件当前的 leader 会写在 endpoints 的 holderIdentity 字段中， 使用以下命令查看组件当前的 leader:

$ kubectl get endpoints kube-controller-manager --namespace=kube-system -o yaml 
    
    $ kubectl get endpoints kube-scheduler --namespace=kube-system -o yaml

关于 kube-controller-manager 和 kube-scheduler 高可用的实现细节可以参考之前写的一篇文章：[kubernets
中组件高可用的实现方式](https://links.jianshu.com/go?to=http%3A%2F%2Fblog.tianfeiyu.com%2F2019%2F03%2F13%2Fk8s_leader_election%2F)。

#### etcd 的高可用配置

etcd 是一个分布式集群，也是一个有状态的服务，其天生就是高可用的架构。为了防止 etcd 脑裂，其组成 etcd 集群的个数一般为奇数个(3 或 5
个节点) 。若使用物理机搭建 k8s 集群，理论上集群的规模也会比较大，此时 etcd 也应该使用 3 个或者5 个节点部署一套独立运行的集群。若想要对
etcd 做到自动化运维，可以考虑使用 [etcd-
operator](https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fcoreos%2Fetcd-
operator) 将 etcd 集群部署在 k8s 中。

**kubernetes 中组件高可用部署的一个架构图** ：

image-20190712163334068

#### 总结

本文主要介绍如何配置一个高可用 kubernetes 集群，kubernetes 新版本已经越来越趋近全面 TLS + RBAC 配置，若
kubernetes 集群还在使用 8080 端口，此时每个 master 节点上的 kube-controller-manager 和 kube-
scheduler 都是通过 8080 端口连接 apiserver，若节点上的 apiserver 挂掉，则 kube-controller-
manager 和 kube-scheduler 也会随之挂掉。apiserver 作为集群的核心组件，其必须高可用部署，其他组件实现高可用相对比较容易。

参考：

[https://k8smeetup.github.io/docs/admin/high-
availability/](https://links.jianshu.com/go?to=https%3A%2F%2Fk8smeetup.github.io%2Fdocs%2Fadmin%2Fhigh-
availability%2F)

转载文章，原文链接：部署高可用 kubernetes 集群

关键字词集群 kubernetes

分享到：

上一篇：kubernetes 自定义资源（CRD）的校验

下一篇：kube-on-kube-operator 开发(一)

如需留言，请登录，没有账号？请注册

0 条评论 0 人参与

网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

部署高可用 kubernetes 集群

admin 1年前

zhou 2年前

zhou 2年前

zhou 2年前

zhou 2年前

网站首页 返回列表 像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

部署高可用 kubernetes 集群

admin 官方 1年前

zhou 2年前

zhou 2年前

zhou 2年前

zhou 2年前

网站首页返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

admin 1年前