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

k8s的整體架構如下圖所示：

Master為叢集控制管理節點，負責整個叢集的管理和控制。Master的元件如下所示：

1）kube-apiserver

kube-apiserver用於暴露Kubernetes API，提供了資源操作的唯一入口。任何的資源請求/呼叫操作都是透過kube-apiserver提供的介面進行。

2）etcd

etcd是Kubernetes的高可用的一致性鍵值儲存系統，也是其提供的預設的儲存系統，用於儲存所有的叢集資料，使用時需要為etcd資料提供備份計劃。

3）kube-scheduler

kube-scheduler 監視新建立沒有分配到Node的Pod，為Pod選擇一個Node以供其執行。

4）kube-controller-manager

kube-controller-manager執行管理控制器，它們是叢集中處理常規任務的後臺執行緒。邏輯上，每個控制器是一個單獨的行程，但為了降低複雜性，它們都被編譯成單個二進位制檔案，併在單個行程中執行。

這些控制器包括：

• 節點（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）控制器：用於建立，附加和裝載捲，以及與雲提供商互動以協調捲。

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。

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

• DNS

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提供了容器日誌儲存，並且提供了搜尋/瀏覽介面。

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

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: v1kind: Podmetadata: name: myapp-pod labels:   app: myappspec: containers: - name: myapp-container   image: busybox   command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

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

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

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

apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector:   app: MyApp ports: - protocol: TCP   port: 80   targetPort: 9376

和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中執行的容器化應用程式使用。

• csi

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

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

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資料儲存。

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

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

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來提供服務。

• 多個釋出版本追蹤

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

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

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

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。

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

StatefulSet主要特性如下：

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

DaemonSet保證在每個Node上都執行一個容器副本，常用來部署一些叢集的日誌、監控或者其他系統管理應用。典型的應用包括：

• • 日誌收集守護程式，比如fluentd，logstash等。
  • 系統監控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等。
  • 叢集儲存後臺行程，比如glusterd，ceph等。
  • 系統程式，比如kube-proxy, kube-dns, glusterd, ceph等。

Job負責批次處理短暫的一次性任務 (short lived one-off tasks)，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。

Kubernetes支援以下幾種Job：

• 非並行任務。
• 具有固定完成計數要求的並行任務。
• 帶有工作佇列的並行任務。

朋友會在“發現-看一看”看到你“在看”的內容

確定