日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢(xún)
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案
創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod拓?fù)浞植技s束

Pod 拓?fù)浞植技s束

FEATURE STATE: Kubernetes v1.19 [stable]

我們提供的服務(wù)有：成都做網(wǎng)站、成都網(wǎng)站建設(shè)、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、海原ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的海原網(wǎng)站制作公司

你可以使用 拓?fù)浞植技s束（Topology Spread Constraints） 來(lái)控制 Pods 在集群內(nèi)故障域 之間的分布，例如區(qū)域（Region）、可用區(qū)（Zone）、節(jié)點(diǎn)和其他用戶(hù)自定義拓?fù)溆颉?nbsp;這樣做有助于實(shí)現(xiàn)高可用并提升資源利用率。

先決條件 

節(jié)點(diǎn)標(biāo)簽 

拓?fù)浞植技s束依賴(lài)于節(jié)點(diǎn)標(biāo)簽來(lái)標(biāo)識(shí)每個(gè)節(jié)點(diǎn)所在的拓?fù)溆颉?nbsp;例如，某節(jié)點(diǎn)可能具有標(biāo)簽：?node=node1,zone=us-east-1a,region=us-east-1 ?

假設(shè)你擁有具有以下標(biāo)簽的一個(gè) 4 節(jié)點(diǎn)集群：

NAME    STATUS   ROLES    AGE     VERSION   LABELS
node1   Ready       4m26s   v1.16.0   node=node1,zone=zoneA
node2   Ready       3m58s   v1.16.0   node=node2,zone=zoneA
node3   Ready       3m17s   v1.16.0   node=node3,zone=zoneB
node4   Ready       2m43s   v1.16.0   node=node4,zone=zoneB

那么，從邏輯上看集群如下：

 

你可以復(fù)用在大多數(shù)集群上自動(dòng)創(chuàng)建和填充的常用標(biāo)簽， 而不是手動(dòng)添加標(biāo)簽。

Pod 的分布約束 

API

?pod.spec.topologySpreadConstraints? 字段定義如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  topologySpreadConstraints:
    - maxSkew: 
      topologyKey: 
      whenUnsatisfiable: 
      labelSelector: 
你可以定義一個(gè)或多個(gè) ?topologySpreadConstraint? 來(lái)指示 kube-scheduler 如何根據(jù)與現(xiàn)有的 Pod 的關(guān)聯(lián)關(guān)系將每個(gè)傳入的 Pod 部署到集群中。字段包括：
    

  • maxSkew 描述 Pod 分布不均的程度。這是給定拓?fù)漕?lèi)型中任意兩個(gè)拓?fù)溆蛑?nbsp;匹配的 pod 之間的最大允許差值。它必須大于零。取決于 ?whenUnsatisfiable ?的 取值，其語(yǔ)義會(huì)有不同。
    • 

      

    • 當(dāng) ?whenUnsatisfiable ?等于 "DoNotSchedule" 時(shí)，?maxSkew ?是目標(biāo)拓?fù)溆?nbsp;中匹配的 Pod 數(shù)與全局最小值之間可存在的差異。
      • 

    • 當(dāng) ?whenUnsatisfiable ?等于 "ScheduleAnyway" 時(shí)，調(diào)度器會(huì)更為偏向能夠降低 偏差值的拓?fù)溆颉?/li>

    

  • topologyKey 是節(jié)點(diǎn)標(biāo)簽的鍵。如果兩個(gè)節(jié)點(diǎn)使用此鍵標(biāo)記并且具有相同的標(biāo)簽值， 則調(diào)度器會(huì)將這兩個(gè)節(jié)點(diǎn)視為處于同一拓?fù)溆蛑小Ｕ{(diào)度器試圖在每個(gè)拓?fù)溆蛑蟹胖脭?shù)量 均衡的 Pod。
    • 

  • whenUnsatisfiable 指示如果 Pod 不滿(mǎn)足分布約束時(shí)如何處理：
    • 

      

    • ?DoNotSchedule?（默認(rèn)）告訴調(diào)度器不要調(diào)度。
      • 

    • ?ScheduleAnyway ?告訴調(diào)度器仍然繼續(xù)調(diào)度，只是根據(jù)如何能將偏差最小化來(lái)對(duì) 節(jié)點(diǎn)進(jìn)行排序。
      • 

    

  • labelSelector 用于查找匹配的 pod。匹配此標(biāo)簽的 Pod 將被統(tǒng)計(jì)，以確定相應(yīng) 拓?fù)溆蛑?nbsp;Pod 的數(shù)量。
    • 



