【編者的話】本文主要探討為何多數中小企業並不傾向使用Kubernetes，同時介紹了Kubernetes的部分特性，包括可擴充套件性及複雜性等。另外，本文亦將闡述Kubernetes相對於ECS、Swarm的關鍵性比較優勢。
Kubernetes是否存在“殺敵一千，自損八百”的問題？
很多朋友可能都思考過這個問題，特別是考慮到大部分中型SaaS、網路及電子商務企業早晚要放棄HeroKu（一款支援多種程式語言的雲平臺），（每個人最終都將放棄Heroku。）而最終決定到底該選擇AWS、Docker Swarm或者是其它更為“簡單”的解決方案——當然，也包括直接投向Kubernetes的懷抱。
由Heroku遷移至AWS、Docker Swarm或者是其它自主開發型解決方案的作法，往往會給我們帶來一些自尋麻煩且本可避免的常見陷阱。這是因為上述解決方案初看起來似乎比Kubernetes更為簡單，但從長遠的角度講卻常會帶來更嚴重的侷限性、更難以解決的挑戰以及更為可觀的開銷。由於單純逃離Heroku並不足以幫助我們擺脫這些恐怖的噩夢，因此目前很多公司開始在猶豫當中選擇Kubernetes。下面，我們將對原因作出具體闡述。
Kubernetes：一切源自可擴充套件性
中小型企業之所以拒絕選擇Kubernetes，一個很普遍的原因就是其可擴充套件性。CTO可能會說，“我只擁有一款Rails程式，一套簡單的傳統EC2虛擬機器就足以解決問題。Kubernetes處處都在考慮擴充套件——而我不需要這麼誇張的可擴充套件能力。”
但這正是問題所在：並非所有的基礎架構都需要進行由數十到數千的大規模節點擴充套件（但是，大家至少需要兩個節點，從而儘可能降低當機事故的可能性）。千萬別被擴充套件性所誤導——Kubernetes的優勢絕不僅限於擴充套件性。
對於新手來講，如果你的Rails應用記憶體不足並引發當機，則執行在普通EC2的例項上的此類應用程式將不會自動重啟； 這意味著運維人員需要隨時待命以解決問題。另外，Kubernetes擁有自動執行狀態檢查機制，因此如果你的應用程式因某種原因而無法響應——包括執行時記憶體不足或者遭遇鎖死，Kubernetes都會自動進行重啟。Kubernetes還能夠輕鬆基於分支環境進行開發，這一點在EC2例項當中同樣幾乎無法實現。
思考一下——您打算如何運用更高可用性、自動擴充套件性以及更為豐富的功能等重要優勢？
意外複雜性與必要複雜性
中小型公司拒絕Kubernetes的另一個原因在於複雜性。
事實上，Kubernetes確實相當複雜。不可否認，Kubernetes的啟動與執行皆難於上手。但這種複雜性也從另一個側面反映出Kubernetes的傾向性。
早在1960年代，弗雷德·布魯克斯（Fred Brooks）立足電腦科學領域撰寫了一本名為《人月神話》的開創性著作。在書中，他討論了他的團隊在構建IBM大型機OS/360系統時的所見所感。他提到了兩種系統性複雜因素：意外複雜性與必要複雜性。意外複雜性屬於一類隨機介入的因素（屬於負面型別），而必要複雜性則屬於完成工作所必需的因素（正面型別）。
ECS與Docker Swarm表面上看起來更簡單，但卻皆具有更多的意外複雜性，並會將這些複雜性直接傳遞給使用者。這種複雜性在初始階段往往並不明顯。那麼這種意外複雜性到底有何表現？首先，大家需要彌補系統在能力方面的缺失。比如：ECS要求使用者編寫大量程式碼以實現可用性（有時需要成百上千行程式碼）。這些工具的使用還受到架構層面的限制，同時帶來陡峭的學習曲線。
在另一方面，Kubernetes的意外複雜性很低而必要複雜性很高（實現使用者實際想要實現的目標所需要的複雜性）。Kubernetes之所以如此強大，是因為它已經是谷歌的第三代容器管理技術——而Swarm與ECS還只是第一代。
Kubernetes的“稅收”
部分企業並不擔心Kubernetes的複雜性，而是擔心這種複雜性無法帶來應有的回報。他們擔心技術團隊在Kubernetes上付出很高的“稅收”，但最終卻沒能因此獲得足夠的價值。
為了避免這種“稅收”，他們會僱傭一支技術水平高超的運維團隊並希望其能帶來理想結果。毫無疑問，如果給予他們充分的發揮空間，他們一定會選擇自行構建一套基於Kubernetes的平臺。但如果許可權不足，他們會嘗試從零開始構建起類似於Kubernetes的解決方案（我們將其稱為‘偽Kubernetes’），而這顯然會給公司帶來技術債務。（因為在自行構建時，大家最終得到的一定只是是一套錯誤且成本更為高昂的Heroku變種。這一點已經在雲基礎架構的第十條法則中進行過充分論證。）
當你的目標是構建產品時，為什麼要將有限的資源浪費在運營任務身上呢？如果你不需要或者至少不必從零開始構建自己的Heroku，為什麼要僱傭那麼多運維工程師呢？我們將在本系列的下一篇文章中就這一話題展開探討，即：你的開發人員是如何變“壞”的。
內容展望？
運維諮詢：利用我們數十年的運維專業知識幫助您完成雲端遷移，讓你的架構擁有自動化能力並將你的SaaS與Web應用提升至新的水平。
運維服務：與專家合作維護你的運維平臺，同時負責各類日常運營問題——這意味著您不再需要招聘全職運維人員進行產品開發與交付。
原文連結：Is Kubernetes Overkill?（翻譯：康良）