Ingress のデバッグ

Virtual Private Cloud Classic infrastructure

クラスターでアプリ用の Ingress リソースを作成して、アプリを公開しました。ただし、Ingress サブドメインまたは Ingress コントローラーの IP アドレスを介してアプリに接続しようとすると、接続が失敗するか、タイムアウトになります。

以下のセクションのステップは、Ingress のセットアップのデバッグに役立ちます。

始める前に、 IBM Cloud Kubernetes Serviceの以下の IBM Cloud IAM アクセス・ポリシーがあることを確認してください。 - クラスターに対する エディター または 管理者 のプラットフォーム・アクセス役割 - ライター または マネージャー サービス・アクセス役割

アプリのサブドメインにアクセスしようとすると、Application is not available ページが表示されますか? アプリのデプロイ状況、Ingress および Route リソースの設定を確認してください。 Connection timeout ページが表示されますか? Ingress コントローラー・ポッドの正常性を確認します。

手順 1: アプリのデプロイ状況、Ingress リソースおよび Route リソースの設定を確認する

最初に、アプリ・デプロイメントおよび Ingress リソース・デプロイメントにエラーがないかを確認します。デプロイメントのエラー・メッセージは、障害の根本原因を見つけて、次のセクションで Ingress のセットアップをさらにデバッグするのに役立ちます。

Ingress をデバッグする前に、まず、アプリ・デプロイメントのデバッグを確認してください。多くの場合、Ingress の問題は、アプリ・デプロイメントや、アプリを公開する ClusterIP サービスの根本的な問題が原因で発生します。例えば、アプリのラベルとサービスのセレクターが一致していない、アプリとサービスのターゲット・ポートが一致していないなどの問題があります。
Ingress リソースのデプロイメントを確認して、警告またはエラー・メッセージがないか探します。
```
oc describe ingress <ingress_resource_name>
```
出力の Events セクションに、Ingress リソースや使用した特定のアノテーション内の無効な値に関する警告メッセージが表示される場合があります。アノテーションに関しては、 Red Hat OpenShift バージョン 4 では、Ingress コントローラーおよび Ingress リソースに対して Ingress- NGINX アノテーション (nginx.ingress.kubernetes.io/<annotation>) がサポートされていないことに注意してください。 Red Hat OpenShift バージョン 4 を実行しているクラスタ内のアプリのルーティングルールをカスタマイズしたい場合は、ルート固有の HAProxy アノテーションを使用できます。このアノテーションの形式は、 haproxy.router.openshift.io/<annotation> または router.openshift.io/<annotation> のようになります。
```
NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  default-http-backend:80 (<none>)
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:  <none>
Events:       <none>
```

Routeリソースのデプロイ状況を確認し、警告やエラーメッセージがないか確認してください。

oc describe route <myroute>

出力の「ステータス 」および「 イベント 」セクションには、Route リソースや使用した特定のアノテーションに含まれる無効な値に関する警告メッセージが表示される場合があります。

Name:         myroute
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  route.openshift.io/v1
Kind:         Route
Metadata:
  Creation Timestamp:  2026-07-01T10:18:43Z
  Generation:          1
  Owner References:
    API Version:     networking.k8s.io/v1
    Controller:      true
    Kind:            Ingress
    Name:            coffee-ingress
    UID:             e7a18dd4-402d-461c-a41f-c4750b6d2032
  Resource Version:  178601
  UID:               17c623e6-e9ef-4179-a3ad-af8ea311f2e5
Spec:
  Host:  mycluster-<hash>-0000.us-south.containers.appdomain.cloud
  Path:  /
  Port:
    Target Port:  http
  Tls:
    Certificate:  ...
    Insecure Edge Termination Policy:  Redirect
    Key: ...
    Termination:  edge
  To:
    Kind:           Service
    Name:           myservice1
    Weight:         100
  Wildcard Policy:  None
Status:
  Ingress:
    Conditions:
      Last Transition Time:     2026-07-01T10:18:43Z
      Status:                   True
      Type:                     Admitted
    Host:                       mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Canonical Hostname:  router-default.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Name:                default
    Wildcard Policy:            None
Events:  <none>