當(dāng) Pod 定義了不止一個(gè) ?topologySpreadConstraint?，這些約束之間是邏輯與的關(guān)系。 kube-scheduler 會(huì)為新的 Pod 尋找一個(gè)能夠滿(mǎn)足所有約束的節(jié)點(diǎn)。
你可以執(zhí)行 ?kubectl explain Pod.spec.topologySpreadConstraints? 命令以 了解關(guān)于 topologySpreadConstraints 的更多信息。
例子：?jiǎn)蝹€(gè) TopologySpreadConstraint 


假設(shè)你擁有一個(gè) 4 節(jié)點(diǎn)集群，其中標(biāo)記為 ?foo:bar? 的 3 個(gè) Pod 分別位于 node1、node2 和 node3 中：
   
如果希望新來(lái)的 Pod 均勻分布在現(xiàn)有的可用區(qū)域，則可以按如下設(shè)置其規(guī)約：
kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: K8S.gcr.io/pause:3.1
?topologyKey: zone? 意味著均勻分布將只應(yīng)用于存在標(biāo)簽鍵值對(duì)為 "zone:" 的節(jié)點(diǎn)。 ?whenUnsatisfiable: DoNotSchedule? 告訴調(diào)度器如果新的 Pod 不滿(mǎn)足約束， 則讓它保持懸決狀態(tài)。
如果調(diào)度器將新的 Pod 放入 "zoneA"，Pods 分布將變?yōu)?nbsp;[3, 1]，因此實(shí)際的偏差 為 2（3 - 1）。這違反了 ?maxSkew: 1? 的約定。此示例中，新 Pod 只能放置在 "zoneB" 上：
   
或者
  
你可以調(diào)整 Pod 規(guī)約以滿(mǎn)足各種要求：
    

  • 將 ?maxSkew ?更改為更大的值，比如 "2"，這樣新的 Pod 也可以放在 "zoneA" 上。
    • 

  • 將 ?topologyKey ?更改為 "node"，以便將 Pod 均勻分布在節(jié)點(diǎn)上而不是區(qū)域中。 在上面的例子中，如果 ?maxSkew ?保持為 "1"，那么傳入的 Pod 只能放在 "node4" 上。
    • 

  • 將 ?whenUnsatisfiable: DoNotSchedule? 更改為 ?whenUnsatisfiable: ScheduleAnyway?， 以確保新的 Pod 始終可以被調(diào)度（假設(shè)滿(mǎn)足其他的調(diào)度 API）。 但是，最好將其放置在匹配 Pod 數(shù)量較少的拓?fù)溆蛑小?nbsp;（請(qǐng)注意，這一優(yōu)先判定會(huì)與其他內(nèi)部調(diào)度優(yōu)先級(jí)（如資源使用率等）排序準(zhǔn)則一起進(jìn)行標(biāo)準(zhǔn)化。）
例子：多個(gè) TopologySpreadConstraints 


下面的例子建立在前面例子的基礎(chǔ)上。假設(shè)你擁有一個(gè) 4 節(jié)點(diǎn)集群，其中 3 個(gè)標(biāo)記為 ?foo:bar? 的 Pod 分別位于 node1、node2 和 node3 上：
   
可以使用 2 個(gè) TopologySpreadConstraint 來(lái)控制 Pod 在 區(qū)域和節(jié)點(diǎn)兩個(gè)維度上的分布：
kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: k8s.gcr.io/pause:3.1
在這種情況下，為了匹配第一個(gè)約束，新的 Pod 只能放置在 "zoneB" 中；而在第二個(gè)約束中， 新的 Pod 只能放置在 "node4" 上。最后兩個(gè)約束的結(jié)果加在一起，唯一可行的選擇是放置 在 "node4" 上。
多個(gè)約束之間可能存在沖突。假設(shè)有一個(gè)跨越 2 個(gè)區(qū)域的 3 節(jié)點(diǎn)集群：
   
