Ingress のデバッグ

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

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

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

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

ステップ 1: アプリ・デプロイメントを確認する

Ingress をデバッグする前に、まず、アプリ・デプロイメントのデバッグを確認してください。

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

ステップ 2: Ingress デプロイメントと ALB ポッドのログでエラー・メッセージを確認する

まず、Ingress リソースのデプロイメント・イベントと ALB ポッドのログでエラー・メッセージを確認します。これらのエラーメッセージは、障害の根本原因を特定し、以下のセクションでIngressの設定をさらにデバッグする上で役立ちます。

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

kubectl describe ingress <myingress>

出力の Events セクションに、Ingress リソースや使用した特定のアノテーション内の無効な値に関する警告メッセージが表示される場合があります。 Ingress（ NGINX ）ベースのALBについては、 Ingressリソースの設定に関するドキュメント、またはアノテーションに関するドキュメントをご確認ください。 Traefik ベースの ALB については、 Ingress リソース設定に関するドキュメントまたは Ingress Controller の設定ドキュメントを参照してください。

NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  <default>
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:                                         <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync

ALB ポッドの状況を確認します。

クラスター内で稼働している ALB ポッドを取得します。

    kubectl get pods -n kube-system | grep alb
    ```
2. **STATUS** 列を確認して、すべてのポッドが実行されていることを確認します。

3. ポッドの状況が `Running` になっていない場合は、ALB を無効にして再度有効にすることができます。 以下のコマンドで、`<ALB_ID>` をポッドの ALB の ID に置き換えます。 例えば、稼働していないポッドの名前が `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z` の場合、ALB ID は `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1` です。
    * クラシック・クラスター:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
    * VPC クラスター:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>
        ```

ALB のログを確認します。

