對於餐館運營者來講門庭若市是好事，但客流量太大對於餐廳日常運營來講是不小的壓力，畢竟人越多，等待時間越長，客戶的滿意度就會直線下降，這對快餐廳來講是致命的。
這家美國連鎖“吃雞”餐廳想出了用物聯網的方式在所有餐廳收集大量資料後上傳到公司內部雲端，然後運用演算法在雲端做流程自動優化來提高運營效率。這年頭開餐館的都有云平臺，厲不厲害。
我們如何為餐廳做執行中Kubernetes邊緣演算法的裸機聚類. 我們收到最常見的（也是最棒的）問題就是“但為什麼呢？”，接下來，我們在本文中會對此作出回答。
為什麼在餐廳中運用K8s？
為什麼像Chick-fil-A這樣的餐廳想要運用Kubernetes邊緣演算法？目標是什麼？我們的結論是：
低延遲、基於網路的可靠應用
這些應用的可用性極高
為快速創新、和快速實現功能落地提供了平臺
橫向對比——基礎設施和應用開發團隊
容量壓力
Chick-fil-A很大程度是因其誘人的食品和完美的客戶服務而成功，而這些都是得益於在我們餐廳中辛勤工作和運營的優秀員工，他們在業內無人能及。所以結果就是餐廳非常繁忙。如果你去過Chick-fil-A，你會懂的。
在曼哈頓人潮擁擠的Chick-fil-A，圖為正在餐廳門口排隊等待的食客。該圖來自華爾街日報
我們非常感恩能取得這樣的成功，但這個成功給我們的業務運營帶來了很大壓力。整體來看，我們週日休息，但一週六天的營業額比競爭對手一週七天的還要高。我們有些店面的人流量比最初設計考慮最大人流量限制的三倍還要多。這些都是需要去解決的問題，首當其衝的就是規模引起的容納能力的問題。
我們認為Chick-fil-A大部分容納問題都可以由科技來解決。
“新一代”工作體量
我們的解決方法之一就是投資讓餐廳更智慧化。
我們的目標是：為餐廳加盟商/運營者、以及他們的員工簡化餐廳工作流程，保證食物優質美味以及提升美食的供給速度，同時，加強當前客流量的容納能力。
我們所有的努力都是基於這個假設：智慧化廚衛設施能夠收集更多資料，將這些資料運用在餐廳上，我們可以建立起更加智慧化的系統，從而更好擴充套件業務版圖。
舉個簡單的例子，想象一個能夠預測每分鐘應當烤制多少個華夫餅（或是其它食物）的預測模型。使用餐廳裡的各種業務層面資料，模型經過雲端的分析計算過程，推匯出最後的預測結果。
雖然這個預測結果並不需要花費大量的精力，但它並不完全準確，也不能提高食物生產量。Chick-fil-A的營業額還會受到多方面因素影響，包括上下班高峰期、當地具體情況（交通、體育活動、天氣等）。
但如果我們從銷售點系統中的實際交易裡收集資料來獲得當下需求情況，並加入炸鍋里正在製作食物情況的資料，再對之前提到的預測模型的結果進行微調，我們能夠得到一個對於當下應該做什麼種類、做多少份食品的更為準確預測結果。
這些資料也能給例如大廚或其他餐廳工作人員一個更智慧的展示，也許未來能夠促進廚房無人化的發展。
這樣的目標帶領著我們為我們的餐廳建立了一個物聯網（IOT）平臺。為了更好地擴張業務，我們還要掌握以下能力：1. 收集資料；2. 將這些資料應用於餐廳自動化的發展。
相對於選擇那些生硬、獨立，難以整合的供應商服務，我們想要擁有一套完全屬於我們自己具有開放性的產業生態鏈。這個方法使我們的內部開發者和外部合作商能夠開發互通的“平臺”（或者說是Edge的應用），並且能夠促進我們平臺支援類似於安全性、獨特性和互通性的普遍需求。
換言之，IOT/Edge團隊是我們部署在Edge上整個應用程式基礎裡的一小部分，也是我們餐廳中運營部門平臺中有效的運營助手。
構架概覽
這是一個我們為達到目標而開發，也是目前正在使用的平臺構架。
我們目前構架的簡單簡單示意圖
雲控制面
目前，我們在雲端執行高階控制皮膚和核心“物聯網”服務，其中包含以下服務：
授權伺服器——裝置識別碼管理
資料攝取/渠道——收集資料，並將其傳輸至需要的地方
執行中的時間序列資料——記錄、監控、預警、追蹤
配置管理——為我們使用GitOps（給Weaveworks上給我們提供這個名稱的朋友們點贊）的應用團隊提供自選服務配置。我們計劃儘快分享出成果和原始碼。
這些服務的執行是基於Kubernetes，因此為我們團隊的部署中提供了共同的正規化。
邊緣
邊緣演算法也即：部署運算資源，使之儘可能地達到更高的可用性和/或更低的延遲時間。
我們將我們的邊緣演算法環境視為“微型私有云”，也就是說，我們為開發者提供了一系列好用的服務，也可以在我們基礎構架上部署他們的應用程式。
這是否意味著我們成為世界上最大的“雲服務提供商”呢？你說了算。
迴歸正題，這個方法給了我們一種獨特的規模。相比帶有數十萬工具集的幾個大型K8s叢集，我們可以全面地使用超過兩千個叢集，每個帶有十來個工具集。這個數字還能隨著我們每年新開店面而顯著增長。
我們的邊緣工作量包括：
提供類似於身份令牌服務、播送接收傳訊(MQTT)、日誌收集/匯出(FluentBit)、監控（Prometheus）等服務
餐廳中與“物聯網”產生互動的應用
一些響應HTTP請求的簡單微型服務
提供一些機器學習模型：利用實時事件（MQTT）與合成雲端開發預測，從而幫助在邊緣做出決策和促進自動化。
我們的邊緣計算物理環境從多個餐廳內交換機（和兩個路由器）獲得連線，因此係統可以在高效能區域網內執行。
現在，幾乎所有在系統中收集的資料只會在本地儲存極短的時間，之後會被上傳到雲端。 資料儲存的流程可能會在未來改變，但目前的策略使我們早期的系統部署非常簡單，並使資料更易於管理。
由於我們擁有一個高度可用的Kubernetes叢集，並且在所有節點上都複製了資料，我們可以保留所有收集的資料，直到網際網路再次可用於資料傳輸為止。 我們還可以根據業務需求在Edge上動態聚合，壓縮或刪除資料。
考慮到以上特性，我們仍然首先使用雲來提供我們的服務。 Edge可以當做一個高可用，低延遲，供餐廳內使用的必不可少的後備部署系統。
跟隨巨人的腳步
我們在消費級硬體上執行我們的邊緣基礎設施，大約花費是1000美元/餐廳。 我們希望硬體投資保持低成本和可擴充套件性。 我們目前還未找到方法讓硬體系統的增加變得動態/有彈性，但也許有一天可以做到。
藉助我們的架構，可以根據需求來新增其他裝置以增加額外的計算容量。我們的硬體系統足夠應付當前的工作量，未來我們可能會擴大硬體裝置空間。 谷歌也開始在商品硬體上增加工作負載。所以我們的方向是對的。
我們希望自己的邊緣計算系統可以鼓勵那些受限於有限資源（物理空間，預算或其他方面）的人進行創造性思考。 簡單來說每個人都有這樣的需求。
其他
最後，我們有連線層和物聯網的問題需要解決。 許多裝置都是直接供電的（沒有電池），但仍然受到晶片/處理能力的限制。 Wi-Fi是裝置預設的連線方法。 我們尚未致力於使用低功耗協議，但對LoRa和WiFi Halo（802.11ah）等專案感興趣。
對於物聯網和物理裝置，我們的團隊還為開發人員提供了一個SDK，用於執行入職流程（基於OAuth）和訪問Edge環境中的服務，如MQTT。 Brian在QConNY 2017上更廣泛地討論了這個問題（注意，我們當時使用的是Docker Swarm與Kubernetes）。
邊緣系統中功能
為什麼要在Edge系統中執行一些功能呢？ 出於同樣的原因，您可以在雲中（或其他任何地方）執行它們。
因為專案管理和測試會變得更加容易。 開發人員體驗更輕鬆，更好。 團隊可以更快，更自主地執行計劃，尤其是在有合理的抽象點（例如k8s名稱空間）和資源限制（CPU / RAM）時。
另一個設計的關鍵目標是保證關鍵應用的可靠性，這意味著架構中不可以出現任何單點故障。 可以通過多種方式實現此類目標，但我們認為在Edge系統上擁有多個物理主機，並且依靠基於功能的業務流程，可以讓我們執行多種工作負載並且最大化發揮團隊人員的技能。
我們最初稱我們的策略為“餐廳冗餘計算”，它真正說明了我們的方法背後的目標。 後來，我們改稱為“邊緣計算”。
能夠有效地協調服務並快速一致地保留所需數量的資料副本，Kubernetes這些能力吸引了我們。
為什麼選擇Kubernetes？
起初，我們計劃使用Docker Swarm進行容器編排，但是在2018年初轉向Kubernetes，因為我們相信它的核心功能和周圍的生態系統（迄今為止）是最強的。 我們很慶幸用Kubernetes相關的一些開發程式，如Istio和OpenFaaS。
最重要的是，我們堅信：創意本身並沒有價值，程式碼本身沒有任何價值，唯一有價值的是在生產中執行的程式碼。 只有這樣，我們才能為使用者創造價值，並有機會改善自己的業務。
因此，在Chick-fil-A，我們希望優化好的想法，將它們轉換為程式碼，並儘可能快地在生產中部署程式碼。
研究表明，使用最新最好的技術（如Kubernetes）與團隊或組織的成功無關。將想法轉化為程式碼並快速將程式碼投入生產的能力才是最重要的。
如果您可以通過VMWare，一臺計算機，一些其他叢集工具或業務流程層或僅使用雲來實現此目標，我們就不會試圖說服你切換到Kubernetes並跟隨我們的選擇。 通常，最簡單的解決方案才是最佳解決方案。
在Chick-fil-A，我們認為實現這些目標的最佳方式是接受叢集化，並使用Kubernetes系統。 在每一天結束時，它都可以幫助顧客更多更好地“多吃雞”（Eat More Chicken該餐廳標誌為一隻雞的頭像）。