Amazon EKS のトラブルシューティング - Amazon EKS

Amazon EKS のトラブルシューティング

この章では、Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。

容量不足

Amazon EKS クラスターを作成しようとするときに次のエラーが表示された場合、指定したいずれかのアベイラビリティーゾーンに、クラスターをサポートするための十分な容量がありません。

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

このエラーメッセージによって返されるアベイラビリティーゾーンでホストされているクラスター VPC 内のサブネットを使用して、クラスターを再作成してください。

ノードをクラスターに結合できません

ノードをクラスターに結合できない一般的な理由はいくつかあります。

  • aws-auth-cm.yaml ファイルにノードの正しい IAM ロール ARN がない場合。aws-auth-cm.yaml ファイルに、ノード IAM ロール ARN (インスタンスプロファイルの ARN ではない) が指定されていることを確認してください。詳細については、「」を参照してくださいセルフマネージド型の Amazon Linux ノードの起動

  • ノード AWS CloudFormation テンプレートの ClusterName が、ノードを結合するクラスターの名前と正確に一致しません。このフィールドに正しくない値を渡すと、ノードの /var/lib/kubelet/kubeconfig ファイルの設定が正しくないために、ノードはクラスターに結合されません。

  • ノードは、クラスターによって 所有 されているためタグ付けされていません。ノードには、次のタグが適用されている必要があります。<cluster-name> はクラスターの名前に置き換えられます。

    キー

    kubernetes.io/cluster/<cluster-name>

    owned

  • ノードは、パブリック IP アドレスを使用してクラスターにアクセスできない場合があります。パブリックサブネットにデプロイされたノードにパブリック IP アドレスが割り当てられていることを確認してください。割り当てられていない場合は、起動後にノードに Elastic IP アドレスを関連付けることができます。詳細については、「Elastic IP アドレスを実行中のインスタンスまたはネットワークインターフェイスに関連付ける」を参照してください。デプロイされたインスタンスにパブリック IP アドレスを自動的に割り当てるようにパブリックサブネットが設定されていない場合は、その設定を有効にすることをお勧めします。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。ノードがプライベートサブネットにデプロイされている場合、サブネットには、パブリック IP アドレスが割り当てられた NAT ゲートウェイへのルートが必要です。

  • ノードのデプロイ先リージョンの STS エンドポイントは、アカウントに対して有効になっていません。リージョンを有効にするには、「AWS STS リージョンでの AWS のアクティブ化と非アクティブ化」を参照してください。

  • ワーカーノードにはプライベート DNS エントリがないため、node "" not found エラーを含む kubelet ログが発生する可能性があります。ワーカーノードが作成される VPC に、DHCP options setOptions として domain-namedomain-name-servers の値のセットがあることを確認してください。デフォルト値は domain-name:<region>.compute.internal および domain-name-servers:AmazonProvidedDNS です。詳細については、Amazon VPC ユーザーガイドの「DHCP Options Sets」を参照してください。

許可されていないか、アクセスが拒否されました (kubectl)

kubectl コマンドの実行中に次のいずれかのエラーが発生した場合、kubectl が Amazon EKS に対して適切に設定されていないか、使用している IAM ユーザーまたはロールの認証情報が Amazon EKS クラスターで十分なアクセス許可を持つ Kubernetes RBAC ユーザーにマッピングされていません。

  • could not get token: AccessDenied: Access denied

  • error: You must be logged in to the server (Unauthorized)

  • error: the server doesn't have a resource type "svc"

これは、クラスターが AWS 認証情報のあるセット (IAM ユーザーまたはロール) から作成されたが、kubectl は別の認証情報のセットを使用していることが原因である可能性があります。

Amazon EKS クラスターが作成されたら、クラスターを作成する IAM エンティティ (ユーザーまたはロール) が管理者 (system:masters のアクセス許可が付与されます) として Kubernetes RBAC 認証テーブルに追加されます。初期状態では、その IAM ユーザーのみが、kubectl を使用して Kubernetes API サーバーを呼び出すことができます。詳細については、「」を参照してくださいクラスターのユーザーまたは IAM ロールの管理 コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl コマンドを実行する際、同じ IAM ユーザー認証情報が AWS SDK 認証情報チェーンにあることを確認する必要があります。

