進擊的K8S：Kubernetes基礎概念
Kubernetes簡介
Kubernetes簡稱K8S（因為k和s中間有8個字母），是一個開源的容器叢集管理平臺，基於Go語言編寫。
使用K8S，將簡化分散式系統上的容器應用部署，使得開發人員可以專注於業務軟體，而非較為底層的負載均衡、服務監控等。因此，可以認為它是介於作業系統軟體和應用軟體之間的”中介軟體“。K8S具有強大的自動化機制，降低了系統後期的運維難度。
此外，K8S沒有限定程式設計介面，無論Java、Go、C++還是Python編寫的服務，都可以對映為K8S的Service。並且由於其對現有的語言、框架、中介軟體沒有任何侵入性，使得服務易於遷移到K8S上。
本文力圖使用通俗易懂的語言概括Kubernetes的一些概念。在閱讀本文前，你至少需要對Linux、docker、容器、yaml/json等有所瞭解。
Kubernetes概貌認知
在遇到一項新技術時，筆者習慣於先搞清楚它“是什麼“，為什麼被髮明出來，是如何使用和運作的。
為什麼需要Kubernetes
如果讀者對容器有所瞭解，並且有一定的使用經驗，那麼就很容易理解Kubernetes存在的理由。
容器是執行在物理機上的輕量化“虛擬機器”，一般一個應用程式就會啟用一個容器。由於各種原因，容器中的程式也許會出現錯誤，甚至容器和伺服器本身會掛掉。在雲資料中心有大量的伺服器，每臺伺服器上可能執行著幾十個乃至上百個容器，如果單純靠運維人員去監視、操作每個容器，那肯定是不現實的。因此就需要更高一層的容器編排管理程式，來自動化地管理容器應用。
或許我們可以自己去搭建這個平臺，不過Kubernetes的出現為我們省去了許多麻煩。有了Kubernetes，我們只需要安裝和啟動它的一組服務就可以了。開發或運維人員只需要編寫一些yaml或json檔案，指定叢集的期望狀態，然後在Terminal執行kubectl命令對叢集進行操作，剩下的過程都由Kubernetes自動完成。這樣，開發人員就可以專注於業務應用，而非與大量的伺服器硬體和作業系統本身打交道，同時後期運維也變得非常簡單。
Kubernetes的服務組成
通常至少需要啟動以下的服務以構成完整的Kubernetes系統：
- etcd：資料庫。平臺內的各種資料、程式的狀態在這裡儲存和交換。不過etcd並不是Kubernetes實現的，後者只是使用它作為平臺的資料庫。
- docker：Kubernetes管理的物件。準確來說管理的物件是容器，docker只是Kubernetes支援的容器執行時的其中一種。當然，它本身也不是Kubernetes實現的。
- kube-apiserver：各類資源的增、刪、改、查、watch等操作的統一介面。
- kube-controller-manager：叢集的管理控制中心，負責各類資源的管理。比如某個Node宕機時，controller-manager會發現故障並自動化修復，保證叢集處在預期的工作狀態。簡單來說，它解決Pod數量和狀態“對不對”的問題。
- kube-scheduler：負責POD的排程工作，負責將Controller Manager建立的Pod排程到具體的Node上。簡單來說，它解決controller manager建立的Pod“去哪”的問題。
- kubelet：執行在Node上，管理下發到本節點的Pod本身及Pod中的容器。
- kube-proxy：Kubernetes叢集內有大量的容器和服務，它們通過TCP相互通訊，kube-proxy就負責解決通訊的問題。
你可以通過Kubernetes官網的這張圖來了解其整體結構：
Kubernetes關鍵概念
或許上一節的一些術語還讓讀者非常疑惑，現在我們一起來具體看看一些重要概念的意思。
叢集和節點
一個叢集就是數臺執行著應用程式的伺服器，每臺伺服器被稱為一個節點，至少3個節點才可以稱得上是一個叢集。
節點可以是物理機，也可以是虛擬機器（傳統意義上的），只要能夠執行docker和Kubernetes服務。
節點有2種：
- 主節點Master：是整個叢集的管理中心。Master上執行的程序包括：
- etcd
- kube-apiserver
- kube-controller-manager
- kube-scheduler
- 工作節點Node：執行具體的工作負載（容器中的應用程式）。Node上執行的程序包括：
- 容器執行時
- kubelet
- kube-proxy
Tip：此處有一個小的歧義，工作節點Node直譯也是節點。“節點”一詞到底是Node和Master的合稱，還是單指Node，英文語境下似乎是後者，而中文裡似乎比較模糊。筆者目前習慣於將Node和Master都稱作”節點“，而將Node稱作”工作節點“，這樣指代比較明確。
Node可以在執行期間動態加入叢集，預設情況下kubelet會向Mater註冊自己。一旦加入叢集，kubelet會定時向Mater節點彙報自身狀態，以便Master進行管理排程。
如果某個Node超過指定時間沒有上報資訊，就會被Master判定為失聯。該Node的狀態將被標記為Not Ready，上面的負載會被轉移。
物件
Kubernetes物件是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示叢集的狀態，包括：
- 哪些容器正在執行，執行在那些Node上
- 容器應用可用的資源
- 關於應用如何執行的策略
一旦建立了物件，Kubernetes會確保物件存在。通過建立物件，可以告訴Kubernetes系統你希望叢集的目標狀態是什麼樣的。
一般在yaml或json檔案中定義物件，再通過Kubernetes API來使用（增刪改查）。有兩種方式來操作物件（即呼叫API），一是通過kubectl命令列工具呼叫，二是在程式語言中呼叫——目前官方提供了Go和Python的庫。
Tip：物件不是一個程序或一組程序，指示物件存在的是一段資訊的記錄（通常是etcd中或檔案中）。
Name和UID
所有物件都用Name和UID來明確標識。
Name就是物件的名稱，通常一部分是由使用者在物件定義檔案中自定義的。那麼另一部分是什麼？
可以思考這樣一個問題：以上面的Pod為例，假如有5個myweb應用的副本（這非常正常，短時間內很可能有多個使用者訪問一個網頁），如何區分它們？筆者理解的是，Kubernetes建立Pod時會在Name中加上一段隨機的字元，以區分不同的副本，如myweb-w3ec4，myweb-t9p84等（筆者隨便寫的，具體的機制還沒有學習到，大概也是雜湊之類）。這有點類似於git的版本號。
從上面也可以看出，一個Name在同一時間只能被一個物件擁有。如果物件被刪除，可以使用相同的Name建立新的物件。
UID則完全是由Kubernetes生成的。在Kubernetes叢集的整個生命週期內，每個物件都擁有不同的UID。也就是說，不僅同一時刻所有的物件UID都不同，而且即便某個物件被刪除後重新建立，也會擁有不同的UID。
Pod
Pod可以說是Kubernetes中最重要的物件，它是Kubernetes中的最小部署單元。Pod通常由一組容器構成，包括一個根容器，和其他一些共同完成業務功能的容器。如下圖所示：
為什麼不以容器本身作為管理的單元，而是又抽象出Pod？原因主要有以下幾點：
- 一項業務功能通常是由好幾個應用程式共同完成的，需要作為一個整體。但單個業務容器異常不能代表業務整體掛掉，難以判斷一項業務是否正常進行。抽象為Pod之後，用根容器的狀態代表整個Pod的狀態解決了這個問題。
- Pod內部通過共享根容器掛載的卷，簡化了業務容器間的通訊。
- Pod內部共享根容器的IP，簡化了與Pod之間（不同業務之間）的通訊。
Pod的兩種型別
Pod資訊存放的位置，實際上對應了Pod的兩種型別：普通Pod，靜態Pod。
普通Pod被建立後，其資訊會被存放在etcd資料庫中，然後會被排程到具體的Node上進行繫結，該Node中的kubelet將其例項化成一組容器。預設情況下，如果一個容器出現問題，Kubernetes檢測到後將重啟整個Pod——實際上是重啟Pod中的所有容器。如果Node宕機，則將在其他Node重新生成新的完全一樣的Pod代替它。
與此相反，靜態Pod則比較特殊，其資訊存放在某個具體的Node上的一個具體檔案中，只在此Node執行，不會被轉移。
Pod的資源限額
可以對Pod使用的計算資源做限額，包括CPU和Memory兩種。
CPU限額的單位是千分之一個CPU核心，記作m。通常一個容器的配額有100300m，即0.10.3個CPU核心。Memory限額的單位是記憶體位元組數。
對配額限定有兩個引數：
- Requets：資源的最小申請量，系統必須滿足要求。
- Limits：資源最大允許使用的量，超過它可能會kill該容器並重啟。
Service
Service是Kubernetes中另一種重要的物件，它定義了一種訪問實體資源（如Pod）的策略，或者說入口，這就是通常說的“微服務”。
考慮一個圖片處理的後臺應用，它有3個副本。這些副本是可以互相代替的，也就是訪問誰的效果都是一樣的，甚至可能掛掉重啟。前端不應該也沒必要關心到底呼叫哪個副本，Service定義的統一入口實現了前後端的解耦。
Pod的IP會隨著Pod本身的銷燬和建立發生變化。與此相反，每個Service建立時都會被分配一個全域性唯一的虛擬IP地址，稱為Cluster-IP。在Service的整個生命週期內，該Cluster-IP不會發生變化。客戶端實際上訪問的是Service，並且我們還希望客戶端能夠通過名稱去訪問。
“通過名稱而不是地址去訪問”，這句話讓讀者有何聯想？沒錯，就是DNS。用Service的Name與Service的Cluster-IP做一個DNS域名對映，這就是Kubernetes的服務發現機制。
參考資料：
《Kubernetes權威指南》（龔正等著）