瞭解Kubernetes主體架構（二十七）

雪雁發表於2019-07-04

架構

前言

Kubernetes的教程一直在編寫，目前已經初步完成了以下內容：

1）基礎理論

2）使用Minikube部署本地Kubernetes叢集

3）使用Kubeadm建立叢集

接下來還會逐步完善本教程，比如Helm、ELK、Windows Server容器等等。

節點（Node）控制器：負責在節點出現故障時警示和響應。
副本（Replication）控制器：負責為系統中的每個副本控制器物件維護正確的pod數量。
端點（Endpoints）控制器：填充Endpoints物件（即連線Services＆Pods）。
Service Account和Token控制器：為新的Namespace建立預設帳戶訪問API 訪問Token。

5）cloud-controller-manager

雲控制器管理器負責與底層雲提供商的平臺互動。雲控制器管理器是Kubernetes版本1.6中引入的。

雲控制器管理器僅執行雲提供商特定的（controller loops）控制器迴圈。可以通過將--cloud-provider flag設定為external啟動kube-controller-manager ，來禁用控制器迴圈。

cloud-controller-manager 具體功能：

節點（Node）控制器：檢查雲端節點，以確保節點在停止響應之後在雲中是否刪除。
路由（Route）控制器：用於在底層雲基礎架構中設定路由。
服務（Service）控制器：用於建立，更新和刪除雲提供商的負載均衡器。
卷（Volume）控制器：用於建立，附加和裝載卷，以及與雲提供商互動以協調卷。

1.1.2 節點（Node）元件

Node是k8s叢集中的工作負載節點，用於被Master分配工作負載（容器）。Node的元件有：

1）kubelet

kubelet是節點代理，它會監視已分配給節點的pod，確保容器在pod中執行。

2）kube-proxy

kube-proxy為節點的網路代理，通過在主機上維護網路規則並執行連線轉發來實現Kubernetes的服務抽象。

kube-proxy負責請求轉發。kube-proxy允許通過一組後端功能進行TCP和UDP流轉發或迴圈TCP和UDP轉發。

3）Container Runtime

容器執行時是負責執行容器的軟體。

Kubernetes支援多個容器執行時：Docker， containerd，cri-o， rktlet以及Kubernetes CRI（容器執行時介面）的任何實現。目前最佳組合為Kubernetes+Docker。

1.1.3 外掛

外掛是實現叢集功能的pod和服務，他們擴充套件了Kubernetes的功能。主要的外掛有：

Kubernetes的叢集DNS擴充套件外掛用於支援k8s叢集系統中各服務之間的發現和呼叫。

Web UI (Dashboard)

Dashboard（儀表盤）是Kubernetes叢集的基於Web的通用UI，它允許使用者管理群集，以及管理叢集中執行的應用程式。

Container Resource Monitoring（容器資源監測）

Container Resource Monitoring工具提供了UI監測容器、Pods、服務以及整個叢集中的資料，用於檢查Kubernetes叢集中，應用程式的效能。

Cluster-level Logging（叢集級日誌記錄）

Cluster-level Logging提供了容器日誌儲存，並且提供了搜尋/瀏覽介面。

1.2 基本概念

初步瞭解了Kubernetes的主題架構和核心元件，我們還需要進一步瞭解一些Kubernetes的基本概念。主要如下所示：

1.2.1 容器組（Pod）

Pod是k8s叢集中執行部署應用或服務的最小單元，一個Pod由一個或多個容器組成。在一個Pod中，容器共享網路和儲存，並且在一個Node上執行。

Kubernetes為每個Pod都分配了唯一的IP地址，稱之為Pod IP，一個Pod裡的多個容器共享Pod IP地址。Kubernetes要求底層網路支援叢集內任意兩個Pod之間的TCP/IP直接通訊，這通常採用虛擬二層網路技術來實現，例如Flannel、Open vSwitch等。因此，在Kubernetes裡，一個Pod裡的容器與另外主機上的Pod容器能夠直接通訊。

Pod有兩種型別：普通的Pod和靜態Pod（Static Pod），靜態Pod不存放在etcd儲存裡，而是存放在某個具體的Node上的一個具體檔案中，並且只在此Node上啟動執行。普通的Pod一旦被建立，就會被儲存到etcd中，隨後會被Kubernetes Master排程到某個具體的Node上並進行繫結（Binding），該Node上的kubelet程式會將其例項化成一組相關的容器並啟動起來。當Pod裡的某個容器停止時，Kubernetes會自動檢測到這個問題並且重新啟動這個Pod（重啟Pod裡的所有容器）；如果Pod所在的Node當機，則會將這個Node上的所有Pod重新排程到其他節點上執行。