AWS CLI をインストールして設定する場合は、ユーザーの IAM 認証情報を設定できます。詳細については、『AWS CLI ユーザーガイド』の「AWS Command Line Interface の設定.」を参照してください。

Amazon EKS クラスターを作成するロールを引き受けた場合は、kubectl が同じロールを引き受けるように設定されていることを確認する必要があります。次のコマンドを使用して、IAM ロールを使用するように kubeconfig ファイルを更新してください。詳細については、「」を参照してくださいAmazon EKS の kubeconfig を作成する

aws eks update-kubeconfig \ --region <region-code> \ --name <cluster_name> \ --role-arn arn:aws:iam::<aws_account_id>:role/<role_name>

IAM ユーザーを Kubernetes RBAC ユーザーにマッピングするには、「クラスターのユーザーまたは IAM ロールの管理」を参照してください。

aws-iam-authenticator Not Found

"aws-iam-authenticator": executable file not found in $PATH というエラーが発生する場合は、kubectl が Amazon EKS 用に設定されていません。詳細については、「」を参照してくださいaws-iam-authenticator のインストール

注記

AWS CLI バージョン 1.16.156 以上がインストールされている場合、aws-iam-authenticator は必要ありません。

hostname doesn't match

システムの Python のバージョンは 2.7.9 以降であることが必要です。それ以外の場合は、AWS CLI で Amazon EKS を呼び出すと hostname doesn't match エラーが表示されます。詳細については、Python Requests FAQ の「What are "hostname doesn't match" errors?」 を参照してください。

getsockopt: no route to host

Docker は Amazon EKS クラスターの 172.17.0.0/16 CIDR 範囲で実行されます。クラスターの VPC サブネットがこの範囲と重ならないようにすることをお勧めします。重なっている場合は、以下のエラーが発生します。

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

マネージド型ノードグループのエラー

AWS Management Console で「インスタンスが kubernetes クラスターに参加できませんでした」というエラーが表示された場合は、クラスターのプライベートエンドポイントアクセスが有効になっているか、パブリックエンドポイントアクセス用に CIDR ブロックが正しく設定されていることを確認します。詳細については、「」を参照してくださいAmazon EKS クラスターエンドポイントでのアクセスコントロール

