Kubernetesのスケジューリングメカニズム

原文出典:https://segmentfault.com/a/1190000012709117
k 8 sのスケジューリングメカニズム
schedulerコンポーネント
k 8 sスケジューラはpodをリソースが要求を満たし、スコアが最も高いnodeにスケジューリングします.1.cpu、メモリの使用要件を設定します.2.nodeのlabelを増加しpodを通過する.Spec.NodeSelectorは強力なマッチングを行います.3.podのnodeNameを直接設定し、スケジュールをスキップして直接送信します.
k 8 s 1.2は実験的な機能:affinityを加えた.親和性を意味する.この特性の設計の目的は,nodeSelectorの代わりに,より強力なスケジューリング戦略を拡張することである.
スケジューラの動作メカニズムは、一、予備作業1、すべてのnodeノードをキャッシュし、cpu、メモリ、ディスクスペース、gpuグラフィックス数などを記録する.2、すべての実行中のpodをキャッシュし、podが存在するnodeによって区別し、各node上のpod requestがどれだけのリソースを統計する.requestはpodのQoS構成で、前の記事を参考にすることができます.3、list&watch podリソースは、新しいPending状態のpodが現れることを確認すると、スケジューリングキューに追加されます.4、スケジューラのworkerコンポーネントはキューからpodを取り出してスケジューリングする.
二、スケジューリングプロセス1、現在のすべてのnodeをキューに入れる.2、predicatesアルゴリズムを実行し、キュー内のnodeをフィルタする.ここでアルゴリズムは、portが競合しない、cpuおよびメモリリソースQoS(ある場合)が満たされなければならない、volume(ある場合)タイプが一致しなければならない、nodeSelectorルールが一致しなければならない、硬いaffinityルール(後述)が一致しなければならない、nodeの状態(condition)が正常でなければならない、taint_tolerationハードルール(後述)など.2、prioritiesアルゴリズムを実行し、キュー内の残りのnodeを採点する.ここには多くの評価項目があり、各項目にはそれぞれの重みがある.全体cpu、メモリ資源のバランス、node上に要求のあるミラーがあるかどうか、rsと同じpodにスケジューリングがあるかどうか、node affinityのソフトルール、taint_tolerationソフトルール(後述)など.3、最終採点が一番高いnodeが選ばれます.すなわち、コード内のsuggestedHost,err:=sched.schedule(pod)文(plugin/pkg/scheduler/scheduler.go)の戻り値.4、スケジューラはassumeメソッドを実行し、podがnodeにスケジューリングされる前に、「このpodがターゲットnode上で実行される」というシーンでスケジューラキャッシュ内のnode情報、すなわち予備作業中の1、2の2点を更新する.これはpodが本当にnodeにスケジューリングされているときに、スケジューラが後続の他のpodのスケジューリングを同時に行うことができるようにするためです.5.スケジューラはbindメソッドを実行し、Bindingリソースを作成し、apiserverがリソースの作成を確認するとpodのnodeNameフィールドがアクティブに更新される.スケジュールを完了します.
nodeSelector
例:

apiVersion: v1kind: Podmetadata:  name: nginx  labels:    env: testspec:  containers:
  - name: nginx    image: nginx    imagePullPolicy: IfNotPresent  nodeSelector:    disktype: ssd

上のpodはdisktype:ssdというlabelを持つnodeにのみスケジューリングされます.これは強いルールで、妥協がなく、守らなければならない.
affinityとanti-affinity

に親和性ルールがあれば、反親和性ルールもあるに違いない.

親和性ルールは、より豊富なルール表現を実現した.nodeSelectorのハードルールと別のソフトルールが含まれています.

ソフト・ルールは、この優先ルールに合致するノードがなければスケジューリングされる優先ルールです.

node親和性
Node親和性はnodeSelectorと同様にlabelによってスケジューリング可能なnodeのフィルタリングを行い、現在2つのnode親和性がある:r e q u i r e d DuringSchedulingIgnoredDuringExecutionとp e r e r e d DuringSchedulingIgnoredDuringExecution:
requiredDuringSchedulingIgnoredDuringExecution
強い規則.NodeSelectorとまったく同じで、labelで強制的な制約を行います.現在、1つのnodeが実行時にlabelが変化し、変化後にその上で実行されるpodのr e q u i r e d D u r g S h e d u l ingIgnoredDuringExecutionと一致しなくなった場合、このnode上のpodも駆逐されず、この機能は後で改善され、その時に1つのタイプのRequiredDuringSchedulingRequiredDuringExecutionが増加する.
preferredDuringSchedulingIgnoredDuringExecution
ソフト・ルールたとえば、コンテナを可能な限り使用可能なドメインXにスケジュールしますが、この使用可能なドメインが存在しない場合、または使用可能なドメインがpodを再実行できない場合、スケジューラはこのpodを他の使用可能なドメインにスケジュールすることもできます.
次の例では、強いルールとソフト・ルールが含まれています.

apiVersion: v1kind: Podmetadata:  name: with-node-affinityspec:  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: gcr.io/google_containers/pause:2.0

