理清定位，找準你的 Kubernetes 與容器技術學習方法

張磊，阿里集團高階技術專家，Kubernetes 專案資深成員和聯合維護者。主要關注容器執行時介面(CRI)、排程、資源管理和基於虛擬化技術的容器執行時等特性，共同負責 Kubernetes 上游和阿里集團大型叢集管理系統的工程工作。張磊曾就職於微軟研究院（MSR）和 KataContainers 團隊，也是 KubeCon 大會上備受歡迎的演講者。

• Kubernetes 和容器技術主要解決的，是程式碼編寫完成後的事情。這不單單是釋出或者 CI/CD，而是指從你執行完 git commit & git push 之後開始，都應該進入容器化的管理流程當中，當然包括後續的釋出、運維、升級、回滾等所有階段。

• Kubernetes 體系的核心，是為開發者提供編寫程式碼過程中的“微服務程式設計正規化”。

比如，在你編寫程式碼的時候，你應該清楚地知道：我該如何劃分模組，就能更方便地利用到 Kubernetes 的 Pod 模型，來構建更加低耦合、高內聚的程式碼製品，讓我後面的升級和重構工作更加容易。

再比如，當你的程式碼需要與一個外部資源進行互動的時候，你應該首先想到：我的這個外部資源，是不是可以作為一個 Kubernetes 的 CRD 放到 Etcd 裡面。這樣，我編寫的程式碼，就可以遵循一個自定義 Controller 或者 Operator 的程式設計正規化，透過宣告式 API 的方式來執行業務邏輯。這樣寫出來的程式碼一定會更加簡單、健壯、容易維護。

這樣的例子其實非常多。作為開發人員，你最應該關注的，是 Kubernetes API 物件的細節、容器設計模式以及 Kubernetes API 程式設計正規化。

Kubernetes 裡的所有 API 物件

你應該習慣於把你的服務想象成一個個容器，把整個應用想象成一個 Pod，學會把基於容器和 Kubernetes 的設計思想和架構方式，融入到自己平常的工程實踐當中。你應該大量實踐這些思想和設計模式，編寫各種各樣的 CRD 和 Controller，並想辦法提高這些自己編寫的自定義 Controller 專案的效能和服務能力。你應該嘗試扮演公司或者組織中推廣微服務和雲原生體系倡導者，並熱心地幫助團隊成員共同學習 Kubernetes 的設計思想和 API，全力幫助 Istio 或者 Knative 這樣的 Service Mesh 和 PaaS 平臺在組織中落地。

這些，都是增強你在即將到來的雲端計算時代競爭力的有效手段。

比如，宣告式 API 的設計與實現原理，Informer、Controller 這些機制的實現方式，為什麼說 Etcd 最適合的場景是配置管理，集中式叢集排程器的核心機制與常用策略都有哪些。

此外，Kubernetes 專案的各個可擴充套件性介面，也是你需要重點關注和理解的物件，比如 CNI 和網路外掛的工作方式、CSI 和儲存外掛的設計、Kubernetes Volume 管理的完整流程，以及 CRI 的設計和各種 container runtime 的異同。

從這個角度來說，Kubernetes 專案就是當前雲端計算平臺層開源專案的事實標準，熟悉它的思想、架構、實現細節甚至核心元件的原始碼，不僅是學習這項技術的必經之路，也是傳統後端技術人員向雲端轉型的最佳途徑。

Kubernetes 透過儲存外掛管理容器持久化儲存的原理

你應該嘗試扮演公司和組織中進行雲原生和基礎架構轉型的關鍵角色，而不是充當傳統和守舊那一方。你應該嘗試用容器和 Kubernetes 化的思想來影響周邊的每一位工程師。要記住，這個程式每前進一步，你的價值就放大一分。

1、瞭解作業系統和硬體的實際工作方式，尤其是 CPU、儲存和網路。

2、充分理解作業系統的設計，甚至可以根據需要重新實現或者繞過某些部分，這是你後面進行系統效能最佳化的關鍵所在。

3、理解“所有系統都是分散式系統”的道理。瞭解經典的分散式系統設計的思想，並從實際的工程實踐中理解這些解決思路，這也是 Kubernetes 這個分散式專案構建的基礎。

只有清楚了自己的定位，你才能夠在 Kubernetes 這樣一個大而全的技術體系面前做到“有所放矢，有的放矢”，才能夠把容器和 Kubernetes 這項技術發展浪潮，與自己的技術路線和個人成長曆程，真正地關聯起來。

Kubernetes 專案核心功能的“全景圖”

一旦明確了定位，抓到了這其中的精髓和主線，那麼接下來的學習過程對於你來說，其實就是“無招勝有招”，可以隨心所欲地按照你實際的專案、所關心的領域逐步展開，而完全不必拘泥於某種特定的套路了。

本文轉自公眾號「極客時間」