5分鐘讓你理解K8S必備架構概念，以及網絡模型（中）

寫在前面

在這用XMind畫了一張導圖記錄Redis的學習筆記和一些面試解析（源文件對部分節點有詳細備註和參考資料，歡迎關注個人公衆號：阿風的架構筆記 後臺發送【導圖】拿下載連接， 已經完善更新）：

前言

在上一篇文章中介紹了K8S的基礎架構流程，以及核心的組件；這篇文章繼續K8S的相關的概念。

上篇介紹到了NodePort Service解決了外部請求K8S內部的應用的問題。下面咱們看看如何搭建應用服務集羣的？

應用集羣

在傳統應用中，咱們通常利用nginx反向代理，經過配置域名指向多個IP地址，從而實現了應用的集羣。若是須要增長應用或減小應用，都須要調整nginx的配置；仍是至關繁瑣的。

那K8S是如何實現應用集羣的呢？

副本集ReplicaSet

上一篇文章中介紹了利用NodePort Service 的Selector 選擇Label標籤，路由到後端的其中一個Pod。

上圖中由3個Pod組成的應用集羣，那如何保證Pod集羣的高可用呢？若是其中一個Pod掛了，被刪除了，K8S會怎麼處理？

K8S有個Replica Set組件，從字面上面來看就是副本集意思；它的做用就是用來保證Pod的高可用，若是咱們在Replica Set中定義了應用數量爲3，那麼它會保證應用數量；即便一個pod掛了，它會自動會啓動1個，始終保證pod應用數量爲3。

編寫yaml

apiVersion: extensions/v1beta1  #指定api版本
kind: ReplicaSet       #指定建立資源的角色/類型
metadata: 
  name: mc-user
spec: 
  replicas: 3       #副本集數量
  template:         #pod模板
    metadata:       #資源的元數據/屬性 
      labels:       #標籤訂義
        app: mc-user  #標籤值
    spec:           # 指定該資源的內容
      containers:    #容器定義
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器鏡像
複製代碼

上面就是定義了 mc-user的pod，副本集數始終爲3。Service的yaml和以前同樣，注意Selector的Label，可提供給外部訪問端口31001

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      nodePort: 31001
  selector:
    app: mc-user
  type: NodePort
複製代碼

執行kubectl apply -f 命令，啓動ReplicaSet和Service

咱們能夠試着查看啓動的3個pod，並選擇其中一個pod將它刪除。

# kubectl get all
# kubectl delete po mc-user-6adfw
複製代碼

咱們再查看pod

kubectl get all
複製代碼

仍是有3個pod，能夠看出即便刪除了一個pod；ReplicaSet會又幫咱們啓動了一個pod。

這個就是ReplicaSet的自愈能力，自我恢復能力。

滾動發佈Rolling Update

咱們先來談談什麼是滾動發佈？滾動發佈是一種高級發佈策略，按批次依次替換老版本，逐步升級到新版本。發佈過程當中，應用不中斷，用戶體驗平滑。

如今Pod中是V1的版本，如今咱們想升級到V2版本，整個流程是什麼樣子呢？

先刪除其中一個V1的pod

而後發佈V2的Pod

再刪除一個V1的pod

再啓動一個V2的Pod

再刪除最後一個V1的pod

最終升級完成。

咱們能夠發現滾動發佈的特色，就是老版本和新版本會共存一段時間。因此此種發佈方式適用版本兼容的應用。也能夠支持滾動回退。咱們來看看和藍綠髮布的區別

滾動發佈抽象Deployment

以前介紹的ReplicaSet 實際上是對Pod的一次包裝，Deployment又在基礎上面對ReplicaSet的又一次包裝。

注意點：ReplicaSet 和 Deployment是一個軟件概念，它是沒有具體的組件的；是抽象出來的名詞，方便你們理解

上圖就是描述了deployment滾動發佈的架構；Deployment的滾動發佈，對用戶請求以及Service是透明的，無感知。

Deployment的yaml

apiVersion: apps/v1  #指定api版本，此值必須在kubectl apiversion中
kind: Deployment       #指定建立資源的角色/類型
metadata: 
  name: mc-user
spec: 
  selector:           #此deployment選擇哪一個標籤進行滾動的發佈
    matchLabels:      #滾動發佈pod的標籤，要跟下面template中的labels一致
      app: mc-user
  minReadySeconds: 10 #最小10s等待就緒時間，能夠方便看到滾動發佈流程
  replicas: 3       #副本集數量
  template:         #pod模板
    metadata:       #資源的元數據/屬性 
      labels:       #標籤訂義
        app: mc-user  #標籤值
    spec:           #指定該資源的內容
      containers:    #容器定義
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器鏡像
複製代碼

