歡迎光臨
每天分享高質量文章

瞭解Kubernetes主體架構(二十八)

 

前言

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

1)基礎理論

2)使用Minikube部署本地Kubernetes集群

3)使用Kubeadm創建集群

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

目錄

Kubernetes主體架構 

1.1.主要核心組件 

1.1.1. Master組件 

1.1.2. 節點(Node)組件 

1.1.3. 插件 

1.2. 基本概念 

1.2.1. 容器組(Pod)

1.2.2. 服務(Service)

1.2.3. 捲(Volume)

1.2.4. 標簽(Labels)和標簽選擇器(Label Selector)

1.2.5. 複製控制器(Replication Controller,RC)

1.2.6. 副本集控制器(Replica Set,RS) 

1.2.7. 部署控制器(Deployment) 

1.2.8. StatefulSet 

1.2.9. 後臺支撐服務集(DaemonSet)

1.2.10. 一次性任務(Job)

 

 

 

Kubernetes主體架構

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

 

 

1.1主要核心組件

 

1.1.1Master組件

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)控制器:用於創建,附加和裝載捲,以及與雲提供商交互以協調捲。

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的功能。主要的插件有:

  • 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提供了容器日誌儲存,並且提供了搜索/瀏覽界面。

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: v1kind: Podmetadata: name: myapp-pod labels:   app: myappspec: 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: v1kind: Servicemetadata: name: my-servicespec: 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中運行的容器化應用程式使用。

 

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

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

1.2.9 後臺支撐服務集(DaemonSet)

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

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

 

1.2.10 一次性任務(Job)

 

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

Kubernetes支持以下幾種Job:

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

分享創造快樂