- Master节点：2c2g+
- Worker节点：2c4g+
- 运行以下之一的一台或多台机器：
- RHEL 7
- CentOS 7.4+
- CentOS 8
- Debian 9
- Ubuntu 16.04+
- 各节点时区时间一致
- 每个节点 mac 地址和 product_uuid 在集群内都是唯一的
- 墙裂建议升级内核到4.17+，关于Bug，你可以从以下地方追踪到：
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,2X 前缀的 play-book 为分步骤安装集群操作，方便学习者明白和了解集群安装的步骤和原理：
00-kernel.yml升级内核为可选项，安装时请先拿一台主机进行内核升级测试，有些云主机升级内核后会出现启动不了系统的情况（比如：京东云），升级内核完成后请一定 重启节点 。- 01-09 前缀的 play-book 为 kubernetes 集群搭建基础操作
- 注意： 这些 play-book 都是依赖上一个 play-book 的，比如需要执行
02-docker.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目录的，请勿随意修改其位置。
- 在执行