App Mesh Kubernetes のトラブルシューティング

このトピックでは、Kubernetes で App Mesh を使用するときに発生する可能性のある一般的な問題を詳細に説明します。

Kubernetes で作成されたアプリケーションメッシュリソースが App Mesh 内で見つからない

症状

Kubernetes カスタムリソース定義 (CRD) を使用して App Mesh リソースを作成しましたが、 AWS Management Console または APIs を使用する場合、作成したリソースは App Mesh に表示されません。

解決方法

考えられる原因は、App Mesh の Kubernetes コントローラーのエラーです。詳細については、「 のトラブルシューティング」を参照してください GitHub。コントローラーのログで、コントローラーがリソースを作成できなかったことを示すエラーまたは警告がないかどうかをチェックしてください。

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

Envoy サイドカーが挿入された後、準備状態とライブネスのチェックに失敗する

症状

アプリケーションのポッドは、以前正常に実行されていましたが、Envoy サイドカーがポッドに挿入された後、準備状態とライブネスのチェックに失敗し始めました。

解決方法

ポッドに挿入された Envoy コンテナが App Mesh の Envoy 管理サービスでブートストラップされていることを確認します。エラーを確認するには、Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました でエラーコードを参照します。次のコマンドを使用して、関連するポッドの Envoy ログを調べることができます。

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

ポッドが AWS Cloud Map インスタンスとして登録されない、または登録解除される。

症状

Kubernetes ポッドは、ライフサイクル AWS Cloud Map の一環として に登録されていないか、 から登録解除されていません。ポッドが正常にスタートし、トラフィックを処理する準備ができていても、受信できない場合があります。ポッドが終了しても、クライアントはその IP アドレスを保持し、トラフィックを送信しようとする可能性があり、失敗します。

解決方法

これは既知の問題です。詳細については、「問題が発生してもポッドが Kubernetes で自動登録/登録解除されない AWS Cloud Map GitHub 」を参照してください。ポッド、App Mesh 仮想ノード、 AWS Cloud Map リソース間の関係により、Kubernetes 用 App Mesh コントローラーは非同期になり、リソースが失われる可能性があります。例えば、これは、関連するポッドを終了する前に仮想ノードリソースが Kubernetes から削除された場合に発生する可能性があります。

この問題を軽減するには、次の手順を実行します。

• Kubernetes 用の App Mesh コントローラーの最新バージョンを実行していることを確認してください。

• 仮想ノード定義で と serviceName が正しいことを確認します AWS Cloud Map namespaceName。

• 仮想ノード定義を削除する前に、関連するポッドをすべて削除してください。仮想ノードに関連付けられているポッドを特定するための助けが必要な場合は、「App Mesh リソースのポッドが実行されている場所を特定できない」を参照してください。

• 問題が解決しない場合は、次のコマンドを実行して、根本的な問題を明らかにするのに役立つ可能性のあるエラーがないかコントローラーログを調べます。

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• 次のコマンドを使用してコントローラーのポッド を再起動することを検討してください。これにより、同期の問題が修正される可能性があります。

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

App Mesh リソースのポッドが実行されている場所を特定できない

症状

Kubernetes クラスターで App Mesh を実行すると、オペレータは、特定の App Mesh リソースに対してワークロードまたはポッドが実行されている場所を特定できません。

解決方法

Kubernetes ポッドのリソースは、関連付けられているメッシュと仮想ノードで注釈が付けられます。次のコマンドを使用して、特定の仮想ノード名に対して実行されているポッドをクエリできます。

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

ポッドが実行されている App Mesh リソースを特定できない

症状

Kubernetes クラスターで App Mesh を実行している場合、オペレータは、特定のポッドが実行されている App Mesh リソースを特定できません。

解決方法

Kubernetes ポッドのリソースには、関連付けられているメッシュと仮想ノードの注釈が付けられます。次のコマンドを使用して、 ポッドに直接クエリを実行することで、メッシュおよび仮想ノード名を出力できます。

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

クライアント Envoy は、IMDSv1 が無効になっていると App Mesh Envoy Management Service と通信できません

症状

IMDSv1 を無効にすると、クライアントの Envoy は App Mesh コントロールプレーン (Envoy Management Service) と通信できなくなります。v1.24.0.0-prod 以前のバージョンの App Mesh Envoy では IMDSv2 はサポートされていません。

解決方法

この問題を解決するには、次の 3 つのいずれかを実行します。

• IMDSv2 がサポートされている App Mesh Envoy バージョン v1.24.0.0-prod 以降にアップグレードします。

• Envoy が実行されているインスタンスで再度 IMDSv1 を有効にします。IMDSv1 の復元方法については、「インスタンスメタデータオプションの設定」を参照してください。

• サービスが Amazon EKS で実行されている場合、認証情報の取得にはサービスアカウントの IAM ロール (IRSA) を使用することをお勧めします。IRSA を有効にする方法については、「サービスアカウントの IAM ロール」を参照してください。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。

App Mesh が有効で、Envoy が挿入されている場合、IRSA はアプリケーションコンテナで動作しません

症状

Amazon EKS 用のApp Mesh コントローラーを利用して Amazon EKS クラスターで App Mesh を有効にした場合、Envoy と proxyinit コンテナがアプリケーションポッドに挿入されます。アプリケーションは IRSA を引き受けることができず、代わりに node role を引き受けます。ポッドの詳細を確認すると、AWS_WEB_IDENTITY_TOKEN_FILE または AWS_ROLE_ARN 環境変数のいずれかがアプリケーションコンテナに含まれていないことがわかります。

解決方法

AWS_WEB_IDENTITY_TOKEN_FILE または AWS_ROLE_ARN 環境変数が定義されている場合、ウェブフックはポッドをスキップします。これらの変数はいずれも指定しないでください。ウェブフックによってこれらの環境変数は自動的に挿入されます。

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

それでも問題が解決しない場合は、GitHub 問題を開くことを検討するか、 AWS サポートにお問い合わせください。