上一篇《 01 | 健康之路 kubernetes(k8s) 实践之路 : 开篇及概况 》我们介绍了我们的大体情况, 也算迈出了第一步. 今天我们主要介绍下我们生产可用的集群架设方案. 涉及了整体拓补图, 和我们采用的硬件配置, 目前存在的问题等内容.
遵循上一篇提到的系列风格, 这边不涉及基础的内容, 这些基础的内容大家可以通过官方文档或其它渠道进行补充, 主要还是分享实践经验及注意点.
涉及到的内容
- LVS
- HAProxy
- Harbor
- Etcd
- Kubernetes (master,node)
整体拓扑图
以上就是我们目前在生产线的整体拓补图(隐去了 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.
- apiserver
- controller-manager
- scheduler
来源: https://www.cnblogs.com/ants/p/11273805.html