イングレスエラー：エリオデグ

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

イングレス・オペレーターがデグレード状態にある場合に、 ERRIODEG のエラーを解決する方法をご覧ください。

ibmcloud oc ingress status-report ignored-errors add コマンドを使用して、無視されたエラーのリストにエラーを追加することができます。 無視されたエラーは、 ibmcloud oc ingress status-report get コマンドの出力には引き続き表示されますが、Ingress 全体の状況を計算する際には無視されます。

ibmcloud oc ingress status-report get コマンドを実行してクラスターの Ingress コンポーネントの状況を確認すると、以下のようなエラーが表示されます。

The Ingress Operator is in a degraded state (ERRIODEG).

Ingress オペレーターは、Ingress コントローラーの正常性を検査し、検査が失敗すると機能低下状態になります。

ノードに過負荷がかかっていないことを確認してください。 ノードに過負荷がかかると、Ingress Operator のヘルスチェックが失敗する原因となる可能性があります。

CPUとメモリに十分な余裕があるかどうかを確認するには、次のコマンドを実行してください。

kubectl top nodes

ingress （ ClusterOperator ）の詳細を確認し、エラーメッセージに基づいて手順を実行してください。

ingress ClusterOperatorの状況を確認します。 DEGRADED 列に False が表示されている場合は、10 分から 15 分待って、Ingress 状況の警告が表示されなくなるかどうかを確認します。 そうでない場合は、 MESSAGE 列のメッセージに基づいてトラブルシューティング・ステップに進みます。

oc get clusteroperator ingress

1 つ以上の状況条件が使用不可であることを示しています: DeploymentAvailable=False

  1. クラスターに少なくとも 2 つのワーカーがあることを確認します。 詳しくは、 クラシック・クラスターへのワーカー・ノードの追加 または VPC クラスターへのワーカー・ノードの追加 を参照してください。
  2. クラスター・ワーカーが正常であることを確認してください。そうしないと、Ingress コントローラー・ポッドをスケジュールできません。 詳しくは、ワーカー・ノードの状態を参照してください。

1 つ以上の状況条件が使用不可であることを示しています: LoadBalancerReady=False

  1. VPC のみ: LBaaS インスタンス割り当て量に達していないことを確認してください。 詳しくは、 割り当て量とサービスの制限 および ibmcloud is load-balancers コマンド を参照してください。
  2. クラスター・マスターが正常であることを確認します。 詳しくは、 マスターの正常性の確認 を参照してください。
  3. ibmcloud oc cluster master refresh コマンド を実行して、クラスター・マスターをリフレッシュします。

1 つ以上の他の状況条件が機能低下状態を示しています: CanaryChecksSucceeding=False

  1. Red Hat OpenShift クラスターにアクセスします。

  2. 正しい LoadBalancer サービス・アドレスが Ingress サブドメインに登録されていることを確認してください。

    1. ibmcloud oc cluster get コマンド を実行して、Ingress サブドメインを確認します。
    2. ibmcloud oc nlb-dns get コマンド を実行して、登録されているアドレスを確認します。
    3. oc get services -n openshift-ingress コマンドを実行して、実際のロード・バランサー・アドレスを取得します。
    4. 登録済みアドレスと実際のアドレスを比較し、サブドメインが異なる場合は更新します。 VPC: ibmcloud oc nlb-dns replace コマンド を実行して、現行アドレスを置き換えます。 クラシック: ibmcloud oc nlb-dns rm classic コマンド を実行して現在登録されているアドレスを削除してから、 ibmcloud oc nlb-dns add コマンド を使用して新しいアドレスを追加します。 Satellite: 実際のアドレスは設定によって異なります。ワーカーノードを外部ロードバランサー経由で公開している場合は、そのロードバランサーのアドレスを登録してください。そうでない場合は、 openshift-ingress ネームスペース内の router-external-default サービスに割り当てられたIPアドレスを登録してください（アドレスを取得するには、 oc get services -n openshift-ingress router-external-default -o yaml コマンドを使用してください）。 ibmcloud oc nlb-dns rm classic コマンド を実行して現在登録されているアドレスを削除してから、 ibmcloud oc nlb-dns add コマンド を使用して新しいアドレスを追加します。

  3. VPC のみ: カナリア・ヘルス・チェック・トラフィックは、クラスターのいずれかのワーカー・ノードから発生します。

    • ヘルス・チェック・トラフィックは、クラスターのいずれかのワーカー・ノードから発信されます。 パブリック・サービス・エンドポイントを持つクラスターの場合、トラフィックは VPC ロード・バランサー・インスタンスのパブリック浮動 IP アドレスに送信されるため、すべてのワーカー・サブネットに Public Gateway を接続する必要があります。 プライベート・サービス・エンドポイントのみを持つクラスターの場合、トラフィックは VPC ロード・バランサーの VPC サブネット IP アドレスに送信されるため、 Public Gateway は必要ありません。 パブリック・サービス・エンドポイントを持つクラスターの場合:
      1. ibmcloud is public-gateways を実行して、パブリック・ゲートウェイを表示します。
      2. ibmcloud is subnets を実行して、サブネットを確認します。
      3. サブネットごとに、 ibmcloud is subnet <subnet-id> を実行して、パブリック・ゲートウェイがあるかどうかを確認します。
        1. サブネットにパブリック・ゲートウェイが接続されていない場合は、接続する必要があります。 詳しくは、 パブリック・ゲートウェイの作成 を参照してください。
    • VPC ロード・バランサーがクラスターのワーカー・ノード以外のサブネットに配置されている場合は、VPC ロード・バランサー・サブネットに接続されているセキュリティー・グループを更新して、ワーカー・サブネットからの着信トラフィックを許可する必要があります。
    • 詳しくは、 仮想プライベート・クラウドでの Red Hat OpenShift クラスターの作成、 VPC サブネットの構成 、および VPC セキュリティー・グループの作成と管理 を参照してください。

  4. UDP および TCP 経由のカナリアトラフィックや DNS トラフィックをブロックするファイアウォールルールがないことを確認してください。 VPC ：カナリアトラフィックは、いずれかのワーカーノードから発信され、VPCを経由して Public Gateway へと流れ、VPCロードバランサーインスタンスのパブリック側に到達します。 この通信を許可するように VPC セキュリティー・グループを構成します。 詳細については、 「デフォルトでセキュアなクラスタVPCネットワークについて 」および「 VPCセキュリティグループの作成と管理 」を参照してください。 クラシック: カナリアトラフィックはワーカーノードのパブリックIPアドレスから発生し、クラシックロードバランサのパブリックIPアドレスに到着します。 この通信を許可するようにネットワーク・ポリシーを構成します。 詳細については、 クラシック・クラスタのネットワーク・ポリシーによるトラフィックの制御を 参照してください。

次のステップ

  1. 30 分待ってから、 oc get clusteroperator ingress コマンドを実行し、 MESSAGE 列を再度確認します。
  2. 別のエラー・メッセージが表示された場合は、トラブルシューティング手順を繰り返します。
  3. 問題が解決しない場合は、サポートにお問い合わせください。 サポート Case を開きます。 ケースの詳細には、関連するログ・ファイル、エラー・メッセージ、またはコマンド出力を必ず含めてください。