如果對(duì)集群應(yīng)用 "two-constraints.yaml"，會(huì)發(fā)現(xiàn) "mypod" 處于 ?Pending ?狀態(tài)。 這是因?yàn)椋簽榱藵M(mǎn)足第一個(gè)約束，"mypod" 只能放在 "zoneB" 中，而第二個(gè)約束要求 "mypod" 只能放在 "node2" 上。Pod 調(diào)度無(wú)法滿(mǎn)足兩種約束。
為了克服這種情況，你可以增加 ?maxSkew ?或修改其中一個(gè)約束，讓其使用 ?whenUnsatisfiable: ScheduleAnyway?。
節(jié)點(diǎn)親和性與節(jié)點(diǎn)選擇器的相互作用  


如果 Pod 定義了 ?spec.nodeSelector? 或 ?spec.affinity.nodeAffinity?， 調(diào)度器將在偏差計(jì)算中跳過(guò)不匹配的節(jié)點(diǎn)。
示例：TopologySpreadConstraints 與 NodeAffinity 


假設(shè)你有一個(gè)跨越 zoneA 到 zoneC 的 5 節(jié)點(diǎn)集群：
   
   
而且你知道 "zoneC" 必須被排除在外。在這種情況下，可以按如下方式編寫(xiě) YAML， 以便將 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同樣，?spec.nodeSelector? 也要一樣處理。
kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: NotIn
            values:
            - zoneC
  containers:
  - name: pause
    image: k8s.gcr.io/pause:3.1
調(diào)度器不會(huì)預(yù)先知道集群擁有的所有區(qū)域和其他拓?fù)溆?。拓?fù)溆蛴杉褐写嬖诘墓?jié)點(diǎn)確定。 在自動(dòng)伸縮的集群中，如果一個(gè)節(jié)點(diǎn)池（或節(jié)點(diǎn)組）的節(jié)點(diǎn)數(shù)量為零， 而用戶(hù)正期望其擴(kuò)容時(shí)，可能會(huì)導(dǎo)致調(diào)度出現(xiàn)問(wèn)題。 因?yàn)樵谶@種情況下，調(diào)度器不會(huì)考慮這些拓?fù)溆蛐畔ⅲ驗(yàn)樗鼈兪强盏?，沒(méi)有節(jié)點(diǎn)。
其他值得注意的語(yǔ)義  


這里有一些值得注意的隱式約定：
    

  • 只有與新的 Pod 具有相同命名空間的 Pod 才能作為匹配候選者。
    • 

  • 調(diào)度器會(huì)忽略沒(méi)有 topologySpreadConstraints[*].topologyKey 的節(jié)點(diǎn)。這意味著：
    • 

      

    1. 位于這些節(jié)點(diǎn)上的 Pod 不影響 maxSkew 的計(jì)算。 在上面的例子中，假設(shè) "node1" 沒(méi)有標(biāo)簽 "zone"，那么 2 個(gè) Pod 將被忽略， 因此傳入的 Pod 將被調(diào)度到 "zoneA" 中。
      2. 

    2. 新的 Pod 沒(méi)有機(jī)會(huì)被調(diào)度到這類(lèi)節(jié)點(diǎn)上。 在上面的例子中，假設(shè)一個(gè)帶有標(biāo)簽 {zone-typo: zoneC} 的 "node5" 加入到集群， 它將由于沒(méi)有標(biāo)簽鍵 "zone" 而被忽略。
      3. 

    



    

  • 注意，如果新 Pod 的 topologySpreadConstraints[*].labelSelector 與自身的 標(biāo)簽不匹配，將會(huì)發(fā)生什么。 在上面的例子中，如果移除新 Pod 上的標(biāo)簽，Pod 仍然可以調(diào)度到 "zoneB"，因?yàn)榧s束仍然滿(mǎn)足。 然而，在調(diào)度之后，集群的不平衡程度保持不變。zoneA 仍然有 2 個(gè)帶有 {foo:bar} 標(biāo)簽的 Pod， zoneB 有 1 個(gè)帶有 {foo:bar} 標(biāo)簽的 Pod。 因此，如果這不是你所期望的，建議工作負(fù)載的 topologySpreadConstraints[*].labelSelector 與其自身的標(biāo)簽匹配。
集群級(jí)別的默認(rèn)約束  


為集群設(shè)置默認(rèn)的拓?fù)浞植技s束也是可能的。默認(rèn)拓?fù)浞植技s束在且僅在以下條件滿(mǎn)足 時(shí)才會(huì)應(yīng)用到 Pod 上：
    

  • Pod 沒(méi)有在其 ?.spec.topologySpreadConstraints? 設(shè)置任何約束；
    • 

  • Pod 隸屬于某個(gè)服務(wù)、副本控制器、ReplicaSet 或 StatefulSet。
    • 