Pod、容器與Node的關係如下圖：

apiVersion: v1

kind: Pod

metadata:

name: myapp-pod

labels:

app: myapp

spec:

containers:

- name: myapp-container

image: busybox

command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

1.2.2 服務（Service）

在Kubernetes中，Pod會經歷“生老病死”而無法復活，也就是說，分配給Pod的IP會隨著Pod的銷燬而消失，這就導致一個問題——如果有一組Pod組成一個叢集來提供服務，某些Pod提供後端服務API，某些Pod提供前端介面UI，那麼該如何保證前端能夠穩定地訪問這些後端服務呢？這就是Service的由來。

Service在Kubernetes中是一個抽象的概念，它定義了一組邏輯上的Pod和一個訪問它們的策略（通常稱之為微服務）。這一組Pod能夠被Service訪問到，通常是通過Label選擇器確定的。

例如，一個圖片處理的後端程式，它執行了3個副本，這些副本是可互換的——前端程式不需要關心它們呼叫了哪個後端副本。雖然組成這一組的後端程式的Pod實際上可能會發生變化，但是前端無需知道也沒必要知道，也不需要跟蹤後端的狀態。Service的抽象解耦了這種關聯。

apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

selector:

app: MyApp

ports:

- protocol: TCP

port: 80

targetPort: 9376

1.2.3 卷（Volume）

和Docker不同，Kubernetes的Volume定義在Pod上，被一個Pod裡的多個容器掛載到具體的檔案目錄下，當容器終止或者重啟時，Volume中的資料也不會丟失。也就是說，在Kubernetes中，Volume是Pod中能夠被多個容器訪問的共享目錄。

目前，Kubernetes支援以下型別的卷：

awsElasticBlockStore

awsElasticBlockStore可以掛載AWS上的EBS盤到容器，需要Kubernetes執行在AWS的EC2上。

azureDisk

Azure是微軟提供的公有云服務，如果使用Azure上面的虛擬機器來作為Kubernetes叢集使用時，那麼可以通過AzureDisk這種型別的卷外掛來掛載Azure提供的資料磁碟。

azureFile

AzureFileVolume用於將Microsoft Azure檔案卷（SMB 2.1和3.0）掛載到Pod中。

cephfs

cephfs Volume可以將已經存在的CephFS Volume掛載到pod中，與emptyDir特點不同，pod被刪除的時，cephfs僅被被解除安裝，內容保留。cephfs能夠允許我們提前對資料進行處理，而且這些資料可以在Pod之間“切換”。

cinder

cinder用於將OpenStack Cinder Volume安裝到Pod中。

configMap

configMap提供了一種將配置資料注入Pod的方法。儲存在ConfigMap物件中的資料可以在configMap型別的卷中引用，然後由在Pod中執行的容器化應用程式使用。

Container Storage Interface（CSI）為Kubernetes定義了一個標準介面，以將任意儲存系統暴露給其容器工作負載。在Kubernetes叢集上部署CSI相容卷驅動程式後，使用者可以使用csi卷型別來附加，裝載等CSI驅動程式公開的卷。

downwardAPI

downwardAPI可以將Pod和Container欄位公開給正在執行的Container。

emptyDir

使用emptyDir時，Pod分配給節點時就會首先建立卷，並且只要Pod在該節點上執行，這個卷就會一直存在。當Pod被刪除時，emptyDir中的資料也不復存在。

fc (fibre channel)

光纖通道區域儲存網路，需要購買支援FC的磁碟陣列裝置、控制器、光纖、光介面以及與設定相匹配的軟體。

flocker

flocker是一個開源的容器叢集資料卷管理器，它提供由各種儲存後端支援的資料卷的管理和編排。

gcePersistentDisk

gcePersistentDisk可以掛載GCE（Google的雲端計算引擎）上的永久磁碟到容器，需要Kubernetes執行在GCE的VM中。與emptyDir不同，Pod刪除時，gcePersistentDisk被刪除，但Persistent Disk的內容任然存在。這就意味著gcePersistentDisk能夠允許我們提前對資料進行處理，而且這些資料可以在Pod之間“切換”。

glusterfs

glusterfs，允許將Glusterfs（一個開源網路檔案系統）Volume安裝到pod中。不同於emptyDir，Pod被刪除時，Volume只是被解除安裝，內容被保留。

hostPath

