ポッドは、主に以下の5種類があり、スケジュール、リソースの特性に影響を与えることができます。
- NodeSelector（ワーキングノードセレクター）
- NodeAffinity（ノードレベル作業親和性）
- PodAffinity（ポッドステージ親和性）
- 汚染さとTolerations（汚れや寛容）
- リソースの制限と要件のポッド
NodeSelector（必須要件）
ノードのラベル、ポッドノードを指定するには、ノード何の仕事にスケジュールすることができます。すべてのノードは、ノードのラベルと一致していない場合、ポッドは作成されません。
次のように使用
template.spec.nodeselector：キーと値のペア（K：V、タグ）
NodeAffinity
親和性の利点：
- より論理的な組み合わせのマッチングだけでなく、正確に文字列に等しいです
- スケジューリング戦略は、ノードスケジューリング条件が満たされていない場合、ポッドは、スケジューリングを完了するために、引き続き、このルールを無視し、ソフトポリシーで、ソフト（ソフト）とハード戦術（ハード）に分かれています。
現時点ではメインノードの親和性：
- requiredDuringSchedulingIgnoredDuringExecutionは、ポッドは、ノードが再試行を停止するには、条件を満たさない場合、ノード上の条件を満たすように配置する必要があります表します。ノードラベルが変更された場合、どのポッドの展開時間後IgnoreDuringExecutionランを表し、もはやポッドを指定された基準を満たしていない、ポッドは、実行していきます。
- requiredDuringSchedulingRequiredDuringExecutionは、ポッドは、ノードが再試行を停止するには、条件を満たさない場合、ノード上の条件を満たすように配置する必要があります表します。ポッドの展開時間後RequiredDuringExecution実行を表し、ノードのラベルが変更された場合、ポッド指定された条件はもはや要件を満たすためにノードを再度選択し、満たされていません。
- preferredDuringSchedulingIgnoredDuringExecutionを優先展開通常のロジックに応じて、これらの条件を無視するように、ノードの状態、条件が満たされない場合、ノードを満足するように配備表明しました。
- preferredDuringSchedulingRequiredDuringExecutionを優先展開通常のロジックに応じて、これらの条件を無視するように、ノードの状態、条件が満たされない場合、ノードを満足するように配備表明しました。後者が表す場合、ノードラベルRequiredDuringExecution変更条件が満たされており、その後、再スケジューリングは、ノードの条件を満足します。
对于软策略还可以为其设置权重weight
公式のインスタンス：
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
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
ここではラベルマッチングロジックがリストにある、任意のオペレーターがあります。
- 中：リスト内のラベルの値
- NotIn：ラベルの値がリストにありません
- 存在：ラベルがあります
- DoesNotExist：ラベルが存在しません。
- GT：一定の値（文字列比較）よりもラベル値より大きい
- LT：以下のラベル（文字列比較）の値よりも値
可利用NotIn和DoesNotExist来实现对node排斥的功能
特別な注意
の両方がnodeselectorとNodeAffinityを定義している場合、両方満たすために必要である
あなたは、複数のnodeselectorTermsを定義した場合、のみ満たすために必要とされている
複数のMatchExpressionsは、唯一のMatchExpressionsのすべてを満たすために必要がある場合は、
PodAffinity
実装は、ポッドとの関係を検討することができ、ポッドとノードの間だけではなく、関係がスケジュールされます。1.（アフィニティ）：2つの対話型アプリケーションポッドが同じノードに期待して、ありますが、ケース2（相互に排他的）：2ポッドは大きな読者を持っているがありますが、私は、同じノード上でスケジュールされていない願っています。
TopologyKeyノードnode、topologyKeyポイントノード内蔵KEYノードタグの選択によって発現;を意味する式ノードの範囲は、トポロジー属します。
- kubernetes.io/hostname
- failure-domain.beta.kubernetes.io/zone
- failure-domain.beta.kubernetes.io/region
そして、類似したノードの親和性、ポッド親和性がrequiredDuringSchedulingIgnoredDuringExecutionとpreferredDuringSchedulingIgnoredDuringExecution、また前と同じ意味。あなたは親和性を使用している場合は、相互に排他的で使いたい場合は、下のpodAntiAffinityフィールドの親和性を付加する、podAffinity親和次のフィールドを追加します。
基準目標ポッドを定義します。
apiVersion: v1
kind: Pod
metadata:
name: pod-flag
labels:
security: "S1"
app: "nginx"
spec:
containers:
- name: nginx
image: nginx
ポッドアフィニティスケジューリング
以下は、親和性のスケジューリングの一例です
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: gcr.io/google_containers/pause:2.0
このノードキル上kubernetes.io/hostnameラベルは、保留状態のままになりますポッドを見つける場合は、あなたがしなかったので、参照ポッドを加えて、同じノードに配置されている上に見ることができるポッドを作成したら、それはありますノードの条件を満たします。
ポッド排他的スケジューリング
以下は、相互に排他的なスケジューリングの例です。
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
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
この例では、同じゾーンにセキュリティ=ポッドS1で新しいポッドを必要とするが、ポッドセキュリティがない= S2は、同じノードです。
原則として、topologyKeyはtopologyKey上、以下の制限ではなく、パフォーマンスとセキュリティのために、任意の有効なタグキーの割り当てを使用することができます。
- ポッドポッド親和性とRequiredDuringSchedulingの相互排他性を定義するには、空のtopologyKeyを許可されていません
- admissioncontrollerはLimitPodHardAntiAffinityTopologyが含まれている場合は、排他的な定義をRequiredDuringSchedulingためのポッドがカスタムtopologyKeyを使用するために、kubernetes.io/hostnameに制限されるだろう、それが適応するか、コントローラを無効にする必要があります
- 定義PerferredDuringSchedulingポッド排他型では、空topologyKeyはkubernetes.io/hostname,failure-domain.beta.kubernetes.io/zoneとfailure-domain.beta.kubernetes.io/regionの組み合わせとして解釈されます
ルールの注意podAffinityセット：
labelSelectorとtopologyKey同じレベルでは、デフォルトで、名前空間の定義されたポッドと一致しますポッド試合内部のネームスペース、ネームスペースのリストを定義することができる場所、もしこのフィールドの定義が、その値が空の場合、すべての一致であります名前空間。
全て満たさのMatchExpressionsのすべての関連requiredDuringSchedulingIgnoredDuringExecution後、システムは、ポッドノード上でスケジュールすることができます。
汚染（しみ）と寛容（トレランス）
汚染は、ポッドが不適切なものをノードを避けるせ、寛容で仕事に必要。明示的に記述ポッドが許容できない限り、一つ以上のテイントノード上の後、これらの「汚染された」は、これらのノード上で動作しません。寛容は、ノードのテイントマークポッドできる（することができますのみ、必ずしもそうではないが）実行してみましょう、属性のポッドです。
イラスト
セットノード染色
kubectl taint nodes node1 key=value:NoSchedule
汚染染色組成物は、キーを押すキーは、値がKEY、NoSchedule表現効果の値を表しています。
3つの効果があります。
- NoSchedule：そうでない場合は、このノードをスケジュールしない場合を除きポッドの設定は、このプロパティを容認します
- PreferNoSchedule：そうでない場合は、このノードをスケジュール避けない限り、ポッドの設定は、このプロパティを容認
- NOEXECUTE：ノード障害に応じて、立ち退きのポッド、。NOEXECUTEザ・テイントの効果が実行しているノード上のポッドに以下のような効果があります。
- 寛容がポッド内に設定されていないが、すぐに追放されます
- 寛容のポッドに設定対応は、無tolerationSeconds割り当てた場合、それは、このノードのままになります
- 指定された時間が追放された後tolerationSeconds対応するポッド構成の寛容は、値を指定して
寛容ポッドのセット
apiVersion: v1
kind: Pod
metadata:
name: pod-taints
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
containers:
- name: pod-taints
image: busybox:latest
これは次のようにも書くことができます。
tolerations:
- key: "key"
operator: "Exists"
effect: "NoSchedule"
pod的Toleration中的key和effect需要与Taint的设置保持一致，并且满足以下条件之一：
- オペレータは、時間値を指定せず、存在であります
- 値に等しい等しい演算子値（デフォルト）
マルチ汚れやより多くの患者
テイントの試合のKubernetesスケジューラプロセスの寛容、テイントアウト試合の残りの部分は、ポッドの何の効果ではありません。ここではいくつかの特殊な例は以下のとおりです。
- 効果= NoScheduleがある場合、スケジューラは、このノード上でスケジュールポッドテイントに残りません。
- 残りテイントNoSchedule効果なし、そこPreferNoSchedule効果場合、スケジューラ試みがこのノードに割り当てられていないPOD
- 結果はNOEXECUTEはテイントに残っている、とポッドは、ノードで実行されている場合は、それが追放され、ノードが実行されていない場合、それはノード上にスケジュールされることはありません。