你可以在 調(diào)度方案（Scheduling Profile） 中將默認(rèn)約束作為 ?PodTopologySpread ?插件參數(shù)的一部分來(lái)設(shè)置。 約束的設(shè)置采用如前所述的 API，只是 ?labelSelector ?必須為空。 選擇算符是根據(jù) Pod 所屬的服務(wù)、副本控制器、ReplicaSet 或 StatefulSet 來(lái)設(shè)置的。
配置的示例可能看起來(lái)像下面這個(gè)樣子：
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway
          defaultingType: List




默認(rèn)調(diào)度約束所生成的評(píng)分可能與 SelectorSpread 插件 所生成的評(píng)分有沖突。 建議你在為 ?PodTopologySpread ?設(shè)置默認(rèn)約束是禁用調(diào)度方案中的該插件。


內(nèi)部默認(rèn)約束  


FEATURE STATE: Kubernetes v1.20 [beta]
當(dāng)你使用了默認(rèn)啟用的 ?DefaultPodTopologySpread? 特性門(mén)控時(shí)，原來(lái)的 ?SelectorSpread ?插件會(huì)被禁用。 kube-scheduler 會(huì)使用下面的默認(rèn)拓?fù)浼s束作為 ?PodTopologySpread ?插件的 配置：
defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
此外，原來(lái)用于提供等同行為的 ?SelectorSpread ?插件也會(huì)被禁用。

  對(duì)于分布約束中所指定的拓?fù)滏I而言，?

 PodTopologySpread ?插件不會(huì)為不包含這些主鍵的節(jié)點(diǎn)評(píng)分。 這可能導(dǎo)致在使用默認(rèn)拓?fù)浼s束時(shí)，其行為與原來(lái)的 ?

 SelectorSpread ?插件的默認(rèn)行為不同， 
如果你的節(jié)點(diǎn)不會(huì) 同時(shí) 設(shè)置 ?

 kubernetes.io/hostname? 和 ?

 topology.kubernetes.io/zone? 標(biāo)簽，你應(yīng)該定義自己的約束而不是使用 Kubernetes 的默認(rèn)約束。



如果你不想為集群使用默認(rèn)的 Pod 分布約束，你可以通過(guò)設(shè)置 ?defaultingType ?參數(shù)為 ?List ?并將 ?PodTopologySpread ?插件配置中的 ?defaultConstraints ?參數(shù)置空來(lái)禁用默認(rèn) Pod 分布約束。
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints: []
          defaultingType: List

    


與 PodAffinity/PodAntiAffinity 相比較 


在 Kubernetes 中，與“親和性”相關(guān)的指令控制 Pod 的調(diào)度方式（更密集或更分散）。
    

  • 對(duì)于 ?PodAffinity?，你可以嘗試將任意數(shù)量的 Pod 集中到符合條件的拓?fù)溆蛑小?/li>

  • 對(duì)于 ?PodAntiAffinity?，只能將一個(gè) Pod 調(diào)度到某個(gè)拓?fù)溆蛑小?/li>



要實(shí)現(xiàn)更細(xì)粒度的控制，你可以設(shè)置拓?fù)浞植技s束來(lái)將 Pod 分布到不同的拓?fù)溆蛳拢?nbsp;從而實(shí)現(xiàn)高可用性或節(jié)省成本。這也有助于工作負(fù)載的滾動(dòng)更新和平穩(wěn)地?cái)U(kuò)展副本規(guī)模。
已知局限性 


    

  • 當(dāng) Pod 被移除時(shí)，無(wú)法保證約束仍被滿(mǎn)足。例如，縮減某 Deployment 的規(guī)模時(shí)， Pod 的分布可能不再均衡。 你可以使用 Descheduler 來(lái)重新實(shí)現(xiàn) Pod 分布的均衡。
    • 

  • 具有污點(diǎn)的節(jié)點(diǎn)上匹配的 Pods 也會(huì)被統(tǒng)計(jì)。 參考 Issue 80921。
    • 



 
                                                

                                                文章標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod拓?fù)浞植技s束                                                

                                                標(biāo)題鏈接：http://www.dlmjj.cn/article/dpdephj.html