K8S アフィニティとアンチアフィニティのスケジューリングを 10 分で理解する

この記事では、Kubernetes のアフィニティ スケジューリングとアンチアフィニティ スケジューリングを中心に、理論と実践を組み合わせて理解を深めます。

まず、一言でまとめると、「アフィニティ スケジューリングは親しいガールフレンドのようなもので、あなたが行くところに私も行きます」ということです。アンチアフィニティ スケジューリングは、決して一緒に遊ぼうとしない 2 人の不機嫌な子供のようなものです。詳しい説明と実際の例については以下を参照してください。 10 分かけて最後まで見れば、必ず何かが得られるでしょう。

1. Podをスケジュールする主な方法

指定されたノードにポッドをスケジュールするには、主に 4 つの方法があります。

• NodeName スケジューリング: Pod の yaml オーケストレーション ファイルで nodeName を直接指定し、指定された名前のノードにスケジュールします。
• NodeSelector のスケジューリング: Pod の YAML オーケストレーション ファイルで nodeSelector を直接指定し、指定されたラベルを持つノードにスケジュールします。
• テイントと許容値のスケジュール設定: 詳細については、「Kubernetes のテイントと許容値を 5 分で理解する (理論 + 実践)」の記事を参照してください。スケジューリングは主に、Node ノードを tainting し、Pod の yaml オーケストレーション ファイルで許容値を構成することによって実現されます。
• アフィニティ-アンチアフィニティ スケジューリング: 説明については以下を参照してください。

2. アフィニティ スケジューリングが必要な理由は何ですか?

nodeName スケジューリング、nodeSelector スケジューリング、taints および tolerances スケジューリングがあるのに、なぜアフィニティ-アンチアフィニティ スケジューリングが必要なのでしょうか?

より柔軟で複雑なスケジュール方法を実現します。たとえば、シナリオによっては、2 つの Pod を 1 つのノードにスケジュールしたり、分離と高可用性のために 2 つの Pod を異なるノードに分離したり、指定したノードに Pod をスケジュールしたりすることがあります。

3. アフィニティスケジューリングの前提条件（重要）

• ラベルは K8S において非常に重要な概念です。シナリオが何であっても、選択とフィルタリングに関連する限り、ラベル フィールドは基本的にマッチングに使用されます。
• アフィニティおよびアンチアフィニティ スケジューリングの場合、フィルタリング基準では引き続きノード ラベル フィールドが使用されます。
• Node アフィニティ スケジューリングであっても Pod アフィニティ スケジューリングであっても、スケジュールされる対象は Pod です。これらはすべて、アフィニティ ルールに基づいて特定のノードにスケジュールされるポッド、または他のポッドに続いて特定のノードにスケジュールされるポッドを指します (たとえば、ポッド 1 はポッド 2 に続き、ポッド 2 はノード B にスケジュールされ、その後ポッド 1 もノード B にスケジュールされます)。
• ノード アフィニティ スケジューリングとポッド アフィニティ スケジューリングの構成は、どちらもオーケストレーション ポッドの yaml ファイルに記述されます。スケジュールされている対象が Pod であるためです。
• ノード アフィニティ スケジューリングは、ポッドとノード間の密接な関係を指します。
• ポッド アフィニティ スケジューリングは、ポッド間の密接な関係を指します。
• ハード アフィニティ: 満たす必要のあるアフィニティ ルールは 1 つだけです。
• ソフト アフィニティ: 複数のルールがあり、それぞれ重みが異なります。重みの優先順位に基づいてルールを選択します。
• ノードアフィニティスケジューリングの図は次のとおりです。 Pod アフィニティ呼び出しと Pod アンチアフィニティ呼び出しは似ています。

4. アフィニティスケジューリングの具体的な概念

中国語で「親近感」は近さを意味し、親近感のスケジュールを説明するのに非常に適しています。

アフィニティ スケジューリング: ノード (またはポッド) とポッドが仲良しな友達のような関係です。ポッドは、「ノード (ポッド) がこのラベルを満たしている限り、それは私の良き友人です。友人がいるところならどこへでも行きます。」と言います。

アンチアフィニティ スケジューリング: 2 つのポッドが 2 人の怒った子供たちで、互いに対立しているようなものです。一方が東に行く場合、もう一方は東以外のどの方向にも行くことができます。彼らは同じ場所に行くことはありません。

