日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod拓撲分布約束

Pod 拓撲分布約束

FEATURE STATE: Kubernetes v1.19 [stable]

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

你可以使用 拓撲分布約束（Topology Spread Constraints） 來控制 Pods 在集群內(nèi)故障域 之間的分布，例如區(qū)域（Region）、可用區(qū)（Zone）、節(jié)點和其他用戶自定義拓撲域。 這樣做有助于實現(xiàn)高可用并提升資源利用率。

先決條件 

節(jié)點標簽 

拓撲分布約束依賴于節(jié)點標簽來標識每個節(jié)點所在的拓撲域。 例如，某節(jié)點可能具有標簽：?node=node1,zone=us-east-1a,region=us-east-1 ?

假設你擁有具有以下標簽的一個 4 節(jié)點集群：

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

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

 

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

Pod 的分布約束 

API

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

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

  • maxSkew 描述 Pod 分布不均的程度。這是給定拓撲類型中任意兩個拓撲域中 匹配的 pod 之間的最大允許差值。它必須大于零。取決于 ?whenUnsatisfiable ?的 取值，其語義會有不同。
    • 

      

    • 當 ?whenUnsatisfiable ?等于 "DoNotSchedule" 時，?maxSkew ?是目標拓撲域 中匹配的 Pod 數(shù)與全局最小值之間可存在的差異。
      • 

    • 當 ?whenUnsatisfiable ?等于 "ScheduleAnyway" 時，調(diào)度器會更為偏向能夠降低 偏差值的拓撲域。
      • 

    

  • topologyKey 是節(jié)點標簽的鍵。如果兩個節(jié)點使用此鍵標記并且具有相同的標簽值， 則調(diào)度器會將這兩個節(jié)點視為處于同一拓撲域中。調(diào)度器試圖在每個拓撲域中放置數(shù)量 均衡的 Pod。
    • 

  • whenUnsatisfiable 指示如果 Pod 不滿足分布約束時如何處理：
    • 

      

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

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

    

  • labelSelector 用于查找匹配的 pod。匹配此標簽的 Pod 將被統(tǒng)計，以確定相應 拓撲域中 Pod 的數(shù)量。
    • 



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


假設你擁有一個 4 節(jié)點集群，其中標記為 ?foo:bar? 的 3 個 Pod 分別位于 node1、node2 和 node3 中：
   
如果希望新來的 Pod 均勻分布在現(xiàn)有的可用區(qū)域，則可以按如下設置其規(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? 意味著均勻分布將只應用于存在標簽鍵值對為 "zone:" 的節(jié)點。 ?whenUnsatisfiable: DoNotSchedule? 告訴調(diào)度器如果新的 Pod 不滿足約束， 則讓它保持懸決狀態(tài)。
如果調(diào)度器將新的 Pod 放入 "zoneA"，Pods 分布將變?yōu)?nbsp;[3, 1]，因此實際的偏差 為 2（3 - 1）。這違反了 ?maxSkew: 1? 的約定。此示例中，新 Pod 只能放置在 "zoneB" 上：
   
或者
  
你可以調(diào)整 Pod 規(guī)約以滿足各種要求：
    

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

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

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


下面的例子建立在前面例子的基礎上。假設你擁有一個 4 節(jié)點集群，其中 3 個標記為 ?foo:bar? 的 Pod 分別位于 node1、node2 和 node3 上：
   
可以使用 2 個 TopologySpreadConstraint 來控制 Pod 在 區(qū)域和節(jié)點兩個維度上的分布：
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
在這種情況下，為了匹配第一個約束，新的 Pod 只能放置在 "zoneB" 中；而在第二個約束中， 新的 Pod 只能放置在 "node4" 上。最后兩個約束的結果加在一起，唯一可行的選擇是放置 在 "node4" 上。
多個約束之間可能存在沖突。假設有一個跨越 2 個區(qū)域的 3 節(jié)點集群：
   
