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 集群将继续在节点数量减少的情况下运行，并随时准备迎接更换节点。