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

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

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

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

容量不足

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

Cannot create cluster 'example-cluster' because region-1d, the targeted アベイラビリティーゾーン, does not currently have sufficient capacity to support the cluster. Retry and choose from these アベイラビリティーゾーンs: region-1a, region-1b, region-1c

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

ノードがクラスターに参加できない

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

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

  • ノードテンプレートの ClusterNameAWS CloudFormation は、ノードが参加するクラスターの名前と正確に一致しません。このフィールドに誤った値を渡すと、ノードの /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 エントリがないためkubelet、ログにnode "" not foundエラーが含まれます。ワーカーノードが作成される VPC に、 domain-name domain-name-servers のように Options および の値が設定されていることを確認しますDHCP options set。デフォルト値は domain-name:<region>.compute.internal および domain-name-servers:AmazonProvidedDNSです。詳細については、『Amazon VPC ユーザーガイド』の「DHCP オプションセット」を参照してください。

許可されていないか、アクセスが拒否されました (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"

これは、クラスターが 1 つのAWS認証情報セット ( IAM ユーザーまたはロール) で作成され、 kubectl が別の認証情報セットを使用しているためです。

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

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

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

aws --region <region-code> eks update-kubeconfig --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 $PATHkubectl は 用に設定されていませんAmazon EKS。詳細については、「 」を参照してくださいのインストール aws-iam-authenticator

注記

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

hostname doesn't match

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

getsockopt: no route to host

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

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

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

AWS マネジメントコンソール で「インスタンスが 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-manager ClusterRole または が欠落していることです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例と比較します。

マネージド型ノードグループオペレーションのリクエスト中にClusterRole、エラーの原因ClusterRoleBindingとして見つからないか、破損している AcessDenied 、または を特定した場合は、それらを復元できます。以下の内容を という名前のファイルに保存します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 ログ収集ツール

Amazon VPC CNI plugin for Kubernetes には、独自のトラブルシューティングスクリプト ( のノードで入手できます/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 設定マップに関連しています。設定マップは、ノードがクラスターに登録するための system:bootstrappers および system:nodes Kubernetes RBAC アクセス許可を提供します。詳細については、「 セルフマネージド型ノードタブでノードがクラスターに参加できるようにするには」を参照してくださいセルフマネージド型Amazon Linuxノードの起動インスタンスプロファイル ARN ではなく、設定マップのインスタンスロールのロール ARN を指定してください。

Authenticator は、次の例のように、 以外のパスが含まれている場合ロール 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

IAM リージョンのクラスターにデプロイされたポッドまたはデーモンセットのサービスアカウントの 中国 ロールを使用していて、仕様で AWS_DEFAULT_REGION 環境変数を設定していない場合、ポッドまたはデーモンセットは次のエラーを受け取る可能性があります。

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>"