對於 Kubernetes 的迷思

在過去的 10 年裏，通過我的諮詢工作，我有機會了解到很多公司的基礎設施和系統架構。在許多企業中，Kubernetes 和 Apache Kafka 已經變得非常普遍和流行，但這往往不是爲了發展更好。

Kubernetes 和 Kafka：夢之隊還是恐怖秀？

#01

這一切是如何開始的

有一天，我認識了幾年的一家中型軟件公司的 CEO 給我打電話尋求建議。他們的 SaaS 產品運行良好，並在過去幾十年中做的很成功，獲得了可觀的收益。他們成功地從一款面向 Windows 的桌面軟件產品過渡到了具有現代事件驅動微服務架構的先進 Web-based SaaS 產品。

我查看了我的日程，安排了一天的時間與他、他的產品和開發團隊進行面談。我很確定這只是一天的面談、技術討論，然後爲他撰寫一份有 5 頁內容的最終報告。

管理層開始有了直觀感受

我到達的那天，他在辦公室裏迎接我，我們在喝咖啡時進行了簡短的交談。這時，我第一次聽到他希望我審查他的團隊正在做的事情的實際原因。他的公司每年的營業額達到百萬歐元的中等收入，開發和運維預算大約佔總收入的 10%，不包括員工成本。利潤率都不錯，運營成本仍在可接受的範圍內。經過一些閒聊，他終於告訴我他爲什麼希望我前來審查他的產品團隊。

“我們的可用性只有 87%，而我們的服務級別協議規定爲 95%，我在下一個財年的運維預算中額外撥款了 50 萬歐元。目前我們還沒有收到客戶投訴，但我對我們的服務質量和運維成本的上升感到擔憂。請幫忙看看在服務質量和運維成本方面是否有改進的空間。”

對於這樣一家規模較小的公司來說，額外投資 50 萬歐元是一個巨大的決定，我理解他爲什麼希望聽取其他人的意見。此外，87% 的可用性非常糟糕，即使在 2019 年也是如此。87% 意味着他們至少有 40 天的停機時間。即使他們的服務級別協議達到了 95%，仍然意味着至少有兩週的停機時間。SaaS 在一年內的服務級別協議大多在 97-99% 之間。即使是 97%，也相當於 11 天的停機時間。

爲什麼選擇 Kubernetes 和 Kafka？

他的公司沒有龐大的管理層，他自己擁有並經營着這家企業。他有一些運維人員、開發人員、產品和研發經理。他們在現代化應用程序時使用了一個大型代碼倉庫託管服務，並使用 Jenkins 作爲他們的持續集成 / 持續交付（CI/CD）流水線，將每個微服務部署到一個 Kubernetes 集羣中。微服務之間的通信通過 Kafka 實現。

作爲諮詢顧問，我會在得出結論之前收集信息。因此，我瞭解了團隊選擇 Kubernetes 和 Kafka 的原因。他們的原因很簡單：在現代化應用程序時，他們請了一位顧問來設計他們的基礎架構，其中包括使用 Kubernetes 來運行重構和現代化的應用程序，並通過 Kafka 進行消息傳遞。

他們的團隊非常開放，我獲得了所有的統計數據。他們在努力維持系統和基礎設施的正常運行，並對我能提供的任何指導表示感激。這是我瞭解中型企業時常見的情況。他們總是面臨資源限制，難以招募到足夠的人員。招聘時，他們總是難以與大型科技巨頭競爭。

#02

我們是否可以拋棄這一切？

當初起草現代化和遷移計劃的顧問早已離職，公司對於對重新聘請他回來似乎並不感興趣。運維和工程團隊的成員對他們的 Kubernetes 和 Kafka 配置並沒有過多的熱情。在與團隊共進午餐時，一位運維人員問我，是否可以徹底拋棄這些技術，是否有更簡單的替代方案。

