Deployment

在新版的 Kubernetes 官方推薦使用 Deployment 來取代 Replication Controller(rc)，兩者間主要相同點包括確保處在服務狀態的 Pod 數量(replicas)能滿足先前所設定的值以及支援滾動升級(Rolling update)，前者額外支援回滾(Roll back)的機制，因此接下來會介紹如何利用 Deployment 來進行滾動升級。

資料來源

簡單提一下為什麼k8s yaml中的kind是使用Deployment，而不是使用Pod呢。
雖然二者都可以把yaml部署到k8s上面，但是行為面來看還是有差異性的。
最直觀的差異性

1.Deployment管理的對象是ReplicaSet，而ReplicaSet管理的對象是Pod
2.Deployment controller會去調度pod
3.對pod進行health check
4.pod壞掉時會監測到並進行重啟
5.使用rolling update的方法更新pod，可以不停機的方式更新pod
6.根據使用資源(CPU/MEM)進行pod的自動擴充/縮減
用Pod就需要自行處理啦~~~
有Deployment沒煩惱

推薦kubernetes deployment cheatsheet By jimmy song，有興趣可以看看，那張圖畫的很棒rrrr
Deployment 结构示意图

Deployment yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-myapp
  labels:
    app: myapp
spec:
  replicas: 3  #定義pod的數量要幾個，k8s會根據此設定值，維持pod數量
  template:    
    spec:
      containers:
        - name: myapp #container的名稱
          image: myapp:latest #container image
          imagePullPolicy: Always #拉image的策略，分成Always,Nerver,IfNotPresent
          env: #環境變數
          - name: MY_ENV
            value: "12345"         
          ports: #container對外的port，如果服務本身除了http外還有grpc接口的需求，可以直接在裡面加入另一種grpc的設定
            - name: http
              containerPort: 80 
              protocol: TCP #
            - name: grpc
              containerPort: 8787 
              protocol: TCP #
          readinessProbe: #檢測container是否正常的探測設定
            httpGet: 
              path: "/healthcheck" #指定http route
              port: 80
            initialDelaySeconds: 2 #啟動container延遲幾秒後探測pod健康度
            periodSeconds: 5 #每幾秒做一次
          command: ["./myapp", "start"] #啟動成功後要執行的shell
          resources: #container的資源設定
            requests:
              cpu: 300m
      nodeSelector:
      

- imagePullPolicy :

- Always :每次都檢查
- Nerver :不檢查
- IfNotPresent :如果local有image就不檢查，local沒有時才pull image

• initialDelaySeconds:如果服務啟動到http service能正常運作前就被進行health check的話，會讓pod一直無限重啟，因為對k8s來說，pod的health check fail就會重啟pod，所以initialDelaySeconds的秒數要設定的比http service ready的時間要長一點。

- resources :

- `CPU`資源一般來說就是vCPU，大概就是1 thread,1000m = 1vCPU，如果node是4vCPU規格，對應就有4000m的cpu資源
- `Memory`這邊是使用Mi(Megabyte)

- requests : limits控制上限，requests控制下限，如果沒設定的話就讓pod自由放飛XD，如果要設定HPA話，需要設定requests喔，HPA後面會再說明

requests:
  memory: "64Mi"
  cpu: "250m"
limits:
  memory: "128Mi"
  cpu: "500m"

如果pod資源超過設定值，有可能會發生以下情形就是了

• pod重啟
• pod被驅逐(Eviction)，可以從kubectl get pods上面看到status會呈現Eviction
• pod被終止，但是有可能因為node資源都滿載的情形下，就完全不會重啟

這邊有篇關於pod resources的文章，有興趣可以看看
[Kubernetes] 分配 & 管理 container 所使用到的計算資源

nodeSelector : 將pod部署到特定的node上面，一般是使用label的方法搭配使用

參考資料來源

nodeSelector:
    kubernetes.io/os: linux #指定到k8s os為linux的node，如果cluster有多種os的node時，可以透過這個label去部署到linux的node上

因為本系列的部署是使用helm，所以就不會特別介紹kubectl的部署作法啦，下面是一些deployment的指令用法

# 建立deployment
kubectl create deployment <deployment_name> --image=<image>

# 更新deployment image版本
kubectl set image deployment/<deployment> <container-name>=image:<version>

# 檢查deployment升級的歷史記錄
kubectl rollout history deployment/<deployment>

# 退版
kubectl rollout undo deployment/<deployment>

# 退到特定版本
kubectl rollout undo deployment/<deployment> --to-revision=2

# 重新啟動deployment
kubectl rollout restart deployment/<deployment>

# 擴充到指定數量的pod
kubectl scale --replicas=5 deployment/<deployment>