hostPath允許掛載Node上的檔案系統到Pod裡面去。如果Pod需要使用Node上的檔案，可以使用hostPath。

iscsi

iscsi允許將iscsi磁碟掛載到pod中，Pod被刪除時，Volume只是被解除安裝，內容被保留。

local

Local 是Kubernetes叢集中每個節點的本地儲存（如磁碟，分割槽或目錄），在Kubernetes1.7中kubelet可以支援對kube-reserved和system-reserved指定本地儲存資源。

通過上面的這個新特性可以看出來，Local Storage同HostPath的區別在於對Pod的排程上，使用Local Storage可以由Kubernetes自動的對Pod進行排程，而是用HostPath只能人工手動排程Pod，因為Kubernetes已經知道了每個節點上kube-reserved和system-reserved設定的本地儲存限制。

但是，本地卷仍受基礎節點可用性的限制，並不適用於所有應用程式。如果節點變得不健康，則本地卷也將變得不可訪問，並且使用它的Pod將無法執行。使用本地卷的應用程式必須能夠容忍這種降低的可用性以及潛在的資料丟失，具體取決於底層磁碟的永續性特徵。

NFS是Network File System的縮寫，即網路檔案系統。Kubernetes中通過簡單地配置就可以掛載NFS到Pod中，而NFS中的資料是可以永久儲存的，同時NFS支援同時寫操作。Pod被刪除時，Volume被解除安裝，內容被保留。這就意味著NFS能夠允許我們提前對資料進行處理，而且這些資料可以在Pod之間相互傳遞。

使用NFS資料卷適用於多讀多寫的持久化儲存，適用於大資料分析、媒體處理、內容管理等場景。

persistentVolumeClaim

persistentVolumeClaim用來掛載持久化磁碟。PersistentVolumes是使用者在不知道特定雲環境的細節的情況下，實現持久化儲存（如GCE PersistentDisk或iSCSI卷）的一種方式。

projected

Projected volume將多個Volume源對映到同一個目錄，目前，可以支援以下型別的卷源：secret、downwardAPI、configMap、serviceAccountToken。

所有源都需要與Pod在同一名稱空間中。

portworxVolume

portworxVolume是一個執行在Kubernetes中的彈性塊儲存層，可以通過Kubernetes動態建立，也可以在Kubernetes Pod中預先配置和引用。它能夠聚合多個伺服器之間的容量，可以將伺服器變成一個聚合的高可用的計算和儲存節點。

quobyte

Quobyte是Quobyte公司推出的分散式檔案儲存系統，它實現了Container Storage Interface（CSI，容器儲存介面）。

RBD允許Rados Block Device格式的磁碟掛載到Pod中，同樣的，當pod被刪除的時候，rbd也僅僅是被解除安裝，內容保留。

RBD的一個特點是它可以同時由多個消費者以只讀方式安裝，但是不允許同時寫入。這意味著我們可以使用資料集預填充卷，然後根據需要從多個Pod中並行使用。

scaleIO

ScaleIO是一種基於軟體的儲存平臺（虛擬SAN），可以使用現有硬體來建立可擴充套件的共享塊網路儲存的叢集。ScaleIO卷外掛允許部署的pod訪問現有的ScaleIO卷。

secret

secret volume用於將敏感資訊（如密碼）傳遞給pod。我們可以將secrets儲存在Kubernetes API中，使用的時候以檔案的形式掛載到pod中，而無需直接連線Kubernetes。secret volume由tmpfs（RAM支援的檔案系統）支援，因此它們永遠不會寫入非易失性儲存。

storageos

StorageOS是一家英國的初創公司，給無狀態容器提供簡單的自動塊儲存、狀態來執行資料庫和其他需要企業級儲存功能。StorageOS在Kubernetes環境中作為Container執行，從而可以從Kubernetes叢集中的任何節點訪問本地或附加儲存。可以複製資料以防止節點故障。精簡配置和內容壓縮可以提高利用率並降低成本。

StorageOS的核心是為容器提供塊儲存，可通過檔案系統訪問。StorageOS Container需要64位Linux，並且沒有其他依賴項。提供免費的開發人員許可。

vsphereVolume

vsphereVolume用於將vSphere VMDK Volume掛載到Pod中。解除安裝卷後，內容將被保留。它同時支援VMFS和VSAN資料儲存。

1.2.4 標籤（Labels）和標籤選擇器（Label Selector）

Labels其實就是附加到物件（例如Pod）上的鍵值對。給某個資源物件定義一個Label，就相當於給它打了一個標籤，隨後就可以通過Label Selector（標籤選擇器）來查詢和篩選擁有某些Label的資源物件，Kubernetes通過這種方式實現了類似SQL的簡單又通用的物件查詢機制。