考慮到他們的吞吐量和資源利用情況，他們幾乎不會觸及 AWS 提供的無服務器方案的服務限制。他們甚至不會超過 AWS SNS 每秒 200 條消息的限制，更不用說達到 AWS SQS 隊列的限制了。他們使用 Kafka 的功能都可以通過 SNS 或 SQS 來實現。甚至不需要流式數據，因此無需考慮 AWS Kinesis 作爲替代方案。

由於他們已經在 AWS 上運行了 Kubernetes 和 Kafka，他們可以輕鬆遷移到無服務器方案（如 Lambda、API Gateway、SQS、SNS），並且在基礎設施費用方面也有很大的成本降低空間。但是，明顯的問題是他們在 Kubernetes 集羣的運維上花費了大量時間，而不是雲基礎設施本身的成本。

與雲無關的集羣混亂

我不喜歡責怪和指責那些不再參與的決策和人員。選擇 Kubernetes 和 Kafka 有其合理的原因。在審查了所有項目文檔之後，選擇 Kubernetes 和 Kafka 的主要原因是 “與雲無關”。在當時的某個時期，有人決定最好 “不依賴任何雲提供商”。我還有一種感覺，風險是 CEO 腦海中的一個考慮因素。

演示時間到了！我有一份用於這類情況的無服務器遷移的藍圖演示文稿。我進行了一次演示，解釋了團隊如何逐步遷移到 AWS 的無服務器方案，以及他們如何接受 AWS、SAM 和 CloudFormation 的培訓。

更重要的是，我提出了一份風險緩解的路線圖，概述了可能發生的，儘管非常不太可能的轉向 Google Cloud、Azure 或 OpenShift 的情況。我的藍圖甚至提供了完全的 “災難撤退至自建環境” 的選擇。儘管撤退到自建環境的選項聽起來有些荒謬，但通常能減輕大部分擔憂。

最終，我成功說服了團隊和管理層逐步採用無服務器方案。我還說服他們將他們已經爲代碼倉庫託管服務付費的 CI/CD 流水線取代他們的 Jenkins。我們達成了一致，我將在幾周後回來，查看事情的進展情況。

#03

幾個月後

在我離開他們的辦公室之後的幾個月裏（實際上我只呆了一天！），他們只偶爾向我諮詢一些問題，問題很少，以至於我甚至沒有向他們收費。最終，我只收取了最初的諮詢費用，因爲我熟識該公司的 CEO，所以我沒有對我們後來的短暫交流收費。

我偶爾詢問他們是否需要我親自前往，但他們拒絕了，稱一切都還好。我的諮詢業務並不是我的主要職業，我主要從事軟件開發工作，所以我並不追求儘可能多的收費小時數。大約在我訪問之後的 7 個月，他們邀請我對他們已經構建和遷移的系統進行一次架構審查。

我再次前往他們的辦公室，進行了一整天的會議。我們基本上沿着架構圖逐步審查了他們迄今爲止所構建的內容。說實話，並沒有太多令人驚訝的地方：微服務結構配合 API Gateway 和 Lambda，使用 SNS 的中央服務總線，以及一些使用 SQS 的分發架構。還有一些 DynamoDB 表和 S3 存儲桶。這些人知道他們在做什麼，除了點頭表示認同，我幾乎沒有什麼可做的事情了。

99.99% 的可用性和約 40% 的成本降低

從技術角度來看，他們的產品並不具備高度複雜性。他們產品的優勢在於與特定行業中客戶的現有生態系統緊密集成。他們還使用一些非常出色的功能，完全自動化了客戶的高度專業化業務流程。

總體而言，他們的產品涉及網頁前端、表單、數據庫、PDF 文件、API、Webhooks 等，並沒有太多其他複雜的內容。其中最 “複雜” 的系統可能是關係型數據庫和搜索引擎。對於普通的運維經理來說，這些並不會讓他們過於擔心。

毫不奇怪，由於他們的大部分基礎設施運維已經外包給了亞馬遜，他們的可用性顯著提高。他們通過遷移出 Kubernetes 的服務，成功削減了雲計算費用，因爲這些服務不再需要持續運行，而是按需調用。我們甚至從未討論過與 AWS Lambda 的冷啓動時間有關的問題。

