このセクションでは、Anthos Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
Anthos Service Mesh には 2 つの Webhook があります。
- Webhook を検証すると、適用された Istio 構成の有効性を確認できます。
- 変更を行う Webhook が、新しい Pod の自動サイドカー インジェクションを設定します。
これらの Webhook の構成に問題があると、新しい Pod が起動しないか、kubectl apply エラー メッセージが生成されます。
サイドカー インジェクションの問題
サイドカー インジェクションは、次のいずれかが表示される場合に正常に機能していません。
- サイドカーを使用せずにスケジューリングを行う Pod
kubectl get podsを使用している場合、サイドカーを挿入する必要がある Pod は表示されませんが、kubectl get replicasetから作成された対応するレプリカセットが存在します。
サイドカー インジェクションの問題のトラブルシューティングは、次の手順に沿って行います。
名前空間または Pod に正しいインジェクション ラベルがあることを確認します。
単一リビジョンの Istio（デフォルト）を実行している場合は、Namespace または Pod の仕様に istio-injection=enabled ラベルがあることを確認します。
複数のリビジョンの Istio（ダウンタイムのない移行、複数のコントロール プレーンなど）を実行している場合は、Namespace または Pod の仕様に適切な
istio.io/rev=<var>REVISION</var>ラベルがあることを確認します。REVISION は、選択した Anthos Service Mesh のバージョンに対応するistiodの Anthos Service Mesh のリビジョン番号です。リビジョン ラベルの詳細については、サイドカー プロキシの挿入をご覧ください。Istio サイドカー インジェクション Webhook が存在しており、CA バンドルがあることを確認します。
自動サイドカー インジェクションに使用されるサイドカー インジェクタ Webhook には、API サーバーと Istiod との安全な接続を確立するために CA バンドルが必要です。この CA バンドルは Istiod によって構成にパッチが適用されていますが、上書きされる（Webhook 構成を再適用した場合など）可能性があります。
CA バンドルが存在することは、次のコマンドを使用して確認できます。
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'出力が空でない場合、CA バンドルが構成されます。CA バンドルがない場合は、Webhook を再スキャンし、CA バンドルを再インストールできるように Istiod を再起動します。
サイドカー インジェクションの失敗を確認します。
インジェクションが有効になっていても、Pod のスケジューリングが表示されない場合は、次の上位の抽象化のステータスを確認します。たとえば、デプロイを実行しても Pod のスケジューリングが行われない場合は、次のコマンドを使用して、該当するレプリカセットのステータスを確認します。
kubectl -n my-namespace describe replicaset your-deployment-name
レプリカセットが存在する場合は、エラーの説明の下部にあるイベントログを確認します。エラーがサイドカー インジェクションに関連する場合は、Istio のログにエラーの原因が示されていないかを確認します。
問題が引き続き発生する場合は、次のいずれかが原因の可能性があります。
- インジェクタに渡される構成に問題がある
- ファイアウォールの構成に問題がある
- Istio コード自体に問題がある
詳細な診断手順については、Istio のトラブルシューティングをご覧ください。
Envoy プロキシが Istiod から構成を受信しない
プロキシが Istiod から構成を受信することを妨げる原因として考えられる問題は複数存在します。
構成リソースの読み込みを妨げる RBAC の問題など、問題が発生した場合、Istiod は Envoy プロキシに構成を push しません。
検出アドレスが正しくない（「正常なアップストリームが存在しません」エラー）
サイドカー インジェクタに対して指定された検出アドレスが正しくありません。
gRPC config stream closed, no healthy upstreamに関するログが表示された場合は、メッシュProxyConfigの検出アドレスが正しく、Istiod サービスを指すことを確認します。プロキシに push される無効な構成です。この場合、構成はプロキシに正常に push されますが、構成は無効です。次のような繰り返しメッセージが表示されます。
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
この例では、
cdsは（Istiod から push された 1 つの更新をレポートする）クラスタ検出サービスです。ldsは（Istiod によって拒否された 1 つの更新をレポートする）リスナー検出サービスです。多くの場合に、拒否の理由を説明するエラー メッセージが表示されます。これは通常、Envoy の構成または類似の内容に関する警告で始まります。この問題を解決するには、拒否された構成の原因を調べます。一般的な原因の 1 つは、
EnvoyFilterリソースが不正であることです。明確な理由がない場合は、プロキシの構成ダンプを添付してバグレポートを提出してください。
Pod の作成に失敗する
Pod が正常に作成されていない場合は、次のコマンドを使用して、根本原因が示されているエラー メッセージを探します。
kubectl describe replicaset YOUR_REPLICA_SET
一般的な Webhook のエラー メッセージ
kubectl apply コマンドによって出力されるエラー メッセージには、根本原因に関するヒントが示されている場合があります。次の表に、一般的なエラー メッセージとその原因、解決策を示します。
| エラー メッセージ | 原因 | 解決策 |
|---|---|---|
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) |
ネットワーク接続に問題がある可能性があります。 | ファイアウォール ルールをチェックして、ポート 15017 での Istio への接続が許可されていることを確認してください。 |
no endpoints available for service 'istiod' |
この問題は、Istiod Pod が使用できない場合、または準備ができていない場合に発生します。 | Istio Pod をチェックして、準備ができていることを確認してください。 |
Service "istiod" not found |
この問題は、Istiod サービスが存在しない場合に発生することがあります。 | Istio のインストールが成功し、正常であることを確認してください。 |
x509: certificate signed by unknown authority |
Webhook 証明書に問題がある可能性があります。 | Webhook で caBundle が正しく設定されていることを確認してください。 |