Ingress のデバッグ

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

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

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

始める前に、 IBM Cloud Kubernetes Serviceの以下の IBM Cloud IAM アクセス・ポリシーがあることを確認してください。

クラスターに対する エディター または 管理者 のプラットフォーム・アクセス役割
ライター または マネージャー サービス・アクセス役割

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

ステップ 1: アプリ・デプロイメントおよび Ingress リソース構成を確認する

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

Ingress をデバッグする前に、まず、アプリ・デプロイメントのデバッグを確認してください。多くの場合、Ingress の問題は、アプリ・デプロイメントや、アプリを公開する ClusterIP サービスの根本的な問題が原因で発生します。例えば、アプリのラベルとサービスのセレクターが一致していない、アプリとサービスのターゲット・ポートが一致していないなどの問題があります。

Ingress リソースのデプロイメントを確認して、警告またはエラー・メッセージがないか探します。

oc describe ingress <ingress_resource_name>

出力の Events セクションに、Ingress リソースや使用した特定のアノテーション内の無効な値に関する警告メッセージが表示される場合があります。アノテーションについては、IBM Cloud Kubernetes Serviceアノテーション（ingress.bluemix.net/<annotation>）とNGINXアノテーション（nginx.ingress.kubernetes.io/<annotation>）は、Red Hat OpenShiftバージョン4のIngressコントローラとIngressリソースではサポートされていないことに注意してください。 Red Hat OpenShift バージョン 4 を実行するクラスター内のアプリのルーティング・ルールをカスタマイズする場合は、 haproxy.router.openshift.io/<annotation> または router.openshift.io/<annotation> の形式の route-specific HAProxy アノテーションを使用できます。

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:
    custom-port:        protocol=http port=7490; protocol=https port=4431
    location-modifier:  modifier='~' serviceName=myservice1;modifier='^~' serviceName=myservice2
Events:
    Type     Reason             Age   From                                Message
    ----     ------             ----  ----                                -------
    Warning  TLSSecretNotFound  1m    router-default-69d6f598f8-vn8tj     Failed to apply ingress resource.
    Warning  AnnotationError    2s    router-default-69d6f598f8-vn8tj     Failed to apply ingress.bluemix.net/custom-port annotation.
    Warning  TLSSecretNotFound  1m    router-dal10-y2d4359tf4-g4ar7       Failed to apply ingress resource.
    Warning  AnnotationError    2s    router-dal10-y2d4359tf4-g4ar7       Failed to apply ingress.bluemix.net/custom-port annotation.

