作者：京東物流 楊建民

一、微服務(wù)架構(gòu)起源

單體架構(gòu)：可以理解為主要業(yè)務(wù)邏輯模塊（我們編寫的代碼模塊，不包括獨立的中間件）運行在一個進(jìn)程中的應(yīng)用，最典型的是運行在一個Tomcat容器中，位于一個進(jìn)程里。單體架構(gòu)好處是技術(shù)門檻低、編程工作量少、開發(fā)簡單快捷、調(diào)試方便、環(huán)境容易搭建、容易發(fā)布部署及升級，開發(fā)運維等總體成本很低、見效快。其缺點也明顯：

（1）單體應(yīng)用系統(tǒng)比較膨脹與臃腫，耦合度高，導(dǎo)致進(jìn)行可持續(xù)開發(fā)和運維很困難。

（2）單體應(yīng)用難以承載迅速增長的用戶請求和需求。

基于Spring Framework的單體應(yīng)用架構(gòu)圖

分布式架構(gòu)核心思想是把一個單一進(jìn)程的系統(tǒng)拆分為功能上相互協(xié)作又能獨立部署在多個服務(wù)器上的一組進(jìn)程，這樣一來，系統(tǒng)可以根據(jù)實際業(yè)務(wù)需要，通過以下兩種方式實現(xiàn)某些獨立組件的擴(kuò)容，提升吞吐量。

• 水平擴(kuò)展：通過增加服務(wù)器數(shù)量進(jìn)行擴(kuò)容
• 垂直擴(kuò)展：給系統(tǒng)中的某些特殊業(yè)務(wù)分配更好的機(jī)器，提供更多資源，從而提升這些業(yè)務(wù)的系統(tǒng)負(fù)載和吞吐

分布式架構(gòu)是將一個龐大的單體應(yīng)用拆分成多個獨立運行的進(jìn)程，這些進(jìn)程能通過某種方式實現(xiàn)遠(yuǎn)程調(diào)用，因此，分布式架構(gòu)要解決的第一個核心技術(shù)問題就是獨立進(jìn)程之間的遠(yuǎn)程通信。該問題的最早答案就是RPC技術(shù)（Remote Procedure Call），一種典型的微服務(wù)架構(gòu)平臺的結(jié)構(gòu)示意圖如下：

大家比較熟知的微服務(wù)架構(gòu)框架有Dubbo與Spring Cloud，之后比較成功的微服務(wù)架構(gòu)基本都和容器技術(shù)掛鉤了，其中最成功的、影響最大的當(dāng)屬Kubernetes平臺了，與之相似的還有Docker公司推出的Docker Swarm(在2017年底，Docker Swarm也支持Kubernetes了)。

關(guān)于微服務(wù)架構(gòu)的優(yōu)勢由于文章篇幅有限，不再展開，但任何技術(shù)都存在兩面性，微服務(wù)架構(gòu)具有一定的復(fù)雜性，如開發(fā)者必須掌握某種RPC技術(shù)，并且必須通過寫代碼來處理RPC速度過慢或者調(diào)用失敗等復(fù)雜問題。為了解決微服務(wù)帶來的編程復(fù)雜性問題，一種新的架構(gòu)設(shè)計思想出現(xiàn)了，這就是Service Mesh，Service Mesh定義是：一個用于處理服務(wù)于服務(wù)之間通信（調(diào)用）的復(fù)雜的基礎(chǔ)架構(gòu)設(shè)施。從本質(zhì)上看，Service Mesh是一組網(wǎng)絡(luò)代理程序組成的服務(wù)網(wǎng)絡(luò)，這些代理會與用戶程序部署在一起，充當(dāng)服務(wù)代理，這種代理后來在Google的Istio產(chǎn)品架構(gòu)中稱為“Sidecar”，其實就是采用了代理模式的思想去解決代碼入侵及重復(fù)編碼的問題，。下圖給出了Service Mesh最簡單的架構(gòu)圖。Servie Mesh同樣不是本次的主角，感興趣的小伙伴可自行學(xué)習(xí)。

二、初識k8s

官方原文是：K8s is an abbreviation derived by replacing the 8 letters “ubernete” with 8.

k8s全稱kubernetes，名字來源于希臘語，意思為“舵手”或“領(lǐng)航員”，它是第一代容器技術(shù)的微服務(wù)架構(gòu)（第二代是Servie Mesh）。

