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

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

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

1. ポッドをスケジュールする主な方法

指定されたノードにポッドをスケジュールするには、主に 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 人の怒った子供たちで、互いに対立しているようなものです。一方が東に行く場合、もう一方は東以外のどの方向にも行くことができます。彼らは同じ場所に行くことはありません。

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

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

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

2. この2つの親和性表現を覚えておく

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

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

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

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

3. 式中の演算子

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

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

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

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

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

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

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

2.ノードセレクタのスケジューリング

たとえば、ラベル「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

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 ノードにスケジュールされていることがわかります。

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. ポッドアンチアフィニティスケジューリング

（１）反親和性ハード親和性

上記の例に従って、次のように 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 ノードにスケジュールされていることがわかります。

（２）反親和性ソフト親和性

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

VI.結論

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

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

<<: Kubernetesコンテナの動作原理を1つの記事で理解する

>>: OpenTelemetry に基づく Kubernetes フルリンク監視を 1 つの記事で理解する