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

時間 2019-11-06

標籤瞭解 kubernetes 主體架構二十七欄目系統架構简体版

原文原文鏈接

前言

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

1）基礎理論前端

2）使用Minikube部署本地Kubernetes集羣sql

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來實現。
有序收縮，有序刪除。