Istio Ingress ゲートウェイ用の ibm-cloud-provider-ip ポッドが pending のままになるのはなぜですか?

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

複数ゾーン・クラスターのみ

kubectl get pod -n ibm-system を実行すると、Istio Ingress ゲートウェイの外部 IP アドレスを提供する ibm-cloud-provider-ip ポッドは pending 状況のままになります。

また、kubectl describe pod <pod_name> -n ibm-system を ibm-cloud-provider-ip ポッドに対して実行すると、スケジューリング競合エラーが出力の「ポッドのイベント」セクションで見つかります。

ご使用のゲートウェイ用の ibm-cloud-provider-ip ポッドを識別するには、kubectl get service -n istio-system を実行してゲートウェイのロード・バランサー・サービスを検出し、そのサービスの EXTERNAL-IP をメモして、ibm-cloud-provider-ip ポッド名内で IP アドレスを探します。

istio-ingressgateway ロード・バランサー・サービスが作成されると、ibm-cloud-provider-ip ポッドが作成されて、そのロード・バランサーに外部 IP アドレスが提供されます。

これらの ibm-cloud-provider-ip ポッドにはノード・アフィニティー・ルールが割り当てられているため、これらのポッドは IP アドレスの取得元サブネットと同じゾーン内で作成されます。 ただし、ExternalTrafficPolicy ロード・バランサー・サービスの istio-ingressgateway 設定が Local に設定されている場合は、ibm-cloud-provider-ip ポッドにも、ゲートウェイ・ロード・バランサー・ポッドと同じゾーンにデプロイされるためのポッド・アフィニティー・ルールが割り当てられます。 IP アドレスとゲートウェイ・ロード・バランサーがクラスター内の異なるゾーンに存在する場合、ibm-cloud-provider-ip ポッドは適切にデプロイできません。

ibm-cloud-provider-ip ポッドと istio-ingressgateway ポッドが同じゾーンに存在していないことを確認するには、以下の手順に従ってください。

  1. ** ポッドのデプロイ先である **NODEistio-ingressgateway を特定します。

    kubectl get pod -n istio-system -o wide

  2. ゲートウェイのロード・バランサー・サービスの EXTERNAL-IP を取得します。

    kubectl get service -n istio-system

  3. ロード・バランサーの ** ポッドのデプロイ先である **NODEibm-cloud-provider-ip を特定します。 <IP-with-hyphens> を、前のステップで見つかった IP アドレスで置き換えます。 IP アドレスでは、ピリオド (.) の代わりにハイフン (-) を使用します。例えば、169.12.345.67 は 169-12-345-67 になります。

    kubectl get pod -n ibm-system -o wide -l ibm-cloud-provider-ip=<IP-with-hyphens>

  4. ワーカー・ノードが存在しているゾーンをリストします。 ステップ 1 と 3 で特定したワーカー・ノードを比較して、ポッドが異なるゾーン内のワーカー・ノードにデプロイされているかどうかを確認します。

    kubectl get node --no-headers -L ibm-cloud.kubernetes.io/zone

    出力例

    10.176.48.106   Ready   <none>   529d    v1.36+IKS   dal10
10.176.48.107   Ready   <none>   196d    v1.36+IKS   dal10
10.184.58.23    Ready   <none>   2y38d   v1.36+IKS   dal12
10.184.58.42    Ready   <none>   529d    v1.36+IKS   dal12

この問題を解決するには、istio-ingressgateway ポッドを ibm-cloud-provider-ip ポッドが存在しているゾーンに移動するか、その逆を行います。

  • istio-ingressgateway ポッドの移動 : ゲートウェイのロード・バランサーについては、移動後も同じ外部 IP アドレスが保持されます。 ただし、バージョン 1.9 以前のアドオンでは、Istio パッチ更新時にゲートウェイのゾーン・ラベルが自動的に入力されたときに、加えた変更内容は上書きされる可能性があります。
  • ibm-cloud-provider-ip ポッドの移動: ゲートウェイについては、移動後に同じ外部 IP アドレスは保持されず、新しい IP アドレスが割り当てられます。 ただし、アドオンの更新時にどの変更内容も上書きされません。

istio-ingressgateway ポッドの移動

istio-ingressgateway ポッドを ibm-cloud-provider-ip ポッドと同じゾーンに移動します。

  1. managed-istio-custom 構成マップ・リソースを編集します。
    kubectl edit cm managed-istio-custom -n ibm-operators
  2. 移動するゲートウェイについて、istio-ingressgateway-zone-1|2|3 設定を ibm-cloud-provider-ip ポッドが存在しているゾーンに変更します。
  3. 構成ファイルを保存して閉じます。 istio-ingressgateway ポッドは ibm-cloud-provider-ip ポッドと同じゾーン内のワーカー・ノードに移動されて、ibm-cloud-provider-ip ポッドは適切にデプロイされます。
  4. これらのポッドが同じゾーンに存在していることを確認するには、『現象の理由』セクションのステップに従います。

ibm-cloud-provider-ip ポッドの移動

ibm-cloud-provider-ip ポッドを istio-ingressgateway ポッドと同じゾーンに移動します。

  1. managed-istio-custom 構成マップ・リソースを編集します。

    kubectl edit cm managed-istio-custom -n ibm-operators

  2. ゲートウェイの istio-ingressgateway-zone-<1|2|3> 設定の名前を書き留めておきます。 この構成マップ例では、dal10に存在するゲートウェイの ibm-cloud-provider-ip ポッドを移動するために、istio-ingressgateway-zone-1 というキーを書き留めておきます。

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "true"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  3. 対応する istio-ingressgateway-public-<1|2|3>-enabled 設定を "false" に変更して、ゲートウェイを一時的に無効にします。 この例の構成マップでは、ibm-cloud-provider-ip に存在しているゲートウェイの dal10 ポッドを移動するには、istio-ingressgateway-public-1-enabled を "false" に変更します。

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "false"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  4. 構成ファイルを保存して閉じます。

  5. ゲートウェイのロード・バランサー・ポッドが削除されたことを確認します。 変更が完了するまでに、最大で 30 分かかることがあるので注意してください。

    kubectl get service -n istio-system -o wide

  6. managed-istio-custom 構成マップ・リソースを開きます。

    kubectl edit cm managed-istio-custom -n ibm-operators

  7. istio-ingressgateway-public-<1|2|3>-enabled 設定を "true"に戻して、ゲートウェイを再び有効にします。

  8. 構成ファイルを保存して閉じます。 ゲートウェイ (istio-ingressgateway ポッド) 用の新しいロード・バランサー・サービスが作成されて、そのロード・バランサーの新しい ibm-cloud-provider-ip ポッドが、istio-ingressgateway ポッドと同じゾーン内のワーカー・ノードにデプロイされます。

  9. これらのポッドが同じゾーンに存在していることを確認するには、『現象の理由』セクションのステップに従います。