02 | 健康之路 kubernetes(k8s) 实践之路 : 生产可用环境及验证

上一篇《 01 | 健康之路 kubernetes(k8s) 实践之路 : 开篇及概况 》我们介绍了我们的大体情况,也算迈出了第一步。今天我们主要介绍下我们生产可用的集群架设方案。涉及了整体拓补图,和我们采用的硬件配置,目前存在的问题等内容。

遵循上一篇提到的系列风格,这边不涉及基础的内容,这些基础的内容大家可以通过官方文档或其它渠道进行补充,主要还是分享实践经验及注意点。

涉及到的内容

LVS

HAProxy

Harbor

Etcd

Kubernetes (master、node)

整体拓扑图

image


以上就是我们目前在生产线的整体拓补图(隐去了IP,除了 K8S Node块其它实例数与图中一致)

SLB

LVS 、HAProxy 被规划为基础层,主要提供了一个高可用的7层负载均衡器。

由LVS keepalived 提供一个高可用的VIP(虚拟IP)。

这个VIP反代到后端的两台HAProxy服务器。

HAProxy反代了K8S Master和Harbor服务器,提供了K8S Master API和Harbor的高可用和负载均衡能力。

为什么不使用Nginx?

这个使用nginx也完全没问题,根据自己的喜好选择,这边选择HAProxy的主要原因是k8s官方文档中出现了HAProxy而不是Nginx。

能否不使用HAProxy,直接从LVS转发到Master?

理论上可行,我们没有试验。

如果不缺两台机器推荐还是架设一层具有7层代理能力的服务。

k8s apiserver、harbor、etcd都是以HTTP的方式提供的api,如果有7层代理能力的服务后续会更容易维护和扩展。

硬件配置

用途

 

数量

 

CPU

 

内存

 

Keepalived

 

2

 

2

 

4GB

 

HAProxy

 

2

 

2

 

4GB

 
kubernetes集群

kubernetes集群主要有两种类型的节点:master和node。

master则是集群领导。

node是工作者节点。

可以看出这边主要的工作在master节点,node节点根据具体需求随意增减就好了。

master节点的高可用拓补官方给出了两种方案。

Stacked etcd topology(堆叠etcd)

External etcd topology(外部etcd)

可以看出最主要的区别在于etcd。

第一种方案是所有k8s master节点都运行一个etcd在本机组成一个etcd集群。

第二种方案则是使用外部的etcd集群(额外搭建etcd集群)。

我们采用的是第二种,外部etcd,拓补图如下:

如果采用堆叠的etcd拓补图则是:

这边大家可以根据具体的情况选择,推荐使用第二种,外部的etcd。

参考来源:https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

Master节点的组件

apiserver

controller-manager

scheduler

一个master节点主要含有上面3个组件 ( 像cloud-controller-manager这边就不多做说明了,正常基本不会用到 )。

apiserver: 一个api服务器,所有外部与k8s集群的交互都需要经过它。(可水平扩展)

controller-manager: 执行控制器逻辑(循环通过apiserver监控集群状态做出相应的处理)(一个master集群中只会有一个节点处于激活状态)

scheduler: 将pod调度到具体的节点上(一个master集群中只会有一个节点处于激活状态)

可以看到除了apiserver外都只允许一个 实例处于激活状态(类HBase)运行于其它节点上的实例属于待命状态,只有当激活状态的实例不可用时才会尝试将自己设为激活状态。

这边牵扯到了领导选举(zookeeper、consul等分布式集群系统也是需要领导选举)

Master高可用需要几个节点?失败容忍度是多少?

k8s依赖etcd所以不存在数据一致性的问题(把数据一致性压到了etcd上),所以k8s master不需要采取投票的机制来进行选举,而只需节点健康就可以成为leader。

所以这边master并不要求奇数,偶数也是可以的。

那么master高可用至少需要2个节点,失败容忍度是(n/0)+1,也就是只要有一个是健康的k8s master集群就属于可用状态。(这边需要注意的是master依赖etcd,如果etcd不可用那么master也将不可用

Master组件说明: https://kubernetes.io/docs/concepts/overview/components/

部署文档: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

硬件配置

用途

 

数量

 

CPU

 

内存

 

k8s master

 

3

 

4

 

6GB

 
etcd

etcd是一个采用了raft算法的分布式键值存储系统。

这不是k8s专属的是一个独立的分布式系统,具体的介绍大家可以参考官网,这边不多做介绍。

我们采用了 static pod的方式部署了etcd集群。

失败容忍度

最小可用节点数:(n/2)+1

总数

 

健康数

 

失败数

 

1

 

1

 

0

 

2

 

2

 

0

 

3

 

2

 

1

 

4

 

3

 

1

 

5

 

3

 

2

 

6

 

4

 

2

 

7

 

4

 

3

 

8

 

5

 

3

 

9

 

5

 

4

 
硬件配置

用途

 

数量

 

CPU

 

内存

 

etcd

 

3

 

4

 

8GB

 

官网: https://etcd.io/

官方硬件建议: https://etcd.io/docs/v3.3.12/op-guide/hardware/

部署文档: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/

Harbor

harbor是一个开源的docker镜像库系统。

眼尖的人可以看出,拓补图中的harbor拓补的高可用其实是存在问题的。

我们目前采用的是双主模式:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpppdp.html