有關Kubernetes是什麼，網上很常見的一種介紹是：Kubernetes是Google開源的容器叢集管理系統，其提供應用部署、維護、擴充套件機制等功能，利用Kubernetes能方便地管理跨機器執行容器化的應用。
由此可見，K8s是構建在容器（Docker）技術之上的。
為什麼需要容器叢集管理？
單機的Docker引擎和單一的容器映象只能解決單一服務的打包和測試問題。而要執行生產級的企業級應用，就需要容器排程管理系統。在這裡面，Docker技術就彷彿運送系統零件的集裝箱，把雲原生應用的各個標準化零件交付到各個企業的不同碼頭，而容器排程管理系統就是企業應用的執行車間，把不同的零件組裝、執行、維護起來。Kubernetes即是為生產環境而設計的容器排程管理系統。

Kubernetes系統架構

一個K8s叢集是由分散式儲存（etcd）、服務節點（Minion）和控制節點（Master）構成的。現在Minion改名為Node。
下圖為叢集架構圖，典型的master/slave模型。

• Master節點：執行叢集的管理控制模組；
• Node節點：真正執行應用容器的主機節點，每個Node上都會執行一個Kubelet代理，控制該節點上的容器、映象和儲存卷等；
• etcd：儲存叢集狀態。

Kubernetes核心概念

Kubernetes以RESTful形式開放介面，使用者可操作的REST物件/資源有三個：Pod，service和replication controller。API Server元件提供了一套對它們按照RESTful格式的增、刪、改、查和監控介面。

1. Pod

在Kubernetes中能夠被建立、排程和管理的最小部署單元，是一組（一個或多個）容器。一個Pod中的所有容器會被排程到同一個node上。

Pod 中的容器共享：

• 網路 NET namespace。由於容器之間共享 NET namespace，所以它們使用同一個 IP 地址，可以通過 localhost 互相通訊。不同 pod 之間可以通過IP地址訪問。
• PID（同一個pod內的應用容器能夠看到對方容器程序），IPC（同一個pod內的應用容器能使用System V IPC或POSIX訊息佇列進行通訊），UTS（同一個pod內的應用容器共享主機名） 等 Linux namespace。
• 儲存卷（volume），方便pod內的容器之間共享資料以及在容器重啟過程中避免資料丟失。實現持久化儲存，volume作為pod的一部分掛載到容器上。

Pod的技術概念是K8s區別於其它容器編排排程工具的顯著特性，帶來的優勢為資源通訊和共享，資料共享和管理。具體來說，同一個Pod裡的容器有如下兩個特性：

• 通過K8s volume機制，在容器之間共享儲存；
• 可以通過 localhost直接訪問另一個容器。

一旦某個pod被分配到指定的工作節點（minion）上，該pod會在這個工作節點上一直執行直到生命週期結束，中途不會被排程到其它工作節點再次執行。

當一個工作節點下線時，其上的pod也隨之刪除。

當系統中執行的Pod數量很多時，如何有效地分類和組織Pod？
解決方案：label。
每個pod都有一個屬性“labels”，即一組鍵值對，形如：

“labels”：{
     “key1”：“value1”，
     “key2”：“value2”
}

列舉所有匹配標籤{‘name’：“nginx”}的pod：$ kubectl get pods -l name=nginx

labels屬性一般不直接作為系統內部唯一標識kubernetes物件的依據，因為不同於物件名和UUID，labels並不保證唯一性。

Pod貼標籤，是為方便管理和維護，比如按以下情況打標籤：release（版本），environment（應用執行環境），tier（複雜分散式應用的若干層級），partition（不同使用者），track（更新週期）等。

label selector：Kubernetes核心的分組機制，客戶端/使用者能夠識別一組有共同特徵或屬性的Kubernetes物件。

注意：儘量不要在單個pod中運行同一個應用的多個例項，因為pod設計的目的就是用於不同應用程式之間的協同。

2. replication controller

設計目標：保證本身狀態為running且容器一切正常的pod數量永遠跟預設的數目一致。
決定一個pod有多少同時執行的副本，並保證這些副本的期望狀態與當前狀態一致。
一般推薦，建立一個pod的同時建立一個replication controller，讓這個controller一直守護pod，直到pod被刪除。
pod的狀態值（podStatus）：pending，running，succeeded，failed。

3. service

作用：
pod在Kubernetes中的IP地址不固定，service作為代理來確保需要使用pod的應用不需要知曉pod的真實IP地址；
當replication controller建立了多個pod副本時，需要service作為代理來為這些pod做負載均衡。
在service被建立的時候，便被分配一個獨一無二的IP地址，該IP地址與service的生命週期相同且不再更改。

綜合上述，可以看到，K8s中每個API物件都有三大類屬性：
- 元資料metadata：標識API物件。每個物件至少有三個元資料：namespace，name和uuid；除此之外，還有labels用來標識和匹配不同物件。
- 規範spec：描述了使用者期望K8s叢集中的分散式系統達到的理想狀態（Desired State）。
K8s中所有的配置都是通過API物件的spec去設定的，也就是使用者通過配置系統的理想狀態來改變系統，這是k8s重要設計理念之一，即所有的操作都是宣告式（Declarative）的而不是命令式（Imperative）的，其好處是穩定。
- 狀態status：描述了系統實際當前達到的狀態（Status）。

Kubernetes核心元件

Master節點：

• API Server：負責對外提供K8s API服務，支援對K8s資源的增、刪、改、查和監測。
  只有API Server與儲存通訊，其他模組通過API Server訪問叢集狀態。
• Scheduler：根據特定的排程演算法將pod排程到指定的minion上（繫結）。
• Controller manager：基於pod API上的一個獨立服務，重點實現service endpoint（服務端點）的動態更新，管理K8s叢集中的各種控制器

Minion節點：

• Kubelet：負責管理和維護這臺主機上執行的所有容器。
• kube-proxy：負責為pod提供代理。

參考文獻：