上面的yaml和ReplicaSet很相似，須要注意的

selector:        #此deployment選擇哪一個標籤進行滾動的發佈
   matchLabels:  #滾動發佈pod的標籤，要跟下面template中的labels一致
      app: mc-user
複製代碼

定義deployment管理哪一個標籤pod

Service的yaml

Service的yaml沒有變化，須要定義selector，選擇標籤就好了

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      nodePort: 31000
  selector:
    app: mc-user
  type: NodePort
複製代碼

咱們用kubectl apply -f命令執行 deployment和service

咱們再用kubectl get all獲取運行狀況，咱們就能夠發現有兩個類型

deployment.apps/mc-user 以及 replicaset.apps/mc-user-4345afaa

要升級的時候，只須要更改deployment中的image名稱，再執行apply

image: rainbow/mc-user:1.1.RELEASE    #容器鏡像
複製代碼

咱們用kubectl get all查看，就會發現replicaset 有2個；一個是老版本的，一個是新版本的。 老版本的pod數逐漸減小，新版本的pod數量逐漸增長，一直到新版本爲3，老版本爲0。

回退版本

若是發現版本有問題，咱們能夠回退版本，可使用下面命令

kubectl rollout undo deployment/mc-user
複製代碼

這個咱們就回退到V1.0的老版本了。

ConfigMap配置

在咱們平常業務過程當中，須要會配置一些配置參數，如：一次性的靜態配置（數據庫鏈接字符串，用戶名，密碼），以及能夠運行過程當中的動態配置（如：限購數量）等；那K8S中的Pod如何得到外部的配置信息呢？

上圖中，K8S提供了ConfigMap這個功能，提供用戶在外部進行配置，而後K8S把ConfigMap以環境變量的方式提供給Pod中的容器或者也能夠經過Volume文件持久化的方式提供給Pod容器。

共享配置

由於咱們會有不少服務的配置是相同的，那實現微服務之間共享一份配置信息，以下圖

一份ConfigMap能夠提供給多個服務使用，ConfigMap會把配置信息以env方式存在於每一個服務的環境變量中。

ConfigMap的yaml

apiVersion: v1  #指定api版本，此值必須在kubectl apiversion中
kind: ConfigMap       #指定建立資源的角色/類型
metadata: 
  name: mc-user-config
data: #定義配置信息
  DATASOURCE_URL: jdbc:mysql://mysql/mc-user
  DATASOURCE_USERNAME: root
  DATASOURCE_PASSWORD: 123456
複製代碼

修改Deployment配置文件

增長envFrom屬性

apiVersion: apps/v1  #指定api版本，此值必須在kubectl apiversion中
kind: Deployment     #指定建立資源的角色/類型
metadata: 
  name: mc-user
spec: 
  selector:           #此deployment選擇哪一個標籤進行滾動的發佈
    matchLabels:      #滾動發佈pod的標籤，要跟下面template中的labels一致
      app: mc-user
  minReadySeconds: 10 #最小10s等待就緒時間，能夠方便看到滾動發佈流程
  replicas: 3       #副本集數量
  template:         #pod模板
    metadata:       #資源的元數據/屬性 
      labels:       #標籤訂義
        app: mc-user  #標籤值
    spec:           #指定該資源的內容
      containers:    #容器定義
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器鏡像
          envFrom:  #環境變量來源
            - configMapRef: #容器應用的configmap引用
                name: mc-user-config #configMap的名稱
複製代碼

envFrom中的configMapRef配置引用名稱；這樣咱們就能夠在pod容器中獲取到configmap的配置信息了。咱們能夠用

kubectl exec mc-user-34wrwq-3423 printenv ｜ grep DATASOURCE_NAME
複製代碼

得到pod容器中的環境變量。

configMap變動

若是服務已經運行中，咱們更新了ConfigMap的配置信息，那麼POD中的容器會即時得到新的配置信息嗎？

很不幸，更新了configMap；再用kubectl apply -f 從新發布configmap；以前的pod容器是不會得到最新的配置信息的。

那如何讓pod容器用最新的ConfigMap配置值呢？咱們能夠刪除pod，由於replicaset會保證pod數量，會自動重啓，那新的pod就會應用新的配置信息了。

總結

今天介紹K8S的副本集ReplicaSet、滾動發佈Deployment、配置ConfigMap的概念；下一篇會介紹網絡相關的模型。謝謝！！！

看完三件事❤️

​ 若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙： ​

1. 點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。
2. 關注公衆號 『 阿風的架構筆記 』，不按期分享原創知識。
3. 同時能夠期待後續文章ing🚀
4. 關注後回覆【666】掃碼便可獲取架構進階學習資料包