Skip to content

antony@notes:~/kubernetes$ cat "CKA-證照準備.md"

CKA 證照準備

2022-09-17· kubernetes ·系統工程

CKA 2022 證照準備

:::warning

:::spoiler 目錄

[TOC]

:::

證照考試準備資源

考前準備注意事項：

  • 安裝 PSI 程式（上網查也有人用 macOS 考試）
    • 明城老師的雲端硬碟連結
    • 啟用 PSI 程式並驗證環境
      • 關閉特定程式（包含但不限於）：
        • Chrome Remote Desktop
        • VMware player
      • 禁用第二視訊輸出（不接受雙螢幕）
  • 身分驗證（傳送照片為主，未通過會使用 WebCam 進行查核）
    • 證件（護照｜信用卡、身分證）
    • 大頭照（WebCam 直接拍攝）
  • 環境檢查
    • 非開放式空間
    • 需要使用 WebCam 環繞拍攝環境及桌下
    • 桌面、桌下淨空
    • 手機離身，並放置於無法拿取的位置

{%hackmd Y7s6leH0TUyvKPAcGu3YfA %}

考前解題 part 1

第 1 題 : Scale deployment to 6

先檢查 node 主機是否都 Ready

$ kubectl get nodes
  • get，Display one or many resources.
    • Prints a table of the most important information about the specified resources.
    • You can filter the list using a label selector and the –selector flag.
    • If the desired resource type is namespaced you will only see results in your current namespace unless you pass –all-namespaces.

output :

NAME   STATUS   ROLES           AGE     VERSION
m1     Ready    control-plane   4d13h   v1.24.3
w1     Ready    worker          4d12h   v1.24.3
w2     Ready    worker          4d12h   v1.24.3

編輯 nginx.yaml ，Deployment 的 name 為 nginx-test ，replicas=3

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
  • 編輯 yaml 檔時，請注意縮排 ! 請注意縮排 ! 請注意縮排 !

透過 kubectl 去 apply nginx.yaml 檔

$ kubectl apply -f nginx.yaml
  • apply，Apply a configuration to a resource by file name or stdin.
    • The resource name must be specified.
    • This resource will be created if it doesn’t exist yet.
    • To use ‘apply’, always create the resource initially with either ‘apply’ or ‘create–save-config’.
  • -f, --filename=[]，that contains the configuration to apply
    • JSON and YAML formats are accepted.

output :

deployment.apps/nginx-test created
  • created ，表示 deployment.apps/nginx-test 已建立，但能不能跑不確定
  • unchanged，代表 yaml 檔沒變動
  • configured，表示已更新 yaml 檔設定

檢查是否符合 replicas=3 之預期

# List all pods in ps output format
$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-544dc8b7c4-8gh9d   1/1     Running   0          26s
nginx-test-544dc8b7c4-lx88x   1/1     Running   0          26s
nginx-test-544dc8b7c4-rwzgr   1/1     Running   0          26s

透過 kubectl scale ，將 deployment 的 replicas 設為 6

$ kubectl scale deployment nginx-test --replicas=6
  • scale，Set a new size for a deployment, replica set, replication controller, or stateful set.
  • --replicas=COUNT，The new desired number of replicas. Required.

檢查是否符合 replicas=6 之預期

$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-544dc8b7c4-5m45n   1/1     Running   0          81s
nginx-test-544dc8b7c4-67f8w   1/1     Running   0          12s
nginx-test-544dc8b7c4-7zt4h   1/1     Running   0          12s
nginx-test-544dc8b7c4-g2s26   1/1     Running   0          81s
nginx-test-544dc8b7c4-hxdnk   1/1     Running   0          81s
nginx-test-544dc8b7c4-qqw9q   1/1     Running   0          12s
  • 看最右邊的時間，可以發現有 3 台 pod 是剛建立的，總共為 6 台

如果 replicas 重設為 3 ，K8S 會刪掉哪 3 台 pods ?

$ kubectl scale deployment nginx-test --replicas=3
deployment.apps/nginx-test scaled