4.1.これら3つのスケジュール関係を覚えておいてください

アフィニティ スケジューリングとアンチアフィニティ スケジューリングの関係には、次の 3 種類があります。

• ノードアフィニティスケジューリング: ハードアフィニティとソフトアフィニティ
• ポッドアフィニティスケジューリング: ハードアフィニティとソフトアフィニティ
• ポッドアンチアフィニティスケジューリング: ハードアフィニティとソフトアフィニティ

4.2.これら2つの親和性表現を覚えておいてください

ノード アフィニティまたはポッド アフィニティに関係なく、アフィニティを表現する方法は 2 つあります。

• RequiredDuringSchedulingIgnoredDuringExecution: これはハード アフィニティ メソッドです。指定されたルールが満たされた場合にのみ、ポッドをノードにスケジュールできます。ここで「Required」という単語に注目してください。これは中国語で「必要」を意味します。
• PreferredDuringSchedulingIgnoredDuringExecution: 特定のルールを最初に満たすことを重視し、次に優先ルールに基づいて Pod をノードにスケジュールするソフト アフィニティ メソッドです。ここで「優先」という言葉に注意してください。中国語で「第一選択」を意味します。選択ルールの優先順位を説明するためにこれを使用することは非常に適切です。

これら 2 つのフィールドも比較的長いです。これらを分解して、RequiredDuringSchedulingIgnoredDuringExecution を RequiredDuringScheduling と IgnoredDuringExecution に分割してみましょう。

• RequiredDuringScheduling: ポッドがノードにスケジュールされる前に、定義されたルールを満たす必要があります (必須)。
• IgnoredDuringExecution: ノード上ですでに実行されているポッドは、定義されたルールを満たす必要はありません。ノード上のラベルが削除された場合でも、そのラベルをノードに含めることを必要とするポッドは引き続きノード上で実行されます。または、次のように理解することもできます。ポッドの実行中にポッドが配置されているノードのラベルが削除され、ポッドのノードアフィニティルールを満たさなくなった場合でも、問題はなく、ポッドはノード上で引き続き実行できます。

4.3 式中の演算子

アフィニティ式では、次のオプションの演算子を使用する必要があります。

• In: タグの値はリスト内にあります
• NotIn: タグの値がリストにありません
• 存在: タグが存在する
• DoesNotExist: タグが存在しません
• Gt: タグの値が特定の値より大きい (文字列比較)
• Lt: タグの値が特定の値より小さい (文字列比較)

これらの演算子には特定のノードを除外する機能はありませんが、これらのラベルを使用することで除外機能を隠蔽することができます。

4.4.スコープトポロジキー

多くの場所で、topologyKey はトポロジ構築として説明されており、非常に混乱を招きます。実際、それは範囲の概念です。

topologyKey がラベル キーで構成されている場合、このキーに対応するラベルを持つすべてのノードは同じスコープ内にあります。

5. 実戦

理論的な知識は説明されましたが、次のステップは実践を通して理解を深めることです。手順に従って練習することができます。

5.1、ノード名のスケジューリング

たとえば、nodeNameがk8s-worker-2であるノードにPodをスケジュールするには

apiVersion: v1 kind: Pod metadata: name: webapp namespace: demo labels: app: webapp spec: nodeName: 'k8s-worker-2' containers: - name: webapp image: nginx ports: - containerPort: 80

5.2. nodeSelector のスケジュール

たとえば、ラベル「special-app」="specialwebapp" を持つノードに Pod をスケジュールするとします。

ノード情報を表示します。

 kubectl describe node k8s-worker-2

Pod の yaml オーケストレーション ファイル:

 apiVersion: v1 kind: Pod metadata: name: webapp namespace: demo labels: app: webapp spec: nodeSelector: # 选择调度到具有这个label的节点"special-app": "specialwebapp" containers: - name: webapp image: nginx ports: - containerPort: 80

Pod がどのマシンにスケジュールされているかを確認します。

 kubectl get pod -n demo -o wide

5.3 ノードアフィニティスケジューリング

ノード アフィニティ スケジューリングは、ノードとポッドの関係を指します。

ハードアフィニティ

Pod-Node のハード アフィニティ yaml ファイルを定義します: pod_node_required_affinity.yaml。ファイルの内容は次のとおりです。

 apiVersion: v1 kind: Pod metadata: name: webapp namespace: demo labels: app: webapp spec: containers: - name: webapp image: nginx ports: - containerPort: 80 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - backend

