Kubernetes之Pod調度約束即將Pod分配給節點

本文轉載自查看原文 2020-03-24 13:45 713 Kubernetes官網

　　參考：https://kubernetes.io/zh/docs/concepts/configuration/assign-pod-node/

　　可以約束一個Pod只能在特定的Nodes上運行，或者有限運行在特定的節點上。有幾種方法可以實現這點，推薦的方法都是用標簽選擇器進行選擇。通常這種約束不是必須的，因為調度器將自行進行合理的放置（比如，將Pod分散到節點上，而不是將Pod放置在資源不足的節點上），但是在某種情況下，可以需要更多控制pod停靠的節點，例如確保pod最終落在連接了SSD的機器上，或者將來自兩個不同服務且有大量通信的pod放置在同一個可用區。

　　nodeSelector

　　nodeSelector 是節點選擇約束的最簡單推薦形式。nodeSelector 是 PodSpec 的一個字段。它指定鍵值對的映射。為了使 pod 可以在節點上運行，節點必須具有每個指定的鍵值對作為標簽（它也可以具有其他標簽）。最常用的是一對鍵值對。

　　讓我們來看一個使用 nodeSelector 的例子。

　　步驟零：先決條件

　　本示例假設你已基本了解 Kubernetes 的 pod 並且已經建立一個 Kubernetes 集群。

　　步驟一：添加標簽到節點

　　執行 kubectl get nodes 命令獲取集群的節點名稱。選擇一個你要增加標簽的節點，然后執行 kubectl label nodes <node-name> <label-key>=<label-value> 命令將標簽添加到你所選擇的節點上。例如，如果你的節點名稱為 ‘kubernetes-foo-node-1.c.a-robinson.internal’ 並且想要的標簽是 ‘disktype=ssd’，則可以執行 kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd 命令。

　　你可以通過重新運行 kubectl get nodes --show-labels 並且查看節點當前具有了一個標簽來驗證它是否有效。你也可以使用 kubectl describe node "nodename" 命令查看指定節點的標簽完整列表。

　　獲取node節點名稱

kubectl get nodes
NAME           STATUS   ROLES    AGE   VERSION
192.168.1.65   Ready    <none>   10d   v1.17.4
192.168.1.66   Ready    <none>   10d   v1.17.4

　　添加標簽

kubectl label nodes 192.168.1.65 disktype=ssd
node/192.168.1.65 labeled

　　查看添加的標簽

# kubectl get nodes --show-labels 
NAME           STATUS   ROLES    AGE   VERSION   LABELS
192.168.1.65   Ready    <none>   10d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.65,kubernetes.io/os=linux
192.168.1.66   Ready    <none>   10d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.66,kubernetes.io/os=linux

　　可以看到node192.168.1.65多了一個添加的標簽disktype=ssd而node192.168.1.66則沒有該標簽

　　步驟二：添加 nodeSelector 字段到 pod 配置中

　　拿任意一個你想運行的 pod 的配置文件，並且在其中添加一個 nodeSelector 部分。例如，如果下面是我的 pod 配置：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx

　　然后像下面這樣添加 nodeSelector：

# cat nginx-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

　　當你之后運行 kubectl apply -f pod-nginx.yaml 命令，pod 將會調度到將標簽添加到的節點上。你可以通過運行 kubectl get pods -o wide 並查看分配給 pod 的 “NODE” 來驗證其是否有效。

kubectl get pod -o wide
NAME                                    READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
nginx-pod                               1/1     Running   0          3m10s   172.17.54.8   192.168.1.65   <none>           <none>

　　插曲：內置的節點標簽

　　除了你附加的標簽外，節點還預先填充了一組標准標簽。這些標簽是

注意：
這些標簽的值特定於雲供應商的，因此不能保證可靠。例如，kubernetes.io/hostname 的值在某些環境中可能與節點名稱相同，但在其他環境中可能是一個不同的值。

　　節點隔離/限制

　　向 Node 對象添加標簽可以將 pod 定位到特定的節點或節點組。這可以用來確保指定的 pod 只能運行在具有一定隔離性，安全性或監管屬性的節點上。當為此目的使用標簽時，強烈建議選擇節點上的 kubelet 進程無法修改的標簽鍵。這可以防止受感染的節點使用其 kubelet 憑據在自己的 Node 對象上設置這些標簽，並影響調度器將工作負載調度到受感染的節點。
　　NodeRestriction 准入插件防止 kubelet 使用 node-restriction.kubernetes.io/ 前綴設置或修改標簽。要使用該標簽前綴進行節點隔離：

