作者 | Alex Hewson

譯者 | 彎月，責編 |?鄭麗媛

頭圖 | CSDN 下載自視覺中國

出品 | CSDN（ID：CSDNnews）

以下為譯文：

我經常聽到有人問這樣一個問題：“我們應該將自家的技術棧托管到Kubernetes上嗎？”不論是新建立的團隊還是成熟的團隊，都有這樣的疑問。鑒于Kubernetes在科技圈內的火熱，相信許多人的答案都是肯定的。

我使用K8s已經很多年了，經常與功能非常強大及復雜的平臺打交道，而我認為這個問題的答案有點微妙。

在本文中，我將盡力為大家解開謎團。我不僅會考慮創業小公司的情況，而且也會考慮在更廣泛的組織中負責托管自家產品的自給自足的團隊，最后還希望為大型組織中更傳統的IT部門人員提供參考價值。

Kubernetes有什么幫助性？

Kubernetes不僅僅是2018年的一個熱門詞匯。這是一個功能強大且高度可擴展的系統，可以讓你利用一系列成熟的技術原語（Pod、服務、Ingress等）構建應用程序部署，然后還可以盡其所能讓實際狀態與你的所需狀態相匹配。當應用程序崩潰時，Kubernetes會重啟它們。當大量底層計算機消失時，Kubernetes會替換它們。如果你正在運行大量服務（可能是作為微服務架構開發的），而且你正在尋找高效、具有彈性以及良好部署的解決方案，則Kubernetes值得考慮。

你希望自己的服務具有基本的彈性？（答案必然是肯定的），那么可以在部署中運行多個副本，然后在這些副本之間實現流量均衡。

如果你的工作負載經常有突發流量（例如大量的API訪問），則可以通過自動擴展來根據需要增加容量。這可以為你節省很多錢，因為你無需長期承擔峰值容量的費用，同時還可以提供基本的負載量，保持平臺正常運行，并在有需要時增加副本。此外，如果你可以將隊列導入到系統中，則自動縮放也可用于基于隊列的工作負載。

擔心代碼遭到破壞？你可以配置存活探針和就緒探針，如果這兩個探針出現問題，則Kubernetes會自動重啟你的服務。同樣，對于硬件故障，我曾見過集群喪失了一半的節點，卻仍在正常運行，就好像什么都沒發生。配置以及維護良好的Kubernetes集群非常強大。如果有足夠的資源，你甚至可以嘗試運行“混亂的猴子”等混亂測試工具，以確保你的技術棧可以承受常規故障。

此外，Kubernetes還可以與CI工作流程完美地集成。最常見的模式（幾乎是所有項目的標準化規范）是，將鏡像推送到Docker容器倉庫，然后通過K8s加載鏡像。當然你也可以根據個人喜好，通過修改部署拉取新標簽或讓標簽指向新鏡像，并觸發K8s重新加載所有的Pod。在大多數情況下，部署可以完全自動化：如果你相信自己的測試和功能標記，則可以實現百分百的自動化（即連續交付）；如果你沒有那么大勇氣，則可以退一步，在構建后手動批準。無論采用哪種方式，開發人員都可以將大多數構建版本發布到集群，而無需Kubernetes專家的幫助。

與CI類似，Kubernetes可以標準化應用程序的日志記錄以及監控。這種做法不是Kubernetes特有的，但是能夠在整個集群范圍內將有關所有服務的數據統一收集到一個地方，可以極大地減輕調試的負擔。我曾見過一個非常優秀的例子：有人使用Fluentd，將應用程序中JSON結構的日志輸出通過管道傳輸到AWS CloudWatch，并通過Insights進行查詢。

最后，Kubernetes還可以極大地提高效率，不僅在托管的層面（即將盡可能多的應用程序塞入昂貴的EC2實例中），而且還可以減少開發人員花在部署軟件上的時間。人力成本高于計算機，因此對于大多數組織而言，后者才是最大的勝利。但Kubernetes并不是萬能的，我見過一些非常漂亮和高效的集群，但結果這些投資只是打了水漂。只有正確使用Kubernetes，才能節省資金。

Kubernetes適用于哪些情況？

首先考慮一下你的工作負載。你需要運行哪種應用程序？它們如何與彼此以及外界對話？根據經驗，我認為以下屬性表明你的技術棧非常適合Kubernetes：

• 從廣義上講，你是否遵循微服務架構？如果你只有一個應用程序，那么使用Kubernetes就大材小用了。你需要通過Docker打包應用程序，然后將其部署到K8s。不論什么項目，從第1天開始就這樣做，可以幫你思考各個服務之間的界限。
  

• 你的服務是否通過HTTP（或HTTPs）相互公開以及對外公開了（應該公開了吧，畢竟都已經2020年了）？這非常適合K8s的模型，你可以使用常規的Ingress控制器作為這些服務的入口。

• 你的應用程序適合負載均衡嗎？即沒有本地狀態（即使用PostgreSQL、Redis等產品），通過已知端點通信，能夠快速啟動和關閉。這并不是說集群中不能有Redis緩存等擁有短暫狀態的應用，但在許多情況下，最好還是使用云提供商提供的服務。

