Kubernetes 是當下的熱門話題，所有主流的雲服務供應商都採用 Kubernetes 作為部署 cloud native app 的解決方案。幾周前，AWS 在 reInvent 大會上釋出的 EKS（亞馬遜 Elastic 容器服務），可以充分地管理 Kubernetes 叢集。
這是 AWS 邁出的巨大一步，因為 AWS 是最大的公有雲服務提供商，並且部署了最多的 Kubernetes 應用。官方提供了工具 kop，用於部署和管理 Kubernetes 叢集，kop 可以很好地在生產環境使用。隨著 Kubernetes 的流行，越來越多的公司也在極力擁抱 Kubernetes，因為 Kubernetes 可以解決許多常見問題。
是否真的應該向 Kubernetes 遷移？ 如何做才是擁抱 Kubernetes 的正確姿勢？我將在本文中分享我的經驗，並儘力回答這個問題。
今年早些時候，我們開始容器化 Sematext Cloud 和 Sematext Enterprise 的一些部署，這看起來確實有些直截了當。需要做的就是容器化應用，為應用所需要的資源如部署、服務等建立一些 Kubernetes 配置，以為已經準備好可以大幹一場了，但事情並非這麼簡單。
主要的問題是所有用於管理髮布的東西都不適合 cloud native 正規化。應用不是 cloud native 的，應用可能沒有使用 CI 或 CD 部署，健康檢查或使用監控工具進行日誌，指標和警報的監控也有問題。應用可能是靜態的並且部署也很複雜。向 Kubernetes 遷移過程中，這種複雜性無濟於事，也不會神奇地消失，只會讓事情變得更糟。cloud native 意味著將作業系統從應用程式中解耦，這也是容器正在做的事情。
在軟體行業的發展中，首先出現的是瀑布模型，然後是 Agile，而現在是 DevOps。這是一個非常重要的難題，也沒有前人的經驗可以借鑒。每個團隊都使用最適合自己的方案，如果你想保持現狀也是可以的。 你只需要確保你的程式能適用於 cloud native app，這意味著你可能需要改變一些東西。讓整個團隊接受 DevOps 原則並不容易，所以這可能需要一些時間，要為此做好準備。
如果想瞭解我對於 DevOps 的看法，可以閱讀 什麼是 DevOps？[1]
這個解決方案無需盲目遵循，這裡只給出想法，並解釋過程中可能遇到的問題。這個話題比較廣泛，我不會詳細解釋我所提到的所有東西。
首先，廢棄所有未使用過的元件，並做好清理工作。軟體開發持續幾年後，就會變得非常複雜，因為總是有更重要的事情要做，新功能、新的修複等等。
其次，對 Kubernetes 的 readiness 和 liveness probes 進行健康檢查，這部分不難。需要花費主要的經歷來管理配置，這部分比較困難。我建議使用 config map 和秘鑰，避免使用環境變數。可以使用一些環境變數，但不要完全使用環境變數來管理配置。你的應用程式應該充分利用 Kubernetes 的潛力。
Kubernetes 應用間使用服務互相通訊。Kubernetes 中有不同型別的服務，可以將這些服務視為負載平衡。你定義的服務名稱即是 endpoint（http：//service_name：port）。如果你正在使用的是有狀態應用程式，則可能需要使用可以訪問特定的 Pod 的 headless service。如你所料，Kubernetes 中的服務以某種方式也解決了服務發現的問題。如果你早已用過諸如 Consul 來做服務發現，恭喜你！你可以繼續使用，只需將其部署在 Kubernetes 上即可——根據 Consul Helm Chart 便可輕鬆部署。
從 Kubernetes 的角度來看，無狀態應用程式應該非常容易擴充套件。 你需要將“部署”作為資源，因為此類服務還可以管理簡單的升級——滾動更新。當然，應用程式需要在處理擴容時不出問題，這可能需要更改一些程式碼才能實現。
主要問題集中在有狀態應用如資料庫上，Kubernetes 為這類應用程式提供了 StatefulSet 資源，但在新增新節點或發生故障時 Kubernetes 不清楚某些特定的應用程式應該作何反應，這是Ops 人員的日常工作。幸運的是，透過編寫Kubernetes Operator來完成這些並不難。
簡而言之，Operator 是 Kubernetes 的自定義資源，或 CRD。可以自己寫也可以用現有的。我們正在使用 Elasticsearch Operator，我們很高興可以為這個專案做出貢獻。我已經提交了一些 pull request。
你可能開始著手整合資源了，但不要忽略計算資源，而且要限制容器的計算資源。有兩種型別的計算資源：請求，它指定一個節點上的最小可用資源量，用於 Kubernetes 排程程式執行特定 Pod；限制，一個 Pod 可以使用的最大計算資源量。這一點非常重要，特別是對於 Java 應用程式。請註意，對於 Java 應用程式，你還需要根據堆記憶體要求調整這些限制。我的建議是使用 Java 版本 8u131 或更新版本，這是 Docker-aware 對 Docker CPU 和記憶體的限制。
標簽化應用程式，這會對你監視容器和應用程式有所幫助。一般來說，元資料資訊就是透過選擇器連線不同的資源的方式。例如，部署和服務。
當你開始編寫 Kubernetes 配置檔案時，你會對覺得還不錯，維護它們也不是什麼大不了的事兒。但當你試圖實現一個部署的 pipeline 時，你會意識到只使用一堆配置檔案會非常糟糕。所以就要提到 Helm 了。 Helm 是用於打包 Kubernetes 應用程式的工具，我強烈建議將其用於部署。像多環境支援，依賴關係，版本控制，回滾以及各種 hook（像資料庫遷移）等功能就足以證明 Helm 有多棒了。但你還需要學習另一個工具，但是我向你保證會學有所值。
無需多個群集來支援不同的環境。只需使用不同的 Kubernetes 名稱空間。例如，為了建立一個新環境，只需建立一個單獨的名稱空間，完成測試後刪除它就行，這樣就節省了大量的時間和金錢。但是，不要忽略安全問題。Kubectl 類似叢集的的 root 使用者，不要給每個人都分配訪問 kubectl 的許可權。有時候，雖然建立一個全新的叢集比較複雜，但可能比管理 RBAC[2] 要好。不過，還是強烈建議使用 RBAC。
那麼如何版本化容器映象呢？ 可以使用 Helm 打包， 當然，這取決於你。最常用的方法是使用 commit ID 標記映象，隨後使用release 標簽。你需要將 Docker 映象儲存在私有或公共的 registry 中。我建議使用 DockerHub，因為 DockerHub 可能是價效比最高的。如果上述都搞定了，那麼你需要建立一個部署的 pipline， 可以使用 Jenkins 來部署所有內容，並作為 DevOps 的主要工具之一。
最近，我們的重點要放在 cloud native 上，而不僅僅是 Kubernetes 本身，Kubernetes 只是一個工具。我們向 Kubernetes 遷移 Sematext Cloud 和 Sematext Enterprise 的工作仍在進行中，這需要一個過程，而不是一次性的工作。
我希望這篇文章能夠讓你瞭解到向 cloud native 和 Kubernetes 遷移的一個過程以及預期達到的效果。雖然過程艱難費時，但對於你的的公司文化及軟體都很有好處。擴充套件將不再是問題，基礎架構上將只會是程式碼和軟體問題。擁抱 Kubernetes，但也要準備好面對挑戰，其中一些挑戰，本文也有所提及。
-
https://akomljen.com/what-is-devops/
-
https://kubernetes.io/docs/admin/authorization/rbac/
原文連結：https://dzone.com/articles/embracing-kubernetes-successfully
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球