作者：京東物流 楊建民

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

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

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

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

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

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

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

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

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

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

二、初識(shí)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)旨在消除編排物理/虛擬計(jì)算，網(wǎng)絡(luò)和存儲(chǔ)基礎(chǔ)設(shè)施的負(fù)擔(dān)，并使應(yīng)用程序運(yùn)營(yíng)商和開發(fā)人員完全將重點(diǎn)放在以容器為中心的原語上進(jìn)行自助運(yùn)營(yíng)。Kubernetes 也提供穩(wěn)定、兼容的基礎(chǔ)（平臺(tái)），用于構(gòu)建定制化的workflows 和更高級(jí)的自動(dòng)化任務(wù)。

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

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

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

Kubernetes主要由以下幾個(gè)核心組件組成：

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

2.2 k8s設(shè)計(jì)理念

API設(shè)計(jì)原則

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

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

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

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

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

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

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

三、資源管理

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

3.1、計(jì)算資源管理

Namespace

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

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

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

Pod

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

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

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

Container

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

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

三個(gè)級(jí)別的計(jì)算資源管理

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

• 容器級(jí)別可以通過Resource Request、Resource Limits配置項(xiàng)

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級(jí)別可以通過創(chuàng)建LimitRange對(duì)象完成設(shè)置，這樣可以對(duì)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級(jí)別可以通過對(duì)ReSourceQuota資源對(duì)象的配置，提供一個(gè)總體的資源使用量限制，這個(gè)限制可以是對(duì)所有Poid使用的計(jì)算資源總量上限，也可以是對(duì)所有Pod某種類型對(duì)象的總數(shù)量上限（包括可以創(chuàng)建的Pod、RC、Service、Secret、ConfigMap及PVC等對(duì)象的數(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é)點(diǎn)的ip，為物理ip.

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

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

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

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

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

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

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

Ingress

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

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

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

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

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

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

如下是一個(gè)典型的Ingress策略定義，Ingress Controller將對(duì)目標(biāo)地址http://mywebsite.com/demo的訪問請(qǐng)求轉(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 存儲(chǔ)資源

k8s支持的Volume類型

臨時(shí)目錄（emptyDir）

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

配置類

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

本地存儲(chǔ)類

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

共享存儲(chǔ)類

• PV（Persistne Volume）：將共享存儲(chǔ)定義為一種“持久存儲(chǔ)卷”，可以被多個(gè)容器共享使用
• PVC（Persistne Volume Claim）：用戶對(duì)存儲(chǔ)資源的一次“申請(qǐng)”，PVC申請(qǐng)的對(duì)象是PV，一旦申請(qǐng)成功，應(yīng)用就能夠想使用本地目錄一樣使用共享存儲(chǔ)卷。下圖是一個(gè)PV對(duì)象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的共享存儲(chǔ)供應(yīng)模式包括靜態(tài)模式（Static）和動(dòng)態(tài)模式（Dynamic），資源供應(yīng)的結(jié)果就是創(chuàng)建好的PV。運(yùn)維人員手動(dòng)創(chuàng)建PV就是靜態(tài)，而動(dòng)態(tài)模式的關(guān)鍵就是StorageClass，它的作用就是創(chuàng)建PV模板。

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

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

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

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

CSI

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

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

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

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

• CSI Identity service

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

• CSI Node service

NodePublishVolume, NodeUnpublishVolume 和 NodeGetCapabilities 是必須的。

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

• CSI Controller Service

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

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

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

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