k8s之deployment

之前service以及rc已經可以做到滾動升級並且服務發現、負載均衡等功能，為什么還需要deployment這個組件呢？

前面使用rc和service是通過selector進行關聯的，但是在rc的滾動升級過程中selector是可能發生改變的，所以升級之后service與rc可能失去關聯關系導致無法訪問。

定義一個deployment：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: 192.168.56.201:5000/nginx:1.13
        ports:
        - containerPort: 80

 

 此時，deployment會創建一個rs，rs具有大部分rc的功能，但是還沒有暴露端口出來還無法訪問，可以通過以下指令暴露端口：

 

 可以看到通過創建svc暴露端口，即宿主機的55107端口，

 

 可以看到此時使用的鏡像是NGINX1.13版本，如果要升級鏡像版本，可以通過直接編輯deployment即可。

 

 再次訪問就已經升級到了新的版本

 

 

---

通過觀察我們可以發現他是通過rs來進行滾動升級，先創建了一個新的rs，rs創建了三個新的pod，但是對service沒有任何影響

此時如果想要回滾，操作也很簡單：

 

 可以看到NGINX又回到了之前的1.13版本

---

同時也可以使用history命令查看該deployment的升級歷史信息，但是這里無法看到CAHNGE-CAUSE，這也是通過edit升級造成的弊端，所以也是不推薦的方式。

 

 想要保留歷史版本的變更信息可以通過以下方式創建deployment。（其中關鍵就在最后的--record參數）

 

 這樣就創建了一個以NGINX：1,13為鏡像、副本數為3、名為NGINX的deployment。

 

這里就可以看到他的歷史變更信息。同樣的，進行升級后也可以查看到相應的變更記錄。

 回滾也是一樣：