• Kubernetes非常適合無頭的應用程序，例如批處理（通過Job控制器）以及長期的隊列消費。

• 內存（以及擴展性更為有限的CPU）的使用是否可以預測？Kubernetes會設法將多個應用程序托管在同一臺物理計算機上，因此，如果其中一個應用程序遇到麻煩，并消耗了所有RAM，則其他工作負載可能會被隨機干掉。以我的經驗，這是Kubernetes集群中最大的不穩定因素。如果你了解應用程序的資源使用情況，則可以聲明resources.requests（資源請求）和resources.limits（資源約束），確保各個應用程序只能獲得所需的內存，而且不會打擾到其他應用程序。

相反，我認為以下這些工作負載不適合使用Kubernetes：

• 靜態網站。通常，使用Kubernetes的話，你需要將內容嵌入一個由Nginx派生而來的容器鏡像中，并通過集群的Ingress控制器公開網站。但這是一種糟糕的托管靜態內容的方式：所有Nginx的小副本都需要維護，效率低下，而且網絡層面的彈性/性能也非常低。當然，你可以將內容放在CDN后面，但如果要這樣做的話，為什么不直接讓云服務托管內容呢？

• 托管不信任的代碼。這可能意味著你的應用程序由客戶或其他第三方提供，有安全方面的隱患，例如NPM的Wordpress或其他有問題的庫。默認情況下，Kubernetes隔離工作負載的功能不是很好。雖然你可以添加諸如Calico之類的產品來控制網絡訪問，但很容易搞砸，而且你的安全模型將完全依賴于容器運行時。Kubernetes的默認設置（采用基于Linux cgroup的Docker）會導致有安全隱患的應用程序暴露大量的被攻擊點：如果集群運行的代碼庫遭到黑客攻擊，那么攻擊者很輕易就能進一步攻擊集群的其余部分。目前人們正在努力開發cgroup的替代方案（例如Kata Containers），但目前還不能向普通用戶推薦。

即便工作負載不合適，你仍然可以選擇將其添加到Kubernetes中（例如，可以通過卷保存長期狀態），但是需要花費大量的工程時間來解決各種問題。而且很多做法都不推薦，因此，最好還是將資源和時間花在設計更好的技術棧上。強推Kubernetes只會讓你的損失更慘重。

Kubernetes并非靈丹妙藥

Kubernetes并非靈丹妙藥。它可以幫助你將托管應用程序的復雜性轉移到精心設計的Kubernetes架構中，但這些復雜性本身并不會消失。你始終需要保護和維護平臺。

為了讓普通的工作負載也能使用集群，我們需要管理很多附加組件。有些附件幾乎每個人都在使用，則有些則比較小眾。其中包括Nginx（Ingress控制器）、cert-manager和cluster-autoscaler（在沒有足夠的容量時添加額外的節點）等。還有一些軟件專門為環境定制的關鍵功能非常獨特，而且也同樣需要管理。此外，這些組件也需要定期更新，有時可能還有質量問題。Helm或Terraform等配置管理工具幾乎是必須的：手動調整集群非常危險，而且沒有聲明式設置你根本沒辦法啟動另外一個一模一樣的集群。我親身經歷過在運維過程或替換成更成熟的集群時引發了無窮無盡的問題。

在Kubernetes上運行任何重要的技術棧，都需要縝密的策劃。放任員工隨意部署他們喜歡的軟件，只會讓你的集群陷入混亂。最終，你只能得到一堆層次不齊的應用程序散布在幾十個（甚至可能是一個）命名空間中，卻沒有人知道它們是如何組織在一起的。雖然舊的意大利面條式的基礎設施非常混亂，但如今你只是換成了一種新型的意大利面條式的基礎設施，最后還用一個更加冰涼的盤子端了上來。

我所見過的最成功的Kubernetes實現方式是：基礎設施專家與開發人員合作，確保工作負載的配置合理、標準化、相互保護，而且還有明確的通信模式。基礎設施專家負責在基礎設施上處理應用程序的初始設置，并將其連接到構建/發布系統，如此一來，開發團隊無需他們的幫助即可發布新版本的代碼。其實，這個過程反應的是組織廣泛的文化，如果你們的工程非常混亂，溝通不順暢，而且職責不明確，那么托管的環境都將逐一反映出來。即便使用Kubernetes，你們的系統也會非常不可靠；而且在最糟糕的情況下，不可靠之余，還會引發不可維護、成本昂貴等各種問題。

使用Kubernetes的成本

如果你需要運行大規模的應用程序，那么Kubernetes可以為你節省很多錢。你可以研究一下自動伸縮（集群和副本集的自動伸縮）、競價式實例池（EC2）或可搶占式虛擬機（Google）等功能。在大型環境中，僅此一項就足以讓你做出決定。