檢查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。
確保你在使用節點授權並且已經啟用 NodeRestriction 准入插件。
將 node-restriction.kubernetes.io/ 前綴下的標簽添加到 Node 對象，然后在節點選擇器中使用這些標簽。例如，example.com.node-restriction.kubernetes.io/fips=true 或 example.com.node-restriction.kubernetes.io/pci-dss=true。

　　親和與反親和

　　nodeSelector提供了一種非常簡單的方法來將Pod約束在具有特定節點標簽的節點上。親和/反親和功能極大地擴展了你可以表達約束的類型。關鍵的增強點是

語言更具表現力（不僅僅是“完全匹配的 AND”）
你可以發現規則是“軟”/“偏好”，而不是硬性要求，因此，如果調度器無法滿足該要求，仍然調度該 pod
你可以使用節點上（或其他拓撲域中）的 pod 的標簽來約束，而不是使用節點本身的標簽，來允許哪些 pod 可以或者不可以被放置在一起。

　　節點親和

　　節點親和概念上類似於nodeSelector，它使你可以根據節點上的標簽來約束pod可以調度到那些節點。

　　目前有兩種類型的節點親和，分別為 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。你可以視它們為“硬”和“軟”，意思是，前者指定了將 pod 調度到一個節點上必須滿足的規則（就像 nodeSelector 但使用更具表現力的語法），后者指定調度器將嘗試執行單不能保證的偏好。“IgnoredDuringExecution”部分意味着，類似於 nodeSelector 的工作原理，如果節點的標簽在運行時發生變更，從而不再滿足 pod 上的親和規則，那么 pod 將仍然繼續在該節點上運行。將來我們計划提供 requiredDuringSchedulingRequiredDuringExecution，它將類似於 requiredDuringSchedulingIgnoredDuringExecution，除了它會將 pod 從不再滿足 pod 的節點親和要求的節點上驅逐。

　　因此，requiredDuringSchedulingIgnoredDuringExecution 的示例將是“僅將 pod 運行在具有 Intel CPU 的節點上”，而 preferredDuringSchedulingIgnoredDuringExecution 的示例為“嘗試將這組 pod 運行在 XYZ 故障區域，如果這不可能的話，則允許一些 pod 在其他地方運行”。

節點親和通過 PodSpec 的 affinity 字段下的 nodeAffinity 字段進行指定。

　　下面是一個使用節點親和的 pod 的實例：

# cat pod-with-node-affinity.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: kubernetes/pause

　　PS：如未匹配到任何標簽選擇則Pod會處於Pending狀態

　　1，此節點親和規則表示，pod 只能放置在具有標簽鍵為 kubernetes.io/e2e-az-name 且標簽值為 e2e-az1 或 e2e-az2 的節點上。另外，在滿足這些標准的節點中，具有標簽鍵為 another-node-label-key 且標簽值為 another-node-label-value 的節點應該優先使用。

　　查看nodes默認標簽

# kubectl get node --show-labels
NAME           STATUS   ROLES    AGE   VERSION   LABELS
192.168.1.65   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.65,kubernetes.io
192.168.1.66   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.66,kubernetes.io

　　node 192.168.1.65添加一個標簽kubernetes.io/e2e-az-name值為e2e-az1

# kubectl label node 192.168.1.65 kubernetes.io/e2e-az-name=e2e-az1
node/192.168.1.65 labeled

　　查看添加標簽以后的node標簽項node192.168.1.65增加了一個標簽項

# kubectl get nodes --show-labels
NAME           STATUS   ROLES    AGE   VERSION   LABELS
192.168.1.65   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/e2e-az-name=e2e-az1,kubernetes.io/hostname=192.168.1.65,kubernetes.io/os=linux
192.168.1.66   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.66,kubernetes.io/os=linux

　　應用

# kubectl apply -f pod-with-node-affinity.yaml 
pod/with-node-affinity unchanged

　　查看是否分配到對應的node

# kubectl get pod with-node-affinity -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          54s   172.17.54.8   192.168.1.65   <none>           <none>

