延續昨天的內容，昨天提到親和性佈署分為兩種模式，一種是HardMode一種是SoftMode。在HardMode中必須有完全符合規則的節點才能成功佈署服務；SoftMode則是參考規則上的積分判斷，依照符合規則所對應到的積分，累積積分較高的節點會優先佈署，如果積分一樣的話則參考資源較多的節點優先佈署，因此不會發生服務無法成功佈署的情況。今天要接著測試的是節點親和性中的SoftMode特性。
底下是這次測試的節點環境:

在Kubernetes節點上測試

首先先加上節點標籤:

kubectl label nodes k8s-node02 status=ok

接著是使用的YAML:

# soft-nodeaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: soft-nodeaffinity
  labels:
    app: soft-nodeaff
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: status
            operator: In
            values:
            - ok
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80

在YAML檔中跟HardMode中的YAML有一點不同:
在spec.affinity.nodeAffinity底下

• requiredDuringSchedulingIgnoredDuringExecution
  改成preferredDuringSchedulingIgnoredDuringExecution，required->preferred

• weight
  權重，意思是如果該節點符合這個規則的話就可以取得對應的積分。最後佈署時便會依照累積積分高低決定服務被佈署的節點。

底下的邏輯規則跟HardMode中的判斷式式一樣的。

kubectl apply -f soft-nodeaffinity.yaml
kubectl get pods -o wide

可以看到k8s-node02節點因為積分較高(符合規則得到1點積分)所以服務被佈署上去。

在KubeEdge節點上測試

把剛剛佈署的服務移除

kubectl delete -f soft-nodeaffinity.yaml

# 去除節點標籤
kubectl label nodes k8s-node02 status-

# 加上節點標籤
kubectl label nodes edge status=ok

同樣使用同一份YAML檔

kubectl apply -f soft-nodeaffinity.yaml
kubectl get pods -o wide

可以看到服務成功佈署到edge節點上

SoftMode與HardMode的差異

我們前面提到SoftMode與HardMode間最大的差別是SoftMode會選擇最符合判斷規則的節點佈署服務；而HardMode會選擇完全符合判斷規則的節點佈署，如果沒有符合的節點便會放棄佈署。因此我們就來測試看看。
首先一樣先移除掉服務

kubectl delete -f soft-nodeaffinity.yaml

接著移除節點標籤，此時所有節點都沒有status=ok這個標籤:

kubectl label nodes edge status-

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

可以發現服務佈署在k8s-node02節點上，由於該節點資源較多因此系統選擇將服務佈署過去，而不會像HardMode時發生服務無法佈署的情形。