Ingress リソース構成ファイルを確認します。
```
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: Diagnostics and Debug Tool を使用した Ingress テストを実行する

IBM Cloud Kubernetes Service Diagnostics and Debug Tool を使用して、Ingress テストを実行し、クラスターから Ingress の関連情報を収集します。このデバッグ・ツールを使用するには、クラスターで該当するアドオンを有効にします。

Red Hat OpenShiftクラスター・コンソールで、デバッグ・ツール・アドオンをインストールするクラスター名をクリックします。
Diagnostics and Debug Tool カードの**「インストール」**をクリックします。
ダイアログ・ボックスで、**「インストール」**をクリックします。アドオンがインストールされるまでに数分かかることがあります。アドオンのデプロイメント中に発生する可能性があるいくつかの一般的な問題を解決するには、アドオンの状態と状況の確認を参照してください。
Diagnostics and Debug Tool カードの**「ダッシュボード」**をクリックします。
デバッグ・ツール・ダッシュボードで、テストの**「ingress」**グループを選択します。潜在的な警告、エラー、または問題を検査するテストもあれば、トラブルシューティング中に参照できる情報を収集するだけのテストもあります。各テストの機能について詳しくは、テストの名前の隣にある情報アイコンをクリックしてください。
「実行 (Run)」 をクリックします。
各テストの結果を確認します。
- テストに失敗した場合は、テスト名の横にある情報アイコンをクリックして、問題の解決方法に関する情報を確認します。
- 以下のセクションで Ingress サービスをデバッグする際に、情報を収集するだけのテストの結果も使用できます。

ステップ 3: Ingress コントローラーの正常性を確認する

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

Ingress オペレーター・ポッドの状況を確認します。
1. クラスター内で稼働している Ingress オペレーター・ポッドを取得します。
```
oc get pods -n openshift-ingress-operator
```
2. STATUS 列を確認して、すべてのポッドが実行されていることを確認します。
3. Running 状況でないポッドがある場合、そのポッドを削除して再始動することができます。
```
oc delete pod <pod> -n openshift-ingress-operator
```
4. Ingress オペレーターのログを取得し、ログでエラー・メッセージを探します。
```
oc logs deployments/ingress-operator -n openshift-ingress-operator -c ingress-operator
```
Ingress コントローラー・ポッドのステータスとログを確認します。
1. クラスター内で実行されている Ingress コントローラー・ポッドを取得します。
```
oc get pods -n openshift-ingress
```
2. 他のゾーンの Ingress コントローラーのすべての router-default ポッドとポッドが STATUS 列を確認して、実行されていることを確認します。マルチゾーン・クラスターを使用している場合は、ワーカー・ノードが存在する最初のゾーンにあるIngress コントローラー・サービスの名前は常に router-default になり、その後でクラスターに追加するゾーンでは、Ingress コントローラー・サービスの名前は router-dal12 になります。
3. Running 状況でないポッドがある場合、そのポッドを削除して再始動することができます。
```
oc delete pod <pod> -n openshift-ingress
```
4. 各ポッドのログを取得し、ログにエラー・メッセージがあるかどうかを確認します。
```
oc logs <pod> -n openshift-ingress
```
各 Ingress コントローラー・サービスのイベントとエラーを確認します。
1. openshift-ingress 名前空間内のサービスをリストします。
```
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
```
2. 各 Ingress コントローラー・サービスを記述し、出力の Events セクションでメッセージを確認します。
```
oc describe svc router-default -n openshift-ingress
```
  - 例えば、VPC クラスターに、「The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline」のようなエラー・メッセージが表示されることがあります。詳しくは、VPC クラスター: ロード・バランサー経由でアプリを接続できないのはなぜですか? を参照してください。

ステップ 4: Ingress サブドメインと Ingress コントローラーのパブリック IP アドレスに ping する

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

Ingress コントローラー・サービスが Ingress コントローラー・ヘルス・チェックによって到達可能であることを確認します。
- クラシック: Calico pre-DNAT ネットワーク・ポリシーまたは別のカスタム・ファイアウォールを使用してクラスターへの着信トラフィックをブロックする場合は、Red Hat OpenShift コントロール・プレーンおよび Akamai の IPv4 IP アドレスから Ingress コントローラー・サービスの IP アドレスへポート 80 または 443 でインバウンド・アクセスを許可して、Red Hat OpenShift コントロール・プレーンが Ingress コントローラーの正常性を確認できるようにする必要があります。たとえば、Calicoポリシーを使用する場合は、ポート 80 およびクラスタが配置されている地域のコントロールプレーンサブネットで Ingress コントローラーの健全性をチェックするために使用されるアカマイのソース IP アドレスから、Ingress コントローラーへのインバウンドアクセスを許可する Calicopre-DNAT ポリシーを作成します。次のステップに進んで、Ingress コントローラーのサービス IP アドレスを取得します。
- VPC: VPCのLBaaSLoadBalancer-as-a-Service）インスタンスでクラスタのイングレスにカスタムセキュリティグループを設定している場合は、セキュリティグループのルールがKubernetesのコントロールプレーンのIPアドレスから443番ポートへのヘルスチェックに必要なトラフィックを許可していることを確認してください。
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
```
  出力例
```
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 アドレスにマップされていることを確認します。
```
host www.my-domain.com
```
  出力例
```
www.my-domain.com has address 169.XX.XX.XXX
www.my-domain.com has address 169.XX.XX.XXX
```