「Kubernetes」- 集群与高可用 @20210422

问题描述

在 Kubernetes 的官方文档中，已经介绍搭建集群的方法，以及各种拓扑的利弊（为了保证知识是有效的，建议定期阅读官方文档）。

在进行研究和对比之后，我们便编写该笔记，用于日后指导我们如何选择高可用集群的拓扑结构，以及注意需要关注的问题。

该部分笔记将记录：在 Kubernetes 中，搭建高可用的 Kubernetes Cluster 的选择，以及相关问题处理，并附有集群搭建笔记。

解决方案

集群类型

高可用集群有两种方案：
1）With stacked control plane nodes（内部 etcd 服务）
2）With an external etcd cluster（外部 etcd 服务）

两种方案各有利弊，在文档 Options for Highly Available topology 中有所描述，需要根据各自需求进行选择。

内部 etcd 服务（Stacked etcd topology）

该类型高可用集群集群，提供数据存储的 etcd 服务在集群（由节点组成，由运行主节点组件的kubeadm管理）内部。

主机节点运行 kube-apiserver、kube-scheduler、kube-controller-manager 组件，而 kube-apiserver 会暴露为工作节点。每个主机节点会创建本地 etcd 成员，它只与本地的 kube-apiserver 通讯。而本地的 kube-controller-manager、kube-scheduler 只与本地 kube-apiserver 通讯。

优点：
1）节省主机：该集群 etcd 成员与主节点在相同节点，相对于外部 etcd 服务集群，该方案需要的主机数量少；
2）部署简单：集群部署比较简单，复制易于管理；

缺点：
1）如果主节点故障，则将无法访问 etcd 服务（因此需要多个主节点），此外该节点的 kube-apiserver、kube-scheduler、kube-controller-manager 组件也将不可用。
2）正如官方文档所说，最少需要 3 个 Control Plane 节点。两个节点是无法容错的，因为一个节点失败后，etcd 无法完成选举，导致 etcd 不可用，进而导致集群不可用。

集群部署参考：
1）1.17, keepalived, Stacked Control Plane
2）1.18, kube-vip, Stacked Control Plane

外部 etcd 服务（External etcd topology）

该类型高可用集群集群，提供数据存储的 etcd 服务在集群（由节点组成，由运行主节点组件的 kubeadm 管理）外部。

主机节点运行 kube-apiserver、kube-scheduler、kube-controller-manager 组件，而 kube-apiserver 会暴露为工作节点。但是 etcd 运行在独立主机，每个 etcd 服务与每个主节点上的 kube-apiserver 通讯。

优点：
1）该类性集群解耦主节点与数据存储（etcd），因此主节点故障或者 etcd 故障不会影响到集群冗余；

缺点：
1）更多主机：至少三台主机运行 etcd 服务，至少三台主机运行主机节点；

集群升级

不同的高可用集群方案具有不相同的集群升级方法，参考 Upgrading kubeadm clusters 文章。

常见问题梳理

如果 Kubernetes Cluster 的 Master 全部失败，会发生什么？

What happens when Kubernetes master fails? - Quora

我们一直担心如果 Master 节点失败，那我们部署在集群里的监控服务将无法正常运行。再后来我们了解到，如果 Master 节点全部失败，集群的管理功能将会丢失，比如 Pod 失败退出之后不会被重启，我们无法在集群中创建新的对象。但是，这并不会影响正在运行的 Pod 实例，外部依旧能够访问。

关于“多环境共用集群”的优劣

部署高可用的 Kuernetes Cluster 需要多台主机，成本较高。其中一种解决方法为：多环境共用同个集群，比如 Production 与 Staging 位于相同集群，并做好资源限制。

那么问题是，我们是否应该采用这种方案呢？

在进行调研对比之后，我们并未采用“多环境共用集群”的方案，原因如下：
1）因为该方案并没有解决其他问题，只是单纯节省资源，
2）它带来的其他优势可以忽略不计：
3）于此同时，还带来其他问题。比如：需要严格控制资源限制、跨命名空间服务访问（同个集群里一定会面临命名冲突的问题，或者会转移为其他问题）

官方文档 Using Kubernetes Namespaces to Manage Environments/Caveats 也进行一定程度的说明，并未鼓励使用该方法。

换个角度，如果这些主机成本我们无法负担，那也许是因为我们的业务还没有那么大规模以至于要使用 Kubernetes 服务。

参考文献

How to Save Big Using One Kubernetes Cluster for Multiple Environments | Blue Sentry
Checklist: pros and cons of using multiple Kubernetes clusters, and how to distribute workloads between them
Multiple environments (Staging, QA, production, etc) with Kubernetes - Stack Overflow
Multiple stages within a Kubernetes cluster - JAXenter
kubernetes - can we create 2 node master-only cluster with High availability - Stack Overflow

posted @ 2021-04-22 09:20 研究林纳斯写的阅读(99) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部