製品アップデート情報
製品に関するお知らせ
ヘルスチェック異常調査v2
Cloud Load Balancer（CLB）はヘルスチェックを通じてバックエンドサービスの可用性を判断します。ヘルスチェックに異常が発生した場合、以下の方法を参照して調査することができます。
説明：
ヘルスチェックで異常が検出された場合、CLB は異常なバックエンドサービスにトラフィックを転送しなくなります。
すべてのバックエンドサービスに異常が検出された場合、リクエストはすべてのバックエンドサービスに転送されます。
ヘルスチェックの原理については、ヘルスチェック概要を参照してください。
1. CVM のセキュリティグループおよび ACL ブロックの調査
注意：
セキュリティグループがデフォルトでインターネットにオープンするように設定されている場合は無視できます。
ステップ1：インスタンスのヘルスチェックソース IP の確認
1. CLB コンソールにログインし、ヘルスチェックソース IP の確認を必要とするインスタンス IDをクリックしてください。
2. インスタンス詳細ページで、リスナー管理タブをクリックし、リスナーをクリックして、右側のリスナーの詳細を展開します。
3. リスナー詳細ページで現在のヘルスチェックソース IP を確認できます。上記の例では、ヘルスチェックソース IP は 100.64.0.0/10 の IP レンジです。
ステップ2：セキュリティグループがヘルスチェックソース IP をインターネットにオープンすることを確認
1. CLB コンソールにログインし、CLB インスタンス IDをクリックします。
2. CLB 例の詳細ページで、セキュリティグループタブをクリックし、紐付けられているセキュリティグループ IDをクリックしてセキュリティグループルールページに移動します。
3. インバウンドルールタブで、ルールの追加をクリックします。
4. インバウンドルール追加ウィンドウで、ソースにインスタンスヘルスチェックソース IP チェックするの 100.64.0.0/10 IP レンジを入力します（ステップ 1 で確認したヘルスチェックソース IP が CLB VIP の場合、その VIP をソースに入力する）。プロトコルポートにはバックエンドサーバーが使用するプロトコルポートを入力し、ポリシーは許可を選択し、確定をクリックして追加を完了します。
ステップ3：サブネットのネットワーク ACL がヘルスチェックソース IP をインターネットにオーペンすることを確認
1. CVM コンソールにログインし、CVM インスタンスをクリックして基本情報ページに入ります。
2. 基本情報ページで、ネットワーク情報モジュールの所属サブネットをクリックして、サブネット情報ページに移動します。
3. ACL ルールタブをクリックし、このページで紐付けられている ACL をクリックし、インバウンドルールとアウトバウンドルールでヘルスチェックソース IP をインターネットにオーペンします。
4. ステップ 1 で確認したヘルスチェックソース IP が 100.64.0.0/10 IP レンジの場合（確認したヘルスチェックソース IP がCLB VIPの場合）、その VIP をソース IP に入力し、プロトコルタイプはヘルスチェック方式で選択したプロトコルを入力し、ポートはALLと記入し、ポリシーを許可を選択し、保存をクリックして追加を完了します。
説明：
CLB が COS、CDB、Redis、Ckafka などの公共サービスと紐付けられている場合、サービスが紐付けられているセキュリティグループおよび所属しているサブネットのネットワーク ACL が CLB ヘルスチェックソース IP をインターネットにオーペンしているかを確認する必要があります。上記の 3 つのステップを参照して調査することができます。
ステップ4：IDC が SNAT IP をインターネットにオーペンすることを確認
ユーザーが CCN または DC 製品を介して IDC 内のマシンを CLB インスタンスのバックエンドサーバーとして紐付けている場合、IDC が SNAT IP をインターネットにオーペンしていることを確認する必要があります。
1. CLB コンソールにログインし、CLBインスタンス IDをクリックします。
2. インスタンス基本情報ページで、バックエンドサービスモジュールで SNAT IP を確認します。
3. ユーザーは、IDC 内のファイアウォールデバイスまたはマシンの iptables がその SNAT IP をインターネットにオーペンしているかどうかを確認する必要があります。
二、CVM の調査
バックエンドサーバーが CVM である場合、以下のステップを参照して調査を行います。
ステップ1：マシン内部のセルフチェック
1. CVM コンソールにログインし、マシン内部に入り、サーバー側のプロセスとポートを確認します。
CLB 設定に対応するバックエンドサーバーポートを確認します。例はポート 80 のチェックコマンドです。
netstat -anltu | grep -w 80
2. もしポート 80 がリスニング状態であると返された場合、マシン内部の異常を除外できます。
注意：
リスニングアドレスは 0.0.0.0 または CVM のプライベートネットワーク IP でなければなりません。リスニングアドレスが 127.0.0.1 のみである場合、マシン内部の異常を除外できません。
tcp 0 0 0.0.0.0:80 0.0.0.0:*LISTEN 9/nginx: master protcp6 0 0 :::80 :::*LISTEN 9/nginx: master pro
ステップ2：CVM が正常に応答するかどうかを確認します
1. 同じ VPC 内の他のマシンを使用利用し、ターゲット CLB のバックエンド CVM の HTTP/HTTPS ポートが正常に応答するかどうかを確認します。
例えば、CLBコ ンソールで設定された location ディレクトリが「/」であり、HTTP ポートがバックエンド CVM のプライベートネットワーク IP を確認する場合、IP 10.0.0.16、ポート 80 を例とします。
curl -I http://10.0.0.16:80/
2. 実際の応答結果が正常かどうかを判断するには、コンソールで設定された応答状態コードを基準とします。例えば設定された応答状態コードが「200」または「404」の場合、その応答結果は正常であり、この異常点を除外できます。
HTTP/1.1 200 OKServer: nginx/1.20.1Date: Sat, 14 Sep 2024 07:07:01 GMTContent-Type: text/html
HTTP/1.1 404 Not FoundServer: nginx/1.20.1Date: Sat, 14 Sep 2024 07:08:51 GMTContent-Type: text/html
ステップ3：iptables がインターネットにオーペンしているかを確認
1. 確認方法は以下を参照してください：ファイアウォールの問題。確認コマンドは以下の通りです。
iptables -nvL
2. ブロックされていることを確認した場合、ヘルスチェックソース IP および CLB リスナーで設定されたバックエンドサーバーポートをインターネットにオーペンするコマンドを追加する必要があります。ヘルスチェックソース IP が 100.64.0.0/10、バックエンドサーバーポートがポート 80 および 443 であることを例します。
iptables -A INPUT -p tcp -s 100.64.0.0/10 --dport 80 -j ACCEPTiptables -A INPUT -p tcp -s 100.64.0.0/10 --dport 443 -j ACCEPTiptables -A INPUT -p icmp -s 100.64.0.0/10 -j ACCEPT
異なる Linux に基づき以下のコマンドを実行します。
#Centos/RHEL：sudo systemctl enable iptablessudo service iptables save
#Ubuntu/Debian：sudo systemctl enable netfilter-persistentsudo netfilter-persistent save
3. インターネットにオーペンした後、再度確認コマンドを実行して調査を行います。
説明：
バックエンドプロトコルが HTTPS のシナリオでは、ヘルスチェックの異常を避けるために HTTP に変更することをお勧めします。
ビジネスバックエンドが HTTPS プロトコルの使用を要求する場合、Nginx サーバー SSL 証明書のインストールおよび配置（Linux）を参照して SSL 設定と確認を行ってください。問題が解決されていない場合は、作業依頼書を提出することをお勧めします。
CLB に HTTPS リスナーを設定し、バックエンドプロトコルが HTTPS の場合のみ、バックエンドサービスに証明書を設定する必要があります。
3. コンテナの調査
バックエンドサーバーがコンテナである場合、以下のステップを参考に調査を行います。TKE クラスターの紐づけを例とします。
TKE コンテナシナリオでは、CLB のバックエンドサーバーは直接接続 Pod と非直接接続（つまり、CLB が nodeport に紐付けられる）の 2 つのシナリオに分けられます。直接接続かどうかを判断する方法は以下の通りです。詳細については、LoadBalancer 直接接続 Pod モードを使用した Service-TKE 標準クラスターガイドをご参照ください。
service に service.cloud.tencent.com/direct-access: 「true」注釈が設定されている場合、直接接続です。
ingress に ingress.cloud.tencent.com/direct-access: 「true」注釈が設定されている場合、直接接続です。
ステップ1：CLB 直接接続 pod シナリオ
CLB 直接接続 pod のシナリオでは、CLB トラフィックは直接バックエンド pod に転送されます。
調査経路は以下の通りです。
1. コンテナ内のリスニングポートをチェックする
コンテナにログインした後、マシン内部のセルフチェックを参照してチェックを行います。
コンテナへのログイン方法は以下を参照してください：リモートターミナルの基本操作。
2. コンテナ自身へのローカルアクセスが正常であることをチェックする
コンテナにログインした後、 CVM が正常に応答できるかをチェックするを参照してチェックを行います。
コンテナへのログイン方法は以下を参照してください：リモートターミナルの基本操作。
3. pod が存在する node から podへ のアクセスが正常かどうかをチェックする
pod がスーパーノードで動作していない場合、node にログインして、 手動テストを参照してください。
通常のノードのログイン方法は以下を参照してください：標準的なログイン方式での Linux インスタンスへのログイン(推奨)。
ネイティブノードのログイン方法は以下を参照してください：ネイティブノードで SSH キーログインを有効にする。
4. node 内部設定のチェック
4.1 ip_forward のチェック
チェックコマンドを入力（IPv6 の場合は、コマンド内の ipv4 を ipv6 に置き換えてください）：
sysctl net.ipv4.ip_forward
正常な結果：
net.ipv4.ip_forward = 1
異常な結果：
net.ipv4.ip_forward = 0
異常な結果に対する解決コマンド：
sysctl -w "net.ipv4.ip_forward=1" && echo 'net.ipv4.ip_forward=1' >>/etc/sysctl.conf
4.2 ENI の forward のチェック
チェックコマンドを入力：
sysctl -a 2>/dev/null | grep ipv4 | grep -w forwarding
正常な結果のすべてのパラメーター値は 1 であり、例えば：
net.ipv4.conf.all.forwarding = 1
正常な結果の完全な例：
異常な結果に 0 のパラメーター値が存在し、例えば：
net.ipv4.conf.all.forwarding = 0
異常な結果を処理するコマンド。例えば：（実際の異常な net.xxx.forwarding 項目に基づいて以下のコマンドを実行する）
sysctl -w net.ipv4.conf.all.forwarding=1
4.3 node の iptables が forward をブロックしているかをチェックする
チェックコマンドを入力：
iptables -nvL FORWARD
出力結果：
policy の後のポリシーは ACCEPT であるべきです。DROP の場合、forward のブロックにつながる可能性があります。
KUBE-FORWARD、KUBE-SERVICES、KUBE-EXTERNAL-SERVICES、DOCKER-USER の 4 つのルールのみがあります。その他のルールがある場合、forward のブロックにつながる可能性があります。
以下は正常な例です。
4.4 セキュリティグループがインターネットにオーペンしているかをチェックする
pod が vpc-cni モードの場合、node の ENI のセキュリティグループがインターネットにオーペンしているか確認します。そうでない場合は node 自体のセキュリティグループがインターネットにオーペンしているかを確認する必要があります。
CLB がデフォルトでインターネットにオーペンすることを有効にするか、セキュリティグループがヘルスチェックソース IP をインターネットにオーペンすることをチェックするを参照してインターネットにオーペンしてください。
ステップ2：CLB 非直接接続のシナリオ
CLB 非直接接続のシナリオでは、CLB トラフィックはまずクラスター内の node の nodeport ポートに転送され、次に iptables/ipvs 経由で転送され、最終的に nodeport のトラフィックは実際のバックエンド pod に転送され、リンクは長いです。
調査経路：
1. CLB 直接接続 pod シナリオの関連内容をチェックする
CLB 直接接続 pod シナリオの関連内容をチェックし、それに基づいて以降のチェックステップを完了します。
2. node のセキュリティグループのインターネットオーペン状況をチェックする
ノードのセキュリティグループと VPC-CNI モードの pod のセキュリティグループが以下のドキュメントを参照してインターネットにオーペンしているかを確認します：コンテナサービスセキュリティグループ設定。
一般ノードのセキュリティグループ設定は次を参照してください：セキュリティグループの設定。
ネイティブノードのセキュリティグループ設定は次を参照してください：ネイティブノードの変更。
スーパーノードのセキュリティグループ設定は次を参照してください：スーパーノードの新規作成 と スーパーノードのスケジューリング可能な Pod の説明。
VPC-CNI モードの pod のセキュリティグループ設定は次を参照してください：VPC-CNI モードセキュリティグループの使用説明。
3. ヘルスが異常であるノード上の kube-proxy コンポーネントが正常に動作しているかをチェックする
kube-proxy コンポーネントは iptables/ipvs ルールの発行に使用されます。チェック方法は次の通りです。
# ノード上の kube-proxy pod を取得し、Ready であるかどうかをチェックしますkubectl get pod -n kube-system -l k8s-app=kube-proxy -owide | grep <ノード名># kube-proxy の実行ログに明らかなエラーがないかをチェックしますkubectl logs -n kube-system <kube-proxy-xxxxx名>
4. ヘルスチェックが異常である CLB バックエンドノードにログインし、バックエンド pod に逐一アクセスする
TCP リスニングは telnet で接続性をテストし、HTTP/HTTPS リスナーは curl でアクセス結果をテストできます。詳細については、TCP サービスの接続性をチェックする、HTTP/HTTPS サービスの応答をチェックする を参照してください。
手動テストの補足説明
ステップ1：ポートリスニング状態をチェックする
netstat、ss などのコマンドでポートのリスニング状態を確認できます。リスニングアドレスが 127.0.0.1 のみである場合は、異常を除外できません。
1. netstat コマンドを使用してポートがリスニング状態にあるかを確認します。ここでは、ポート 80 を例とします。
netstat -tulnp | grep 80
以下の内容が出力されている場合は、リスニング状態とみなされます。
tcp 0 0 0.0.0.0:80 0.0.0.0:*LISTEN 9/nginx: master protcp6 0 0 :::80 :::*LISTEN 9/nginx: master pro
2. ss コマンドでポートがリスニング状態にあるかを確認します。ここでは、ポート 80 を例とします：
ss -tulnp | grep 80
以下の内容が出力されている場合は、リスニング状態とみなされます。
tcp LISTEN 0 511 *:80 *:*users:(("nginx",pid=9,fd=6))tcp LISTEN 0 511 [::]:80 [::]:*users:(("nginx",pid=9,fd=8))
ステップ2：TCP サービスの接続性をチェックする
telnet コマンドを使用して TCP サービスの接続性を確認できます。
注意：
接続が正常であるかどうかにかかわらず応答がないので、低バージョンの busybox の telnet を使用してテストしないでください。
IP 172.16.1.29 のポート 80 の確認を例とします。
echo "" |telnet 172.16.1.29 80
出力が Connected であるばあいは正常に接続されています。Trying にとどまる場合は、ネットワークに問題があり、セキュリティグループなどをチェックする必要があります（詳しくはサブネットのネットワーク ACL がヘルスチェックソース IP をインターネットにオーペンすることを確認する、iptables がインターネットにオーペンしているかどうかをチェックするのセクションを参照してください）。Connection refused が返された場合、ポートがリスニングされていません。
Trying 172.16.1.29...Connected to 172.16.1.29.Escape character is '^]'.Connection closed by foreign host.
ステップ3：HTTP/HTTPS サービスの応答をチェックする
curl コマンドでサービスが返した HTTP 状態コードを確認できます。
リクエストプロトコル HTTP、メソッド GET、ドメイン名が mydomain.com、パス/health、ポート 8080、IP 172.16.1.29 を例とします。
curl -X GET -H "Host: mydomain.com" http://172.16.1.29:8080/health -s -o /dev/null -w "\\nhttpcode: %{http_code}\\n"
応答結果：
httpcode: 404
ヘルスチェック設定の正常な状態コードで期待される応答 1xx-4xx を選択した場合、上記の応答結果が 404 であれば期待通りです。応答結果がヘルスチェック設定の期待を満たしていませんが、実際には正常である場合は、期待設定の調整をお勧めします。
フィードバック