Bare Metal K8S集群在美国快餐连锁Chick-fil-A 的大规模使用

最大的挑战是，我们的边缘计算部署并不完全在“数据中心环境”中。

边缘计算硬件及经典的安装方式

集群管理：我们考虑过的选择

• Kubespray  - 我们最开始调查了基于Ansible的Kubespray，但我们发现它相当脆弱。当事情进展顺利时，我们能得到了一个集群；但当事情进展不太顺利时，我们就会创建一块难以变回计算机的“砖块”。我们还发现使用Kubespray启动集群的过程非常缓慢，通常在我们的硬件栈上花费的时间长达30分钟。我们相信Kubespray能有更长远的发展，但就我们的调研结果而言，我们认为得从别的方向探索别的解决方案。

• Openshift  - Openshift可以创建Kubernetes集群，但我们不喜欢在至关重要的基础设施部分跟供应商的解决方案捆绑地太过紧密，不想承担未来可能被技术锁定的风险。

• Kops  - 我们是Kops的忠实粉丝，我们用它来部署我们云的“控制面板”Kubernetes集群。不幸的是，当我们将其使用到我们的边缘计算中时，Kops并不是一个可行的裸机解决方案。我们期待看到它在未来的发展。

• Kubeadm  - Kubeadm是另一个不错的Kubernetes集群实用程序。Kubeadm项目看起来很有发展前景，但我们认为它比一些替代品 （尤其在其灵活性上）复杂的多，包括...

RKE

要使用RKE，你需要确定一个领导节点并为其提供一个配置YAML文件，YAML文件中包含有关该集群的数据，主要是参与集群活动的节点的主机名。

如果集群中的节点发生添加、删除、或死亡，则配置文件需要拥有一个对当前和未来节点的准确描述。如果配置不能保持持续最新，集群就会失败。虽然我们认为缺少节点不应该使群集初始化／更新失败，但目前来看实际情况正是如此。

安装过程

尚未被纳入集群的节点之间，需要彼此协调以确定谁将被纳入到集群中。他们还需要选出一个主节点来通过RKE执行集群创建。

Highlander

Highlander是我们基础边缘镜像的一部分。当每个节点启动时，UDP会广播其存在并询问是否存在已建立的领导者。它也会开始倾听自己。几秒钟后没有回复，它将发送另一个广播，宣布自己成为领导者。有什么异议吗？如果没有反对的讯息，该节点将很快成为集群领导者，并以领导者身份回应未来接收到的所有请求。

如果另一个节点已经声明了自己领导者的角色，新节点将确认该声明。现有的领导者会执行“RKE up”将新节点纳管到现有的集群中。

节点们会定期沟通以确保领导者仍在其中。如果旧领导者已经死亡，一个新的领导者将通过一个使用随机睡眠和领导声明的简单协议来选举而出。虽然这很简单不复杂，容易推理和理解，但它能实现成规模地有效工作。

领导者选举完成后，Highlander还能确保集群被正确得配置。在我们的环境中，这包括：

?        将 KubeDNS切换成CoreDNS

?        创建Istio或其他核心控制面板节点

?        OAuth身份认证

注意：我们的每个节点都有自己的身份和短暂的JWT来访问已验证的资源。Highlander提供此身份，并以Kubernetes秘钥的形式来提供token令牌。

整合过程

（不可避免的）失败

同时，我们的Kubernetes集群将继续在节点数量减少的情况下运行，并随时准备迎接更换节点。