クラスター内で稼働している ALB ポッドの ID を取得します。

    kubectl get pods -n kube-system | grep alb
    ```
1. Ingress（ NGINX ）ベースのALBについては、各ALBポッド上の `nginx-ingress` コンテナのログを取得してください。 Traefik ベースの ALB については、各 ALB ポッド上の「 `traefik` 」コンテナのログを取得します。
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. ALB ログでエラー・メッセージを確認します。

ステップ 3: ALB サブドメインとパブリック IP アドレスに ping する

Ingress サブドメインと ALB のパブリック IP アドレスの可用性を確認します。また、 IBM （ NS1 ）がALBにアクセスしてヘルスチェックを実行できることを確認してください。

パブリック ALB が listen している IP アドレス (クラシック) またはホスト名 (VPC) を取得します。

ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

dal10 および dal13 のワーカー・ノードを持つ複数ゾーンのクラシック・クラスターの出力例:

ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
private-cr24a9f2caf6554648836337d240064935-alb1   false     disabled   private   -               dal13   ingress:1.1.2_2507_iks   2294021       -
private-cr24a9f2caf6554648836337d240064935-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
public-cr24a9f2caf6554648836337d240064935-alb1    true      enabled    public    169.62.196.238  dal13   ingress:1.1.2_2507_iks   2294019       -
public-cr24a9f2caf6554648836337d240064935-alb2    true      enabled    public    169.46.52.222   dal10   ingress:1.1.2_2507_iks   2234945       -

パブリック ALB に IP アドレス (クラシック) またはホスト名 (VPC) が指定されていない場合は、Ingress ALB がゾーンにデプロイされないを参照してください。

ALB のヘルス・チェックで、ALB の IP アドレスが到達可能であることを確認します。
- 基本事項 ： Calico のDNAT前のネットワークポリシーやその他のカスタムファイアウォールを使用してクラスターへの着信トラフィックをブロックしている場合、 Kubernetes コントロールプレーンがALBのヘルス状態を確認できるように、 Kubernetes および IBM NS1 の IPv4 のIPアドレスから、ALBのIPアドレスへのポート80または443での着信アクセスを許可する必要があります。たとえば、 Calico ポリシーを使用する場合は、「 Calico 」というプレDNATポリシーを作成し、 IBM NS1 の送信元IPアドレスからのポート80へのALB IPアドレスへのインバウンドアクセス、およびクラスターが配置されているリージョンのコントロールプレーンサブネットからのアクセスを許可するように設定します。
- VPC ：クラスターのインジェス用に、VPC内の LBaaS （ LoadBalancer-as-a-Service ）インスタンスにカスタムセキュリティグループを設定している場合は、セキュリティグループのルールで、 Kubernetes のコントロールプレーンIPアドレスからポート443への必要なヘルスチェックトラフィックが許可されていることを確認してください。

ALB IP (クラシック) またはホスト名 (VPC) の正常性を確認します。

各パブリックALBのIPアドレス（従来型）またはホスト名（VPC）に対してpingを実行し、各ALBがパケットを正常に受信できることを確認します。プライベート ALB を使用している場合は、プライベート・ネットワークからのみ IP アドレス (クラシック) またはホスト名 (VPC) を ping できます。

    ping <ALB_IP>
    ```
    * CLI がタイムアウトを返し、ワーカー・ノードを保護するカスタム・ファイアウォールがある場合は、ファイアウォールで ICMP を許可していることを確認します。
    * ファイアウォールが存在していない、またはファイアウォールで ping をブロックしていないのに ping がタイムアウトになる場合は、[ALB ポッドの状況を確認](#check_pods)します。

* 複数ゾーン・クラスターの場合のみ: MZLB ヘルス・チェックを使用して、ALB の IP (クラシック) またはホスト名 (VPC) の状況を確認できます。 以下の HTTP cURL コマンドは、`albhealth` ホストを使用します。このホストは、IBM Cloud Kubernetes Service によって構成され、ALB IP の `healthy` または `unhealthy` の状況を返します。
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    コマンド例:
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    出力例
    ```sh {: screen}
    healthy
    ```
    1 つ以上の IP から `unhealthy` が返された場合は、[ALB ポッドの状況を確認してください。](#check_pods)>

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

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

出力例

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

このセクションのステップ 1 で取得した各パブリック ALB の IP (クラシック) またはホスト名 (VPC) が、クラスターの IBM 提供の Ingress サブドメインに登録されていることを確認します。例えば、マルチゾーンのクラシック・クラスターでは、ワーカー・ノードがある各ゾーンのパブリック ALB IP は、同じサブドメインで登録される必要があります。
```
kubectl get ingress -o wide
```
出力例
```
NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h
```

ステップ 4: ドメイン・マッピングと Ingress リソース構成を確認する

カスタム・ドメインを使用する場合は、DNS プロバイダーを使用してカスタム・ドメインを IBM 提供のサブドメインまたは ALB のパブリック IP アドレスにマップしていることを確認します。 IBM では IBM サブドメインに対する自動ヘルス・チェックを提供しており、障害のある IP がすべて DNS 応答から削除されるため、CNAME の使用がお勧めされることに注意してください。

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.46.52.222
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238
    ```
* **パブリック IP アドレスの A レコード**: A レコードで ALB のポータブル・パブリック IP アドレスにカスタム・ドメインがマップされていることを確認します。 IP は、[前のセクション](#ping)のステップ 1 で取得したパブリック ALB IP と一致する必要があります。
```sh {: pre}
    host www.my-domain.com
    ```
    出力例
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```

クラスターの Ingress リソース構成ファイルを確認します。
```
kubectl get ingress -o yaml
```
1. 1 つのホストは、必ず 1 つの Ingress リソースだけに定義するようにしてください。 1 つのホストが複数の Ingress リソースに定義された場合、ALB はトラフィックを正しく転送しないことがあり、その場合エラーが発生する場合があります。
2. サブドメインと TLS 証明書が正しいことを確認します。 IBM 提供の Ingress サブドメインと TLS 証明書を見つけるには、ibmcloud ks cluster get --cluster <cluster_name_or_ID> を実行します。
3. アプリが、Ingress の path セクションで構成されているパスを使用して listen していることを確認します。アプリがルート・パスで listen するようにセットアップされている場合は、/ をパスとして使用します。このパスへの着信トラフィックを、アプリがリスニングしている別のパスにルーティングする必要がある場合は、 Ingress-NGINX に対してパスの書き換えアノテーションを使用してください。 Traefik では、 ReplacePath ミドルウェアを使用してください。
4. 必要に応じてリソース構成 YAML を編集します。エディターを閉じると、変更内容が保存され、自動的に適用されます。
```
    kubectl edit ingress <myingressresource>
    ```
```

Classic でのデバッグのために DNS から ALB を削除する

特定の ALB IP を介してアプリにアクセスできない場合は、その DNS 登録を無効にすることによって、一時的に ALB を実動から削除することができます。その後、ALB の IP アドレスを使用して、その ALB に対してデバッグ・テストを実行できます。

例えば、2 つのゾーンに複数ゾーン・クラスターがあり、2 つのパブリック ALB に IP アドレス 169.46.52.222 と 169.62.196.238 が指定されているとします。 2 番目のゾーンの ALB についてはヘルス・チェックで正常と返されますが、アプリがそこから直接到達することはできません。デバッグのために実動から ALB の IP アドレス 169.62.196.238 を削除します。 1 番目のゾーンの ALB IP 169.46.52.222 がドメインに登録され、2 番目のゾーンの ALB のデバッグ中にトラフィックのルーティングを続行します。

以下のコマンドを使用して、ドメイン名からIPアドレスを削除してください。 update コマンドは登録済みの IP アドレスをすべて上書きするため、コマンド内では正常な IP アドレスのみを指定する必要があります：
```
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222
```
IBM （ NS1 ）サーバーを確認し、ドメインのDNS登録からALBのIPアドレスが削除されていることを確認してください。 DNS 登録は更新に数分かかることがあります。
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net
```
正常な ALB IP (169.46.52.222) のみが DNS 登録に残っており、正常でない ALB IP (169.62.196.238) が削除されたことを確認できる出力例:
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
```
これで、ALB IP が実動から削除されたので、これを使用してアプリに対してデバッグ・テストを実行できます。この IP を使用してアプリとの通信をテストするには、次の cURL コマンドを、例の値を独自の値に置き換えて実行します。
```
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/
```
- すべてが正しく構成されていれば、アプリから予期される応答が返されます。
- 応答にエラーがある場合、アプリにエラーがあるか、この特定の ALB にのみ適用される構成にエラーがある可能性があります。アプリのコード、 Ingressのリソース設定ファイル（ Ingress- NGINX ）、 TraefikのIngress Controller設定ドキュメント、およびこのALBにのみ適用しているその他の設定を確認してください。

デバッグが完了したら、次のコマンドを使用して、ALBのDNS登録を復元してください

ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238

IBM （ NS1 ）サーバーを確認し、ドメインのDNS登録においてALBのIPアドレスが復元されていることを確認してください。 DNS 登録は更新に数分かかることがあります。

host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net

出力例

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238