進擊的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，通常一個容器的配額有100_{300m，即0.1}0.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權威指南》（龔正等著）

Kubernetes官網檔案

Kubernetes中文檔案

標籤：其他

上一篇：Python 跳動的小球

下一篇：神經網路模型量化基礎