$ kg pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-544dc8b7c4-7252x   1/1     Running   0          75s
nginx-test-544dc8b7c4-dz25n   1/1     Running   0          75s
nginx-test-544dc8b7c4-wd5q8   1/1     Running   0          75s
  • 推測為隨機刪除

如果 replicas 重設為 2 ，K8S 會無視原始 yaml 檔宣告的 3 個 replicas ，刪掉 1 台 pod 嗎 ?

$ kubectl scale deployment nginx-test --replicas=2 
deployment.apps/nginx-test scaled

$ kg pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-544dc8b7c4-dz25n   1/1     Running   0          3m1s
nginx-test-544dc8b7c4-wd5q8   1/1     Running   0          3m1s
  • 答 : 會

如果 replicas 重設為 0 ，K8S 會刪掉全部的 pod 嗎 ?

$ kubectl scale deployment nginx-test --replicas=0
deployment.apps/nginx-test scaled

$ kubectl get pods
No resources found in default namespace.
  • 透過 kubectl scale 設定的 replicas 的優先權會高於 yaml 檔的設定值

檢查 kubectl scale 是否會更改 yaml 檔的 replicas 設定值

$ kubectl get deployment nginx-test -o yaml
  • -o, --output=''，Output format. One of: ( json, yaml… 等 )

output :

...
spec:
  progressDeadlineSeconds: 600
  replicas: 0
...
  • 答 : 會，但原始的 yaml 檔不會。

此時再將 replicas 設回 3

$ kubectl scale deployment nginx-test --replicas=3
deployment.apps/nginx-test scaled

$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-544dc8b7c4-9vc4x   1/1     Running   0          10s
nginx-test-544dc8b7c4-gm7rn   1/1     Running   0          10s
nginx-test-544dc8b7c4-srjlt   1/1     Running   0          10s

將 replicas 設為 -1

$ kubectl scale deployment nginx-test --replicas=-1
error: The --replicas=COUNT flag is required, and COUNT must be greater than or equal to 0

將 replicas 設為 999 (按 Enter 需要勇氣)

$ kubectl scale deployment nginx-test --replicas=999

:::spoiler output :

:::

:::spoiler 可能的失敗原因 :

:::

  • 記憶體或 cpu 不夠。
  • kubelet 太操了。

