快捷導(dǎo)航

K8s容器的定向調(diào)度與親和性詳解

更新時(shí)間：2025年07月04日 09:14:48 作者：KubeSphere 云原生

這篇文章主要介紹了K8s容器的定向調(diào)度與親和性,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

Kubernetes（K8s）是一個(gè)開源的容器編排工具，而容器調(diào)度是其非常重要的特性，所謂的調(diào)度是指將容器（Pod）分配到集群中的節(jié)點(diǎn)上運(yùn)行的過程。為了更好地控制容器的調(diào)度，K8s 提供了多種調(diào)度策略，其中包括定向調(diào)度和親和性策略。在實(shí)際的 K8s 集群維護(hù)場景中，合理使用這些調(diào)度策略，對(duì)集群的穩(wěn)定性至關(guān)重要。本文將通過分享實(shí)踐案例，幫助你更好地理解和使用這些功能。

定向調(diào)度

定向調(diào)度通過 nodeName 和 nodeSelector 來聲明 Pod 期望調(diào)度的目標(biāo)節(jié)點(diǎn)，這種方式的調(diào)度是強(qiáng)制性的，不管節(jié)點(diǎn)是否存在，是否宕機(jī)，都會(huì)往聲明的節(jié)點(diǎn)上去調(diào)度，當(dāng)目標(biāo)不存在或不可調(diào)度時(shí)，將會(huì)導(dǎo)致 Pod 無法運(yùn)行。

nodeName

強(qiáng)制將 Pod 調(diào)度到指定主機(jī)名的節(jié)點(diǎn)上，這種方式簡單粗暴，沒有經(jīng)過 Scheduler 的調(diào)度邏輯。

示例：我有一個(gè)機(jī)器學(xué)習(xí)的應(yīng)用，需要調(diào)度到集群中唯一的 GPU 節(jié)點(diǎn)上，可以這樣做。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: athena
spec:
  replicas: 1
  selector:
    matchLabels:
      app: athena
  template:
    metadata:
      labels:
        app: athena
    spec:
      containers:
      - name: athena
        image: athena:2.0.0
      nodeName: k8s-node-gpu-1

NodeSelector

強(qiáng)制將 Pod 調(diào)度到指定標(biāo)簽的節(jié)點(diǎn)上，這種方式通過 Label-selector 機(jī)制實(shí)現(xiàn)，在 Pod 創(chuàng)建之前，會(huì)由 Schedule 的 MatchNodeSelector 調(diào)度策略根據(jù) Label 匹配節(jié)點(diǎn)，再將 Pod 調(diào)度到目標(biāo)節(jié)點(diǎn)上。

示例：我有一個(gè)機(jī)器學(xué)習(xí)的應(yīng)用，需要調(diào)度到集群中帶有 hardware-type:gpu 標(biāo)簽的節(jié)點(diǎn)上，帶有該標(biāo)簽的節(jié)點(diǎn)有多臺(tái)，可以這樣做。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: athena
spec:
  replicas: 1
  selector:
    matchLabels:
      app: athena
  template:
    metadata:
      labels:
        app: athena
    spec:
      containers:
      - name: athena
        image: athena:2.0.0
      nodeSelector:
        hardware-type: gpu
        # gpu-type: T4 (允許有多l(xiāng)abel匹配)

定向調(diào)度比較簡單粗暴，那有沒有相對(duì)溫和、靈活點(diǎn)的調(diào)度策略呢？當(dāng)然是有的，接下來讓我們來看看親和性調(diào)度策略。

親和性調(diào)度

親和性調(diào)度（Affinity）在定向調(diào)度的基礎(chǔ)上，通過靈活的節(jié)點(diǎn)親和性（nodeAffinity）、Pod 親和性（podAffinity）、Pod 反親和性（podAntiAffinity）規(guī)則，滿足更多樣化的調(diào)度場景。

nodeAffinity

比 nodeSelector 更加強(qiáng)大和靈活，可以讓 Pod 滿足更多樣化的條件調(diào)度到指定的節(jié)點(diǎn)上，支持“軟性調(diào)度”（PreferredDuringSchedulingIgnoreDuringExecution）和“硬性調(diào)度”（RequiredDuringSchedulingIgnoredDuringExecution）”，硬性調(diào)度比較強(qiáng)硬，不滿足條件則調(diào)度不成功，而軟性調(diào)度相對(duì)溫和，屬于傾向性優(yōu)先選擇滿足條件的節(jié)點(diǎn)，并不強(qiáng)求。

讓我們來看兩個(gè)示例，加深理解：

示例 1