Kubernetes最初源于谷歌內(nèi)部的Borg，提供了面向應(yīng)用的容器集群部署和管理系統(tǒng)。Kubernetes 的目標(biāo)旨在消除編排物理/虛擬計算，網(wǎng)絡(luò)和存儲基礎(chǔ)設(shè)施的負(fù)擔(dān)，并使應(yīng)用程序運營商和開發(fā)人員完全將重點放在以容器為中心的原語上進(jìn)行自助運營。Kubernetes 也提供穩(wěn)定、兼容的基礎(chǔ)（平臺），用于構(gòu)建定制化的workflows 和更高級的自動化任務(wù)。

Kubernetes 具備完善的集群管理能力，包括多層次的安全防護(hù)和準(zhǔn)入機(jī)制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊和服務(wù)發(fā)現(xiàn)機(jī)制、內(nèi)建負(fù)載均衡器、故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動升級和在線擴(kuò)容、可擴(kuò)展的資源自動調(diào)度機(jī)制、多粒度的資源配額管理能力。

Kubernetes 還提供完善的管理工具，涵蓋開發(fā)、部署測試、運維監(jiān)控等各個環(huán)節(jié)。

2.1 k8s架構(gòu)與組件

Kubernetes主要由以下幾個核心組件組成：

1. etcd保存了整個集群的狀態(tài)；
2. apiserver提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機(jī)制；
3. controller manager負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測、自動擴(kuò)展、滾動更新等；
4. scheduler負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；
5. kubelet負(fù)責(zé)維護(hù)容器的生命周期，同時也負(fù)責(zé)Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理；
6. Container runtime負(fù)責(zé)鏡像管理以及Pod和容器的真正運行（CRI）；
7. kube-proxy負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；

2.2 k8s設(shè)計理念

API設(shè)計原則

API對象是k8s集群中的管理操作單元。k8s集群系統(tǒng)每支持一項新功能，引入一項新技術(shù)，一定會新引入對應(yīng)的API對象，支持對該功能的管理操作。例如副本集Replica Set對應(yīng)的API對象是RS。

k8s采用聲明式操作，由用戶定義yaml，k8s的API負(fù)責(zé)創(chuàng)建。每個對象都有3大類屬性：元數(shù)據(jù)metadata、規(guī)范spec和狀態(tài)status。元數(shù)據(jù)是用來標(biāo)識API對象的，每個對象都至少有3個元數(shù)據(jù)：namespace，name和uid；除此以外還有各種各樣的標(biāo)簽labels用來標(biāo)識和匹配不同的對象，例如用戶可以用標(biāo)簽env來標(biāo)識區(qū)分不同的服務(wù)部署環(huán)境，分別用env=dev、env=testing、env=production來標(biāo)識開發(fā)、測試、生產(chǎn)的不同服務(wù)。規(guī)范描述了用戶期望k8s集群中的分布式系統(tǒng)達(dá)到的理想狀態(tài)（Desired State），例如用戶可以通過復(fù)制控制器Replication Controller設(shè)置期望的Pod副本數(shù)為3；status描述了系統(tǒng)實際當(dāng)前達(dá)到的狀態(tài)（Status），例如系統(tǒng)當(dāng)前實際的Pod副本數(shù)為2；那么復(fù)制控制器當(dāng)前的程序邏輯就是自動啟動新的Pod，爭取達(dá)到副本數(shù)為3。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

• apiVersion - 創(chuàng)建對象的Kubernetes API 版本
• kind - 要創(chuàng)建什么樣的對象？
• metadata- 具有唯一標(biāo)示對象的數(shù)據(jù)，包括 name（字符串）、UID和Namespace（可選項）

使用上述.yaml文件創(chuàng)建Deployment，是通過在kubectl中使用kubectl create命令來實現(xiàn)。將該.yaml文件作為參數(shù)傳遞。如下例子：

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

k8s常見對象：Pod、復(fù)制控制器（Replication Controller,RC）、副本集（Replica Set,RS）、部署（Deployment）、服務(wù)（Service）、任務(wù)（Job）、存儲卷（Volume）、持久存儲卷和持久存儲卷聲明（Persistent Volume,PV、Persistent Volume Claim,PVC）、節(jié)點（Node）、ConfigMap、Endpoint等。

控制機(jī)制設(shè)計原則