k8s-worker-3 ノードにラベルを追加します。

 kubectl label node k8s-worker-3 app=backend

k8s-worker-3 ノードのラベルを確認します。

 kubectl get node k8s-worker-3 --show-labels

上記の yaml を実行して Pod をデプロイすると、Pod が k8s-worker-3 ノードにスケジュールされていることがわかります。

ソフトアフィニティ

ソフト アフィニティ スケジューリングでは、主に複数のルールを追加し、各ルールに重みを設定します。 yaml ファイルは次のとおりです。

 apiVersion: v1 kind: Pod metadata: name: webapp namespace: demo labels: app: webapp spec: containers: - name: webapp image: nginx ports: - containerPort: 80 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: app2 operator: Exists - weight: 20 preference: matchExpressions: - key: app operator: In values: - backend2

以前の Pod を削除し、k8s-worker-3 ノードの以前のラベルを削除してから、k8s-worker-2 ノードにラベル app2=backend を追加します。

 kubectl delete pod webapp -n demo kubectl label node k8s-worker-3 app- kubectl label node k8s-worker-2 app2=backend

上記のソフト アフィニティ yaml ファイルをデプロイすると、Pod が k8s-worker-2 ノードにスケジュールされていることがわかります。

5.4 ポッドアフィニティスケジューリング

ポッド アフィニティ スケジューリングは、ポッド間の関係を指します。

ハードアフィニティ

たとえば、Pod1 が Pod2 に続き、Pod2 がノード B にスケジュールされている場合、Pod1 もノード B にスケジュールされます。

ここで 2 つのポッドを準備します。 Pod1 は上記の例を使用して、Node ハード アフィニティを使用して Pod1 を k8s-worker-3 ノードにスケジュールします。次に、Pod2 をデプロイして Pod1 に追従させると、k8s-worker-3 ノードにもスケジュールされます。

次のように、Pod2 の yaml オーケストレーション ファイル pod_pod_required_affinity.yaml を準備します。

 apiVersion: v1 kind: Pod metadata: name: webapp-1 namespace: demo labels: app: webapp-1 spec: containers: - name: webapp image: nginx ports: - containerPort: 80 affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname labelSelector: matchExpressions: - key: app operator: In values: - webapp

Pod2 は Pod1 に続き、k8s-worker-3 ノードにもスケジュールされていることがわかります。

ソフトアフィニティ

ソフト アフィニティはハード アフィニティに似ていますが、重みが追加されています。自分で試してみることもできます。

5.5.ポッドアンチアフィニティスケジューリング

ハードアフィニティ対アフィニティ

上記の例に従って、次のように Pod3 の YAML オーケストレーション ファイルを準備します。

 apiVersion: v1 kind: Pod metadata: name: webapp-2 namespace: demo labels: app: webapp-2 spec: containers: - name: webapp image: nginx ports: - containerPort: 80 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname labelSelector: matchExpressions: - key: app operator: In values: - webapp

Pod アンチアフィニティを使用して、Pod3 と Pod1 が一緒にデプロイされるのを防ぎます。デプロイが完了したら、結果を確認すると、反アフィニティにより Pod3 が k8s-worker-2 ノードにスケジュールされていることがわかります。

アンチアフィニティソフトアフィニティ

アンチアフィニティのソフト アフィニティは、追加の重みがあることを除いて、ハード アフィニティに似ています。自分で試してみることもできます。

6. まとめ

この記事では主に、Kubernetes のアフィニティ スケジューリングとアンチアフィニティ スケジューリングについて簡単に説明します。この記事を読んだ後、次の 3 つの点を覚えておく必要があります。

• アフィニティおよびアンチアフィニティ スケジューリングの場合、フィルタリング条件にはノード (ポッド) のラベル フィールドが使用されます。
• アフィニティ スケジューリング: ノード (ポッド) とポッドが仲良しな友達のような関係です。ポッドは「このラベルに適合するノード (ポッド) はどれも私の良き友人です。友人がいるところならどこへでも行きます」と言います。
• アンチアフィニティ スケジューリング: 2 つのポッドが 2 人の怒った子供たちで、互いに対立しているようなものです。一方が東に行く場合、もう一方は東以外のどの方向にも行くことができます。彼らは同じ場所に行くことはありません。