如果對集群應用 "two-constraints.yaml"，會發(fā)現(xiàn) "mypod" 處于 ?Pending ?狀態(tài)。 這是因為：為了滿足第一個約束，"mypod" 只能放在 "zoneB" 中，而第二個約束要求 "mypod" 只能放在 "node2" 上。Pod 調(diào)度無法滿足兩種約束。
為了克服這種情況，你可以增加 ?maxSkew ?或修改其中一個約束，讓其使用 ?whenUnsatisfiable: ScheduleAnyway?。
節(jié)點親和性與節(jié)點選擇器的相互作用  


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


假設你有一個跨越 zoneA 到 zoneC 的 5 節(jié)點集群：
   
   
而且你知道 "zoneC" 必須被排除在外。在這種情況下，可以按如下方式編寫 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)度器不會預先知道集群擁有的所有區(qū)域和其他拓撲域。拓撲域由集群中存在的節(jié)點確定。 在自動伸縮的集群中，如果一個節(jié)點池（或節(jié)點組）的節(jié)點數(shù)量為零， 而用戶正期望其擴容時，可能會導致調(diào)度出現(xiàn)問題。 因為在這種情況下，調(diào)度器不會考慮這些拓撲域信息，因為它們是空的，沒有節(jié)點。
其他值得注意的語義  


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

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

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

      

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

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

    



    

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


為集群設置默認的拓撲分布約束也是可能的。默認拓撲分布約束在且僅在以下條件滿足 時才會應用到 Pod 上：
    

  • Pod 沒有在其 ?.spec.topologySpreadConstraints? 設置任何約束；
    • 

  • Pod 隸屬于某個服務、副本控制器、ReplicaSet 或 StatefulSet。
    • 



你可以在 調(diào)度方案（Scheduling Profile） 中將默認約束作為 ?PodTopologySpread ?插件參數(shù)的一部分來設置。 約束的設置采用如前所述的 API，只是 ?labelSelector ?必須為空。 選擇算符是根據(jù) Pod 所屬的服務、副本控制器、ReplicaSet 或 StatefulSet 來設置的。
配置的示例可能看起來像下面這個樣子：
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




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


內(nèi)部默認約束  


FEATURE STATE: Kubernetes v1.20 [beta]
當你使用了默認啟用的 ?DefaultPodTopologySpread? 特性門控時，原來的 ?SelectorSpread ?插件會被禁用。 kube-scheduler 會使用下面的默認拓撲約束作為 ?PodTopologySpread ?插件的 配置：
defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
此外，原來用于提供等同行為的 ?SelectorSpread ?插件也會被禁用。

  對于分布約束中所指定的拓撲鍵而言，?

 PodTopologySpread ?插件不會為不包含這些主鍵的節(jié)點評分。 這可能導致在使用默認拓撲約束時，其行為與原來的 ?

 SelectorSpread ?插件的默認行為不同， 
如果你的節(jié)點不會 同時 設置 ?

 kubernetes.io/hostname? 和 ?

 topology.kubernetes.io/zone? 標簽，你應該定義自己的約束而不是使用 Kubernetes 的默認約束。



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

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

    


與 PodAffinity/PodAntiAffinity 相比較 


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

  • 對于 ?PodAffinity?，你可以嘗試將任意數(shù)量的 Pod 集中到符合條件的拓撲域中。
    • 

  • 對于 ?PodAntiAffinity?，只能將一個 Pod 調(diào)度到某個拓撲域中。
    • 



要實現(xiàn)更細粒度的控制，你可以設置拓撲分布約束來將 Pod 分布到不同的拓撲域下， 從而實現(xiàn)高可用性或節(jié)省成本。這也有助于工作負載的滾動更新和平穩(wěn)地擴展副本規(guī)模。
已知局限性 


    

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

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



 
                                                

                                                當前題目：創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod拓撲分布約束                                                

                                                URL地址：http://m.5511xx.com/article/dpdephj.html