　　如果一個node滿足標簽another-node-label-key=another-node-label-key但是不滿足標簽kubernetes.io/e2e-az-name=e2e-az1則也不會分配到此節點因為requiredDuringSchedulingIgnoredDuringExecution是必須滿足的

　　node192.168.1.66增加標簽another-node-label-key=another-node-label-key

kubectl label node 192.168.1.66 another-node-label-key=another-node-label-key
node/192.168.1.66 labeled

　　查看node標簽項

kubectl get nodes --show-labels
NAME           STATUS   ROLES    AGE   VERSION   LABELS
192.168.1.65   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/e2e-az-name=e2e-az1,kubernetes.io/hostname=192.168.1.65,kubernetes.io/os=linux
192.168.1.66   Ready    <none>   10d   v1.17.4   another-node-label-key=another-node-label-key,kubernetes.io/arch=amd64,kubernetes.io/hostname=192.168.1.66,kubernetes.io/os=linux

　　刪除以后再應用

# kubectl delete -f pod-with-node-affinity.yaml 
pod "with-node-affinity" deleted
# kubectl apply -f pod-with-node-affinity.yaml 
pod/with-node-affinity created

　　查看還是被分配到節點192.168.1.65上

# kubectl get pod with-node-affinity -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          29s   172.17.54.8   192.168.1.65   <none>           <none>

　　給node192.168.1.66也增加標簽kubernetes.io/e2e-az-name=e2e-az1

# kubectl label node 192.168.1.66 kubernetes.io/e2e-az-name=e2e-az1
node/192.168.1.66 labeled

　　查看node標簽可以看到node192.168.1.66除了滿足標簽kubernetes.io/e2e-az-name=e2e-az1還滿足標簽another-node-label-key=another-node-label-key

# kubectl get nodes --show-labels
NAME           STATUS   ROLES    AGE   VERSION   LABELS
192.168.1.65   Ready    <none>   10d   v1.17.4   kubernetes.io/arch=amd64,kubernetes.io/e2e-az-name=e2e-az1,kubernetes.io/hostname=192.168.1.65,kubernetes.io/os=linux
192.168.1.66   Ready    <none>   10d   v1.17.4   another-node-label-key=another-node-label-key,kubernetes.io/arch=amd64,kubernetes.io/e2e-az-name=e2e-az1,kubernetes.io/hostname=192.168.1.66

　　需要刪除重新創建才會重新調度，因為親和選擇只在pod調度期間有效，參考下面第六條

# kubectl delete -f pod-with-node-affinity.yaml 
pod "with-node-affinity" deleted
# kubectl apply -f pod-with-node-affinity.yaml 
pod/with-node-affinity created

　　查看，調度到node192.168.1.66上了，因為node192.168.1.66標簽滿足了kubernetes.io/e2e-az-name=e2e-az1的同時又滿足了標簽another-node-label-key=another-node-label-key所以優先調度

# kubectl get pod with-node-affinity -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          43s   172.17.71.3   192.168.1.66   <none>           <none>

　　2，你可以在上面的例子中看到 In 操作符的使用。新的節點親和語法支持下面的操作符： In，NotIn，Exists，DoesNotExist，Gt，Lt。你可以使用 NotIn 和 DoesNotExist 來實現節點反親和行為，或者使用節點污點將 pod 從特定節點中驅逐。

　 3，如果你同時指定了 nodeSelector 和 nodeAffinity，兩者必須都要滿足，才能將 pod 調度到候選節點上。

　　4，如果你指定了多個與 nodeAffinity 類型關聯的 nodeSelectorTerms，則如果其中一個 nodeSelectorTerms 滿足的話，pod將可以調度到節點上。

　, 5，如果你指定了多個與 nodeSelectorTerms 關聯的 matchExpressions，則只有當所有 matchExpressions 滿足的話，pod 才會可以調度到節點上。

　　6，如果你修改或刪除了 pod 所調度到的節點的標簽，pod 不會被刪除。換句話說，親和選擇只在 pod 調度期間有效。

　　preferredDuringSchedulingIgnoredDuringExecution 中的 weight 字段值的范圍是 1-100。對於每個符合所有調度要求（資源請求，RequiredDuringScheduling 親和表達式等）的節點，調度器將遍歷該字段的元素來計算總和，並且如果節點匹配對應的MatchExpressions，則添加“權重”到總和。然后將這個評分與該節點的其他優先級函數的評分進行組合。總分最高的節點是最優選的。

