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 リソース構成の資料またはアノテーションの資料を参照してください。
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 ---- ------ ---- ---- ------- Normal Success 1m public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Successfully applied ingress resource. Warning TLSSecretNotFound 1m public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Failed to apply ingress resource. Normal Success 59s public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Successfully applied ingress resource. Warning AnnotationError 40s public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Failed to apply ingress.bluemix.net/custom-port annotation. Error annotation format error : One of the mandatory fields not valid/missing for annotation ingress.bluemix.net/custom-port Normal Success 40s public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Successfully applied ingress resource. Warning AnnotationError 2s public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Failed to apply ingress.bluemix.net/custom-port annotation. Invalid port 7490. Annotation can't use ports 7481 - 7490 Normal Success 2s public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n Successfully applied ingress resource. -
ALB ポッドの状況を確認します。
-
クラスター内で稼働している ALB ポッドを取得します。
kubectl get pods -n kube-system | grep alb -
STATUS 列を確認して、すべてのポッドが実行されていることを確認します。
-
ポッドの状況が
Runningになっていない場合は、ALB を無効にして再度有効にすることができます。 以下のコマンドで、<ALB_ID>をポッドの ALB の ID に置き換えます。 例えば、稼働していないポッドの名前がpublic-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6zの場合、ALB ID はpublic-crb2f60e9735254ac8b20b9c1e38b649a5-alb1です。- クラシック・クラスター:
ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID> - VPC クラスター:
ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>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 - 各 ALB ポッドの
nginx-ingressコンテナーのログを取得します。kubectl logs <ingress_pod_ID> nginx-ingress -n kube-system - ALB ログでエラー・メッセージを確認します。
- クラスター内で稼働している ALB ポッドの ID を取得します。
ステップ 3: ALB サブドメインとパブリック IP アドレスに ping する
Ingress サブドメインと ALB のパブリック IP アドレスの可用性を確認します。 さらに、Akamai マルチゾーン・ロード・バランサーが 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 pre-DNAT ネットワークポリシーまたはその他のカスタムファイアウォールを使用してクラスターへの受信トラフィックをブロックしている場合は、 Kubernetes コントロールプレーンおよびアカマイの IPv4 IP アドレスから ALB の IP アドレスへのポート 80 または 443 によるインバウンドアクセスを許可し、 Kubernetes コントロールプレーンが ALB の健全性をチェックできるようにする必要があります。 たとえば、 Calico ポリシーを使用する場合、 Calico pre-DNAT ポリシーを作成し、ポート 80 の アカマイのソース IP アドレスおよび クラスタが配置されている地域のコントロールプレーンサブネットから 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 ポッドの状況を確認します。
-
複数ゾーン・クラスターの場合のみ: MZLB ヘルス・チェックを使用して、ALB の IP (クラシック) またはホスト名 (VPC) の状況を確認できます。 以下の HTTP cURL コマンドは、
albhealthホストを使用します。このホストは、IBM Cloud Kubernetes Service によって構成され、ALB IP のhealthyまたはunhealthyの状況を返します。curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"コマンド例:
curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"出力例
healthy1 つ以上の IP から
unhealthyが返された場合は、ALB ポッドの状況を確認してください。>
-
-
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.comwww.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 は、前のセクションのステップ 1 で取得したパブリック ALB IP と一致する必要があります。
出力例host www.my-domain.comwww.my-domain.com has address 169.46.52.222 www.my-domain.com has address 169.62.196.238
- IBM 提供のサブドメインの CNAME: 正規名レコード (CNAME) でクラスターの IBM 提供のサブドメインにカスタム・ドメインがマップされていることを確認します。
- クラスターの Ingress リソース構成ファイルを確認します。
kubectl get ingress -o yaml-
1 つのホストは、必ず 1 つの Ingress リソースだけに定義するようにしてください。 1 つのホストが複数の Ingress リソースに定義された場合、ALB はトラフィックを正しく転送しないことがあり、その場合エラーが発生する場合があります。
-
サブドメインと TLS 証明書が正しいことを確認します。 IBM 提供の Ingress サブドメインと TLS 証明書を見つけるには、
ibmcloud ks cluster get --cluster <cluster_name_or_ID>を実行します。 -
アプリが、Ingress の path セクションで構成されているパスを使用して listen していることを確認します。 アプリがルート・パスで listen するようにセットアップされている場合は、
/をパスとして使用します。 このパスへの着信トラフィックを、アプリが listen している別のパスにルーティングする必要がある場合は、再書き込みパス・アノテーションを使用します。 -
必要に応じてリソース構成 YAML を編集します。 エディターを閉じると、変更内容が保存され、自動的に適用されます。
kubectl edit ingress <myingressresource>
-
デバッグのための 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 アドレスを持つ ALB の名前を取得します。
ibmcloud ks ingress alb ls --cluster <cluster_name> | grep <ALB_IP>例えば、到達不能な IP
169.62.196.238は、ALBpublic-cr24a9f2caf6554648836337d240064935-alb1に属しています。ALB ID Enabled Status Type ALB IP Zone Build ALB VLAN ID NLB Version public-cr24a9f2caf6554648836337d240064935-alb1 false disabled private 169.62.196.238 dal13 ingress:1.1.2_2507_iks 2294021 - -
前のステップの ALB 名を使用して、ALB ポッドの名前を取得します。 以下のコマンドでは、前のステップの ALB 名の例を使用しています。
kubectl get pods -n kube-system | grep public-cr24a9f2caf6554648836337d240064935-alb1出力例
public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq 2/2 Running 0 24m public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-trqxc 2/2 Running 0 24m -
すべての ALB ポッドに対して実行されるヘルス・チェックを無効にします。 前のステップで取得した ALB ポッドごとに、これらのステップを繰り返します。 これらのステップのコマンドと出力の例では、1 番目のポッド
public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtqを使用しています。- ALB ポッドにログインして、NGINX 構成ファイルで
server_name行を確認します。kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- grep server_name /etc/nginx/conf.d/kube-system-alb-health.confalbhealth.<domain>で構成されていることを確認する出力例:server_name albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud; - ヘルス・チェックを無効にして IP を削除するには、
#の前にserver_nameを挿入します。 ALB のalbhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud仮想ホストが無効になっている場合、自動ヘルス・チェックにより、DNS 応答から IP が自動的に削除されます。kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- sed -i -e 's*server_name*#server_name*g' /etc/nginx/conf.d/kube-system-alb-health.conf - 変更が適用されたことを確認します。
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- grep server_name /etc/nginx/conf.d/kube-system-alb-health.conf#server_name albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud - DNS 登録から IP を削除するには、NGINX 構成を再ロードします。
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- nginx -s reload - ALB ポッドごとに、これらのステップを繰り返します。
- ALB ポッドにログインして、NGINX 構成ファイルで
-
ここで、
albhealthホストに cURL を実行して ALB IP をヘルス・チェックしようとすると、チェックが失敗します。curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"出力:
<html> <head> <title>404 Not Found</title> </head> <body bgcolor="white"><center> <h1>404 Not Found</h1> </body> </html> -
Akamai サーバーを調べて、ご使用のドメインの DNS 登録から ALB IP アドレスが削除されたことを確認します。 DNS 登録は更新に数分かかることがあります。
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud ada.ns.Akamai.com正常な 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 リソース構成ファイル、またはこの ALB のみに適用したその他の構成を確認します。
-
デバッグが完了したら、ALB ポッドに対するヘルス・チェックをリストアします。 ALB ポッドごとに、これらのステップを繰り返します。
- ALB ポッドにログインし、
#からserver_nameを削除します。kubectl exec -ti <pod_name> -n kube-system -c nginx-ingress -- sed -i -e 's*#server_name*server_name*g' /etc/nginx/conf.d/kube-system-alb-health.conf - ヘルス・チェックのリストアが適用されるように、NGINX 構成を再ロードします。
kubectl exec -ti <pod_name> -n kube-system -c nginx-ingress -- nginx -s reload
- ALB ポッドにログインし、
-
ここで、
albhealthホストに cURL を実行して ALB IP をヘルス・チェックすると、チェックでhealthyが返されます。curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud" -
Akamai サーバーを調べて、ご使用のドメインの DNS 登録で ALB IP アドレスがリストアされたことを確認します。 DNS 登録は更新に数分かかることがあります。
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud ada.ns.Akamai.com出力例
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