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