• 每個模塊都可以在必要時優(yōu)雅地降級服務(wù)控制邏輯應(yīng)該只依賴于當(dāng)前狀態(tài)。這是為了保證分布式系統(tǒng)的穩(wěn)定可靠，對于經(jīng)常出現(xiàn)局部錯誤的分布式系統(tǒng)，如果控制邏輯只依賴當(dāng)前狀態(tài)，那么就非常容易將一個暫時出現(xiàn)故障的系統(tǒng)恢復(fù)到正常狀態(tài)，因為你只要將該系統(tǒng)重置到某個穩(wěn)定狀態(tài)，就可以自信的知道系統(tǒng)的所有控制邏輯會開始按照正常方式運行。
• 假設(shè)任何錯誤的可能，并做容錯處理。在一個分布式系統(tǒng)中出現(xiàn)局部和臨時錯誤是大概率事件。錯誤可能來自于物理系統(tǒng)故障，外部系統(tǒng)故障也可能來自于系統(tǒng)自身的代碼錯誤，依靠自己實現(xiàn)的代碼不會出錯來保證系統(tǒng)穩(wěn)定其實也是難以實現(xiàn)的，因此要設(shè)計對任何可能錯誤的容錯處理。
• 盡量避免復(fù)雜狀態(tài)機(jī)，控制邏輯不要依賴無法監(jiān)控的內(nèi)部狀態(tài)。因為分布式系統(tǒng)各個子系統(tǒng)都是不能嚴(yán)格通過程序內(nèi)部保持同步的，所以如果兩個子系統(tǒng)的控制邏輯如果互相有影響，那么子系統(tǒng)就一定要能互相訪問到影響控制邏輯的狀態(tài)，否則，就等同于系統(tǒng)里存在不確定的控制邏輯。
• 假設(shè)任何操作都可能被任何操作對象拒絕，甚至被錯誤解析。由于分布式系統(tǒng)的復(fù)雜性以及各子系統(tǒng)的相對獨立性，不同子系統(tǒng)經(jīng)常來自不同的開發(fā)團(tuán)隊，所以不能奢望任何操作被另一個子系統(tǒng)以正確的方式處理，要保證出現(xiàn)錯誤的時候，操作級別的錯誤不會影響到系統(tǒng)穩(wěn)定性。
• 每個模塊都可以在出錯后自動恢復(fù)。由于分布式系統(tǒng)中無法保證系統(tǒng)各個模塊是始終連接的，因此每個模塊要有自我修復(fù)的能力，保證不會因為連接不到其他模塊而自我崩潰。
• 每個模塊都可以在必要時優(yōu)雅地降級服務(wù)。所謂優(yōu)雅地降級服務(wù)，是對系統(tǒng)魯棒性的要求，即要求在設(shè)計實現(xiàn)模塊時劃分清楚基本功能和高級功能，保證基本功能不會依賴高級功能，這樣同時就保證了不會因為高級功能出現(xiàn)故障而導(dǎo)致整個模塊崩潰。根據(jù)這種理念實現(xiàn)的系統(tǒng)，也更容易快速地增加新的高級功能，以為不必?fù)?dān)心引入高級功能影響原有的基本功能。

三、資源管理

容器云平臺如何對租戶可用資源進(jìn)行精細(xì)管理，對平臺的可用性、可維護(hù)性和易用性起著至關(guān)重要的作用，是容器云平臺能夠為用戶提供豐富的微服務(wù)管理的基石。在云計算領(lǐng)域，資源可被分為計算資源、網(wǎng)絡(luò)資源和存儲資源三大類，也可被分別稱作計算云、網(wǎng)絡(luò)云和存儲云。

3.1、計算資源管理

Namespace

在k8s集群中，提供計算資源的實體叫做Node，Node既可以是物理機(jī)服務(wù)器，也可以是虛擬機(jī)服務(wù)器，每個Node提供了CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源。每個Node（節(jié)點）具有運行pod的一些必要服務(wù)，并由Master組件進(jìn)行管理，Node節(jié)點上的服務(wù)包括Docker、kubelet和kube-proxy。

通過引入Namespace，k8s將集群近一步劃分為多個虛擬分組進(jìn)行管理，Namespace所實現(xiàn)“分區(qū)”是邏輯上的，并不與實際資源綁定，它用于多租戶場景實現(xiàn)資源分區(qū)和資源最大化利用。

大多數(shù)Kubernetes資源（例如pod、services、replication controllers或其他）都在某些Namespace中，但Namespace資源本身并不在Namespace中。而低級別資源（如Node和persistentVolumes）不在任何Namespace中。Events是一個例外：它們可能有也可能沒有Namespace，具體取決于Events的對象。