クラスタレベルのイベントに警告やエラーメッセージがないか確認してください。
```
oc get events
```
場合によっては、Ingress リソースに関連する警告やエラーイベントがクラスタレベルで発生することがあります。イベントは名前空間ごとにスコープが定義されることに留意してください。
```
LAST SEEN   TYPE      REASON                          OBJECT             MESSAGE
2m40s       Warning   IncompleteIngressToRouteRules   ingress/myingress  Incomplete ingress to route rules detected: Invalid or missing TLS secret for rule host "mycluster-<hash>-0000.us-south.containers.appdomain.cloud" at index 0, path index 0
```
Ingress または Route リソースの設定ファイルを確認してください。
```
oc get ingress -o yaml
```
1. 1 つのホストは、必ず 1 つの Ingress リソースだけに定義するようにしてください。 1 つのホストが複数の Ingress リソースに定義された場合、Ingress コントローラーはトラフィックを正しく転送しないことがあり、その場合エラーが発生する場合があります。
2. サブドメインと TLS 証明書が正しいことを確認します。 IBM 提供の Ingress サブドメインと TLS 証明書を見つけるには、ibmcloud oc cluster get --cluster <cluster_name_or_ID> を実行します。
3. アプリが、Ingress の path セクションで構成されているパスを使用して listen していることを確認します。
4. 必要に応じてリソース構成 YAML を編集します。エディターを閉じると、変更内容が保存され、自動的に適用されます。
```
    oc edit ingress <myingressresource>
    ```
```
アカウントごとに許可されている VPC ロード・バランサーの最大数に達しているかどうかを確認してください。 VPC 内のすべての VPC クラスターに渡る VPC リソース割り当て量については、VPC 割り当て量に関する資料を確認します。

ステップ 2: Ingress コントローラーの状態を確認する

Ingress オペレーターと Ingress コントローラーが正常であることを確認します。 Ingress コントローラーは、Ingress オペレーターによって管理されます。 Ingress コントローラーは、Ingress リソースで定義され、Ingress コントローラーによって実装されたルールに従ってのみ、そのアプリのポッドに要求を転送します。

IngressController のカスタムリソースを確認することで、Ingressオペレーターのステータスを確認できます。 IBM Cloud の「 Red Hat OpenShift 」では、Ingress オペレーターはプラットフォームによって管理されており、そのポッドには直接アクセスできません。その代わりに、 IngressController のリソースステータスを確認して、オペレーターの正常動作状態を確認してください。
1. デフォルトの IngressController について説明し、「 Conditions 」セクションを確認して、 False または Unknown のステータスエントリとそのメッセージがないか確認してください。
```
    oc describe ingresscontroller/default -n openshift-ingress-operator
    ```
2. `IngressController` のリソースをすべて一覧表示し、パフォーマンスが低下している状態にあるものがないことを確認します。
```sh {: pre}
    oc get ingresscontrollers -n openshift-ingress-operator
    ```
```

Ingress コントローラー・ポッドのステータスとログを確認します。

クラスター内で実行されている Ingress コントローラー・ポッドを取得します。

    oc get pods -n openshift-ingress
    ```
2. 他のゾーンの Ingress コントローラーのすべての `router-default` ポッドとポッドが **STATUS** 列を確認して、実行されていることを確認します。 マルチゾーン・クラスターを使用している場合は、ワーカー・ノードが存在する最初のゾーンにあるIngress コントローラー・サービスの名前は常に `router-default` になり、その後でクラスターに追加するゾーンでは、Ingress コントローラー・サービスの名前は `router-dal12` になります。

3. `Running` 状況でないポッドがある場合、そのポッドを削除して再始動することができます。
```sh {: pre}
    oc delete pod <pod> -n openshift-ingress
    ```
4. 各ポッドのログを取得し、ログにエラー・メッセージがあるかどうかを確認します。
```sh {: pre}
    oc logs <pod> -n openshift-ingress
    ```

各 Ingress コントローラー・サービスのイベントとエラーを確認します。

openshift-ingress 名前空間内のサービスをリストします。

    oc get svc -n openshift-ingress
    ```
    `dal10` および `dal13` のワーカー・ノードを持つ複数ゾーン・クラスターの出力例:
    ```sh {: screen}
    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
    router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
    router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d
    ```
2. 各 Ingress コントローラー・サービスを記述し、出力の `Events` セクションでメッセージを確認します。
```sh {: pre}
    oc describe svc router-default -n openshift-ingress
    ```
    例えば、VPC クラスターに、「`The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline`」のようなエラー・メッセージが表示されることがあります。 詳しくは、[VPC クラスター: ロード・バランサー経由でアプリを接続できないのはなぜですか? ](/docs/openshift?topic=openshift-vpc_ts_lb)を参照してください。

ステップ 3：Ingress サブドメインおよび Ingress コントローラーのパブリック IP アドレスに対して ping を実行する

Ingress コントローラーのパブリック IP アドレスが使用可能であることを確認し、サブドメイン・マッピングを検証します。さらに、Red Hat OpenShift コントロール・プレーンが Ingress コントローラーにアクセスしてヘルス・チェックを実行できることを確認してください。

