Kubernetes 爲什麼難用？

作者 ｜ Regis Wilson

譯者 ｜ 劉雅夢

策劃 ｜ Tina

Kubernetes 爲何如此難用？本文給出了 4 個原因，並指出瞭如何做才能使其易於使用。

1 介 紹

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 運行應用程序需要多長時間？爲什麼它不易於使用呢？

2Kubernetes 的基礎設置很難用

即使大多數公司不會自己構建自己的 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 服務是多麼簡單。對話是這樣的：

Him: “kind: Deployment”You: “Oh, I see. Yes, I like it.”Him: “apiVersion: apps/v1beta1.”You: “Uh, okay. Isn’t v1beta1 out of date? You can use v1 as of k8s 1.9.It’s actually removed in 1.16, but I wonder how many people have neverupdated.”Him: “Start over.”You: “Wat.”Him: “kind: Deployment”You: “Stop with the Kinds everywhere!”Him: “apiVersion: apps/v1”You: “This again.”Him: “spec:”You: “Huh??”Him: “selector:”You: “No.”Him: “matchLabels:”You: “Wat.”Him: “app: nginx”You: “That’s nearly the first thing I’ve understood about this so far.”Him: “spec:”You: “Again?”Him: “containers:”You: “Okay, now we’re getting somewhere.”Him: “image: nginx:1.14.2”You: “Hmm.”Him: “ports:”You: “Aiiiiieeee.”Him: “containerPort: 80”You: “I’m going home. I quit. There must be a devops job I can get whereI work on Gatsby blogsall day.”

這只是試着去閱讀和理解文件。嘗試閱讀兩個 k8s yaml 示例，然後從頭開始自己編寫一個。更好的方法是，每天都嘗試一種 CodeKata 實踐，編寫可運行可部署的 Kubernetes 配置。

3 複製粘貼不是代碼

我還在爲上一節的內容而暗自發笑，因爲這是我每天生活中的日常痛苦點，而直面這種痛苦就像是站在高速公路上 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 配置了。

4 很難調試

k8s 最棒的地方在於：當出現問題時，沒人知道。我已經數不清有多少次我部署了一些東西，然後投入到其他事情中去了，幾個小時後回來，發現部署悄然失敗了，沒有人通知我。只有幾個地方的錯誤信息是可用的：部署日誌中的還是在 pod 日誌中？ingress 或 ingress 部署是否還在運行？在數十個 Kind 文件中，日誌條目會出現在哪裏？根本原因通常是一些不相關的問題：一個錯誤的、看不見的空格；應該用雙引號但沒有用；應該用單引號也沒有用；或者三週前在修復複製 - 粘貼問題時，縮進被破壞了。

當然，有一些工具、技術和監控工具可以幫助我們解決這個問題；這就像埃隆 · 馬斯克（Elon Musk）的火星軌道飛行器 MVP：“這有用嗎？“當然！！一千次，都是的！“它有什麼用？“它幾乎是你想要的任何東西!” 你必須知道要找什麼，在哪裏找，然後必須知道如何找出解決方法，那麼你就必須知道在這數十個文件中哪一行或哪幾行需要修復，然後你也必須要知道如何修復它們。

k8s 的另一個優點是你擁有了它就擁有了一切。聽着：朋友（friendo），夥計（pal），老兄（buddy），你選擇了這種存在。你複製粘貼的 “代碼”。文檔示例可以起作用。我可以在我的筆記本電腦上運行“你好，世界！”，很明顯，這都是你的功勞。你就是那個穿着毛巾溼漉漉地跑過辦公室喊“Kubernetes！” 的人，如果希波克拉底誓言（Hippocratic oath）是“不要傷天害理”（“Do no harm” ），那麼 Devops 的誓言可能就是“別做壞事，否則你將被解僱。”

而 k8s 最偉大之處在於：有很多人和公司聲稱他們知道發生了什麼、該怎麼辦，他們會很樂意拿着你的錢來告訴你這是不是真的。在搜索引擎中輸入 Kubernetes，就可以看到所有彈出的廣告。本文就是該問題的一部分，也是解決方案的一部分，所以請繼續聽下去。

5 最後，解決方案

有幾種方法可以使 Kubernetes 更易於使用：

尋找一種解決方案，將你的應用程序部署到適合你的環境中，然後繼續進行你實際上從事的任何業務。自動化工具和服務可以幫助你運行應用程序，而無需對上述活動進行投資。總得有人去做，但最好不是你。

原文鏈接：

https://releasehub.com/blog/why-kubernetes-is-so-hard

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

猜你喜歡