Pod

Pod是Kubernetes創(chuàng)建或部署的最小/最簡單的基本單位，一個Pod代表集群上正在運行的一個進(jìn)程。

一個Pod封裝一個應(yīng)用容器（也可以有多個容器），存儲資源、一個獨立的網(wǎng)絡(luò)IP以及管理控制容器運行方式的策略選項。Pod代表部署的一個單位：Kubernetes中單個應(yīng)用的實例，它可能由單個容器或多個容器共享組成的資源。

每個Pod都是運行應(yīng)用的單個實例，如果需要水平擴(kuò)展應(yīng)用（例如，運行多個實例），則應(yīng)該使用多個Pods，每個實例一個Pod。在Kubernetes中，這樣通常稱為Replication。Replication的Pod通常由Controller創(chuàng)建和管理。Controller可以創(chuàng)建和管理多個Pod，提供副本管理、滾動升級和集群級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節(jié)點上的Pod調(diào)度到其他健康的Node上。

Container

docker本身比較重，2015年OCI（Open Container Initiative）誕生，它定義了鏡像標(biāo)準(zhǔn)、運行時標(biāo)準(zhǔn)和分發(fā)標(biāo)準(zhǔn)，由于k8s 本身不具備創(chuàng)建容器的能力，是通過 kubelet 組件調(diào)用容器運行時 API 接口和命令來創(chuàng)建容器，Kubernete 與 容器運行時的關(guān)系是歷史性的，也很復(fù)雜。但是隨著 Kubernete 棄用 Docker ，目前主流的運行時主要是 containerd 和 CRI-O

“one-container-per-Pod”模式是Kubernetes最常見的用法，一個Pod也可以有多個容器。

三個級別的計算資源管理

在k8s中，可以從Namespace、Pod和Container三個級別區(qū)管理資源的配置和限制。例如：

• 容器級別可以通過Resource Request、Resource Limits配置項

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
spec:
  containers:
  - name: memory-demo-3-ctr
    image: vish/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
    args:
    - -mem-total
    - 150Mi
    - -mem-alloc-size
    - 10Mi
    - -mem-alloc-sleep
    - 1s

• Pod級別可以通過創(chuàng)建LimitRange對象完成設(shè)置，這樣可以對Pod所含容器進(jìn)行統(tǒng)一配置

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 2Gi
    min:
      cpu: 200m
      memory: 6Mi
    maxLimitRequestRatio:
      cpu: 3
      memory: 2
    type: Pod
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
    maxLimitRequestRatio:
      cpu: 5
      memory: 4
    type: Container

• Namespace級別可以通過對ReSourceQuota資源對象的配置，提供一個總體的資源使用量限制，這個限制可以是對所有Poid使用的計算資源總量上限，也可以是對所有Pod某種類型對象的總數(shù)量上限（包括可以創(chuàng)建的Pod、RC、Service、Secret、ConfigMap及PVC等對象的數(shù)量）

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
  request.cpu: "4"
  request.memory: 8GB
  limit.memory:16GB
  pods: "2"

3.2 網(wǎng)絡(luò)資源管理

k8s的ip模型

?node Ip ：node節(jié)點的ip，為物理ip.

pod Ip：pod的ip，即docker 容器的ip，為虛擬ip。

cluster Ip：service 的ip，為虛擬ip。提供一個集群內(nèi)部的虛擬IP以供Pod訪問。實現(xiàn)原理是通過Linux防火墻規(guī)則，屬于NAT技術(shù)。當(dāng)訪問ClusterIP時，請求將被轉(zhuǎn)發(fā)到后端的實例上，如果后端實例有多個，就順便實現(xiàn)了負(fù)載均衡，默認(rèn)是輪訓(xùn)方式。

跨主機(jī)容器網(wǎng)絡(luò)方案

在k8s體系中，k8s的網(wǎng)絡(luò)模型設(shè)計的一個基本原則：每個pos都擁有一個獨立的IP地址，而且假定所有的Pod都在一個可以直接聯(lián)通的、扁平的網(wǎng)絡(luò)空間中，不管它們是否運行在同一個Node（宿主機(jī)）中，都可以直接通過對方的IP進(jìn)行訪問。但k8s本身并不提供跨主機(jī)的容器網(wǎng)絡(luò)解決方案。公有云環(huán)境（例如AWS、Azure、GCE）通常都提供了容器網(wǎng)絡(luò)方案，但是在私有云環(huán)境下，仍然需要容器云平臺位不同的租戶提供各種容器網(wǎng)絡(luò)方案。