この例は、このpodがkubernetesを伴うスケジューリングのみを許可することを示している.io/e 2 e-az-name=e 2 e-az 1またはe 2 e-az 2のlabelのnode上、すなわちe 2 e-az 1またはe 2 e-az 2の2つの利用可能なドメインへのスケジューリングのみを許可する.またpodは、another-node-label-keyを含む値がanother-node-label-valueのnodeにできるだけスケジューリングします.
matchExpressions構造は、key、operator、valuesを含む様々な式を記録し、それぞれキーワード、キーワードマッチング関係、キーワードマッチング値を表します.マッチング関係には,In,NotIn,Exists,DoesNotExist,Gt,Ltが含まれる.NotInとDoesNotExistはnode anti-affinityの表現である.
1つのpodの記述情報にnodeSelectorとnodeAffinityが同時に含まれている場合、スケジューリング時に2つのルールが満たされます.
1つのnodeAffinityに複数のnodeSelectorTermsが含まれている場合、スケジューラは1つだけを満たす必要があります.nodeSelectorTermsに複数のmatchExpressionsが記録されている場合、スケジューラはすべてのmatchExpressionsを満たす必要があります.
inter-pod affinityとanti-affinity
この2つの特性はいずれも1.4バージョンに含まれており、上の親和性はnode親和性であり、これがpod親和性であり、簡単に言えば、podをあるnodeにスケジューリングするには、このnodeに既存のpodがいくつかの条件を満たすか、できるだけ満たすことができる.この特性はpod.spec.affinity.podAffinityとpod.spec.affinity.podAntiAffinityで表します.
pod親和性のルールは、このpodがノードX上で実行されるべきである(または実行されないべきである)べきであり、X上でルールYを満たすpodが1つ以上実行されている必要があることを示すことができる.ルールYの表現はlabelSelectorに似ており、namespaceリスト:namespaces(なければ「allnamespaces」を表す)、Xはnodeまたはazである可能性があります.フィールドtopologyKeyを使用してXを計画します.つまり、すべてのXはtopologyKeyと同じで、一般的にtopologyKeyはlabelのkeyです.
なぜnamespaceリストがあるのですか?nodeとは異なりpodには分namespaceがあるため、podのlabelにも分namespaceがある.この場合、ルールYは、このルールがどのnamespaceに適用されるかを示す必要がある.例えばnodeではhyというnamespaceの下のpodが実行されており,podのlabelとルールYのnodeSelectorが同じであっても,我々はルールに合わないと見なしている.
node親和性と同様にpod親和性も2つ(ハードルールとソフトルール):

requiredDuringSchedulingIgnoredDuringExecution:ハードルール.

preferredDuringSchedulingIgnoredDuringExecution:

例を挙げます.

apiVersion: v1kind: Podmetadata:  name: with-pod-affinityspec:  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: kubernetes.io/hostname  containers:
  - name: with-pod-affinity    image: gcr.io/google_containers/pause:2.0

上のpodテンプレートはpodAffinityのハードルールとpodAntiAffinityのソフトルールを使用しています.

podAffinityルールのtopologyKeyはzone、すなわち利用可能なドメインであり、このルールが計画的にスケジューリングされたドメインを計画できることを示している.まず、node上に少なくとも1つのrunning状態のpodがkeyがsecurity、valueがS 1のlabelを含む必要がある.この条件が満たされる限り、このnodeとその同じドメイン(同じfailure-domain.beta.kubernetes.io/zoneがkeyであり、値が同じlabelを持つ)のnodeはスケジュールされます.

podAntiAffinityルールのtopologyKeyはhostnameであり、あるnodeができるだけスケジューリングされないことを約束していることを示し、このnodeにはkeyがsecurity、valueがS 2のlabelを含むpodが実行されている.

現在node a,b,cがある場合、aとbは同じzoneを有し、b上でpodが実行され、このpodにはlabelがあり、keyはsecurityであり、valueはS 1である.では、上記の親和性ルールの3つのコピーを作成すると、3つのコピーがaまたはbにスケジュールされます.b上でpodが同時に実行され、このpodにlabelがあり、keyがsecurityであり、valueがS 2である場合、すべてのコピーはnode a上にスケジューリングされます.

taint toleration
Nodeは、汚点マークを付け、汚点許容ポリシーを構成することができる.podの記述情報に同じ汚点許容ポリシーが含まれている場合、このnodeにスケジューリングすることができ、逆にできない、またはできるだけ許さない.
ハードルール
node aに汚点name=huangを付け、ポリシーはスケジューリング不可:kubectl taint nodes a name=huang:NoSchedule作成したpodには次のような記述が含まれています.

tolerations:
- key: "name"
  operator: "Equal"
  value: "huang"
  effect: "NoSchedule"

このpodは、このような汚点を有するnodeを許容することができ、すなわちnode aにスケジューリングすることができ、もちろん、以下の説明を用いることもできる.

tolerations:
- key: "name"
  operator: "Exist"
  effect: "NoSchedule"

同様の硬い規則はeffectフィールドに現れ、NoExecuteもあり、NoScheduleよりも厳しく、podだけでなく、node上の既存のpodが汚点を容認できないと駆逐され、フィールドtolerationSecondsに合わせて駆逐されるpodがnode上にどのくらい滞在できるかを規定することができる.
ソフトルール
NoExecute、NoScheduleのほかに、PreferNoScheduleというソフトルールがあります.effect=PreferNoScheduleを構成すると、関連する汚点ポリシーのないpodは、nodeへのスケジューリングを最小限に抑えることができます.