Kubernetes資源管理的四種方式
【編者的話】本文將介紹4種管理Kubernetes資源的方法和工具，每一種方法和工具都是爲處於Kubernetes旅程不同階段的組織準備的。
Kubectl，新的ssh
當我開始接觸Linux系統時，我首先要了解的工具是ssh。天啊，這是一個多麼美妙和強大的軟件啊。你不僅可以登錄到你的服務器，複製文件，還可以創建vpn，省略SOCKS代理和端口轉發規則的防火牆，等等。但是，對於Kubernetes，這個工具主要用於節點維護，前提是你仍然需要管理它們，並且沒有切換到CoreOS或不可變節點類型的另一種變體。對於其他情況，可以使用kubectl，它是新的ssh。如果你不直接使用API調用，那麼你可能會以某種形式使用它，併爲它提供大量的yaml文件。讓我們面對現實吧——這就是如今管理Kubernetes環境的樣子。你用Kubernetes的資源定義創建了那些漂亮的、冗長的文本文件，然後神奇的事情發生了，你成了今天的英雄。除非你想用不同的配置創建幾十個甚至上百個。這就是事情變得複雜的時候。
簡單vs靈活
對於基本場景，簡單的yaml文件就足夠了。然而，隨着環境的增長，資源和配置的數量也在增長。你可能會開始注意到創建應用程序的新實例、重新配置已經運行的應用程序、與社區或希望根據需要自定義應用程序的客戶共享應用程序所花費的時間更多。目前，我發現以下是最常用的方法:
它們都可以用來管理你的資源，而且它們在許多方面也有所不同。其中一個明顯的因素是複雜性，這也意味着需要花費很多精力來學習、使用和維護一個特定的方法。另一方面，當你真正想要創建複雜的配置時，從長遠來看，這樣做可能會有好處。你可以在下圖中觀察到這種關係:
[attach]27053[/attach]
所以在靈活性和簡單性之間存在權衡。對一些人來說，簡單是可以取勝的，但對另一些人來說，這還遠遠不夠。讓我們仔細看看這四種方法，看看它們在哪些情況下最適合。
1、使用純yaml文件保持簡單
我總是告訴參加我的課程的人，通過學習Kubernetes，他們可以成爲yaml程序員。這可能聽起來很傻，但實際上，Kubernetes的基本用法歸根結底就是用yaml編寫一些對象的定義。當然，你必須知道兩件事——第一件是你想要創建什麼，第二件是關於Kubernetes API的知識，它是這些yaml文件的基礎。
在你學習瞭如何編寫yaml文件之後，你可以使用kubectl將其發送到Kubernetes，這樣你的工作就完成了。沒有參數，沒有模板，也不知道如何改變它。如果你想創建應用程序或整個環境的附加實例，只需複製和粘貼即可。當然，這裏會有一些重複，但這是爲了簡單所付出的代價。此外，在一些情況下，這不是什麼大問題，大多數組織可能可以接受這個不完美的解決方案，至少在他們旅途不盡如人意的時候是可以的。
何時使用：
- 對於應用程序或環境的配置/實例少於4個的項目
- 對於小型創業公司
- 大公司開始他們的第一個Kubernetes項目（例如作爲PoC的一部分）
- 學習Kubernetes API的個人
何時避免：
- 發佈針對Kubernetes環境的產品或服務的組織和項目
- 在項目中，每個實例都有很大的差異，需要大量的調整
2、使用Kustomize
Kustomize是Kubernetes官方團體之一的一個項目。它定義了基於繼承的Kubernetes資源的概念，yaml文件，沒錯——你逃不掉的。但是，這一次，使用Kustomize，你可以對已經存在的資源集應用任何你想要的更改。簡單地說，Kustomize可以看作是一個Kubernetes特有的補丁工具。它讓你覆蓋所有部分的yaml文件與其他功能，包括以下：
- 更改容器鏡像的存儲庫、名稱和標記
- 直接從文件生成ConfigMap對象，並生成散列，確保部署在發生更改時觸發新的rollout
- 使用kustomize cli動態修改配置（在CI/CD管道中非常有用）
從1.14版開始，它就內置在kubectl二進制文件中，這使它很容易開始。不幸的是，在獨立的kustomize項目中添加新特性的速度要快得多，而且它的發佈週期與kubectl二進制文件的官方版本不同步。因此，我強烈建議使用它的獨立版本，而不是kubectl的內置功能。
根據其創建者的說法，它鼓勵你直接使用Kubernetes API，而無需創建另一個人工抽象層。
何時使用：
- 對於不需要太多參數的少於10個配置/實例的項目
- 對於開始成長但仍在內部使用Kubernetes的初創公司（即不需要將清單作爲其產品的一部分）
- 對於任何知道Kubernetes API的人來說，都可以直接使用它
何時避免：
- 如果你的環境或實例最多變化30-50%，因爲你只需通過添加補丁來重寫大部分清單
- 與普通yamls的情況相同
3、進階，強大的Helm圖表
如果你還沒有見過Helm Hub，那麼我建議你去做，並尋找你最喜歡的軟件，特別是如果它是一個流行的開源項目，我非常確定它在那裏。隨着Helm 3的發佈，它的大部分缺陷都得到了修復。實際上，最大的組件是不再需要的Tiller組件，這使其成爲你部署的絕佳工具。對於OpenShift用戶來說，這也是一種解脫，因爲它的模板系統太簡單了（我儘量避免使用“糟糕”這個詞，但它確實很簡單）。
大多數已經開始使用Helm部署這些就緒服務的人常常開始爲應用程序編寫自己的圖表，以及在Kubernetes上部署的幾乎所有東西。對於非常複雜的配置來說，這可能是一個好主意，但是在大多數情況下，這是多餘的。如果你沒有將圖表發佈到某個註冊表（甚至很快也會發布到容器註冊表），而只是使用它們的模板特性（在Helm 3中，最終可以不下載圖表的源代碼），那麼使用Kustomize可能會更好。
然而，對於高級場景，Helm纔是正確的選擇。它可以是你用來發布應用程序以供其他團隊將其部署到其環境中的單一工具。你的客戶也可以使用一個簡單的命令——字面上就是掌舵升級你的圖表——來部署你的應用程序的一個新版本。
- 以能夠處理所有這些情況和配置變量的方式編寫圖表模板
- 使用CI/CD管道、測試和發佈來創建和維護整個發佈過程
Helm Hub上的許多示例顯示瞭如何將複雜的軟件打包到一個圖表中，從而使安裝過程變得非常簡單，並使定製變得更容易訪問，特別是對於不想深入瞭解太多細節的最終用戶。我自己也使用許多Helm Charts來安裝軟件，並將其視爲Kubernetes生態系統中最重要的項目之一。
何時使用：
- 對於擁有超過10個配置/實例的大型項目，這些配置/實例有許多變量和參數
- 用於在Internet上發佈以使其易於安裝的項目
何時避免：
- 如果你的應用程序不是那麼複雜，並且你不需要在任何地方發佈它們
- 如果你不打算爲發佈過程維護CI/CD，因爲維護沒有管道的圖表是非常耗時的
- 如果你對Kubernetes API還沒有深入的瞭解
4、自動化機器人（Operator）爲你服務
最後一個，最複雜的，也是最強大的。實際上，這是CoreOS（現在的Red Hat）提出的一種設計模式，它只是利用Kubernetes的一些特性，比如自定義資源定義和內嵌在直接運行在Kubernetes上的軟件中的自定義邏輯，並利用其稱爲controller的內部API。它在OpenShift生態系統中得到了廣泛的應用，並且自從OpenShift 4發佈以來，紅帽公司一直在推廣它，認爲它是在OpenShift上創建服務的最佳方式。他們甚至提供了一個定製OpenShift web界面的操作符。這就是我所說的抽象層！這裏的一切都由幾十個自定義操作符處理yaml來控制，因爲整個邏輯都嵌入在這裏。
簡單地說，什麼是Operator，我想說Operator是一個等價的雲服務，如亞馬遜RDS，GCP雲發佈/訂閱或Azure Cosmos數據庫。你可以構建一個操作符來提供一種一致的、簡單的方法來安裝和維護（包括升級）你的應用程序，在任何Kubernetes平臺上都可以使用其本機API以“即服務”的方式安裝和維護應用程序。它不僅提供了最高級別的自動化，而且還允許包括複雜的邏輯，如內置監視、無縫升級、自修復和自動標度。同樣，你需要做的只是提供一個yaml格式的定義，其餘的將由操作符處理。
“它看起來太棒了！有人會說。許多人認爲它應該而且將是交付應用程序的首選方式。我不同意這種說法。我認爲，如果你是一個軟件供應商，爲數百個客戶（甚至是內部客戶）提供你的應用程序，這就是該走的路。否則，編寫操作符可能過於複雜和耗時。特別是如果你想要遵循最佳實踐，使用Golang並提供一個簡單的升級路徑（它可能會變得棘手）。
我發現以下項目對Operator的開發和維護非常有幫助：
- kubebuilder：第一個面向Go開發者的操作框架，最強大、最複雜的一個
- kopf：用於在Python KUDO中開發操作符的kopf框架——以聲明的方式編寫操作符
- operator-sdk：來自CoreOSRed Hat的框架，用於在Go和Ansible中編寫操作符
- operator-lifecycle：對於任何有興趣認真對待操作器及其lifrecycle（安裝、維護、升級）的人來說，這是必須的。
何時使用：
- 如果你需要在Kubernetes上創建自己的服務（例如，你的產品即服務）
- 如果你計劃爲你的服務添加額外的功能（例如監視、自動縮放、自動癒合、分析）
- 如果你是爲Kubernetes平臺提供軟件的軟件供應商
- 如果你想開發安裝在OpenShift上的軟件，併成爲OpenShift生態系統的一部分（例如，在他們的“應用市場”上發佈你的軟件——operatorhu.io）
何時避免：
- 對於簡單的應用程序
- 對於其他應用時，舵輪圖用一些半複雜的模板就可以了
- 當不需要額外的自動化時，或者可以通過現有組件的簡單配置來實現
總結
我所描述的每一種方法和工具都是爲處於Kubernetes旅程不同階段的組織準備的。對於標準用例，簡單的yamls可能就足夠了，隨着更多的應用，Kustomize可以極大地增強這種方法。當事情變得嚴重和應用程序變得更復雜時，Helm Chart在複雜性和靈活性之間提供了一個完美的平衡。對於在Kubernetes中以類似於雲服務的方式交付應用程序的供應商，以及那些計劃使用OpenShift爲企業客戶提供應用程序的供應商，我可以推薦Operator。
原文鏈接：4 ways to manage Kubernetes resources
譯者：孤遠，軟件研發工程師、DevOpsDays、HDZ深圳核心組織者，目前供職於華爲，從事雲計算工作，專注於Kubernetes、微服務領域。