作者 ｜ Regis Wilson
譯者 ｜ 劉雅夢
策劃 ｜ Tina
Kubernetes 為何如此難用？本文給出了 4 個原因，並指出瞭如何做才能使其易於使用。
介 紹
Kubernetes（k8s）在過去幾年曾經風靡一時，因為對於執行容器的生產工作負載來說，應用程式編排已經成為事實上的牌局需求。“容器化”應用程式相對簡單，大多數稱職的 DevOps 工程師都能建立一些 Dockerfile，並都能在準備執行的管道中構建映象。但是你在哪裡“執行”你的 Docker 容器呢？你要部署哪些版本呢？所有的容器是如何相互通訊的呢？這就是編排發揮作用的地方，也是大型供應商提供某些選項的地方。在撰寫本文時，有兩個主要的選項可用：來自 Amazon Web Services（AWS）的彈性容器服務（Elastic Container Service，ECS）及所有基礎設施即服務（IaaS）提供商（甚至包括 AWS）提供的 Kubernetes。
編排的希望在於：能夠使公司快速、輕鬆地將其容器化的應用程式交付到測試和整合環境中。理想的情況是“就是這麼好用”（ “ it just works”），也就是說，在看到應用程式在你面前執行之前，你只需要放鬆下手指並等待幾分鐘。理想情況下，你只需要指定執行應用程式所需的最少資訊（名稱、框架、依賴項等等，但這些最好也是從現有的可用配置檔案中讀取）即可。這就是編排希望的全部。
顯然，從標題上看，我們關注的是 Kubernetes，主要是因為它是無處不在的，唯一例外的其他選項就是 ECS，但這也正好證明了我們論文的觀點：Kubernetes 很難使用，因為 AWS 提出了自己的解決方案，並且更易於使用。但是為什麼 Kubernetes 這麼難用呢？用 K8s 執行應用程式需要多長時間？為什麼它不易於使用呢？
Kubernetes 的基礎設定很難用
即使大多數公司不會自己構建自己的 Kubernetes 叢集，我們也要從基礎設施開始。如果你打算使用託管基礎設施服務，那麼 K8s 將是首選。我敢肯定有些人會在自己膝上型電腦上啟動 minikube，然後對自己說，“哇，這太簡單了！我可以自己做！！”這讓我想起了那些在膝上型電腦上啟動 Elasticsearch 容器的人，他們會說，“哇，我們應該在我們的網站實現這個！！”。快進到六個月或一年後的產品釋出，簡單的“我們自己能做到”的口號變成了“我希望我們不必再這樣做了。”
如果你真的要構建自己的 Kubernetes 叢集，那麼你需要透過所選擇的 IaaS 在你的裸機或虛擬機器（VM）上構建所有的控制平面（control plane）伺服器和服務，然後使用一些奇特的網路配置將它們連線在一起，以將控制平面流量與容器流量分開。你需要配置和執行所有的控制平面軟體，並讓它們相互通訊，穩定執行並進行適當的監控。有悖常理的是，你需要編排用於編排應用程式的容器，但又無需進行大量的編排！當你在 Windows 上執行 minikube 或 Docker Desktop 時，你會看到一個奇妙的幻影，它隱藏了所有使用容器執行容器編排系統的初始狀態。
我們甚至還沒有談到 Ingress（通常就是 nginx 例項）和位於控制平面堆疊頂部或旁邊的負載平衡器的複雜性。很多時候，你會覺得自己在建立一個完整的基礎設施，只是為了讓你的基礎設施執行（這並不罕見，但肯定不會比你自己嘗試編排更好）。我們還沒有深入瞭解基於角色的身份驗證控制（Role Based Authentication Controls）和網路策略，這些需要設定成能支援在一個叢集中執行的多個應用程式或堆疊。配置點和伺服器端設定的數量開始迅速增加，我們甚至還沒有開始編排應用程式，這才是我們建立編排系統的意義所在。
讓我們假設你確實踏入到了波濤洶湧冰冷刺骨的北大西洋深處，併為自己建造了一艘具有生產價值的船隻，可以將你的容器編排成一個實際的應用程式。你回過頭來看下日曆，從你開始到現在已經過去了六個月或者一年，你現在正在部署一個控制平面，上面寫著“你好，世界！”（“Hello World！”）你認為自己成功了，正要慶祝一下，但檢視網站上的釋出板塊時，卻發現你又有一個新版的 k8s 要部署！！！
我聽到你們在說什麼了，“我們是一家大公司，我們有很多 DevOps 工程師，他們是全世界最頂尖的工程人才。我們能夠應付所有這些繁重的工作。你只是個愛發牢騷、愛嫉妒的孩子。”我看到你了，Datadog 和 Ticketmaster。（順便說一句，你對嫉妒的指責可能是對的。在我的好朋友 Justin Dean 的主題演講結束時，他展示了所有團隊成員的幻燈片，我的照片應該在上面——但我兩年前就離開了團隊。）對於其他所有人來說，我們一致決定不花六個月或一年的時間來構建自己的控制平面，只是啟動我們 IaaS 供應商的託管服務，然後祈禱就好了。
k8s 的 YAML 不是標記語言
如果你已經跳過了前面的內容，並且剛剛啟動了一個託管的 k8s 叢集，你仍需經歷一段漫長而乏味的旅程，會陷入 YAML 這個令人困惑的深淵。YAML 之於文字就像詹姆斯·喬伊斯（James Joyce）的《芬尼根的守靈》（Finnegan’s Wake）之於英語一樣。如果你閉上一隻眼，只用左手的小拇指和右手的大拇指跟隨幾個巴西音，把你的腳放在芭蕾舞的第五個姿勢，然後再低聲背誦二戰密碼，那麼你就會很容易看出 YAML 是相當容易理解的了。一旦你掌握了它的竅門，就像騎腳踏車在一個冰凍的湖面上，雖然冰只有釐米厚，但狂野的狼在追你。這就像闖入了黃金大劫案時期在諾克斯堡（Fort Knox）舉行的遠古外星人（Ancient Aliens）雞尾酒會一樣簡單。
看，實際上並不難，對吧？假設有一個人在街上向你走來。他是一位 k8s 專家，他將要向你展示部署“你好，世界！”這個 Web 服務是多麼簡單。對話是這樣的：
這只是試著去閱讀和理解檔案。嘗試閱讀兩個 k8s yaml 示例，然後從頭開始自己編寫一個。更好的方法是，每天都嘗試一種 CodeKata 實踐，編寫可執行可部署的 Kubernetes 配置。
複製貼上不是程式碼
我還在為上一節的內容而暗自發笑，因為這是我每天生活中的日常痛苦點，而直面這種痛苦就像是站在高速公路上 Keanu Reeves 駕駛的公共汽車面前一樣。唯一能讓我繼續埋頭苦幹的是我意識到使用 NodeJs 會更糟。問題在於 Kubernetes 的文件相當好。你複製貼上一些“你好，世界！”的示例，輸出看起來就可以工作。你開始很擅長使用 kubectl 了。你可以在 YAML 中看到模糊的形狀和輪廓。你開始有了信心，相信自己也許能做一些有用的事情。
“讓我們嘗試將應用程式遷移到 Kubernetes！“當你全身溼淋淋地從浴缸裡出來、只裹著一條毛巾時，你大喊大叫，就像阿基米德（Archimedes）在雪城（Syracuse）的街道上奔跑一樣。“我們只需在這裡複製一些片段，然後貼上到那裡，就可以立即執行我們的應用程式了，”你屏息向同事解釋。“行嗎？！“他們興奮地問。“還不行。我是說，還需要縮排下這個片段，刪除一個在這個規範中沒有使用的片段。然後需要決定是使用部署（deployment）或守護程式（daemonset），但它肯定能行的。我發誓！”
首先，穿上衣服。我完全贊成一邊洗澡一邊思考 kubernetes YAML 檔案，但你需要先穿好衣服。另外，我知道如果你把 Macbook Air 丟進浴缸，結果可能會更另讓人激動。其次，這裡有一個謎團：你認為執行和部署應用程式需要多少個 YAML 檔案？幸好人有十個手指和十個腳趾，這是件好事，因為這可能就是你需要的數量。它們都是相關的，但又並沒有真正的關聯。如果你喜歡冒險且容易上當受騙，你可以複製貼上這些片段，但是你不知道這些片段是否相容。只有四個必填欄位，但都是亂碼，所有內容都在 spec：（包括 spec：）下。大部分都是重複的，但都又只重複一點。它們在宏觀上是相同的部分在微觀上其實是不同的。
複製貼上是一門很棒的藝術，我個人的整個職業生涯都是這樣。我很高興地承認，我生活中的所有產出就像是從 stack overflow 和文件示例中剪下的勒索信（ransom note）。但是，透過拼湊這張脆弱的文字網來做實際上本該很簡單且明顯的事情是乏味且容易出錯的，而且這也是被反覆驗證的結果。更好的方法是表達你想要什麼，並且能夠實際地發出可操作的、可執行的程式碼來產生你想要的結果：即應用程式執行。
所有關於 YAML 的抱怨都很有趣，但實際上這也是原因的徵兆：Kubernetes 如此難用，因為介面必須是完全剛性的。K8s 的配置不是活生生的、雄偉的樹木，而是一堆枯木。它們比砍掉的木頭還要糟糕，它們是整片石化的森林，巨大的岩石堆，上面印著幾千年的年輪，已經被儲存了數百萬年。
不，它們比石化的森林還糟糕！Kubernetes 所展示的是二十一世紀的打孔卡片。每一個 YAML 都是一個孔的集合，這些孔被戳進我們無法閱讀和理解的碎木卡中，我們盲目地將這些孔塞進 kubectl apply-f 命令中，並且我們希望能以正確的順序放置它們，在堆疊中的任何地方都沒有放錯孔。然後，就像過去的機器一樣，我們試圖透過觀察閃爍的燈光和模糊的錄音帶輸出來瞭解正在發生的事情，並希望能夠收集到一些資訊。
就像嘗試在自動鋼琴上重現莫扎特（Mozart）或貝多芬（Beethoven）的音樂一樣，是一件乏味、費力、容易出錯並且最終無法實現的事情，同樣，k8s 的表現形式也會被永久凍結，無法表達性地寫出來，而且會無限地演奏同一首曲子。儘管 v1 已經推出兩年了，但人們仍然使用 v1beta1，原因是從那時起就沒有人再生成新的 k8s 配置了。
很難除錯
k8s 最棒的地方在於：當出現問題時，沒人知道。我已經數不清有多少次我部署了一些東西，然後投入到其他事情中去了，幾個小時後回來，發現部署悄然失敗了，沒有人通知我。只有幾個地方的錯誤資訊是可用的：部署日誌中的還是在 pod 日誌中？ingress 或 ingress 部署是否還在執行？在數十個 Kind 檔案中，日誌條目會出現在哪裡？根本原因通常是一些不相關的問題：一個錯誤的、看不見的空格；應該用雙引號但沒有用；應該用單引號也沒有用；或者三週前在修復複製 - 貼上問題時，縮排被破壞了。
當然，有一些工具、技術和監控工具可以幫助我們解決這個問題；這就像埃隆·馬斯克（Elon Musk）的火星軌道飛行器 MVP：“這有用嗎？“當然！！一千次，都是的！“它有什麼用？“它幾乎是你想要的任何東西！”你必須知道要找什麼，在哪裡找，然後必須知道如何找出解決方法，那麼你就必須知道在這數十個檔案中哪一行或哪幾行需要修復，然後你也必須要知道如何修復它們。
k8s 的另一個優點是你擁有了它就擁有了一切。聽著：朋友（friendo），夥計（pal），老兄（buddy），你選擇了這種存在。你複製貼上的“程式碼”。文件示例可以起作用。我可以在我的膝上型電腦上執行“你好，世界！”，很明顯，這都是你的功勞。你就是那個穿著毛巾溼漉漉地跑過辦公室喊“Kubernetes！”的人，如果希波克拉底誓言（Hippocratic oath）是“不要傷天害理”（“Do no harm” ），那麼 Devops 的誓言可能就是“別做壞事，否則你將被解僱。”
而 k8s 最偉大之處在於：有很多人和公司聲稱他們知道發生了什麼、該怎麼辦，他們會很樂意拿著你的錢來告訴你這是不是真的。在搜尋引擎中輸入 Kubernetes，就可以看到所有彈出的廣告。本文就是該問題的一部分，也是解決方案的一部分，所以請繼續聽下去。
最後，解決方案
有幾種方法可以使 Kubernetes 更易於使用：
不要用 k8s： run，尖叫著逃命吧
訓練所有的人都來解決這個問題（當你完成後再來找我；我可能還活著。也許已經不在了。）
為你的團隊僱傭更多的人來解決這個問題（我有空，打電話給我。哈哈，開玩笑的。）
請別人幫你做
等待更長的時間，少花錢多辦事，最終選擇做一些不可怕的事情
尋找一種解決方案，將你的應用程式部署到適合你的環境中，然後繼續進行你實際上從事的任何業務。自動化工具和服務可以幫助你執行應用程式，而無需對上述活動進行投資。總得有人去做，但最好不是你。
https：//releasehub。com/blog/why-kubernetes-is-so-hard