マネージド型ノードグループで正常性の問題が発生した場合は、Amazon EKS から問題の診断に役立つエラーメッセージが返されます。以下のエラーメッセージとそれに関連する説明を下に示します。

  • AccessDenied: Amazon EKS または 1 つ以上のマネージド型ノードが Kubernetes クラスターの API サーバーの認証に失敗しています。このエラーを解決する方法の詳細については、「マネージド型ノードグループの AccessDenied エラーを修正する」を参照してください。

  • AmiIdNotFound: 起動テンプレートに関連付けられている AMI ID が見つかりませんでした。AMI が存在し、アカウントと共有されていることを確認してください。

  • AutoScalingGroupNotFound: マネージド型ノードグループに関連付けられている Auto Scaling グループが見つかりませんでした。同じ設定で Auto Scaling グループを再作成して復旧できる場合があります。

  • ClusterUnreachable: Amazon EKS または 1 つ以上のマネージド型ノードが Kubernetes クラスターの API サーバーと通信できません。このエラーはネットワークが中断したり、API サーバーがリクエストの処理をタイムアウトしている場合に発生する可能性があります。

  • Ec2SecurityGroupNotFound: クラスターのクラスターセキュリティグループが見つかりませんでした。クラスターを再作成する必要があります。

  • Ec2SecurityGroupDeletionFailure: マネージド型ノードグループのリモートアクセスセキュリティグループを削除できませんでした。セキュリティグループから依存関係を削除します。

  • Ec2LaunchTemplateNotFound: マネージド型ノードグループの Amazon EC2 起動テンプレートが見つかりませんでした。復旧には、ノードグループを再作成する必要があります。

  • Ec2LaunchTemplateVersionMismatch: マネージド型ノードグループの Amazon EC2 起動テンプレートのバージョンが、Amazon EKS が作成したバージョンと一致しません。Amazon EKS が作成したバージョンに戻すことで復旧できる場合があります。

  • IamInstanceProfileNotFound: マネージド型ノードグループの IAM インスタンスプロファイルが見つかりませんでした。同じ設定でインスタンスプロファイルを再作成して復旧できる場合があります。

  • IamNodeRoleNotFound: マネージド型ノードグループの IAM ロールが見つかりませんでした。同じ設定で IAM ロールを再作成して復旧できる場合があります。

  • AsgInstanceLaunchFailures: インスタンスの起動中に Auto Scaling グループに障害が発生しています。

  • NodeCreationFailure: 起動したインスタンスを Amazon EKS クラスターに登録できません。この障害の一般的な原因は、ノード IAM ロールのアクセス許可が不十分か、ノードのアウトバウンドインターネットアクセスがないことです。ノードが適切に機能するためには、パブリック IP アドレスを使用してインターネットにアクセスできる必要があります。詳細については、「」を参照してくださいVPC IP アドレス指定 ノードには、インターネットに対して開いているポートも必要です。詳細については、「」を参照してくださいAmazon EKS セキュリティグループの考慮事項

  • InstanceLimitExceeded: AWS アカウントが、指定されたインスタンスタイプのインスタンスをこれ以上起動できません。Amazon EC2 のインスタンス制限の引き上げをリクエストして復旧できる場合があります。

  • InsufficientFreeAddresses: マネージド型ノードグループに関連付けられている 1 つ以上のサブネットに、新しいノードに使用できる十分な IP アドレスがありません。

  • InternalFailure: これらのエラーは通常、Amazon EKS サーバー側の問題が原因で発生します。

マネージド型ノードグループで操作を実行する際に AccessDenied エラーが発生する最も一般的な原因は、eks:node-managerClusterRole または ClusterRoleBinding がないことです。Amazon EKS は、マネージド型ノードグループでのオンボーディングの一環として、クラスター内にこれらのリソースを設定します。これらのリソースは、ノードグループの管理に必要です。

ClusterRole は時間の経過とともに変化する可能性がありますが、次の例のようになります。

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create

ClusterRoleBinding は時間の経過とともに変化する可能性がありますが、次の例のようになります。

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager

eks:node-manager ClusterRole リソースが存在することを確認します。

kubectl describe clusterrole eks:node-manager

存在する場合は、出力を以前の ClusterRole の例と比較します。

eks:node-manager ClusterRoleBinding リソースが存在することを確認します。

kubectl describe clusterrolebinding eks:node-manager

存在する場合は、出力を以前の ClusterRoleBinding の例と比較します。

マネージド型ノードグループの操作のリクエスト中に AcessDenied エラーの原因として ClusterRoleClusterRoleBinding が紛失または破損していることを発見した場合は、それらを復元できます。次の内容を eks-node-manager-role.yaml という名前のファイルに保存します。

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager

ファイルを適用します。

kubectl apply -f eks-node-manager-role.yaml

ノードグループの操作を再試行して、問題が解決したかどうかを確認します。

CNI ログ収集ツール

Kubernetes 用の Amazon VPC CNI プラグインには、独自のトラブルシューティングスクリプトがあります。このスクリプトは /opt/cni/bin/aws-cni-support.sh のノードで使用できます。このスクリプトを使用して、サポートケースおよび一般的なトラブルシューティングの診断ログを収集できます。

ノードでスクリプトを実行するには、次のコマンドを使用します。

sudo bash /opt/cni/bin/aws-cni-support.sh
注記

指定された場所にスクリプトが存在しない場合は、CNI コンテナの実行に失敗します。手動でスクリプトをダウンロードして実行するには、次のコマンドを使用します。

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh sudo bash eks-log-collector.sh

このスクリプトは、次の診断情報を収集します。デプロイした CNI バージョンは、スクリプトバージョンより前のバージョンである可能性があります。