解決辦法

  • Kubernetes 的 Access List Control ( ?
  • 設計一個指令中介層，進行預警阻擋破壞性指令 ( ?

第 9 題 : 計算 node 數量，不包含 taint 是 noschedule 的，並寫入指定檔案

這題主要是讓我們可以得知 pod 可以在哪幾台 node 上長出來

透過 $ kubectl get node -o json | jq 可以知道要找的資料在哪個欄位裡面

$ kubectl get node -o custom-columns=NAME:.metadata.name,TAINT:.spec.taints[*].effect
NAME   TAINT
m1     <none>
w1     <none>
w2     <none>
  • -o, --output=''，One of: ( json, yaml, custom-columns…等 )
  • custom-columns= ，可以客製化欄位名稱，中間用 , 做分隔
  • NAME:.metadata.name，NAME 為我們自訂的欄位名稱，: 後面接資料在哪個欄位下，這邊我們要的是 metadata 裡面的 name 的資料
  • TAINT:.spec.taints[*].effect，TAINT 為我們自訂的欄位名稱，: 後面接資料在哪個欄位下，這邊我們要的是 spec 裡面的 taints 裡面的 effect 裡面的資料
    • [*]，所有的 taints 都要

將螢幕資訊做剪剪貼貼

$ kubectl get node -o custom-columns=NAM:.metadata.name,TAINT:.spec.taints[*].effect | grep -v 'NoSchedule' | tail -n 2 | wc -l > Q9

$ cat Q9
2
  • |，pipe，將左邊命令執行後的結果輸入給右邊的命令
  • grep -v，Select non-matching lines，選擇沒有符合 NoSchedule 的其他行
  • tail -n 2，輸出倒數兩行
  • wc -l，算有幾行
  • > Q9，將收到的資料重導到 Q9 這個檔案裡面

延伸討論 : 如果一開始的 pod 建立在一台 Node 上，這時將這台 Node 加上 NoSchedule 這個 taints，原來的 pod 可以跑嗎，還是會被趕走 ?

移除 m1 node NoSchedule 的 taints

$ kubectl taint node m1 node-role.kubernetes.io/master:NoSchedule-

編輯 sleep.yaml 檔

apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    app: busybox1
spec:
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  nodeSelector:
    kubernetes.io/hostname: m1

查看 pod 是否建立在 m1 這台 node 上

$ kubectl apply -f sleep.yaml
pod/busybox1 created

$ kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE   NOMINATED NODE   READINESS GATES
busybox1   1/1     Running   0          3m43s   10.244.0.7   m1     <none>           <none>

幫 m1 node 的 taints 加上 NoSchedule

$ kubectl taint node m1 node-role.kubernetes.io/master:NoSchedule
node/m1 tainted

# 檢查 m1 node 的 taints
$ kubectl get node -o custom-columns=NAM:.metadata.name,TAINT:.spec.taints[*].effect | head -n 2
NAM   TAINT
m1    NoSchedule

檢查 pod 是否還在 m1

$ kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE   NOMINATED NODE   READINESS GATES
busybox1   1/1     Running   0          6m32s   10.244.0.8   m1     <none>           <none>

將整個 K8S Cluster 重開後，檢查 pod 是否會與火重生在別台 node

$ kg nodes
NAME   STATUS   ROLES           AGE     VERSION
m1     Ready    control-plane   4d22h   v1.24.3
w1     Ready    worker          4d22h   v1.24.3
w2     Ready    worker          4d22h   v1.24.3

$ kubectl get node -o custom-columns=NAM:.metadata.name,TAINT:.spec.taints[*].effect | head -n 2
NAM   TAINT
m1    NoSchedule

$ kg node m1 -o json
spec:
...
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...

$ kg pods -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP           NODE   NOMINATED NODE   READINESS GATES
busybox1   1/1     Running   1          14m   10.244.0.9   m1     <none>           <none>
  • 答 : 沒有，還是在 m1 上 running
  • 俊逸老師補充 : 有無可能與 metadata 有關 ? 因一開始 pod 先建立，才在 m1 加上 NoSchedule 的 taint ， NoSchedule 的 taint 目的為 打上去後，之後建立的 pod 不會再被 deploy 到 m1 主機上
  • 結論 : 已經處於 running 狀態的 pod 不會去檢查 NoSchedule 的 taint
  • 根據 Kubernetes 的官網 taint 介紹連結 : https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#concepts
  • The taint has key key1, value value1, and taint effect NoSchedule. This means that no pod will be able to schedule onto node1 unless it has a matching toleration.
    • 以上並沒有說明，node 的 taint effect 值為 NoSchedule ，會驅逐已存在該 node 的 pod ，只說明擁有和這個 taint 相匹配的 toleration 的 Pod 才能夠被分配到 node 這個節點。
  • 於是我檢查了 busybox1 這台 pod 的 toleration
$ kg pods busybox1 -o yaml
...
spec:
...
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  • :::spoiler 發現只有兩個系統預設每個 pod 會有的 toleration ( 點我可展開 )
    • effect: NoExecute ，設定 effect 為 NoExecute ，表示這台 pod 能活在 taint effect 為 NoExecute 的 node 並不會被趕走，如果下面沒設定 tolerationSeconds 的話。
    • key: node.kubernetes.io/not-ready ， node 未準備好。這相當於 node 狀況 Ready 的值為" False"。
    • node.kubernetes.io/unreachable ，當 controler manager 訪問不到 node 。這相當於 node 狀況 Ready 的值為" Unknown"。
    • tolerationSeconds: 300 ，表示在 pod 所在的 node taint 被設定 effect 為 NoExecute 之後，還可以存在多久，單位是秒，以這裡來看就是 5 分鐘
    • 因 K8S 要自動化管理，所以自動添加的 toleration 意味著 Pod 可以在檢測到對應的問題之一時，在 5 分鐘內保持綁定在該節點上。
    • 設定 5 分鐘的原因，可能是 node 不小心斷線，結果上面的 pod 全部被趕走就尷尬了。 :::
  • 根據以上結果也沒發現這台 pod 存在對應 taint effect 為 NoSchedule 的 toleration，所以用結果反推 taint effect 為 NoSchedule 的話
  • NoSchedule，當某一台 node 上設定了 taint 的 effect 為 NoSchedule，那麼 K8S 就不會把該 pod 分派到該 node 上，但不影響正在運作中的 pod。
  • NoExecute，當某一台 node 被設定了 effect 為 NoExecute 的 taint，那麼 K8S 還是會把已經存在該 node 上的 pod 趕走，也不會把該 pod 分派到該 node 上。
  • taint & toleration 是互相抵消的關係，若 node 上有設定 taint，而 pod spec 中又有設定符合的 toleration，就會互相抵消；而 k8s scheduler 在判斷時會以最後剩下的 taint 來進行工作分派的依據。
  • 參考文章連結 : https://godleon.github.io/blog/Kubernetes/k8s-Taints-and-Tolerations/

第 12 題 : 列出指定 pod 的 log 中的 error 記錄到指定檔案

先建立一個空檔案

$ touch error.txt

編輯 error.yaml，故意讓 while 迴圈沒有 do

apiVersion: v1
kind: Pod
metadata:
  name: error-example
spec:
  containers:
  - image: busybox
    args: [/bin/sh, -c, 'while true; echo $(date); sleep 1; done']
    imagePullPolicy: IfNotPresent
    name: error-example
  restartPolicy: Never

透過 kubectl logs 顯示 pod 裡面 Container 的 log ，再用 > ，將訊息重導到 error.txt

$ kubectl logs error-example > error.txt

$ cat error.txt
/bin/sh: syntax error: unexpected "done" (expecting "do")
  • logs，Print the logs for a container in a pod or specified resource. If the pod has only one container, the container name is optional.

如果一個 pod 裡面有多個 Container ，這時候要怎麼指定 ?

編輯 yaml 檔，讓不同 Container 錯不一樣的內容

apiVersion: v1
kind: Pod
metadata:
  name: error-example
spec:
  containers:
  - image: busybox
    args: [/bin/sh, -c, 'while true; echo $(date); sleep 1; done']
    imagePullPolicy: IfNotPresent
    name: error-example-1
  - image: busybox
    args: [/bin/sh, -c, 'while do true; echo $(date); sleep 1']
    imagePullPolicy: IfNotPresent
    name: error-example-2
  restartPolicy: Never

再重新 apply

$ kubectl delete -f error.yml

$ kubectl apply -f error.yml

$ kubectl logs error-example
Defaulted container "error-example-1" out of: error-example-1, error-example-2
/bin/sh: syntax error: unexpected "done" (expecting "do")

$ kubectl logs error-example -c error-example-1
/bin/sh: syntax error: unexpected "done" (expecting "do")

$ kubectl logs error-example -c error-example-2
/bin/sh: syntax error: unexpected "do"
  • 如果沒有特別指定要看 pod 裡面的 Container 的話，執行 kubectl logs 只會看到預設 Container 的錯誤訊息
  • 如果要指定的話，要再命令後面加 -c 來指定要看哪個 Container
  • 明成老師的經驗分享 :
    • 如果 pod 裡面有 init Container 出 Error ，用 kubectl logs 可以看的到 Error 是甚麼，但會看不到是哪個 Container 爆 Error ，所以要記住自己 init 哪個 Container 的名稱，因為 logs 出來是 pod 已經成形了，他才會知道他有哪些 Container 。
    • init Container 做完會不見， pod 成形之前，Container 在 init 時發生錯誤時是查的到的。
    • describe，紀錄 K8S 收到佈署命令之後的所有過程都會在 describe 中出現。
  • 俊逸老師補充 :
    • init Container 做完就會刪除，所以看不到很正常，因為 init Container 產生的資訊會被記錄，寫下來的東西會被最後面成形的 Container 繼承，所以看的到 log 但會不曉得 init Container 為什麼出錯。
    • init Container 如果有很多台，只要中間有一個步驟錯了，後面就不會再繼續做下去。如果有 3 個 init Container ，在第三個錯的話，後面就不會做了，如果是在第 2 的錯的話，第三個和最後建的 Container 和 pod 都不會執行。

CKA Simulator Kubernetes 1.24 模擬考筆記

Pre Setup 

alias k=kubectl                         # will already be pre-configured

export do="--dry-run=client -o yaml"    # k create deploy nginx --image=nginx $do

export now="--force --grace-period 0"   # k delete pod x $now
  • --dry-run=client，https://stackoverflow.com/questions/64279343/kubectl-dry-run-is-deprecated-and-can-be-replaced-with-dry-run-client

Question 2 | Schedule Pod on Master Node

Task weight: 3%

Use context: kubectl config use-context k8s-c1-H

Create a single Pod of image httpd:2.4.41-alpine in Namespace default. The Pod should be named pod1 and the container should be named pod1-container. This Pod should only be scheduled on a master node, do not add new labels any nodes.

Answer:

First we find the master node(s) and their taints:

# find master node
$ k get node

# get master node taints
$ k describe node cluster1-master1 | grep Taint -A1 

# get master node labels
$ k get node cluster1-master1 --show-labels

Next we create the Pod template:

# check the export on the very top of this document so we can use $do
$ k run pod1 --image=httpd:2.4.41-alpine $do > 2.yaml

$ nano 2.yaml

Perform the necessary changes manually. Use the Kubernetes docs and search for example for tolerations and nodeSelector to find examples:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  containers:
  - image: httpd:2.4.41-alpine
    name: pod1-container                       # change
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  tolerations:                                 # add
  - effect: NoSchedule                         # add
    key: node-role.kubernetes.io/master        # add
  - effect: NoSchedule                         # add
    key: node-role.kubernetes.io/control-plane # add
  nodeSelector:                                # add
    node-role.kubernetes.io/control-plane: ""  # add
status: {}
  • apiVersion ，使用哪一個版本的 Kubernetes API 創建想要的物件
  • kind，想要建立甚麼物件?
    • kubectl api-resources，打這個命令可以看到當前版本的所有物件
  • metadata，Data that helps uniquely identify the object, including a name string, UID, and optional namespace.
    • creationTimestamp，記錄物件創建的時間
    • labels，設定 pod 上的標籤
      • run: pod1，格式 key: value，等等建立出來的 pod 會有這個標籤
    • name，設定物件的名字
  • spec，對於物件的描述，在 pod 的描述中，container 是必須存在的
    • Container，中文翻成貨櫃，把要執行的單一程序 (process) 與他的相依檔 (Bin/API) 使用 Linux Namespace 將之隔離, 並整合 Linux 核心功能 chroot/overlay2/CGroup/Virtual Bridge 及 Linux Kernel 使之成為一部 真實電腦
    • image，run Container 用的 image
    • name，設定 Container 的名字
    • resources，設定 Container 可以用的硬體資源，像是 CPU 和 記憶體的限制
    • dnsPolicy，Set DNS policy for the pod. Defaults to “ClusterFirst”，
      • ClusterFirst，通過 CoreDNS 來做域名解析，Pod 內 /etc/resolv.conf 配置的 DNS 服務地址是集群 DNS 服務的 kube-dns 地址。
      • 參考文件連結
    • restartPolicy，設定 pod 裡的所有 Container 甚麼時候會被重啟
    • tolerations，容忍度，在條件允許下，pod 能被派到在有 Taints 的 node 上
      • effect: NoSchedule 和 key: node-role.kubernetes.io/master，要一起看，表示 pod 可以接受 “帶有 key 是 node-role.kubernetes.io/master 和 effect 是 NoSchedule” 的 taint 的 node
      • effect: NoSchedule 和 key: node-role.kubernetes.io/control-plane，要一起看，表示 pod 可以接受 “帶有 key 是 node-role.kubernetes.io/control-plane 和 effect 是 NoSchedule” 的 taint 的 node
      • :mag_right: NOTE: In K8s 1.24 master/controlplane nodes have two Taints which means we have to add Tolerations for both. This is done during transitioning from the wording “master” to “controlplane”.
    • nodeSelector，根據 node 上的標籤來指定 pod 會被分派到哪台 node 上
      • node-role.kubernetes.io/control-plane: ""，此標籤的 key 是 node-role.kubernetes.io/control-plane，value 是空值
    • status，描述物件的當前狀態
      • {}，因為目前物件未產生，所以沒有狀態

Important here to add the toleration for running on master nodes, but also the nodeSelector to make sure it only runs on master nodes. If we only specify a toleration the Pod can be scheduled on master or worker nodes.

Now we create it:

$ k -f 2.yaml create

Let’s check if the pod is scheduled:

$ k get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP           NODE   NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          25s   10.244.2.2   m3     <none>           <none>

Question 12 | Deployment on all Nodes

Task weight: 6%

Use context: kubectl config use-context k8s-c1-H

Use Namespace project-tiger for the following. Create a Deployment named deploy-important with label id=very-important (the Pods should also have this label) and 3 replicas. It should contain two containers, the first named container1 with image nginx:1.17.6-alpine and the second one named container2 with image kubernetes/pause.

There should be only ever one Pod of that Deployment running on one worker node. We have two worker nodes: cluster1-worker1 and cluster1-worker2. Because the Deployment has three replicas the result should be that on both nodes one Pod is running. The third Pod won’t be scheduled, unless a new worker node will be added.

In a way we kind of simulate the behaviour of a DaemonSet here, but using a Deployment and a fixed number of replicas.

Answer:

There are two possible ways, one using podAntiAffinity and one using topologySpreadConstraint.

PodAntiAffinity

The idea here is that we create a “Inter-pod anti-affinity” which allows us to say a Pod should only be scheduled on a node where another Pod of a specific label (here the same label) is not already running.

Let’s begin by creating the Deployment template:

$ k -n project-tiger create deployment \
  --image=nginx:1.17.6-alpine deploy-important $do > 12.yaml
  
$ nano 12.yaml

Then change the yaml to:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    id: very-important                  # change
  name: deploy-important
  namespace: project-tiger              # important
spec:
  replicas: 3                           # change
  selector:
    matchLabels:
      id: very-important                # change
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        id: very-important              # change
    spec:
      containers:
      - image: nginx:1.17.6-alpine
        name: container1                # change
        resources: {}
      - image: kubernetes/pause         # add
        name: container2                # add
      affinity:                                             # add
        podAntiAffinity:                                    # add
          requiredDuringSchedulingIgnoredDuringExecution:   # add
          - labelSelector:                                  # add
              matchExpressions:                             # add
              - key: id                                     # add
                operator: In                                # add
                values:                                     # add
                - very-important                            # add
            topologyKey: kubernetes.io/hostname             # add
status: {}
  • spec.template.spec.affinity，設定 pod 的親和力
    • 有分 Node affinity/anti-affinity 和 Inter-pod affinity/anti-affinity
  • affinity.podAntiAffinity，設定 pod 不應該被分配到已經有同樣 label 的 pod 正在 running 的 node 上
  • anti-affinity 官網定義，allow you to constrain (約束) which nodes your Pods can be scheduled on based on the labels of Pods already running on that node, instead of the node labels.
  • requiredDuringSchedulingIgnoredDuringExecution ，要拆成兩個部分來看
    • requiredDuringScheduling ，一定要 pod 符合條件，scheduler 才會把 pod 分派到 node 上面去跑
    • IgnoredDuringExecution，表示當 pod 已經正在運作中了，即使 pod 的 label 在之後遭到變更，pod 浴火重生，也不會影響正在運作中的 pod
  • operator，提供多種篩選機制
    • In，指定 values 的值存在 Label 列表中
    • NotIn：指定 values 的值不存在 Label 列表中
    • Exists：指定的 Label 存在 (不考慮 values)
    • DoesNotExist: 指定的 Label 不存在
    • Gt：Label 對應的值大於 values (字串比對)
    • Lt：Label 對應的值小於 values (字串比對)
  • topologyKey，pod 在分配時要確保 worker node 帶有 key 為 “kubernetes.io/hostname” 的 label，但不能有相同的 value
  • 參考文件 :
Kubernetes 公共建設Kubernetes Resource Storage