他們正在深入進行他們的 AWS 雲之旅，其中一些人考慮獲得 AWS 認證，我感覺到他們在開始遷移到 AWS 的原生無服務器服務後，總體上更加平靜、輕鬆和快樂。在現場的僅僅一天時間裏，我的工作似乎已經完成得差不多了。

#04

不需要感謝

像這樣的挑戰只是 CEO 和管理團隊每天面臨的數百個挑戰之一。當你從事諮詢工作時，你知道幾乎不會得到感謝。他們對你的感謝就是將款項匯入你的企業賬戶，也許會給你一個推薦。就是這樣。

我不認爲運維和開發團隊知道他們離 CEO 說 “我需要通過人力資源來解決這個問題” 有多近。通常情況下，高級管理人員在無法理解技術挑戰時，會將問題解決歸結爲人力資源的問題，作爲最後的手段。這意味着管理人員試圖通過替換圍繞問題的一些人員來解決問題。

這是 Kubernetes 和 Kafka 的錯嗎？

從技術角度來看，Kubernetes 和 Kafka 並沒有任何問題，但它們已經成爲一個經濟問題。儘管從技術上來說，它們是非常出色的解決方案，但這家企業既沒有足夠的人力資源，也沒有財力資源來運維 Kubernetes 和 Kafka。而且，實際上，他們沒有任何有效的經濟理由來運維這些系統。

回過頭來看，這真是浪費金錢。當企業，更具體地說，內部的人員最初決定選擇 Kubernetes 和 Kafka 時，他們沒有與其他選擇（如 AWS、Google Cloud 或 Azure 上的無服務器方案）進行 TCO（總體擁有成本）的比較。

爲什麼 Kubernetes 可能讓你丟掉工作

Kubernetes 不是一種玩具。運維一個 Kubernetes 集羣需要人力、時間和預算。在我參與的大多數業務案例計算中，無論是從經濟角度還是與 Serverless 或多 AZ 部署的負載均衡器相比，Kubernetes 始終處於劣勢。我們談論的不僅僅是小差距。

無論你的技術水平有多高，如果 Kubernetes 集羣的 TCO 比下一個最佳替代方案高出 2-4 倍，你將會陷入麻煩。隨着越來越多的公司轉向 FaaS（函數即服務），只需進行盡職調查或技術審計，你就必須解釋爲什麼你選擇運行 Kubernetes 集羣。當管理層看到其他公司的基準測試時，“其他人都這樣做” 這樣的論點並不具有說服力。

結果可能是你的管理層會將 Kubernetes 集羣或昂貴的 Kafka 環境歸咎於你。我的建議是：積極主動地將你的 Kubernetes 和 / 或 Kafka 集羣的 TCO 與 AWS、Google Cloud、Azure 或 IBM/Red Hat 上的無服務器方案進行比較。評估你是否需要 Kubernetes 和 / 或 Kafka，以及爲什麼沒有合理的替代方案。

#05

它吞噬了你的薪水

當你在簡歷上寫擁有 Kafka 和 Kubernetes 的經驗時，看起來無疑很好，但如果你能通過放棄它們來節省 50 萬歐元的費用，那就更加出色了。僱主投入到過重的基礎設施和系統中的每一分錢，都是他們無法花在你身上、你的培訓和下一次薪資增加上的一分錢。

你更有可能因爲降低成本、提高服務質量和上市時間而獲得獎勵，而不是因爲擁有一個壯觀的 Kafka 或 Kubernetes 集羣。我還沒有遇到過一個會對 Kubernetes 集羣印象深刻的 CEO。

你有什麼經驗？你是否在大規模運行 Kubernetes 集羣，它們在經濟上與 Serverless 相比如何？你是否曾經成爲 Kubernetes 炒作的受害者？

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XyxfbRTkAx9nxk2Mv2GDqw