IBM Cloud Docs
Ingress の状況に ERRIODEG エラーが表示されるのはなぜですか?

Ingress の状況に ERRIODEG エラーが表示されるのはなぜですか?

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

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 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: 実際のアドレスは、構成によって異なります。ワーカー・ノードを外部ロード・バランサーで公開する場合は、ロード・バランサー・アドレスを登録します。そうでない場合は、 router-external-default サービスに割り当てられた IP アドレスを openshift-ingress 名前空間に登録します ( 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. カナリア・トラフィックをブロックするファイアウォール・ルールがないことを確認します。 VPC: カナリア・トラフィックは、ワーカー・ノードの 1 つから発信され、VPC Public Gateway を経由して、VPC ロード・バランサー・インスタンスのパブリック側に到着します。 この通信を許可するように VPC セキュリティー・グループを構成します。 詳細については、「VPCセキュリティグループでトラフィックを制御する」を参照してください。 クラシック: カナリア・トラフィックは、いずれかのワーカー・ノードのパブリック IP アドレスから発信され、クラシック・ロード・バランサーのパブリック IP アドレスに到着します。 この通信を許可するようにネットワーク・ポリシーを構成します。 詳しくは、 クラシック・クラスターでのネットワーク・ポリシーを使用したトラフィックの制御 を参照してください。

次のステップ

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