为什么 kubeadm config 的 controlPlaneEndpoint 是必需的？答案

【问题标题】：Why is kubeadm config's controlPlaneEndpoint necessary?为什么 kubeadm config 的 controlPlaneEndpoint 是必需的？
【发布时间】：2020-01-10 17:17:11
【问题描述】：

没有set a controlPlaneEndpoint是无法加入主节点的：

错误执行阶段预检：
不满足托管新控制平面实例的一个或多个条件。
无法向没有稳定 controlPlaneEndpoint 地址的集群添加新的控制平面实例
请确保：
* 集群有稳定的 controlPlaneEndpoint 地址。

但如果你改为加入一个工作节点（即没有--control-plane），那么它不仅知道集群中的其他节点，而且知道哪些是主节点。

这是因为mark-control-plane 阶段会：

通过添加标签“node-role.kubernetes.io/master=''”将节点标记为控制平面通过添加污点 [node-role.kubernetes.io/master:NoSchedule] 将节点标记为控制平面

那么masters (--control-plane) 不能加入集群并使用角色标签发现其他控制平面节点吗？

是否有任何此类插件或其他配置此行为的方式以避免单独的基础架构用于负载平衡 API 服务器？

【问题讨论】：

标签： kubernetes kubeadm

【解决方案1】：

查看kubeadm types definition，我发现这个很好的描述清楚地解释了它：

ControlPlaneEndpoint 为控制平面设置一个稳定的 IP 地址或 DNS 名称；它可以是有效的 IP 地址或 RFC-1123 DNS 子域，都带有可选的 TCP 端口。如果未指定 ControlPlaneEndpoint，则 AdvertiseAddress + BindPort 被使用；如果指定了 ControlPlaneEndpoint 但没有 TCP 端口，使用了 BindPort。可能的用法是：例如在具有多个控制平面实例的集群中，该字段应为在前面分配了外部负载均衡器的地址控制平面实例。例如在强制节点回收的环境中，ControlPlaneEndpoint 可用于为控制平面分配稳定的 DNS。

这也可能会影响 kubernetes 生成的 PKI，因为它需要知道一个通用名称/IP，您将通过该名称/IP 访问集群，以包含在它为 api 节点生成的证书中，否则这些将不匹配正确。

如果您真的不想拥有负载均衡器，您可以使用所有控制平面节点的 IP 设置循环 dns 条目，并尝试将其指定为 controlPlaneEndpoint 值。然而，这对故障转移和冗余没有帮助，因为故障节点不会从记录中删除，并且一些客户端可能会缓存地址而不尝试重新解析它，从而进一步延长任何中断。

希望这会有所帮助。

【讨论】：

谢谢，我最终做了类似于你描述的事情，在每个控制平面节点上使用 ipvs 作为其他控制平面节点的 LB，从 DNS 记录中获取节点列表：@ 987654322@我仍然不明白为什么不能只给新节点一个初始端点以允许它们加入集群，然后他们可以在加入后发现（并维护）其他节点。

【解决方案2】：

如果使用集群 Kubespray 方法，它有这样的配置：

## External LB example config
## apiserver_loadbalancer_domain_name: "elb.some.domain"
# loadbalancer_apiserver:
#   address: 1.2.3.4
#   port: 1234

## Internal loadbalancers for apiservers
# loadbalancer_apiserver_localhost: true
# valid options are "nginx" or "haproxy"
# loadbalancer_apiserver_type: nginx  # valid values "nginx" or "haproxy"

所以方法可以选择：外部负载均衡器、本地nginx负载均衡器或localhost:6443上的本地haproxy负载均衡器

他们在文档中提到了如何确保 apiserver 的 HA。

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ha-mode.md

【讨论】：