你（多半）不需要 Kubernetes

這也許是一個不太受歡迎的觀點，但大多數主流公司最好不要再使用 k8s 了。

你知道那個古老的「以程序員技能寫 Hello world 」笑話嗎？—— 從一個新手程序員的 printf("hello, worldn") 語句開始，最後結束於高級軟體架構工程師令人費解的 Java OOP 模式設計。使用 k8s 就有點像這樣。

• 新手系統管理員：

./binary

• 有經驗的系統管理員：

在 EC2 上的 ./binary

• DevOp：

在 EC2 上自部署的 CI 管道運行 ./binary

• 高級雲編排工程師：

在 EC2 上通過 k8s 編排的自部署 CI 管道運行 ./binary

¯_(ツ)_/¯

這不意味著 Kubernetes 或者任何這樣的東西本身都是壞的，就像 Java 或者 OOP 設計本身並不是壞的一樣，但是，在很多情況下，它們被嚴重地誤用，就像在一個 hello world 的程序中可怕地誤用 Java 面向對象設計模式一樣。對大多數公司而言，系統運維從根本上來說並不十分複雜，此時在這上面應用 k8s 起效甚微。

複雜性本質上來說創造了工作，我十分懷疑使用 k8s 對大多數使用者來說是省時的這一說法。這就好像花一天時間來寫一個腳本，用來自動完成一些你一個月進行一次，每次只花 10 分鐘完成的工作。這不是一個好的時間投資（特別是你可能會在未來由於擴展或調試這個腳本而進一步投入的更多時間）。

你的部署大概應該需要自動化 – 以免你 最終像 Knightmare 那樣 —— 但 k8s 通常可以被一個簡單的 shell 腳本所替代。

在我們公司，系統運維團隊用了很多時間來設置 k8s 。他們還不得不用了很大一部分時間來更新到新一點的版本（1.6 ➙ 1.8）。結果是如果沒有真正深入理解 k8s ，有些東西就沒人會真的明白，甚至連深入理解 k8s 這一點也很難（那些 YAML 文件，哦呦！）

在我能自己調試和修復部署問題之前 —— 現在這更難了，我理解基本概念，但在真正調試實際問題的時候，它們並不是那麼有用。我不經常用 k8s 足以證明這點。

k8s 真的很難這點並不是什麼新看法，這也是為什麼現在會有這麼多 「k8s 簡單用」的解決方案。在 k8s 上再添一層來「讓它更簡單」的方法讓我覺得，呃，不明智。複雜性並沒有消失，你只是把它藏起來了。

以前我說過很多次：在確定一樣東西是否「簡單」時，我最關心的不是寫東西的時候有多簡單，而是當失敗的時候調試起來有多容易。包裝 k8s 並不會讓調試更加簡單，恰恰相反，它讓事情更加困難了。

Blaise Pascal 有一句名言：

幾乎所有的痛苦都來自於我們不善於在房間里獨處。

k8s —— 略微拓展一下，Docker —— 似乎就是這樣的例子。許多人似乎迷失在當下的興奮中，覺得 「k8s 就是這麼回事！」，就像有些人迷失在 Java OOP 剛出來時的興奮中一樣，所以一切都必須從「舊」方法轉為「新」方法，即使「舊」方法依然可行。

有時候 IT 產業挺蠢的。

或者用 一條推特 來總結:

• 2014 - 我們必須採用 #微服務 來解決獨石應用的所有問題
• 2016 - 我們必須採用 #docker 來解決微服務的所有問題
• 2018 - 我們必須採用 #kubernetes 來解決 docker 的所有問題

你可以通過 martin@arp242.net 給我發郵件或者 創建 GitHub issue 來給我反饋或提出問題等。

via: https://arp242.net/weblog/dont-need-k8s.html

作者：Martin Tournoij 選題：lujun9972 譯者：beamrolling 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive