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 ノードの起動」を参照してください。

  • ノード テンプレートの ClusterName が、ノードを結合するクラスターの名前と正確に一致しない。AWS 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 リージョンでの AWS STS のアクティブ化と非アクティブ化」を参照してください。

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

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

  • 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 ロールの管理」を参照してください。コンソールを使用してクラスターを作成する場合は、クラスター上で IAM AWS コマンドを実行する際、同じ 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>

Kubernetes RBAC ユーザーに IAM ユーザーをマップするには、クラスターのユーザーまたは 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 マネジメントコンソール で「インスタンスが kubernetes クラスターに参加できませんでした」というエラーが表示された場合は、クラスターのプライベートエンドポイントアクセスが有効になっているか、パブリックエンドポイントアクセス用に CIDR ブロックが正しく設定されていることを確認します。詳細については、「Amazon EKS クラスターエンドポイントのアクセスコントロール」を参照してください。

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

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

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

  • : ClusterUnreachable または 1 つ以上のマネージド型ノードが Kubernetes クラスター API サーバーと通信できません。Amazon EKSこれは、ネットワークの中断が発生した場合、または 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 エラーの原因として、欠落している、または破損している ClusterRoleBindingAcessDenied を特定した場合は、復元できます。次の内容を 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 ログ収集ツール

CNI plugin for Kubernetes には、独自のトラブルシューティングスクリプト (Amazon VPC のノードで利用可能) があり、サポートケースや一般的なトラブルシューティング用の診断ログ収集に使用できます。/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 認証設定マップに関連しています。設定マップは、ノードがクラスターに登録するための system:bootstrappers および system:nodes Kubernetes RBAC アクセス許可を提供します。詳細については、「」の [Self-managed nodes (セルフマネージド型ノード)] タブにある「To enable nodes to join your cluster (ノードがクラスターに参加できるようにするには)セルフマネージド型 Amazon Linux ノードの起動」を参照してください。インスタンスプロファイル 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

リージョンのクラスターにデプロイされたポッドまたはデーモンセットのサービスアカウントの 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>"