目前，為容器設(shè)置Overlay網(wǎng)絡(luò)是最主流的跨主機(jī)容器網(wǎng)絡(luò)方案。Overlay網(wǎng)絡(luò)是指在不改變原有網(wǎng)絡(luò)配置的前提下，通過某種額外的網(wǎng)絡(luò)協(xié)議，將原IP報文封裝起來形成一個邏輯上的網(wǎng)絡(luò)。在k8s平臺上，建議通過CNI插件的方式部署容器網(wǎng)絡(luò)。

CNI（Container Network Interface）是CNCF基金會下的一個項目，由一組用于配置容器的網(wǎng)絡(luò)接口的規(guī)范和庫組成，它定義的是容器運行環(huán)境與網(wǎng)絡(luò)插件之間的接口規(guī)范，僅關(guān)心容器創(chuàng)建時的網(wǎng)絡(luò)配置和容器被銷毀是網(wǎng)絡(luò)資源的釋放，并且一個容器可以綁定多個CNI網(wǎng)絡(luò)插件加入網(wǎng)絡(luò)中，如下圖。

目前比較流程的CNI插件實現(xiàn)方式有Flannel、Calico、macvlan、Open vSwitch、直接路由。

Ingress

在k8s集群內(nèi)，應(yīng)用默認(rèn)以Service的形式提供服務(wù)，有kube-proxy實現(xiàn)Service到容器的負(fù)載均衡器的功能，如下圖定義一個mysql service：

kind: Service
apiVersion: v1
metadata:
  name: mysql-master
spec:
  selector:
    app: mysql-master
  ports:
      port: 3306
      targetPort: 3306

此時，集群外是無法訪問這個Service的。對于需要k8s集群外的客戶端提供服務(wù)的Service，可以通過Ingress將服務(wù)暴露出去，并且如果該集群（網(wǎng)絡(luò)）擁有真實域名，則還能將Service直接與域名進(jìn)行對接。

k8s將一個Ingress資源對象的定義和一個具體的Ingress Controller相結(jié)合來實現(xiàn)7層負(fù)載均衡器。Ingress Controller在轉(zhuǎn)發(fā)客戶請求到后端服務(wù)時，將跳過kube-proxy提供的4層負(fù)載均衡器的功能，直接轉(zhuǎn)發(fā)到Service的后端Pod（Endpoints），以提高網(wǎng)絡(luò)轉(zhuǎn)發(fā)效率。

如上圖展示了一個典型的HTTP層路由的Ingress例子，其中：

• 對http://mywebsite.com/api的訪問將被路由到后端名為“api”的Service；
• 對http://mywebsite.com/web的訪問將被路由到后端名為“web”的Service；
• 對http://mywebsite.com/doc的訪問將被路由到后端名為“doc”的Service。

如下是一個典型的Ingress策略定義，Ingress Controller將對目標(biāo)地址http://mywebsite.com/demo的訪問請求轉(zhuǎn)發(fā)到集群內(nèi)部服務(wù)的webapp(webapp:8080/demo)

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   name: mywebsite-ingress
spec:
   rules:
   -host：mywebsite.com
    http:
       paths:
      - path: /demo
          backend:
           serviceName: webapp
           servicePort: 8080

常用的Ingress Controller有：Nginx、HAProxy、Traefik、apisix等。

3.3 存儲資源

k8s支持的Volume類型

臨時目錄（emptyDir）

使用emptyDir，當(dāng)Pod分配到Node上時，將會創(chuàng)建emptyDir，并且只要Node上的Pod一直運行，Volume就會一直存。當(dāng)Pod（不管任何原因）從Node上被刪除時，emptyDir也同時會刪除，存儲的數(shù)據(jù)也將永久刪除。注：刪除容器不影響emptyDir。

配置類

• ConfigMap：將保存在ConfigMap資源對象中的配置文件信息掛載到容器的某個目錄下
• Secret：將保存在Secret資源對象中的密碼密鑰等信息掛載到容器內(nèi)的某個文件中
• DownwardApI：將downward API的數(shù)據(jù)以環(huán)境變量或文件的形式注入容器中
• gitRepo：將某Git代碼庫掛載到容器內(nèi)的某個目錄下

本地存儲類

• hostPath：將宿主機(jī)的目錄或文件掛載到容器內(nèi)進(jìn)行使用
• local：從v1.9版本引入，將本地存儲以PV形式提供給容器使用，并能夠給實現(xiàn)存儲空間的管理

