クラシック・クラスター: テイント適用ノードを使用するとソース IP 保持が失敗するのはなぜですか?

クラシック・インフラストラクチャー

サービス設定ファイルの externalTrafficPolicy を Local に変更して、 イングレス ALB のソース IP 保存を有効にする。 しかし、トラフィックがアプリのバックエンド・サービスに到達しません。

Ingress ALB サービスのソース IP 保持を有効にすると、クライアント要求のソース IP アドレスは保持されます。 これらのサービスは、要求パケットの IP アドレスが変更されないようにするために、同じワーカー・ノード上の各アプリ・ポッドにのみトラフィックを転送します。

通常、Ingress ALB サービスポッドは、アプリポッドと同じワーカーノードにデプロイされます。 しかし、状況によっては、サービスポッドとアプリポッドが同じワーカーノードでスケジュールされないことがあります。 ワーカーノードで Kubernetes テイントを使用する場合、テイント耐性を持っていないポッドは汚染されたワーカーノードで実行できなくなります。 使用したテイントの種類によっては、ソースIPの保全が機能しない場合があります：

  • エッジ・ノードのテイント: クラスター内の各パブリック VLAN 上の複数のワーカー・ノードに dedicated=edge ラベルを追加して、Ingress ポッドがそれらのワーカー・ノードにのみデプロイされるようにしました。 その後、それらのエッジ・ノードにテイントも適用して、他のすべてのワークロードがエッジ・ノードで実行されないようにしました。 しかし、アプリ・デプロイメントにエッジ・ノードのアフィニティー・ルールと容認を追加しませんでした。 アプリ・ポッドは、サービス・ポッドと同じテイント適用ノードにスケジュールすることはできず、トラフィックはアプリのバックエンド・サービスに到達しません。

  • カスタム・テイント: カスタム・テイントをいくつかのノード上で使用して、そのテイントの容認があるアプリ・ポッドだけをそれらのノードにデプロイできるようにしました。 アプリのデプロイメントと、Ingress サービスにアフィニティー・ルールと容認を追加したので、それらのポッドはそれらのノードにのみデプロイされます。 しかし、ibm-cloud-provider-ip 名前空間に自動的に作成される keepalived ibm-system ポッドがあるので、ALB ポッドとアプリ・ポッドは必ず同じワーカー・ノードにスケジュールされます。 これらの keepalived ポッドには、使用したカスタムのテイントに対する容認がありません。 これらのポッドをアプリ・ポッドが実行されているノードと同じテイント適用ノードにスケジュールすることはできず、トラフィックはアプリのバックエンド・サービスに到達しません。

以下のいずれかのオプションを選択して、この問題を解決します。

前のステップを完了したにもかかわらず、 keepalived ポッドがまだスケジュールされていない場合は、 keepalived ポッドに関する詳細情報を収集します：

  1. keepalived ポッドを取得します。
    kubectl get pods -n ibm-system
  2. 出力で、ibm-cloud-provider-ipStatus** が ** になっている Pending ポッドを探します。 次に例を示します。
    ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>
  3. 各ポッド（ keepalived ）について説明し、 「イベント」 セクションを確認する。 記載されているエラーメッセージや警告メッセージに対処する。
    kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system