　　Pod間親和與反親和

　　pod 間親和與反親和使你可以基於已經在節點上運行的 pod 的標簽來約束 pod 可以調度到的節點，而不是基於節點上的標簽。規則的格式為“如果 X 節點上已經運行了一個或多個滿足規則 Y 的pod，則這個 pod 應該（或者在非親和的情況下不應該）運行在 X 節點”。Y 表示一個具有可選的關聯命令空間列表的 LabelSelector；與節點不同，因為 pod 是命名空間限定的（因此 pod 上的標簽也是命名空間限定的），因此作用於 pod 標簽的標簽選擇器必須指定選擇器應用在哪個命名空間。從概念上講，X 是一個拓撲域，如節點，機架，雲供應商地區，雲供應商區域等。你可以使用 topologyKey 來表示它，topologyKey 是節點標簽的鍵以便系統用來表示這樣的拓撲域。請參閱上面插曲：內置的節點標簽部分中列出的標簽鍵。

注意：
Pod 間親和與反親和需要大量的處理，這可能會顯著減慢大規模集群中的調度。我們不建議在超過數百個節點的集群中使用它們。

注意：
Pod 反親和需要對節點進行一致的標記，即集群中的每個節點必須具有適當的標簽能夠匹配 topologyKey。如果某些或所有節點缺少指定的 topologyKey 標簽，可能會導致意外行為。

　　與節點親和一樣，當前有兩種類型的 pod 親和與反親和，即 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution，分表表示“硬性”與“軟性”要求。請參閱前面節點親和部分中的描述。requiredDuringSchedulingIgnoredDuringExecution 親和的一個示例是“將服務 A 和服務 B 的 pod 放置在同一區域，因為它們之間進行大量交流”，而 preferredDuringSchedulingIgnoredDuringExecution 反親和的示例將是“將此服務的 pod 跨區域分布”（硬性要求是說不通的，因為你可能擁有的 pod 數多於區域數）。

　　Pod 間親和通過 PodSpec 中 affinity 字段下的 podAffinity 字段進行指定。而 pod 間反親和通過 PodSpec 中 affinity 字段下的 podAntiAffinity 字段進行指定。

　　Pod 使用 pod 親和的示例

# cat pod-with-pod-affinity.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0

　　在這個 pod 的 affinity 配置定義了一條 pod 親和規則和一條 pod 反親和規則。在此示例中，podAffinity 配置為 requiredDuringSchedulingIgnoredDuringExecution，然而 podAntiAffinity 配置為 preferredDuringSchedulingIgnoredDuringExecution。pod 親和規則表示，僅當節點和至少一個已運行且有鍵為“security”且值為“S1”的標簽的 pod 處於同一區域時，才可以將該 pod 調度到節點上。（更確切的說，如果節點 N 具有帶有鍵 failure-domain.beta.kubernetes.io/zone 和某個值 V 的標簽，則 pod 有資格在節點 N 上運行，以便集群中至少有一個節點具有鍵 failure-domain.beta.kubernetes.io/zone 和值為 V 的節點正在運行具有鍵“security”和值“S1”的標簽的 pod。）pod 反親和規則表示，如果節點已經運行了一個具有鍵“security”和值“S2”的標簽的 pod，則該 pod 不希望將其調度到該節點上。（如果 topologyKey 為 failure-domain.beta.kubernetes.io/zone，則意味着當節點和具有鍵“security”和值“S2”的標簽的 pod 處於相同的區域，pod 不能被調度到該節點上。）查閱設計文檔來獲取更多 pod 親和與反親和的樣例，包括 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 兩種配置。

　　Pod 親和與反親和的合法操作符有 In，NotIn，Exists，DoesNotExist。

　　原則上，topologyKey 可以是任何合法的標簽鍵。然而，出於性能和安全原因，topologyKey 受到一些限制：