共享存儲類

• PV（Persistne Volume）：將共享存儲定義為一種“持久存儲卷”，可以被多個容器共享使用
• PVC（Persistne Volume Claim）：用戶對存儲資源的一次“申請”，PVC申請的對象是PV，一旦申請成功，應(yīng)用就能夠想使用本地目錄一樣使用共享存儲卷。下圖是一個PV對象ymal定義：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  annotations:
        "volume.alpha.kubernetes.io/node-affinity": '{
            "requiredDuringSchedulingIgnoredDuringExecution": {
                "nodeSelectorTerms": [
                    { "matchExpressions": [
                        { "key": "kubernetes.io/hostname",
                          "operator": "In",
                          "values": ["example-node"]
                        }
                    ]}
                 ]}
              }'
spec:
    capacity:
      storage: 100Gi
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: local-storage
    local:
      path: /mnt/disks/ssd1

PV與PVC

PV和PVC相互關(guān)系生命周期如上圖所示，k8s的共享存儲供應(yīng)模式包括靜態(tài)模式（Static）和動態(tài)模式（Dynamic），資源供應(yīng)的結(jié)果就是創(chuàng)建好的PV。運維人員手動創(chuàng)建PV就是靜態(tài)，而動態(tài)模式的關(guān)鍵就是StorageClass，它的作用就是創(chuàng)建PV模板。

創(chuàng)建StorageClass里面需要定義PV屬性比如存儲類型、大小等；另外創(chuàng)建這種PV需要用到存儲插件。最終效果是，用戶提交PVC，里面指定存儲類型，如果符合我們定義的StorageClass，則會為其自動創(chuàng)建PV并進(jìn)行綁定。

下圖通過ymal創(chuàng)建一個StorageClass對象

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs    // 存儲分配器
parameters:
  type: gp2
reclaimPolicy: Retain   // 回收策略
mountOptions:
  - debug

StorageClass和PV、PVC之間的運作關(guān)系如下圖所示：

CSI

CSI（Container Storage Interface）與k8s的關(guān)系與CNI有點類似，CSI旨在容器和共享存儲之間建議一套標(biāo)準(zhǔn)的存儲訪問接口。在它誕生前，經(jīng)歷了“in-tree”方式、FlexVolume模式。

CSI規(guī)范用語將存儲供應(yīng)商代碼與k8s代碼完全解耦，存儲插件的代碼由存儲供應(yīng)商自行維護(hù)。

和kube-apiserver直接進(jìn)行交互的是K8S官方直接提供的一些sidecar容器，這些sidecar直接部署即可。這些sidecar容器（主要是上圖的三個主要部件）監(jiān)聽自己對應(yīng)的CRD，觸發(fā)對應(yīng)的操作，通過UDS接口直接調(diào)用CSI driver的接口（例如CreateVolume() 、NodePublishVolme()等）來實現(xiàn)對卷的操作。

要開發(fā)CSI Drivers一般來說實現(xiàn)以下幾個服務(wù)：

• CSI Identity service

允許調(diào)用者(Kubernetes組件和CSI sidecar容器)識別驅(qū)動程序及其支持的可選功能。

• CSI Node service

NodePublishVolume, NodeUnpublishVolume 和 NodeGetCapabilities 是必須的。

所需的方法使調(diào)用者能夠使卷在指定的路徑上可用，并發(fā)現(xiàn)驅(qū)動程序支持哪些可選功能。

• CSI Controller Service

實現(xiàn)CreateVolume、DeleteVolume接口

3.4 多集群資源管理方案-集群聯(lián)邦（Federation）

Federation是Kubernetes的子項目，其設(shè)計目標(biāo)是對多個Kubernetess集群進(jìn)行統(tǒng)一管理，將用戶的應(yīng)用部署到不同地域的數(shù)據(jù)中心。Federation引入了一個位于Kubernetes集群只上的控制平面，屏蔽了后端各k8s子集群，向客戶提供了統(tǒng)一的管理入口，如下圖:

Federation控制平面“封裝”了多個k8s集群的Master角色，提供了統(tǒng)一的Master，包括Federation API Server、Federation Controller Manafer，用戶可以向操作單個集群一樣操作Federation，還統(tǒng)一了全部k8s集群的DNS、ConfigMap，并將數(shù)據(jù)保存在集中的etcd數(shù)據(jù)庫中。