本文记录了在部署高可用的k8s集群时，遇到的一个故障及其解决方法。
集群环境
描述：三主三从，eth0为外网网卡，eth1为内网网卡，内网互通。
需求：eth0只负责访问外网，eth1作为集群间的通信。
| 主机名 | 网卡，IP | 内存 | CPU |
|---|---|---|---|
| controller1 | eth0: 10.45.25.11/24 eth1: 10.9.7.11/24 | 8 | 4，开启虚拟化 |
| controller2 | eth0: 10.45.25.12/24 eth1: 10.9.7.12/24 | 8 | 4，开启虚拟化 |
| controller3 | eth0: 10.45.25.13/24 eth1: 10.9.7.13/24 | 8 | 4，开启虚拟化 |
| node1 | eth0: 10.45.25.14/24 eth1: 10.9.7.14/24 | 8 | 4，开启虚拟化 |
| node2 | eth0: 10.45.25.15/24 eth1: 10.9.7.15/24 | 8 | 4，开启虚拟化 |
| node3 | eth0: 10.45.25.16/24 eth1: 10.9.7.16/24 | 8 | 4，开启虚拟化 |
| controller VIP | 10.9.7.100 | / | / |
问题描述
在加入node节点后，calico组件就绪失败。
失败原因如下图。
看报错是没有到10.96.0.1的路由，导致流量过不去。
处理过程
懵懂排错
-
在集群中，10.96.0.1状态正常。
- 换calico版本后，无果
- 换k8s版本重新部署后，无果
初见端倪
就在手足无措抓头时，我查看了一下集群负载信息。
突然意识到在加入主节点时就出现了问题，然后尝试了很多办法去指定初始化时的IP地址。很神奇的是不管什么方法都不生效。
解决方法
就在我即将放弃之际，我想到了去官网溜达溜达，无意间发现了救命稻草--apiserver-advertise-addres。
在join时使用此选项指定IP即可，问题轻松解决。
附
kubeadm init流程
kubeadm init | Kubernetes
kubeadm init 命令通过执行下列步骤来启动一个 Kubernetes 控制平面节点。
-
在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告， 其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了
--ignore-preflight-errors=<错误列表>参数。 -
生成一个自签名的 CA 证书来为集群中的每一个组件建立身份标识。 用户可以通过将其放入
--cert-dir配置的证书目录中（默认为/etc/kubernetes/pki） 来提供他们自己的 CA 证书以及/或者密钥。 API 服务器证书将为所有--apiserver-cert-extra-sans参数值提供附加的 SAN 条目，必要时将其小写。 -
将 kubeconfig 文件写入
/etc/kubernetes/目录以便 kubelet、控制器管理器和调度器连接到 API 服务器，它们每一个都有自己的身份标识。再编写额外的 kubeconfig 文件，将 kubeadm 作为管理实体（admin.conf）和可以绕过 RBAC 的超级管理员用户（super-admin.conf）。 -
为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话，也会为 etcd 生成一份额外的静态 Pod 清单文件。
静态 Pod 的清单文件被写入到
/etc/kubernetes/manifests目录； kubelet 会监视这个目录以便在系统启动的时候创建 Pod。一旦控制平面的 Pod 都运行起来，
kubeadm init的工作流程就继续往下执行。 -
对控制平面节点应用标签和污点标记以便不会在它上面运行其它的工作负载。
-
生成令牌，将来其他节点可使用该令牌向控制平面注册自己。如 kubeadm token 文档所述，用户可以选择通过
--token提供令牌。 -
为了使得节点能够遵照启动引导令牌和 TLS 启动引导 这两份文档中描述的机制加入到集群中，kubeadm 会执行所有的必要配置：
-
创建一个 ConfigMap 提供添加集群节点所需的信息，并为该 ConfigMap 设置相关的 RBAC 访问规则。
-
允许启动引导令牌访问 CSR 签名 API。
-
配置自动签发新的 CSR 请求。
更多相关信息，请查看 kubeadm join。
-
-
通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 在 Kubernetes v1.11 和更高版本中，CoreDNS 是默认的 DNS 服务器。 请注意，尽管已部署 DNS 服务器，但直到安装 CNI 时才调度它。
kubeadm join流程
kubeadm join | Kubernetes
kubeadm join 初始化 Kubernetes 工作节点或控制平面节点并将其添加到集群中。 对于工作节点，该操作包括以下步骤：
-
kubeadm 从 API 服务器下载必要的集群信息。 默认情况下，它使用引导令牌和 CA 密钥哈希来验证数据的真实性。 也可以通过文件或 URL 直接发现根 CA。
-
一旦知道集群信息，kubelet 就可以开始 TLS 引导过程。
TLS 引导程序使用共享令牌与 Kubernetes API 服务器进行临时的身份验证，以提交证书签名请求 (CSR)； 默认情况下，控制平面自动对该 CSR 请求进行签名。 -
最后，kubeadm 配置本地 kubelet 使用分配给节点的确定标识连接到 API 服务器。
对于控制平面节点，执行额外的步骤：
-
从集群下载控制平面节点之间共享的证书（如果用户明确要求）。
-
生成控制平面组件清单、证书和 kubeconfig。
-
添加新的本地 etcd 成员。
