涉及到的内容
- LVS
- HAProxy
- Harbor
- etcd
- Kubernetes (Master Worker)
整体拓补图
以上是最小生产可用的整体拓补图(相关节点根据需要进行增加, 但不能减少)
按功能组划分
- SLB
- LVS
- HAProxy
- etcd
- K8S Node (Master / Worker)
- SLB
LVS ,HAProxy 被规划为基础层, 主要提供了一个高可用的 7 层负载均衡器.
由 LVS keepalived 提供一个高可用的 VIP(虚拟 IP).
这个 VIP DR 模式转发到后端的 HAProxy 服务器.
HAProxy 反代了 K8S Master 服务器, 提供了 K8S Master API 的高可用和负载均衡能力.
可以使用 Nginx 代替 HAProxy 吗?
是可以的, 这边使用 HAproxy 是因为 k8s 文档中出现了 HAproxy, 且后续可能会有 4 层反代的要求, 从而使用了 HAProxy.
可以直接从 LVS 转发到 Master 吗?
理论上可行, 我没有试验.
如果不缺两台机器推荐还是架设一层具有 7 层代理能力的服务.
k8s apiserver,harbor,etcd 都是以 HTTP 的方式提供的 API, 如果有 7 层代理能力的服务后续会更容易维护和扩展.
推荐配置
用途 | 数量 | CPU | 内存 |
---|---|---|---|
Keepalive | 2 | 4 | 4GB |
HAProxy | 2 | 4 | 4GB |
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 (8~16) | 8GB (16GB~64GB) |
官网:
https://etcd.io/
官方硬件建议:
https://etcd.io/docs/v3.3.12/op-guide/hardware/
Static Pod 部署文档:
Kubernetes 集群
kubernetes 集群主要有两种类型的节点: Master 和 Worker.
Master 则是集群领导.
Worker 是工作者节点.
可以看出这边主要的工作在 Master 节点, Worker 节点根据具体需求随意增减就好了.
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/11489598.html