總的來說，使用Label可以給物件建立多組標籤，Label和Label Selector共同構成了Kubernetes系統中最核心的應用模型，使得被管理物件能夠被精細地分組管理，同時實現了整個叢集的高可用性。

1.2.5 複製控制器（Replication Controller，RC）

RC的作用是保障Pod的副本數量在任意時刻都符合某個預期值，不多也不少。如果多了，就殺死幾個，如果少了，就建立幾個。

RC有點類似於程式管理程式，但是它不是監視單個節點上的各個程式，而是監視多個節點上的多個pod，確保Pod的數量符合預期值。

RC的定義由以下內容組成：

當我們定義了一個RC並提交到Kubernetes叢集中後，Master節點上的Controller Manager元件就得到通知，定期巡檢系統中當前存活的目標Pod，並確保目標Pod例項的數量剛好等於此RC的期望值。如果有過多的Pod副本在執行，系統就會停掉多餘的Pod；如果執行的Pod副本少於期望值，即如果某個Pod掛掉，系統就會自動建立新的Pod以保證數量等於期望值。

通過RC，Kubernetes實現了使用者應用叢集的高可用性，並且大大減少了運維人員在傳統IT環境中需要完成的許多手工運維工作（如主機監控指令碼、應用監控指令碼、故障恢復指令碼等）。

常見使用場景：

重新規劃

比如重新設定Pod數量。

縮放
滾動更新

RC支援滾動更新，也就是允許我們在更新服務時，逐個的替換Pod。也就是說，滾動更可以保障應用的可用性，確保任何時間都有可用的Pod來提供服務。

多個釋出版本追蹤

除了在程式更新過程中同時可以執行多個版本的程式外，也可以在更新完成之後的一段時間內或者持續的同時執行多個版本（新舊）。需通過標籤選擇器來完成。

1.2.6 副本集控制器（Replica Set，RS）

ReplicaSet是下一代複製控制器。ReplicaSet和 Replication Controller之間的目前的唯一區別是選擇器的支援——Replica Set支援基於集合的Label selector（Set-based selector），而RC只支援基於等式的Label selector（equality-based selector），所以Replica Set的功能更強大。

Replica Set很少單獨使用，它主要被Deployment（部署）這個更高層的資源物件所使用，從而形成一整套Pod建立、刪除、更新的編排機制。

1.2.7 部署控制器(Deployment)

Deployment（部署控制器）為Pod和Replica Set提供宣告式更新。

我們只需要在Deployment中描述想要的目標狀態是什麼，Deployment controller就會幫我們將Pod和Replica Set的實際狀態改變到目標狀態。我們可以定義一個全新的Deployment，也可以建立一個新的替換舊的Deployment。

Deployment相對於RC的最大區別是我們可以隨時知道當前Pod“部署”的進度。一個Pod的建立、排程、繫結節點及在目標Node上啟動對應的容器這一完整過程需要一定的時間，所以我們期待系統啟動N個Pod副本的目標狀態，實際上是一個連續變化的“部署過程”導致的最終狀態。

Deployment的典型使用場景有以下幾個：

建立一個Deployment物件來生成對應的Replica Set並完成Pod副本的建立過程。
檢查Deployment的狀態來看部署動作是否完成（Pod副本的數量是否達到預期的值）。
更新Deployment以建立新的Pod（比如映象升級）。
如果當前Deployment不穩定，則回滾到一個早先的Deployment版本。
暫停Deployment以便於一次性修改多個Pod Template Spec的配置項，之後再恢復Deployment，進行新的釋出。
擴充套件Deployment以應對高負載。
檢視Deployment的狀態，以此作為釋出是否成功的指標。
清理不再需要的舊版本ReplicaSet。

1.2.8 StatefulSet

StatefulSet用於管理有狀態應用程式，比如Mysql叢集、MongoDB叢集、ZooKeeper叢集等。

StatefulSet主要特性如下：

StatefulSet裡的每個Pod都有穩定、唯一的網路標識，可以用來發現叢集內的其他成員。
穩定的持久化儲存，即Pod重新排程後還是能訪問到相同的持久化資料，基於PersistentVolume來實現，刪除Pod時預設不會刪除與StatefulSet相關的儲存卷（為了保證資料的安全）。
有序部署，有序擴充套件，即Pod是有順序的，在部署或者擴充套件的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod執行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現。
有序收縮，有序刪除。