ALB ポッドがワーカー・ノードにデプロイされないのはなぜですか?

仮想プライベートクラウド クラシック・インフラストラクチャー

kubectl get pods -n kube-system | grep alb を実行すると、ALB ポッドが表示されないか、一部の ALB ポッドしかワーカー・ノードに正常にデプロイされていません。

kubectl describe pod -n kube-system <pod_name> を実行して ALB ポッドを記述すると、出力の Events セクションに次のようなメッセージがあります。

0/3 nodes are available: 1 node(s) didn’t match pod affinity/anti-affinity, 2 node(s) didn’t match node selector.

高可用性を確保して定期的に更新を適用するために、Ingress にはゾーンごとにワーカー・ノードが 2 台以上必要です。

デフォルトでは、ALB ポッドには 2 つのレプリカがあります。 しかし、高可用性のために、ALB には各ワーカー・ノードに 1 つしかポッドをスケジュールしないようにするアンチアフィニティー・ルールが設定されます。 クラシック・クラスターまたは VPC クラスター内のゾーンごとにワーカー・ノードが 1 つしか存在しない場合、またはクラシック・クラスターが接続されている VLAN 上にワーカー・ノードが 1 つしか存在しない場合は、ALB ポッドを正しくデプロイできません。

以下の手順に従って問題を解決してください：

1. クラスター内のゾーンあたりのワーカー・ノードの数を確認します。

   ibmcloud ks worker ls -c <cluster_name_or_ID>
   

2. ゾーンにワーカーノードが1つしかない場合は、そのゾーンのワーカーノード数を増やす。

   • クラシッククラスタとVPCクラスタ ：
     • エッジノードを使用しない場合既存のワーカープールのサイズを変更するか、 VPCクラスタに新しいワーカープールを作成 するか、 クラシッククラスタに新しいワーカープールを 作成して、各ゾーンに少なくとも2つのワーカノードが存在するようにします。
     • エッジノードを使用する場合各ゾーンで少なくとも2つの エッジワーカーノードが 有効になっていることを確認する。
   • クラシック クラスタのみ ：クラシック クラスタの各ゾーンに複数のワーカー ノードが存在する場合、ワーカー ノードが 1 つのゾーン内で異なる VLAN に接続され、プライベート VLAN 上にワーカー ノードが 1 つしか存在しないことがあります。 次のステップに進んでください。

3. ゾーンごとに複数のワーカーノードがあるクラシッククラスタの場合は、各ワーカーノードが接続しているプライベートVLANを確認してください。

   ibmcloud ks worker get -w <worker_ID> -c <cluster_name_or_ID>
   

4. あるプライベート VLAN 上に存在しているワーカー・ノードが 1 つだけで、ゾーン内の他のワーカー・ノードが別のプライベート VLAN に接続されている場合は、ワーカー・ノード 1 台以上のサイズを指定して新規ワーカー・プールを作成します。 ワーカープールにゾーンを追加するときは、以前に特定したワーカーノードと同じゾーンとプライベートVLANを指定する。

5. この手順をクラスターのゾーンごとに繰り返して、1 つのプライベート VLAN 上に複数のワーカー・ノードが存在するようにします。

新しいワーカー・ノードをデプロイすると、 ALB ポッドがそれらのワーカー・ノードにデプロイされるように自動的にスケジュールされます。