Ingress コントローラーのロードバランサーが、Ingress のヘルスチェックから到達可能であることを確認してください。
- 基本事項 ： Calico のプレDNATネットワークポリシーやその他のカスタムファイアウォールを使用して、クラスターへのトラフィックまたはクラスターからのトラフィックをブロックしている場合（「 Calico のプレDNATポリシーの作成」チュートリアルを含む）、以下の点に注意してください
  - クラスタのワーカーから（ヘルスチェックはそこから送信されるため）、ポート443におけるALBのIPアドレスへのインバウンドアクセスを許可する必要があります
  - また、クラスタのワーカーからALBのIPアドレスへのポート443へのアウトバウンドアクセスを許可する必要があります
- VPC ：クラスターのVPCセキュリティグループ、またはサブネットのVPCネットワークACLのいずれかをカスタマイズしている場合。
  - VPCのセキュリティグループおよびネットワークACLにおいて、クラスタのワーカーノード（ヘルスチェックはそこから送信されるため）からのポート443への、Ingress VPCロードバランサー（ LBaaS ）のIPアドレスへのインバウンドアクセスが許可されていることを確認する必要があります
  - また、VPCのセキュリティグループおよびネットワークACLが、クラスターのワーカーから LBaaS のアドレス（ポート443）へのアウトバウンドアクセスを許可するように設定する必要があります
  - この作業を行う際は、VPCの LBaaS のアドレス（デフォルトのALBを使用している場合）が変更される可能性があることにご注意ください。
Ingress コントローラー・サービスが listen している外部 IP アドレスを取得します。複数ゾーン・クラスターの場合、ワーカー・ノードがある最初のゾーンの Ingress コントローラー・サービスの名前は常に router-default になり、その後クラスターに追加するゾーンの Ingress コントローラー・サービスの名前は router-dal12 になることに注意してください。 VPC クラスターでは、外部 IP アドレスに、VPC ロード・バランサーによって割り当てられるホスト名 (aabb1122-us-south.lb.appdomain.cloud など) が紐付けられます。
```
oc get svc -n openshift-ingress
```
dal10 および dal13 のワーカー・ノードを持つ複数ゾーンのクラシック・クラスターの出力例:
```
NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d
```
Ingress コントローラーに外部 IP アドレス（クラシック）またはホスト名（VPC）がない場合は、「バージョン 4：Ingress コントローラーがゾーンにデプロイされないのはなぜですか？」を参照してください。
Ingress コントローラー・ポッド (クラシック) またはホスト名 (VPC) の正常性を確認します。
- クラシック・クラスター: Ingress コントローラー・ポッドのステータスを確認します。
- VPC クラスター: マルチゾーン・クラスターのルーター・サービスは、/healthz パスを使用して作成されるため、各サービス IP アドレスの正常性を確認できます。以下の HTTP cURL コマンドでは、/healthz パスを使用しており、IP が正常な場合に ok 状況が返されます。
```
curl -X GET http://<router_svc_IP_or_hostname>/healthz -H "Host:router-default.<ingress_subdomain>"
```
1 つ以上の IP アドレスが ok を返さない場合は、Ingress コントローラー・ポッドのステータスを確認します。

IBM 提供の Ingress サブドメインを取得します。

ibmcloud oc cluster get --cluster <cluster_name_or_ID> | grep Ingress

出力例:

Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

Ingress コントローラーの IP アドレスが、クラスターの IBM が提供する Ingress サブドメインに登録されていることを確認します。例えば、複数ゾーン・クラスターでは、ワーカー・ノードがある各ゾーンのパブリック Ingress コントローラー IP を同じサブドメインに登録する必要があります。
```
host <ingress_subdomain>
```
出力例:
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XXX.XX
```

カスタム・ドメインを使用する場合は、DNS プロバイダーを使用して、カスタム・ドメインを IBM が提供するサブドメインまたは Ingress コントローラーのパブリック IP アドレスにマップしたことを確認します。

IBM 提供のサブドメインの CNAME: 正規名レコード (CNAME) でクラスターの IBM 提供のサブドメインにカスタム・ドメインがマップされていることを確認します。

    host www.my-domain.com
    ```
    出力例:
    ```sh {: screen}
    www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    ```
* **パブリック IP アドレスの A レコード**: カスタム・ドメインが、A レコード内の Ingress コントローラーのポータブル・パブリック IP アドレスにマップされていることを確認します。
```sh {: pre}
    host www.my-domain.com
    ```
    出力例:
    ```sh {: screen}
    www.my-domain.com has address 169.XX.XX.XXX
    www.my-domain.com has address 169.XX.XX.XXX
    ```