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

美国快餐连锁店Chick-fil-A在其2000多家餐厅的边缘计算中使用着Kubernetes，在规模上看，这意味着有大约6000台设备上同时运行着Kubernetes。其中与此相关的最大的一个挑战是：如何在餐厅的物理机上部署和管理这么多Kubernetes集群。本文由Chick-fil-A的技术团队所写，分享他们在Kubernetes集群管理技术选型、物理机上Kubernetes集群的安装和管理方面的经验。

---

大多数状况下，Kubernetes都在云中部署，或由熟练Kubernetes的技术人员在物理机上部署（再或者至少配有远程访问）。但对Chick-fil-A而言，咱们的Kubernetes部署是由那些仅关注初始硬件安装的安装人员完成的。由于其自启动的特性，它们从不须要直接链接到计算设备——而是链接以太网和电源线，并经过查看应用程序app来检查集群的状态 。整个替换过程由对技术并不太专业的餐厅老板／运营者或他们的团队完成。最大的挑战是，咱们的边缘计算部署并不彻底在“数据中心环境”中。

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

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

为了解决集群管理的挑战，咱们作过全面的技术调研，曾考虑过以下几个选项：

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

Openshift - Openshift能够建立Kubernetes集群，但咱们不喜欢在相当重要的基础设施部分跟供应商的解决方案捆绑地太过紧密，不想承担将来可能被技术锁定的风险。
Kops - 咱们是Kops的忠实粉丝，咱们用它来部署咱们云的“控制面板”Kubernetes集群。不幸的是，当咱们将其使用到咱们的边缘计算中时，Kops并非一个可行的裸机解决方案。咱们期待看到它在将来的发展。

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

RKE

就咱们目前的选择而言，RKE是最终赢家。RKE是由Rancher Labs提供的开源的Kubernetes集群管理引擎。虽然咱们暂时未使用Rancher 2.0来管理咱们的集群，但咱们确实喜欢使用RKE来初始化和维护集群的简单性。

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

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

安装过程

咱们在餐厅的安装过程很是简单——将设备拆箱，将其插入电源和标记的交换机端口，就是这样。它们会自动启动电源，并实现自引导和集群建立。RKE让非技术用户可以在不了解Kubernetes甚至总体架构的状况下，经过无比简单的过程执行安装和替换的工做，这一体验很是棒，不过它也确实须要一些更复杂的引导过程。

还没有被归入集群的节点之间，须要彼此协调以肯定谁将被归入到集群中。他们还须要选出一个主节点来经过RKE执行集群建立。

Highlander

为了解决这个问题，咱们开发Highlander。
由于咱们只能有一个集群发起者。Highlander是咱们基础边缘镜像的一部分。当每一个节点启动时，UDP会广播其存在并询问是否存在已创建的领导者。它也会开始倾听本身。几秒钟后没有回复，它将发送另外一个广播，宣布本身成为领导者。有什么异议吗？若是没有反对的讯息，该节点将很快成为集群领导者，并以领导者身份回应将来接收到的全部请求。

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

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

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

• 将 KubeDNS切换成CoreDNS

• 建立Istio或其余核心控制面板节点

• OAuth身份认证

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

整合过程

尽管咱们在本文中主要关注集群初始化，接下来咱们也介绍一下在餐厅中实时进行节点初始化的整个流程。

（不可避免的）失败

最后咱们想分享一些失败的经验。若基础设施出现故障，咱们但愿可以灵活应对。节点故障可能由多种缘由致使：设备故障，网络交换机故障，电源线意外拔出。在全部这些状况下，咱们必须快速诊断什么是致使故障的真正缘由，而什么是无关的异常。这个过程很复杂，将来咱们会带来另外一篇文章来以此为主题展开分享。也就是说，当咱们诊断失败时，咱们的流程是向餐厅投放一个基本图片替代品（包含可视化安装说明），并让餐厅老板／运营者或他们的团队执行替换工做。同时，咱们的Kubernetes集群将继续在节点数量减小的状况下运行，并随时准备迎接更换节点。

微信号：RancherLabs