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集羣將繼續在節點數量減小的狀況下運行，並隨時準備迎接更換節點。