我有一個(gè)機(jī)器學(xué)習(xí)的應(yīng)用，必須調(diào)度到集群中帶有 hardware-type: gpu，且區(qū)域 kubernetes.io/zone 的值為 cn-shenzhen-1 或 cn-shenzhen-2 標(biāo)簽的節(jié)點(diǎn)上。我們可以通過親和性的硬性調(diào)度實(shí)現(xiàn)，具體如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: athena
spec:
  replicas: 2
  selector:
    matchLabels:
      app: athena
  template:
    metadata:
      labels:
        app: athena
    spec:
      containers:
      - name: athena
        image: athena:2.0.0
      affinity:
        nodeAffinity:
          # 硬性調(diào)度，節(jié)點(diǎn)必須滿足所有條件才可以調(diào)度
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: hardware-type
                # 運(yùn)算
                operator: In
                values:
                - gpu
              - key: kubernetes.io/zone
                operator: In
                values:
                - cn-shenzhen-1
                - cn-shenzhen-2

Operator 支持的運(yùn)算符還有：

Exists(key必須存在，value可以是任意的)
DoesNotExist（key不能存在）
In（key的value必須在提供的值列表中）
NotIn（key的value不能在提供的值列表中）
Gt（key的value必須大于提供的值，僅支持整數(shù)）
Lt（key的value必須小于提供的值）

示例 2

我有一個(gè)機(jī)器學(xué)習(xí)的應(yīng)用，傾向于調(diào)度到集群中帶有 hardware-type: gpu，且區(qū)域 kubernetes.io/zone 的值為 cn-shenzhen-1 或 cn-shenzhen-2 標(biāo)簽的節(jié)點(diǎn)上。我們可以通過親和性的軟性調(diào)度實(shí)現(xiàn)，如果不能滿足條件，他也會(huì)嘗試去調(diào)度其他節(jié)點(diǎn)，具體如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: athena
spec:
  replicas: 2
  selector:
    matchLabels:
      app: athena
  template:
    metadata:
      labels:
        app: athena
    spec:
      containers:
      - name: athena
        image: athena:2.0.0
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          # 滿足條件的節(jié)點(diǎn)會(huì)加分，值支持（1-100），分?jǐn)?shù)越高，優(yōu)先級(jí)越高
          # 不加的話，滿足條件的節(jié)點(diǎn)權(quán)重也為0，不能保證其優(yōu)先級(jí)。
          - weight: 1
            preference:
              matchExpressions:
              - key: hardware-type
                # 運(yùn)算，支持的運(yùn)算符跟硬性調(diào)度一致
                operator: In
                values:
                - gpu
              - key: kubernetes.io/zone
                operator: In
                values:
                - cn-shenzhen-1
                - cn-shenzhen-2

Pod 親和性（podAffinity）和反親和性（podAntiAffinity）

顧名思義，Pod 親和性用來指定哪些 Pod 應(yīng)該跟哪些 Pod 更加靠近，而 Pod 反親和性通常用來打散 Pod，讓某些 Pod 不在同一節(jié)點(diǎn)或區(qū)域，同樣也有“軟性調(diào)度”（PreferredDuringSchedulingIgnoreDuringExecution）”和“硬性調(diào)度” （RequiredDuringSchedulingIgnoredDuringExecution），接下來我將用一個(gè)示例，加深對(duì) Pod 親和性和反親和性的理解：

示例：有兩個(gè)微服務(wù) zeus 和 athena 相互調(diào)用比較頻繁，他們都有兩個(gè)副本，出于提升效率和可用性考慮，我想將 zeus 和 athena 的副本打散到兩個(gè)不同的可用區(qū)（zone），并讓他們的副本必須部署到同一個(gè)節(jié)點(diǎn)上，假設(shè) zeus 已經(jīng)部署好了，那 athena 的部署可以這樣實(shí)現(xiàn)。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: athena
spec:
  replicas: 2
  selector:
    matchLabels:
      app: athena
  template:
    metadata:
      labels:
        app: athena
    spec:
      containers:
      - name: athena
        image: athena:2.0.0
      affinity:
        # Pod親和性
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: zeus
            # 拓?fù)滏I，表示在相同主機(jī)上調(diào)度
            topologyKey: kubernetes.io/hostname
        # Pod反親和性
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: athena
            # 拓?fù)滏I，表示在不同區(qū)域上調(diào)度
            topologyKey: topology.kubernetes.io/zone

總結(jié)

在文章開頭我們提到如何借助調(diào)度策略來提升 K8s 集群的可用性，相信看完全文的小伙伴都可以悟出其中奧妙，我們可以將高計(jì)算、高內(nèi)存的 Pod 調(diào)度到指定的節(jié)點(diǎn)，避免影響關(guān)鍵服務(wù)運(yùn)行，另外為了保障微服務(wù)的高可用性，我們通常會(huì)打散副本到不同的節(jié)點(diǎn)或者可用區(qū)。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

您可能感興趣的文章: