iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 7
0

昨天介紹完了,基礎的 Deployment 的應用,今天要來講講實務上 Deployment 的應用方式。

一般來說,我們都會系統可以高自動化,可以自動做擴展, ex 當 CPU 超過多少就幫我擴展 N 個 POD、當 RAM 超過多少時就增加 POD。

Horizontal Pod Autoscaler

其實設定的方式很簡單,我們只要透過下面語法就能做到,

$ kubectl --kubeconfig ~/.kube/k3s.yaml autoscale deployment nginx-deployment --min=5 --max=15 --cpu-percent=70
horizontalpodautoscaler.autoscaling/nginx-deployment autoscaled

## 上面意思為,我最小需求 POD 為 5 個,最大不能超過 15 個,只要 POD CPU使用率超過 70% 就做擴展。所以他啟動時會從 5 個,依照 loading 慢慢往上加。

也可以透過語法檢查目前 HPA 的設定。

$ kubectl --kubeconfig ~/.kube/k3s.yaml get hpa
NAME               REFERENCE                     TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
nginx-deployment   Deployment/nginx-deployment   <unknown>/70%   5         15        10         2m27s

比較好的方式是直接在部署時決定要怎麼 scale 的策略,所以我們修改一下昨天部署過的 yaml 檔

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 # 同時建立 3 個 nginx 的 pod
  # replicaset 的效果套用在帶有 app=nginx 的 pod 上
  # 必須要與下面的 pod label 有相符合
  selector:
    matchLabels:
      app: nginx
  # .spec.template 其實就是 pod 的定義
  template:
    # pod metadata
    metadata:
      # 設定給 pod 的 label 資訊
      labels:
        app: nginx
    spec:
      # 這邊可以看到,其實跟昨天的 nginx 是一樣的。
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        # 這邊加上資源限制,有了資源限制,後續才好評估超過時要怎麼 scale
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m

然後再透過 HPA yaml 就可以達成跟指令一樣的效果

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-deployment
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta2
    kind: Deployment
    name: nginx-deployment
  minReplicas: 5
  maxReplicas: 15
  targetCPUUtilizationPercentage: 70

RollingUpdateStrategy

這個東西,也是在實務上很重要的一環,他可以決定你在更新當下,可以維持多少 POD 是正常運作的。

我們來看看下面這個設定檔,跟前幾天的有什麼不一樣。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # 升級過程中最多可以比原先設定所多出的 pod 數量 ex 下面是指升級過程中 POD 總數可能會變到 4 個(上面設定 replicas 為 3)
      maxSurge: 1
      # 最多可以有幾個 pod 處在無法服務的狀態 ex 下面為最多一個 POD 為不可服務狀態。
      maxUnavailable: 1
  # 容器內應用程式的啟動時間,Kubernetes 會等待設定的時間後才繼續進行升級流程 (沒設定 POD 完成會直接啟動)
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

如果不想要 RollingUpdate 可以強制把 strategy.type 設定成 Recreate (就算不填預設是 RollingUpdate),這樣升級策略就會變成,他會一次把全部 POD 關閉,然後再一次把全部 POD 升級上來。這樣服務就無法做到無中斷更新。

總結

Deployment 是 k8s 裡面非常重要的元素,這邊只是用了少少的篇幅去介紹幾個我比較常用,以及我覺得入門時應該先學的幾個重點,如果行有餘力,建議還是參考官方的完整參數設定,會更了解 Deployment 的一切。


上一篇
Day6 k8s Deployment 介紹-1
下一篇
Day8 k8s Service 介紹
系列文
k8s 生態鏈 完美組合30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言