- Master节点:2c2g+
- Worker节点:2c4g+
- 运行以下之一的一台或多台机器:
- RHEL 7
- CentOS 7.4+
- CentOS 8
- Debian 9
- Ubuntu 16.04+
- 各节点时区时间一致
- 每个节点 mac 地址和 product_uuid 在集群内都是唯一的
- 墙裂建议升级内核到4.17+,关于Bug,你可以从以下地方追踪到:
- OpenEuler 操作系统需手动关闭 SELINUX 并重启系统后进行操作
sed -i 's/^SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config
Note: 搭建集群时脚本会关闭节点上防火墙,集群搭建完毕后会使用到如下表列出的端口:
离线安装时kubeadm-ha节点 | ||||
---|---|---|---|---|
TCP | 入站 | 5000 | registry | All |
TCP | 入站 | 12480 | yum repository | All |
控制平面节点 | ||||
协议 | 方向 | 端口范围 | 使用者 | 用途 |
TCP | 入站 | 6443 | Kubernetes APIserver | All |
TCP | 入站 | 2379-2380 | etcd server clientAPI | kube-apiserver,etcd |
TCP | 入站 | 10248,10250 | Kubelet API | Self,Controlplane |
TCP | 入站 | 10251,10259 | kube-scheduler | Self |
TCP | 入站 | 10252,10257 | kube-controller-manager | Self |
工作节点 | ||||
协议 | 方向 | 端口范围 | 使用者 | 用途 |
tcp | 入站 | 80 | ingress-controller | All |
tcp | 入站 | 443 | ingress-controller | All |
tcp | 入站 | 18443 | ingress-controller | Self |
tcp | 入站 | 10254 | ingress-controller | Self |
TCP | 入站 | 10248,10250 | KubeletAPI | Self,Controlplane |
TCP | 入站 | 30000-32767 | NodePort Services | All |
TCP | 入站 | 10256 | kube-proxy | 健康检查 |
Flannel | ||||
协议 | 方向 | 端口范围 | 使用者 | 用途 |
UDP | 双向 | 8285 | flannel networking(UDP) | 收发封装数据包 |
UDP | 双向 | 8472 | flannel networking(VXLAN) | 收发封装数据包 |
Calico | ||||
协议 | 方向 | 端口范围 | 使用者 | 用途 |
TCP | 双向 | 179 | Calico networking(BGP) | 收发封装数据包 |
TCP | 双向 | 5473 | Calico networking with Typha | 收发封装数据包 |
load-balancer | ||||
协议 | 方向 | 端口范围 | 使用者 | 用途 |
tcp | 入站 | 112 | keepalived | lb kube-apiserver |
tcp | 入站 | 8443 | nginx,haproxy,envoy | lb kube-apiserver |
tcp | 入站 | 8081 | nginx,haproxy,envoy | 健康检查 |
tcp | 入站 | 9090 | haproxy,envoy | 管理端口 |
该负载均衡模式是在节点本地部署一个负载均衡器,节点本地所有需要链接 apiserver 的组件均通过本地负载均衡器进行访问。
- 优点:兼容所有云;无额外的网络消耗(共用主机 network namespace);不会出现 lb 宕机而整个集群崩溃的情况。
- 缺点:集群外需要链接 apiserver 无法做到高可用(除非再搭建一套负载均衡);节点本地负载均衡器宕机则该节点无法正常工作;添加或删除 master 节点会涉及所有节点更新负载均衡器配置(当然不更新也是可以的)。
+------------------------+ +------------------------+
| master-A | | master-B |
+------------------------+ +------------------------+
| nginx +-------+--------> apiserver |
+-----^------+------^----+ | +-----------^------------+
| | | | | | | | |
+-----+----+ | +----+----+ | +---------+ | +----------+
|controller| | |scheduler| | |scheduler| | |controller|
+----------+ | +---------+ | +----+----+ | +-----+----+
| | | | | | | | |
+------------v-----------+ | +----v------+-------v----+
| apiserver <-------+--------+ nginx |
+------------------------+ | +------------------------+
|
>----------------------^----------------------<
| | |
+---------+----------+ +---------+----------+ +---------+----------+
| nginx | | nginx | | nginx |
+---^-----------^----+ +---^-----------^----+ +---^-----------^----+
| | | | | | | | | | | |
+---+---+ +-----+----+ +---+---+ +-----+----+ +---+---+ +-----+----+
|kubelet| |kube-proxy| |kubelet| |kube-proxy| |kubelet| |kube-proxy|
+-------+ +----------+ +-------+ +----------+ +-------+ +----------+
| | | | | |
+--------------------+ +--------------------+ +--------------------+
| node-A | | node-B | | node-C |
+--------------------+ +--------------------+ +--------------------+
该负载均衡模式是在集群外搭建一个主备负载,虚拟IP(VIP)飘在这些节点上,当节点挂掉虚拟IP(VIP)会迅速转移到正常工作的节点上,该模式常见的组合即为:HAproxy + keepalived。
- 优点:集群内外链接 apiserver 均为高可用。
- 缺点:公有云无法使用;额外的网络消耗;所有node的网络I/O都会高度集中于一台机器上(VIP),一旦集群节点增多,pod增多,单机的网络I/O迟早是网络隐患;lb 宕机整个集群崩溃(当然这种情况很少)。
+----------------------+ +----------------------+
| master-A | | master-B |
+----------------------+ +----------------------+
| apiserver <---------+--------> apiserver |
+----------------------+ | +----------------------+
| | | | |
+----------+ +---------+ | +---------+ +----------+
|controller| |scheduler| | |scheduler| |controller|
+----+-----------+-----+ | +------+----------+----+
| | | | |
v------v-----------v >------------^------------< v----------v------v
| | | |
| +-------------------+-------------------------+------------------+ |
| |keepalived| |HAproxy| |HAprox | |keepalived| |
| +----------+ +-------+ +-------+ +----------+ |
| | | VIP | | |
| | LB-A | | LB-B | |
| +-----------------------+--------^--------+----------------------+ |
| | |
>---->----------->---------->------^----<----------<-----------<-----<
| | | | | |
+---+-----------+----+ +---+-----------+----+ +---+-----------+----+
|kubelet| |kube-proxy| |kubelet| |kube-proxy| |kubelet| |kube-proxy|
+-------+ +----------+ +-------+ +----------+ +-------+ +----------+
| | | | | |
+--------------------+ +--------------------+ +--------------------+
| node-A | | node-B | | node-C |
+--------------------+ +--------------------+ +--------------------+
-
编号 0X,1X,2X 前缀的 play-book 为分步骤安装集群操作,方便学习者明白和了解集群安装的步骤和原理:
00-kernel.yml
升级内核为可选项,安装时请先拿一台主机进行内核升级测试,有些云主机升级内核后会出现启动不了系统的情况(比如:京东云),升级内核完成后请一定 重启节点 。- 01-09 前缀的 play-book 为 kubernetes 集群搭建基础操作
- 注意: 这些 play-book 都是依赖上一个 play-book 的,比如需要执行
02-container-engine.yml
前,你必须先执行01-base.yml
。
- 注意: 这些 play-book 都是依赖上一个 play-book 的,比如需要执行
- 2X 前缀的 play-book 为 kubernetes 集群搭建完成后,基础插件安装。
25-cert-manager.yml
默认为不进行安装,需添加(修改)cert_manager_enabled
、acme_email
后进行方可安装,具体参数详解请查看example/variables.yaml
-
编号 8X 前缀的 play-book 为搭建集群后节点添加删除操作。
-
编号 9X 前缀的 play-book 为一键安装或维护整个集群操作。
- 在执行
93-backup-cluster.yml
操作后,得到的备份文件将会拉取到 play-book 所在目录的cluster-backup
目录中;94-restore-cluster.yml
是依赖cluster-backup
目录的,请勿随意修改其位置。
- 在执行