對於親和與 requiredDuringSchedulingIgnoredDuringExecution 要求的 pod 反親和，topologyKey 不允許為空。
對於 requiredDuringSchedulingIgnoredDuringExecution 要求的 pod 反親和，准入控制器 LimitPodHardAntiAffinityTopology 被引入來限制 topologyKey 不為 kubernetes.io/hostname。如果你想使它可用於自定義拓撲結構，你必須修改准入控制器或者禁用它。
對於 preferredDuringSchedulingIgnoredDuringExecution 要求的 pod 反親和，空的 topologyKey 被解釋為“所有拓撲結構”（這里的“所有拓撲結構”限制為 kubernetes.io/hostname，failure-domain.beta.kubernetes.io/zone 和 failure-domain.beta.kubernetes.io/region 的組合）。
除上述情況外，topologyKey 可以是任何合法的標簽鍵。

除了 labelSelector 和 topologyKey，你也可以指定表示命名空間的 namespaces 隊列，labelSelector 也應該匹配它（這個與 labelSelector 和 topologyKey 的定義位於相同的級別）。如果忽略或者為空，則默認為 pod 親和/反親和的定義所在的命名空間。

所有與 requiredDuringSchedulingIgnoredDuringExecution 親和與反親和關聯的 matchExpressions 必須滿足，才能將 pod 調度到節點上。

　　更實際的用例

　　Pod 間親和與反親和在與更高級別的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用時，它們可能更加有用。可以輕松配置一組應位於相同定義拓撲（例如，節點）中的工作負載。

　　在三節點集群中，一個 web 應用程序具有內存緩存，例如 redis。我們希望 web 服務器盡可能與緩存放置在同一位置。

下面是一個簡單 redis deployment 的 yaml 代碼段，它有三個副本和選擇器標簽 app=store。Deployment 配置了 PodAntiAffinity，用來確保調度器不會將副本調度到單個節點上。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 2
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

　　下面 webserver deployment 的 yaml 代碼段中配置了 podAntiAffinity 和 podAffinity。這將通知調度器將它的所有副本與具有 app=store 選擇器標簽的 pod 放置在一起。這還確保每個 web 服務器副本不會調度到單個節點上。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 2
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.12-alpine

　　創建Deployment以后

　　web-server 的兩個副本都按照預期那樣自動放置在同一位置。

# kubectl get pod -o wide
NAME                                    READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
redis-cache-6bc7d5b59d-wnm8l            1/1     Running   0          4m29s   172.17.71.4   192.168.1.66   <none>           <none>
redis-cache-6bc7d5b59d-zhb96            1/1     Running   0          4m29s   172.17.54.8   192.168.1.65   <none>           <none>
web-server-655bf8bdf4-5fk94             1/1     Running   0          3m43s   172.17.54.9   192.168.1.65   <none>           <none>
web-server-655bf8bdf4-qbrz8             1/1     Running   0          3m43s   172.17.71.6   192.168.1.66   <none>           <none>

　　永遠不放置在相同節點

　　上面的例子使用 PodAntiAffinity 規則和 topologyKey: "kubernetes.io/hostname" 來部署 redis 集群以便在同一主機上沒有兩個實例。參閱 ZooKeeper 教程，以獲取配置反親和來達到高可用性的 StatefulSet 的樣例（使用了相同的技巧）。

　　nodeName

　　nodeName 是節點選擇約束的最簡單方法，但是由於其自身限制，通常不使用它。nodeName 是 PodSpec 的一個字段。如果它不為空，調度器將忽略 pod，並且運行在它指定節點上的 kubelet 進程嘗試運行該 pod。因此，如果 nodeName 在 PodSpec 中指定了，則它優先於上面的節點選擇方法。

使用 nodeName 來選擇節點的一些限制：

如果指定的節點不存在，
如果指定的節點沒有資源來容納 pod，pod 將會調度失敗並且其原因將顯示為，比如 OutOfmemory 或 OutOfcpu。
雲環境中的節點名稱並非總是可預測或穩定的。

　　下面的是使用 nodeName 字段的 pod 配置文件的例子：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

　　上面的 pod 將運行在 kube-01 節點上。

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 Kubernetes 將Pod調度到Master節點【Kubernetes】創建Pod並分配到指定節點 kubernetes調度pod運行於master節點上 Kubernetes使用節點親緣性將POD調度到特定節點上 kubernetes之pod調度 Kubernetes之Pod調度 Kubernetes-Pod介紹(三)-Pod調度 kubernetes之pod拓撲分布約束 (十四)Kubernetes Pod調度器 Kubernetes使用節點污點和pod容忍度阻止節點調度到特定節點