kubernetesにおけるnodeのスケジューリングポリシー

1、ノードセレクタ(nodeSelector)
NodeSelectorは現在最も簡単なpodランタイムスケジューリング制限であり、現在Kubernetes 1にある.7.xおよび以下のバージョンが使用可能です.Pod.spec.nodeSelectorはkubernetesのlabel-selectorメカニズムによってノードを選択し、スケジューラスケジューリングポリシーによってlabelと一致し、podをターゲットノードにスケジューリングします.このマッチングルールは強制制約に属します.

kubectl label node node1 disktype=ssd		--      

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:								--        
disktype: ssd

Nodeノードにlabelを設定し、pod起動yamlドキュメントでnodeSelector選択ラベルで対応するlabelを選択します.
2、親和性(Affinity)と非親和性(anti-affinity)
前に説明したnodeSelectorは、labelがpodを指定したノードに強制的に制限するという非常に簡単な方法でのみ使用されます.一方、親和性(Affinity)と非親和性(anti-affinity)は、nodeSelectorよりもanti-affinityとanti-affinityの優位性が、podを所望のノードに柔軟に指定しています.
(1)、記述構文はより多様化しており、強制制約とマッチングに限られない.
(2)、スケジューリング規則は強制制約(hard)ではなく、代わりにソフトリミット(soft)またはプリファレンス(preference)である.
(3)、podが同じ/異なるトポロジーの下に配置できるpodを指定します.
ジルコニウム親和性は主にnode affinityとinter-pod affinity/anti-affinityの3種類に分けられる.
2.1、ノード親和性(Node affinity)
 Node affinityはKubernetes 1.2でalphaとして導入されており、nodeSelector機能をカバーしており、主にr e q u i r e d DuringSchedulingIgnoredDuringExecutionとp r e f r e d DuringSchedulingIgnoredDuringExecutionの2種類に分類されている.前者は、ノードのラベルが変化してPodのスケジューリング要求ノードに合致しない場合、podスケジューリングが失敗する強制的な制限と考えられる.後者はソフトリミットまたはプリファレンスとして理解され、同様にノードのラベルが変化してpodのスケジューリング要件に合致しなくなった場合、podは依然として実行をスケジューリングする.

$ kubectl label nodes node1 cpu=high
node "node1" labeled

$  kubectl label nodes node1 cpu=mid
node "node1" labeled

$  kubectl label nodes node1 cpu=low
node "node1" labeled

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
affinity:
nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: role
        operator: NotIn
        values:
        - master
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 1
    preference:
      matchExpressions:
      - key: cpu
        operator: In
        values:
        - high
containers:- name: nginx
image: nginx
imagePullPolicy: IfNotPresent

2.2.pod親和性(Inter-pod affinity)と反親和性(anti-affinity)
 inter-pod affinityとanti-affinityはKubernetes 1.4によって導入され、現在beta段階にあり、podAffinityはpodがどのpodと同じトポロジー構造の下に配置できるかをスケジューリングするために使用される.一方、podAntiAffinityは、podが同じトポロジーの下に配置できないpodを規定するために使用されます.podとpodの関係はpod affinityとanti-affinityによって解決される.
  Node affinityと同様にpod affinityはanti-affinityと同様にr e q u i r e d D u r g S h e d u n g I g n o r e d DuringExecution and p r e f r e d DuringSchedulingIgnoredDuringExecutionの2種類に分けられ、前者は強制制約とされ、後者はソフトリミット(soft)や好み(preference)を理解していると考えられる.

spec:
replicas: 1template:
metadata:
  labels:
    app: is

spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: NotIn
            values:
            - solr                                --   pod  solr，        
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - oltp                            --  pod oltp,        
         topologyKey: beta.kubernetes.io/os

3、汚点(Taints)と許容(tolerations)
Node affinityでは、強制制約(hard)またはプリファレンス(preference)方式にかかわらず、podを所望のノードにスケジューリングするが、Taintsは正反対であり、ノードがTaintsとマークされている場合、Podが汚点に耐えられるノードとして識別されていない限り、Taintsノードはpodをスケジューリングしない.Taintsとtolerationsは現在beta段階にある.
例えば、ユーザがKubernetes MasterノードをKubernetesシステムコンポーネントに残して使用したい場合、または特定のリソースのセットをいくつかのpodに残したい場合など、Taintsノードアプリケーションシーン.podはtaintタグが付けられたノードにスケジューリングされません.
適用シーン:
(1)、特定のリソースを持つノードに対して、リソースに対して特別な要求があるpodを上で実行することを許可する
(2)、node 1、node 2を部分1またはプロジェクト1に割り当てるなど、異なる環境に対して区別する.Node 3、node 4を他の部門またはその他のプロジェクトに割り当てる

# node1      
kubectl taint node node1 node-type=production:NoSchedule
node/node1 tainted

#    
kubectl taint nodes node_name key:[effect]-    #(   key    value)
kubectl taint node node1 node-type:NoSchedule-

#describe node1          
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"

#      ，          pod        ，        pod                   pod

#    yaml，        ( containers            )，       pod               
    spec:
      tolerations:
      - key: node-type
        operator: Equal
        value: production
        effect: NoSchedule
      containers:
        - name: nginx
          image: nginx:latest
          imagePullPolicy: Never
          ports:
            - containerPort: 80

#           pod，          pod，          pod    。

effectには、実際のニーズに応じて設定できる3つのオプションがあります.
(1)、NoSchedule:podはtaintsノードとしてマークされていない.
(2)、PreferNoSchedule:NoScheduleの「preference」または「soft」バージョン.
(3)、NoExecute:このオプションは、ノード内で実行中のPodがTolerate設定に対応していない場合、Taintが有効になると、直接追放されることを意味します.
以下を参照してください.https://toutiao.io/posts/3bdbaf/preview