iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 19
0
IoT

從開源kubernetes雲端運算到kubeedge雲邊協同系列 第 19

Day 19 KubeEdge Pod親和性(I)

  • 分享至 

  • xImage
  •  

在前幾天的介紹中我們用來將服務佈署在特定節點上的方式是透過對節點標籤的操作。接下來兩天我們要介紹的是以Pod為條件達到將服務佈署在特定節點上的方法。
透過Pod為條件協助我們佈署服務至指定節點是甚麼意思呢?透過篩選節點上有佈署或沒有佈署哪些Pod做篩選依據,舉例來說我有A跟B兩個對資源要求很高的服務,為了避免他們被佈署到同一節點上,我可以設定條件:B服務只能佈署在沒有運行A服務的節點上;這種以Pod作為篩選佈署節點依據的方式稱為Pod親和性(Pod Affinity)。同時這種佈署方式也有分為HardMode跟SoftMode兩種模式,如同前幾天所提到的一樣意思,今天我們測試的是HardMode。
開始之前一樣放上我的節點狀態,方便辨認那些節點是透過KubeEdge規則加進來的那些是透過Kubernetes加入叢集的:

參數說明

底下是我們用到的YAML檔,接著對參數部分作對照:

# hard-podaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hard-podaffinity
  labels:
    app: hard-podaff
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - high-cost
      topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80

仔細觀察可以發現他和這幾天提到的Node Affinity YAML配置有蠻多相似點的,這裡針對不同點作說明:

  • affinity
    親和性設定
  • nodeAffinity -> podAffinity
    pod親和性
  • nodeSelectorTerms -> labelSelector
    依據Pod作為篩選條件,實際上也就是依據Pod身上帶的標籤(label)去判斷是否有這樣的Pod在節點上

在配對條件中透過類似表達式的方式去設定條件:

  • key
    相當於pod標籤
  • value
    相當於pod標籤的健值
  • operator
    邏輯判斷符號,效果如下表1所示

表1 親和性中的邏輯判斷符號與效果

operator 效果
In 指定 values 的值存在 Label 列表中
NotIn 指定 values 的值不存在 Label 列表中
Exists 指定的 Label 存在 (只考慮label存在與否,不考慮它的 values)
DoesNotExist 指定的 Label 不存在
Gt Label 對應的值大於 values
Lt Label 對應的值小於 values

佈署

接著在佈署之前,我們先營造Pod環境。這裡我們將busybox透過nodeSelector的方式讓他運行到edge節點上。

# busybox-podaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
  labels:
    app: target
spec:
  containers:
  - image: busybox:latest
    name: busybox
    command:
    - "sleep"
    - "3600"
  nodeSelector:
    name: edge

在這裡的YAML檔可以看到labels欄位中的app: target,就是Pod身上附帶的標籤(label)。

kubectl apply -f busybox-podaffinity.yaml

# 檢查佈署狀態
kubectl get pods -o wide

接著佈署hard-podaffinity.yaml

kubectl apply -f hard-podaffinity.yaml

# 查看佈署狀態
kubectl get pods -o wide


可以發現NGINX和busybox被佈署在相同節點上(edge)。

同樣我們也可以在Kubernetes節點上試一次。
先把剛剛佈署的服務砍掉:

kubectl delete -f busybox-podaffinity.yaml hard-podaffinity.yaml

稍微修改一下busybox-podaffinity.yaml,改成將busybox佈署到k8s-node02節點上:

# busybox-podaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
  labels:
    app: target
spec:
  containers:
  - image: busybox:latest
    name: busybox
    command:
    - "sleep"
    - "3600"
  nodeSelector:
    name: k8s-node02
#再次佈署服務
kubectl apply -f busybox-podaffinity.yaml

# 確定服務佈署狀態
kubectl get pods -o wide

kubectl apply -f hard-podaffinity.yaml
kubectl get pods -o wide


可以看到兩個服務同樣都被佈署到k8s-node02上。


上一篇
Day 18 KubeEdge 節點親和性(II)
下一篇
Day 20 KubeEdge Pod親和性(II)
系列文
從開源kubernetes雲端運算到kubeedge雲邊協同30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言