This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami Trying to collect common operating system logs... Trying to collect kernel logs... Trying to collect mount points and volume information... Trying to collect SELinux status... Trying to collect iptables information... Trying to collect installed packages... Trying to collect active system services... Trying to collect Docker daemon information... Trying to collect kubelet information... Trying to collect L-IPAMD information... Trying to collect sysctls information... Trying to collect networking information... Trying to collect CNI configuration information... Trying to collect running Docker containers and gather container data... Trying to collect Docker daemon logs... Trying to archive gathered information... Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

診断情報が収集され、 に保存されます。

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Container runtime network not ready (コンテナランタイムネットワークの準備ができていません)

以下のような Container runtime network not ready エラーと承認エラーが表示される場合があります。

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized
4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

これらのエラーは、AWS IAM Authenticator の設定マップがノードに適用されていないことで発生している可能性が高いと考えられます。この設定マップは、クラスターに登録するための Kubernetes RBAC アクセス許可 system:bootstrappers および system:nodes をノードに付与します。詳細については、セルフマネージド型の Amazon Linux ノードの起動 の[セルフマネージド型ノード] タブの「To enable nodes to join your cluster (ノードをクラスターと結合するには)」を参照してください。インスタンスプロファイル ARN ではなく、設定マップのインスタンスロールのロール ARN を指定してください。

認証コードが次の例のように / 以外のパスを含む場合、ロール ARN は認識されません。

arn:aws:iam::<111122223333>:role/<development/apps/prod-iam-role-NodeInstanceRole-621LVEXAMPLE>

指定した設定マップのロール ARN/ 以外のパスを含む場合は、そのパスを削除する必要があります。上記の ARN は以下のように指定します。

arn:aws:iam::<111122223333>:role/<prod-iam-role-NodeInstanceRole-621LVEXAMPLE>

TLS ハンドシェイクタイムアウト

ノードがパブリック API サーバーエンドポイントへの接続を確立できない場合、次のようなエラーが発生する可能性があります。

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post net/http: TLS handshake timeout\""

kubelet プロセスは、API サーバーエンドポイントを継続的に再生成およびテストします。このエラーは、コントロールプレーンでクラスターのローリング更新を行う手順 (設定の変更やバージョンの更新など) で一時的に発生することもあります。

この問題を解決するには、ルートテーブルとセキュリティグループを確認して、ノードからのトラフィックがパブリックエンドポイントに到達できることを確認します。

InvalidClientTokenId

中国リージョンでクラスターにデプロイされている Pod または DaemonSet 用サービスアカウントの IAM ロールを使用していて、spec に AWS_DEFAULT_REGION 環境変数を設定していない場合、Pod または DaemonSet に次のエラーが表示されることがあります。

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

この問題を解決するには、次の Pod spec の例に示すように、AWS_DEFAULT_REGION 環境変数を Pod または DaemonSet spec に追加する必要があります。

apiVersion: v1 kind: Pod metadata: name: envar-demo labels: purpose: demonstrate-envars spec: containers: - name: envar-demo-container image: gcr.io/google-samples/node-hello:1.0 env: - name: AWS_DEFAULT_REGION value: "<region-code>"

VPC アドミッションウェブフック証明書の有効期限切れ

VPC アドミッション Webhook の署名に使用された証明書の有効期限が切れた場合、新しい Windowsポッドデプロイのステータスは ContainerCreating のままとなります。これが表示される場合は、以下のコマンドを使用して、この状態のポッドに関する情報を表示します。

kubectl describe pod my-pod -n my-namespace

返される出力には、次のイベントが表示されます。

Warning FailedCreatePodSandBox 39s kubelet

証明書の有効期限は、次のコマンドを使用して確認できます。

kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 --decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2

出力

May 27 14:23:00 2021 GMT

証明書の有効期限が切れている場合は、更新が必要です。詳細については、「VPC アドミッションウェブフック証明書の更新」を参照してください。新しい証明書をデプロイしたら、ContainerCreating ステータスのままの各ポッドの再デプロイが必要です。