一 宣告式的升級應用

　　1.1 回顧一下kubernets叢集裡面部署一個應用的形態應該是什麼樣子的，通過一副簡單的圖來描述一下

• 通過RC或者RS裡面的模板建立了三個pod，之後通過一個servcie跟它進行關聯
• 使用者通過service訪問pod裡面應用
• RC或者RS來維護保障叢集裡面的pod數量始終恆定

二 如何對pod裡面應用進行升級

　　　　2.1 升級RS/RC裡面管控的的pod裡面服務，我們無法通過修改某個檔案或者程式碼的形式來替換pod應用的內容，只能通過刪除之前的pod，之後重新建立新版本的pod，之後新的版本pod對客戶端提供服務，這裡有2種方式可以完成這個老版本到新的版本的切換

• 直接刪除所有舊的pod，之後建立新的pod
• 也可以建立新的pod，並等待它們全部執行成功，之後再一次性刪除所有的舊的pod
• 還可以一邊建立新的pod，一邊刪除舊的pod

　　　　2.2 上面提到的辦法各有優缺點

• 直接刪除所有舊的pod，之後建立新的pod，這種比較簡單粗暴，但是會導致服務的短時間的不可用
• 先建立所有新的pod，等待成功之後，在一次全部刪除，這樣會浪費更多的資源，並且要求，服務能夠同時相容新舊版本
• 一邊建立新的pod，一邊刪除舊的pod，這種方式既不浪費資源並且也不會中斷服務，唯一要求就是需要服務能夠同時相容新舊版本，但是對操作要求比較高，也是我們需要深度研究的一種升級版本的方式

三 重點探究第三種實現自動滾動式的升級的方法

　　3.1 建立第一個版本的RC以及service，建立的mainifest如下圖所示

[root@node01 Chapter09]# cat kubia-rc-and-service.yml
apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia-v1
spec:
  replicas: 3
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      
 
- image: luksa/kubia:v1
        name: nodejs
---
apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  type: LoadBalancer
  selector:
    app: kubia
  ports:
  - port: 80
    targetPort: 8080

• 在這個mainifest裡面建立了2個資源，一個RC以及SVC，SVC的selector是RC的標籤
• 若想在一個mainifest裡面建立多個資源，需要使用---進行隔離