此外，Kubernetes還有一個優秀的工具生態系統，可以幫助任何工程師創建各種測試集群來測試應用程序。在這些工具的幫助下，Kubernetes的入門學習曲線非常平緩，因此很容易將其投入到生產環境中并成為業務的關鍵部分，卻沒有意識到這樣做所需的投資規模。Kubernetes的故障模式非常復雜，只有擁有大量專業技術才能充分利用。放任經驗不足的開發團隊急急忙忙地將集群搭建起來（使用Kops是常見的反模式），通常都會成為一場災難。雖然開頭的幾個月可以正常工作，但如果你需要進行重大更改，那么往往會在緊急關頭遭遇重新配置群集或故障排除某個已知的問題。

從零構建K8s集群的難度不亞于編譯自己的內核，這是一項艱巨的工作，需要學習底層的工作原理，以及怎樣運行生產應用程序的點點滴滴。因此，你應該使用現成的解決方案，例如AWS EKS或Google的GKE。很多精英人才投入了大量時間來解決這些問題，即使每個月你需要支付幾百美元也是值得的。

即使使用現成的Kubernetes發行版，你也需要專業技能。控制平面由亞馬遜負責，但是總有一天你會在節點上觸發一些晦澀的bug，而且往往是在業務最繁忙的時候。因此，你必須隨時準備好投入大量資源，而且可以接受相應的費用，才能運行系統。Kubernetes的發布周期很短，因此每年至少需要升級一次集群，還有API的定期改動，所以可千萬不要小覷這項工作。無論你運行什么插件，都需要維護。如果你的系統規模非常小，要求非常低，那么可以雇傭兼職人員，但請相信我，如果某天凌晨4點，你所有的容器都拋出了某個莫名的線程錯誤，那么你可能需要其他人的幫助。

所有這些都令我相信，規模/復雜性超過某個閾值，才能高效地使用Kubernetes。如果你運行的服務很少（比如<5個）、很簡單、需求不高，那么就不必再糾結了。只有當需要管理大量部署、工作負載變化繁多或標準化工具可以節省大量復雜性/成本的情況下，Kubernetes才能大展拳腳。

所以，我應該使用Kubernetes嗎？

雖然我羅嗦了一大堆，但最終的答案仍然是：“視情況而定”。或許你可以馬上繪制一張系統架構圖。

如果你只有寥寥幾個服務，而且短期內不會增加，那么簡單又廉價的方式就是托管技術棧。你可以看看AWS ECS（尤其是與Fargate結合使用），將你的API或批處理作業重寫為Lambdas / Cloud Functions，甚至還可以將你的應用程序托管給PaaS提供商（比如Heroku）。這種方式聽起來雖然老套，但不要忽視在幾臺維護良好的Linux機器上運行簡單的低流量應用程序所帶來的價值和穩定性。

另外，安全性和合規性要求可能會影響你的決定。如果必須將工作負載托管到內部硬件上，則你可能需要承擔大量的運維開銷，盡管你也可以使用Kubernetes，但傳統的解決方案可能更適合你。根據合規性的要求，審核所有使用的插件可能不太現實。

我見過很多創業公司，他們以為自己需要Kubernetes，最終卻白白投入了大量資源。所以，請認真思考你是否需要所有的功能，以及是否有能力承擔良好的實現。如果你的需求證明這些投資很合理，則當然應該下手。否則，你可以將Kubernetes作為備選，考慮將來引入Kubernetes的渠道，以及如何將其納入你的技術決策中。如果決定使用Kubernetes，那么從第1天開始就應該在Docker中運行應用程序（使用docker-compose，對于開發人員和生產人員都非常有價值），而且需要考慮清楚是否讓應用程序存儲本地狀態。

另一方面，預測未來的增長幅度也非常重要。如果現今你只有幾個簡單的服務，則可能不需要K8s。但是，它們是否會突飛猛進地發展成幾十種呢？如果是，那么你現在就應該開始學習掌握這種復雜性的技術。雖然在雙翼飛機的年代，沒有人想著建造波音747；但另一方面，如果你需要承載300名乘客，則索普威思駱駝飛機絕對解決不了問題。

綜上所述，基礎設施的決策通常取決于軟件體系結構方面的抉擇。在選擇基礎設施時，你不能后知后覺，但也不要忘記基礎設施越多成本就越高。如果有需要，你可以投資復雜的系統，但一定要三思而后行。

原文：https://mbird.biz/writing/do-i-need-kubernetes.html

本文為 CSDN 翻譯，轉載請注明來源出處。

更多閱讀推薦

• 閑魚的云原生故事：靠什么支撐起萬億的交易規模？

• 野雞大學怎么知道考生電話的？

• 達摩院NLP團隊斬獲六項世界冠軍背后，讓AI沒有難懂的語言
  

• 我把這篇文章給女朋友看，她終于明白什么是「數據中臺」了

• 云交易所已成資金盤、殺豬盤重災區，曾被寄予厚望，如今罪惡叢生
  

總結

以上是生活随笔為你收集整理的Kubernetes 并非灵丹妙药...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。