**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS クラスターとノードに関する問題をトラブルシューティングする
この章では Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。特定の Amazon EKS 領域のトラブルシューティングが必要な場合、別の [IAM のトラブルシューティング](security-iam-troubleshoot.md)、[Amazon EKS Connector の問題をトラブルシューティングする](troubleshooting-connector.md)、および「[EKS アドオンを使用した ADOT のトラブルシューティング](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on/troubleshooting)」を参照してください。
その他のトラブルシューティング情報については*AWS re:Post* の「[Amazon Elastic Kubernetes Service に関するナレッジセンターのコンテンツ](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service)」を参照してください。
## 容量不足
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 内のサブネットを使用して、クラスターを再作成してください。
クラスターを配置できないアベイラビリティーゾーンがあります。サブネットが属するアベイラビリティーゾーンを、[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)内のアベイラビリティーゾーンのリストと比較してください。
## ノードをクラスターに結合できません
ノードをクラスターに結合できない一般的な理由はいくつかあります。
+ ノードがマネージド型の場合、Amazon EKS はノードグループの作成時に、`aws-auth` `ConfigMap` にエントリを追加します。エントリが削除または変更された場合は再度追加する必要があります。詳細についてはターミナルに `eksctl create iamidentitymapping --help` を入力してください。現在の `aws-auth` `ConfigMap` エントリを確認するには次のコマンドの *マイクラスター* をクラスターの名前に置き換えて、変更したコマンド `eksctl get iamidentitymapping --cluster my-cluster ` を実行してください。指定する役割の ARN には`/` 以外の[パス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)を含めることはできません。例えば、役割の名前が `development/apps/my-role` の場合、役割の ARN を指定するときに `my-role` に変更する必要があります。ノード IAM 役割 ARN (インスタンスプロファイルの ARN ではない) を指定していることを確認してください。
ノードがセルフマネージド型で、ノードの IAM [役割の](access-entries.md) ARN のアクセスエントリを作成していない場合はマネージド型ノード用にリストされているのと同じコマンドを実行してください。ノード IAM 役割の ARN のアクセスエントリを作成している場合、そのエントリがアクセスエントリで正しく設定されていない可能性があります。`aws-auth` `ConfigMap` エントリまたはアクセスエントリのプリンシパル ARN として、ノード IAM 役割 ARN (インスタンスプロファイルの ARN ではない) が指定されていることを確認してください。アクセスエントリの詳細については「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ ノード AWS クラウドフォーメーション テンプレートの **クラスター名** が、ノードを結合するクラスターの名前と正確に一致しません。このフィールドに正しくない値を渡すと、ノードの `/var/lib/kubelet/kubeconfig` ファイルの設定が正しくなくなるため、ノードはクラスターに結合されません。
+ ノードはクラスターによって所有されているためタグ付けされていません。ノードには次のタグが適用されている必要があります。*マイクラスター* はクラスターの名前に置き換えられます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/troubleshooting.html)
+ ノードはパブリック IP アドレスを使用してクラスターにアクセスできない場合があります。パブリックサブネットにデプロイされたノードにパブリック IP アドレスが割り当てられていることを確認してください。割り当てられていない場合は起動後にノードに Elastic IP アドレスを関連付けることができます。詳細については「[Elastic IP アドレスをインスタンスまたはネットワークインターフェイスに関連付ける](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating)」を参照してください。デプロイされたインスタンスにパブリック IP アドレスを自動的に割り当てるようにパブリックサブネットが設定されていない場合はその設定を有効にすることをお勧めします。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、サブネットにはパブリック IP アドレスが割り当てられた NAT ゲートウェイへのルートが必要です。
+ ノードのデプロイ先 AWS リージョンの AWS STS エンドポイントはアカウントに対して有効になっていません。リージョンを有効にするには「[AWS リージョンでの AWS STS のアクティブ化と非アクティブ化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate)」を参照してください。
+ ノードにはプライベート DNS エントリがないため、`node "" not found` エラーを含む `kubelet` ログが記録されます。ノードが作成される VPC に、`DHCP options set` の `Options` として `domain-name` と `domain-name-servers` の値のセットがあることを確認してください。デフォルト値は `domain-name:.compute.internal` および `domain-name-servers:AmazonProvidedDNS` です。詳細については「*Amazon VPC ユーザーガイド*」の「[DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS)」を参照してください。
+ マネージドノードグループ内のノードが 15 分以内にクラスターに接続しない場合、「NodeCreationFailure」という正常性の問題が出力され、コンソールのステータスが `Create failed` に設定されます。起動時間が遅い Windows AMI の場合、この問題は[高速起動](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/win-ami-config-fast-launch.html)を使用して解決できます。
ワーカーノードがクラスターに参加できない一般的な原因を特定してトラブルシューティングするには`AWSSupport-TroubleshootEKSWorkerNode` ランブックを使用できます。詳細についてはAWS システム・マネージャー Automation ランブックリファレンスの「` [AWSSupport-TroubleshootEKSWorkerNode](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshooteksworkernode.html) `」を参照してください。
## 許可されていないか、アクセスが拒否されました (`kubectl`)
`kubectl` コマンドの実行中に次のいずれかのエラーが発生した場合は、`kubectl` が Amazon EKS に対して適切に設定されていないか、使用している IAM プリンシパルの認証情報 (役割またはユーザー) が、Amazon EKS クラスターで Kubernetes オブジェクトに対して十分なアクセス許可を持つ Kubernetes ユーザー名にマッピングされていません。
+ `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"`
この原因としては次のいずれかが考えられます。
+ クラスターはある IAM プリンシパルの認証情報を使用して作成されており、`kubectl` は別の IAM プリンシパルの認証情報を使用するよう設定されています。この問題を解決するにはクラスターを作成した認証情報を使用するように `kube config` ファイルを更新してください。詳細については「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
+ クラスターが [EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)の前提条件セクションの最小プラットフォーム要件を満たしている場合、IAM プリンシパルにはアクセスエントリは存在しません。存在する場合、必要な Kubernetes グループ名が定義されていないか、適切なアクセスポリシーが関連付けられていません。詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ クラスターが [ EKS アクセス エントリを使用して IAM ユーザーに Kubernetes へのアクセスを許可する](access-entries.md) の最小プラットフォーム要件を満たしていない場合、`aws-auth` `ConfigMap` に IAM プリンシパルのエントリが存在しません。存在しても、Kubernetes `Role` または `ClusterRole` にバインドされている、必要なアクセス許可を持つ Kubernetes グループ名にはマップされません。Kubernetes 役割ベースの承認 (RBAC) オブジェクトの詳細については、Kubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。現在の `aws-auth` `ConfigMap` エントリを確認するには次のコマンドの *マイクラスター* をクラスターの名前に置き換えて、変更したコマンド `eksctl get iamidentitymapping --cluster my-cluster ` を実行してください。IAM プリンシパルの ARN を含むエントリが `ConfigMap` にない場合はターミナルに `eksctl create iamidentitymapping --help` を入力して作成方法を確認してください。
AWS CLI をインストールして設定する場合は使用する IAM 認証情報を設定できます。詳細についてはAWS コマンドラインインターフェイスユーザーガイドの「[AWS CLI を設定する](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。クラスター上の Kubernetes オブジェクトにアクセスする IAM ロールを引き受ける場合は、IAM ロールを使用するように `kubectl` を設定することもできます。詳細については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
## `hostname doesn’t match`
システムの Python のバージョンは `2.7.9` 以降であることが必要です。それ以外の場合はAWS CLI で Amazon EKS を呼び出すと `hostname doesn’t match` エラーが表示されます。詳細については「Python Requests のよくある質問」の「[What are "hostname doesn't match" errors?](https://requests.readthedocs.io/en/latest/community/faq.html#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..:10250: getsockopt: no route to host
```
## `Instances failed to join the Kubernetes cluster`
AWS マネジメントコンソール で `Instances failed to join the Kubernetes cluster` エラーが表示された場合、クラスターのプライベートエンドポイントアクセスが有効になっているか、パブリックエンドポイントアクセス用に CIDR ブロックが正しく設定されていることを確認します。詳細については「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
## マネージド型ノードグループのエラー
マネージド型ノードグループでハードウェアのヘルスに問題が発生した場合は Amazon EKS によって問題の診断に役立つエラーメッセージが返されます。これらのヘルスチェックは [Amazon EC2 ヘルスチェック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)に基づいているため、ソフトウェアの問題は検出されません。次のリストはエラーコードについての説明です。
**AccessDenied**
Amazon EKS または 1 つ以上のマネージド型ノードが、Kubernetes クラスター API サーバーでの認証または認可に失敗しています。共通のレスポンスヘッダーの詳細については「[`AccessDenied`マネージド型ノードグループエラーを修正する](#access-denied-managed-node-groups)」を参照してください。プライベート Windows AMI では、`Not authorized for images` エラーメッセージと共にこのエラーコードが表示されることもあります。詳細については、「[`Not authorized for images`](#not-authorized-for-images)」を参照してください。
**AmiIdNotFound**
起動テンプレートに関連付けられている AMI ID が見つかりませんでした。AMI が存在し、アカウントと共有されていることを確認してください。
**AutoScalingGroupNotFound**
マネージド型ノードグループに関連付けられている 自動スケーリング グループが見つかりませんでした。同じ設定で 自動スケーリング グループを再作成して復旧できる場合があります。
**ClusterUnreachable**
Amazon EKS または 1 つ以上のマネージド型ノードが Kubernetes クラスター API サーバーと通信できません。このエラーはネットワークが中断したり、API サーバーがリクエストの処理をタイムアウトしている場合に発生する可能性があります。
**Ec2セキュリティグループNotFound**
クラスターのクラスターセキュリティグループが見つかりませんでした。クラスターを再作成する必要があります。
**Ec2セキュリティグループDeletionFailure**
マネージド型ノードグループのリモートアクセスセキュリティグループを削除できませんでした。セキュリティグループから依存関係を削除します。
**Ec2LaunchTemplateNotFound**
マネージド型ノードグループの Amazon EC2 起動テンプレートが見つかりませんでした。復旧にはノードグループを再作成する必要があります。
**Ec2LaunchTemplateVersionMismatch**
マネージド型ノードグループの Amazon EC2 起動テンプレートのバージョンが、Amazon EKS が作成したバージョンと一致しません。Amazon EKS が作成したバージョンに戻すことで復旧できる場合があります。
**IamInstanceProfileNotFound**
マネージド型ノードグループの IAM インスタンスプロファイルが見つかりませんでした。同じ設定でインスタンスプロファイルを再作成して復旧できる場合があります。
**IamNodeRoleNotFound**
マネージド型ノードグループの IAM 役割が見つかりませんでした。同じ設定で IAM 役割を再作成して復旧できる場合があります。
**AsgInstanceLaunchFailures**
インスタンスの起動中に 自動スケーリング グループに障害が発生しています。
**NodeCreationFailure**
起動したインスタンスを Amazon EKS クラスターに登録できません。この障害の一般的な原因は[ノード IAM 役割](create-node-role.md)のアクセス許可が不十分か、ノードのアウトバウンドインターネットアクセスがないことです。ノードは以下の要件のいずれかを満たしている必要があります。
+ パブリック IP アドレスを使用してインターネットにアクセス可能です。ノードが存在するサブネットに関連付けられているセキュリティグループが、通信を許可する必要があります。詳細については[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)および[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。
+ ノードと VPC は[「インターネットアクセスが制限されたプライベートクラスターをデプロイする」](private-clusters.md) に記載される要件を満たしている必要があります。
**InstanceLimitExceeded**
AWS アカウントが、指定されたインスタンスタイプのインスタンスをこれ以上起動できません。Amazon EC2 のインスタンス制限の引き上げをリクエストして復旧できる場合があります。
**InsufficientFreeAddresses**
マネージド型ノードグループに関連付けられている 1 つ以上のサブネットに、新しいノードに使用できる十分な IP アドレスがありません。
**InternalFailure**
これらのエラーは通常、Amazon EKS サーバー側の問題が原因で発生します。
### `AccessDenied`マネージド型ノードグループエラーを修正する
マネージド型ノードグループで操作を実行する際に `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` の例と比較します。
マネージド型ノードグループの操作のリクエスト中に `AcessDenied` エラーの原因として `ClusterRole` や `ClusterRoleBinding` が紛失または破損していることを発見した場合はそれらを復元できます。*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
```
ノードグループの操作を再試行して、問題が解決したかどうかを確認します。
## `Not authorized for images`
`Not authorized for images` エラーメッセージの考えられる原因の 1 つは、プライベート Amazon EKS Windows AMI を使用して Windows マネージドノードグループを起動することです。新しい Windows AMI をリリースすると、AWS は 4 か月以上前の AMI を非公開にし、アクセス不可にします。マネージドノードグループがプライベート Windows AMI を使用している場合は、[Windows マネージドノードグループを更新する](update-managed-node-group.md)ことを検討してください。非公開になった AMI へのアクセスを可能にできるかは保証できませんが、AWS サポートにチケットを提出することでアクセスをリクエストできます。詳細については「*Amazon EC2 ユーザーガイド*」の「[パッチ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-windows-ami.html#ami-patches-security-ID)」を参照してください。
## ノードが `NotReady` 状態です
ノードが `NotReady` 状態になった場合は、そのノードに異常があり、新しい Pod をスケジュールできない可能性があります。これはノードに CPU、メモリ、利用可能なディスクスペースの十分なリソースがないなど、さまざまな理由で発生します。
Amazon EKS 最適化 Windows AMI の場合、`kubelet` 設定のデフォルトではコンピューティングリソースの予約は指定されていません。リソースの問題を防ぐために、`kubelet` に [kube-reserved](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#kube-reserved) および/または [system-reserved](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) の設定値を指定することで、システムプロセスのコンピューティングリソースを予約できます。これを行うにはブートストラップスクリプトの `-KubeletExtraArgs` コマンドラインパラメータを使用します。詳細については、Kubernetes ドキュメントの「[Reserve Compute Resources for System Daemons](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/)」、およびこのユーザーガイドの「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
## EKS ログコレクター
Amazon EKS ノードの問題をトラブルシューティングするために、ノード上の `/etc/eks/log-collector-script/eks-log-collector.sh` に構築済みのスクリプトが用意されています。このスクリプトを使用して、サポートケースおよび一般的なトラブルシューティングの診断ログを収集できます。
ノードでスクリプトを実行するには次のコマンドを使用します。
```
sudo bash /etc/eks/log-collector-script/eks-log-collector.sh
```
**注記**
その場所にスクリプトがない場合は、手動でスクリプトをダウンロードして実行するには次のコマンドを使用します。
```
curl -O https://amazon-eks.s3.amazonaws.com/support/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh
```
このスクリプトは次の診断情報を収集します。
```
$ sudo bash /etc/eks/log-collector-script/eks-log-collector.sh
This is version 0.7.8. New versions can be found at https://github.com/awslabs/amazon-eks-ami/blob/main/log-collector-script/
Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
...
...
Done... your bundled logs are located in /var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz
```
診断情報が収集され、以下に保存されます。
```
/var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz
```
Bottlerocket ノードのログバンドルを取得するには、「[Bottlerocket Log](https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#logs)」で詳細を参照してください。
## コンテナランタイムネットワークの準備ができていません
以下のような `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
```
これは次のいずれかの理由で発生します。
1. クラスターに `aws-auth` `ConfigMap` がないか、ノードに設定した IAM 役割のエントリが含まれていないかのどちらかです。
この問題を解決するには次のコマンドの *マイクラスター* をクラスターの名前に置き換えて、変更したコマンド `eksctl get iamidentitymapping --cluster my-cluster ` を実行することで、`ConfigMap` 内の現在のエントリを確認します。コマンドからエラーメッセージが表示される場合はクラスターに `aws-auth` `ConfigMap` がないことが原因である可能性があります。次のコマンドは `ConfigMap` にエントリを追加します。`ConfigMap` が存在しない場合はコマンドによって作成されます。*111122223333* を IAM ロールの AWS ID に、*myAmazonEKSNodeRole* をノードの役割の名前に置き換えます。
```
eksctl create iamidentitymapping --cluster my-cluster \
--arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \
--username system:node:{{EC2PrivateDNSName}}
```
指定する役割の ARN には`/` 以外の[パス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)を含めることはできません。例えば、役割の名前が `development/apps/my-role` の場合、役割の ARN を指定するときに `my-role` に変更する必要があります。ノード IAM 役割 ARN (インスタンスプロファイルの ARN ではない) を指定していることを確認してください。
1. セルフマネージド型ノードが、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する」のトピックの前提条件に記載されている最小バージョンのプラットフォームバージョンのクラスターにあるものの、ノードの IAM 役割のエントリが ](access-entries.md) `aws-auth` (前の項目を参照)`ConfigMap` に記載されていないか、役割のアクセスエントリが存在しません。この問題を解決するには次のコマンドの *マイクラスター* をクラスターの名前に置き換えて、変更したコマンド `aws eks list-access-entries --cluster-name my-cluster ` を実行することで、現在のアクセスエントリを確認します。次のコマンドはノードの IAM 役割のアクセスエントリを追加します。*111122223333* を IAM ロールの AWS ID に、*myAmazonEKSNodeRole* をノードの役割の名前に置き換えます。Windows ノードを使用している場合は*EC2\$1LINUX* を `EC2_Windows` に置き換えてください。ノード IAM 役割 ARN (インスタンスプロファイルの ARN ではない) を指定していることを確認してください。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --type EC2_LINUX
```
## 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 サーバーエンドポイントを継続的に再生成およびテストします。このエラーはコントロールプレーンでクラスターのローリング更新を行う手順 (設定の変更やバージョンの更新など) で一時的に発生することもあります。
この問題を解決するにはルートテーブルとセキュリティグループを確認して、ノードからのトラフィックがパブリックエンドポイントに到達できることを確認します。
## 無効なクライアントトークンID
中国 AWS リージョンでクラスターにデプロイされている Pod または DaemonSet 用サービスアカウントの IAM ロールを使用していて、仕様に `AWS_DEFAULT_REGION` 環境変数を設定していない場合、Pod または DaemonSet に次のエラーが表示されることがあります。
```
An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid
```
この問題を解決するには、次の Pod の仕様例に示すように、`AWS_DEFAULT_REGION` 環境変数を Pod または DaemonSet の仕様に追加する必要があります。
```
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"
```
## コントロールプレーンをアップグレードする前に、ノードグループが Kubernetes バージョンと一致する必要があります
クラスター内の、マネージドノードと Fargate ノードのマイナーバージョンは、コントロールプレーンを新しい Kubernetes バージョンにアップグレードする前に、コントロールプレーンの現在のバージョンと同じにする必要があります。Amazon EKS `update-cluster-version` API はすべての EKS マネージド型ノードが現在のクラスターバージョンにアップグレードされるまで、リクエストを拒否します。Amazon EKS はマネージド型ノードをアップグレードするための API を提供します。マネージドノードグループの Kubernetes バージョンのアップグレードについては、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。Fargate ノードのバージョンをアップグレードするには、ノードによって表されるポッドを削除し、コントロールプレーンをアップグレードした後にポッドを再デプロイします。詳細については、「[既存のクラスターを新しい Kubernetes バージョンに更新する](update-cluster.md)」を参照してください。
## 多数のノードを起動すると、`Too Many Requests` エラーが発生します。
多数のノードを同時に起動すると、[Amazon EC2 ユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-shell-scripts)の実行ログに「`Too Many Requests`」というエラーメッセージが表示される場合があります。これはコントロールプレーンが `describeCluster` 呼び出しで過負荷になっているために発生する可能性があります。過負荷が原因で、スロットリングが発生し、ノードがブートストラップスクリプトを実行できなくなり、ノードが完全にクラスターに参加できなくなります。
`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数がノードのブートストラップスクリプトに渡されていることを確認してください。これらの引数を含める場合、ブートストラップスクリプトが `describeCluster` 呼び出しを行う必要がなくなり、コントロールプレーンが過負荷になるのを防ぐのに役立ちます。詳細については、「[Amazon EKS に最適化された Linux/Bottlerocket AMI に含まれる `bootstrap.sh` ファイルに引数を渡すためのユーザーデータを提供する](launch-templates.md#mng-specify-eks-ami)」を参照してください。
## Kubernetes API サーバーリクエストに対する HTTP 401 Unauthorized エラーレスポンス
これらのエラーは、Pod のサービスアカウントトークンがクラスターで期限切れになった場合に表示されます。
Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンによるリクエストが拒否されます。以前の Kubernetes バージョンでは、トークンに有効期限はありませんでした。つまり、これらのトークンに依存しているクライアントは、1 時間以内にトークンを更新する必要があります。無効なトークンが原因で Kubernetes API サーバーによりリクエストが拒否されないようにするには、ワークロードで使用されている [Kubernetes クライアント SDK](https://kubernetes.io/docs/reference/using-api/client-libraries/) バージョンを、次のバージョンと同じか、それ以降にする必要があります。
+ Go - バージョン `0.15.7` 以降
+ Python バージョン `12.0.0` 以降
+ Java バージョン `9.0.0` 以降
+ JavaScript バージョン `0.10.3` 以降
+ Ruby `master` ブランチ
+ Haskell バージョン`0.3.0.0`
+ C\$1 バージョン `7.0.5` 以降
古いトークンを使用しているクラスター内の既存の Pod をすべて特定できます。詳細については、「[サービスアカウントトークン](service-accounts.md#service-account-tokens)」を参照してください。
## Amazon EKS プラットフォームのバージョンは現在のプラットフォーム バージョンより 2 つ以上遅れています
これは、Amazon EKS がクラスターの [platform-version](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) を自動的に更新できない場合に発生する可能性があります。これには多くの原因がありますが、一般的な原因のいくつかが続きます。これらの問題のいずれかがクラスターに当てはまる場合、それはまだ機能する可能性がありますが、そのプラットフォームバージョンは Amazon EKS によって更新されません。
**問題**
[クラスターIAM役割](cluster-iam-role.md) が削除されました - この役割はクラスターの作成時に指定されました。次のコマンドで、どの役割が指定されたかを確認できます。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2
```
出力例は次のとおりです。
```
eksClusterRole
```
**ソリューション**
同じ名前で新しい [クラスター IAM 役割](cluster-iam-role.md) を作成します。
**問題**
クラスターの作成中に指定されたサブネットが削除されました - クラスターで使用するサブネットはクラスターの作成中に指定されました。次のコマンドで、指定されたサブネットを確認できます。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds
```
出力例は次のとおりです。
```
[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]
```
**ソリューション**
アカウントにサブネット ID が存在するかどうかを確認します。
```
vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"
```
出力例は次のとおりです。
```
[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]
```
出力で返されたサブネット ID が、クラスターの作成時に指定されたサブネット ID と一致しない場合、Amazon EKS でクラスターを更新するにはクラスターで使用されるサブネットを変更する必要があります。これはクラスターの作成時に 2 つ以上のサブネットを指定した場合、Amazon EKS は指定したサブネットをランダムに選択して新しいエラスティックネットワークインターフェイスを作成するためです。これらのネットワーク インターフェイスにより、コントロールプレーンはノードと通信できます。Amazon EKS は選択したサブネットが存在しない場合、クラスターを更新しません。Amazon EKS が新しいネットワーク インターフェイスを作成するために選択する、クラスターの作成時に指定したサブネットをコントロールすることはできません。
クラスターの Kubernetes バージョンの更新を開始すると、同じ理由で更新が失敗する可能性があります。
**問題**
クラスターの作成中に指定されたセキュリティグループが削除されました - クラスターの作成中にセキュリティグループを指定した場合は次のコマンドでそれらの ID を確認できます。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds
```
出力例は次のとおりです。
```
[
"sg-EXAMPLE1"
]
```
`[]` が返された場合、クラスターの作成時にセキュリティグループが指定されておらず、セキュリティグループの欠落は問題ではありません。セキュリティグループが返された場合はセキュリティグループがアカウントに存在することを確認します。
**ソリューション**
これらのセキュリティグループがアカウントに存在するかどうかを確認します。
```
vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"
```
出力例は次のとおりです。
```
[
"sg-EXAMPLE2"
]
```
出力で返されたセキュリティグループ ID が、クラスターの作成時に指定されたセキュリティグループ ID と一致しない場合、Amazon EKS でクラスターを更新するにはクラスターで使用されるセキュリティグループを変更する必要があります。クラスターの作成時に指定されたセキュリティグループ ID が存在しない場合、Amazon EKS はクラスターを更新しません。
クラスターの Kubernetes バージョンの更新を開始すると、同じ理由で更新が失敗する可能性があります。
+ クラスターの作成時に指定した各サブネットで、少なくとも 6 つ (ただし、16 をお勧めします) の使用可能な IP アドレスがありません。サブネットに十分な使用可能な IP アドレスがない場合はサブネット内の IP アドレスを解放するか、十分な使用可能な IP アドレスを持つサブネットを使用するように、クラスターで使用されるサブネットを変更する必要があります。
+ クラスターの作成時に [ シークレット暗号化 ](enable-kms.md) を有効にしましたが、指定した AWS KMS キーは削除されました。Amazon EKS でクラスターを更新する場合は新しいクラスターを作成する必要があります
## クラスターの正常性に関するよくある質問およびエラーコードと解決パス
Amazon EKS は EKS クラスターとクラスターインフラストラクチャの問題を検出し、それらを EKS クラスターリソースの*ヘルス*オブジェクトに保存します。クラスターヘルスの情報を利用することで、クラスターの問題をより迅速に検出、トラブルシューティング、対処できます。これにより、より安全で最新のアプリケーション環境を構築できます。さらに、必要なインフラストラクチャまたはクラスター設定に問題があるため、Kubernetes の新しいバージョンにアップグレードしたり、Amazon EKS が劣化したクラスターにセキュリティ更新をインストールしたりできない場合があります。Amazon EKS は問題を検出したり、問題が解決されたことを検出したりするまでに 3 時間かかる場合があります。
Amazon EKS クラスターの状態は Amazon EKS とそのユーザー間で共有される責任です。IAM 役割や Amazon VPC サブネットの前提となるインフラストラクチャ、および事前に提供する必要があるその他の必要なインフラストラクチャはお客様の責任となります。Amazon EKS はこのインフラストラクチャとクラスターの設定の変更を検出します。
Amazon EKS コンソールからクラスターのヘルスにアクセスするには、Amazon EKS クラスターの詳細ページからオブザーバビリティのダッシュボードにアクセスし、**[クラスターヘルスの問題]** タブの中から **[ヘルスの問題]** と書かれたテーブルを探します。このデータはEKS API の `DescribeCluster` アクションを、例えば AWS コマンドラインインターフェイス内から呼び出すことでも使用できます。
**この機能を使用する理由は何ですか?**
Amazon EKS クラスターの状態を把握しやすくなり、問題を迅速に診断して修正できます。デバッグや AWS サポートケースの作成に時間を費やす必要はありません。例えば、Amazon EKS クラスターのサブネットを誤って削除した場合、Amazon EKS はクロスアカウントのネットワークインターフェイスや `kubectl` exec や `kubectl` ログなどの Kubernetes AWS CLI コマンドを作成できなくなります。この場合、次のエラーとともに処理が失敗します: `Error from server: error dialing backend: remote error: tls: internal error.` そして、次のような Amazon EKS ヘルスの問題が表示されます: `subnet-da60e280 was deleted: could not create network interface`。
**この機能は他の AWS サービスとどのように関連し、連携しますか?**
IAM 役割と Amazon VPC サブネットはクラスターヘルスが問題を検出するための前提条件となるインフラストラクチャの 2 つの例です。この機能はこれらのリソースが正しく設定されていない場合に詳細情報を返します。
**ヘルスに問題があるクラスターには料金がかかりますか?**
はい。Amazon EKS クラスターはすべて標準の Amazon EKS 料金で請求されます。クラスターヘルス機能は追加料金なしで利用できます。
**この機能は AWS アウトポスト の Amazon EKS クラスターで動作しますか?**
はい。クラスターの問題はAWS アウトポスト の拡張クラスターと AWS アウトポスト のローカルクラスターを含む AWS Cloud 内の EKS クラスターで検出されます。クラスターヘルスでは、Amazon EKS Anywhere や Amazon EKS Distro (EKS-D) の問題は検出されません。
**新しい問題が検出されたときに通知を受けることはできますか?**
はい。AWS は新しいクラスターのヘルスの問題が検出されると、E メールと Personal Health Dashboard の通知を送信します。
**コンソールにはヘルスの問題に関する警告が表示されますか?**
はい。ヘルスに問題があるクラスターにはコンソールの上部にバナーが表示されます。
最初の 2 つの列は API レスポンス値に必要なものです。[Health ClusterIssue](https://docs.aws.amazon.com/eks/latest/APIReference/API_ClusterIssue.html) オブジェクトの 3 番目のフィールドは resourceIds で、返される値は課題タイプによって異なります。
| コード | メッセージ | ResourceIds | クラスターは回復可能ですか? |
| --- | --- | --- | --- |
| SUBNET\$1NOT\$1FOUND | クラスターに現在関連付けられている 1 つ以上のサブネットが見つかりませんでした。Amazon EKS update-cluster-config API を呼び出して、サブネットを更新します。 | サブネット ID | はい |
| SECURITY\$1GROUP\$1NOT\$1FOUND | クラスターに現在関連付けられている 1 つ以上のセキュリティグループが見つかりませんでした。Amazon EKS update-cluster-config API を呼び出して、セキュリティグループを更新します | セキュリティグループ ID | はい |
| IP\$1NOT\$1AVAILABLE | クラスターに関連付けられている 1 つ以上のサブネットに、Amazon EKS がクラスター管理操作を実行するための十分な IP アドレスがありません。サブネット内のアドレスを解放するか、Amazon EKS update-cluster-config API を使用して別のサブネットをクラスターに関連付けます。 | サブネット ID | はい |
| VPC\$1NOT\$1FOUND | クラスターに関連付けられている VPC が見つかりませんでした。クラスターを削除して再作成する必要があります。 | VPC ID | いいえ |
| ASSUME\$1ROLE\$1ACCESS\$1DENIED | クラスターは Amazon EKS サービスにリンクされた役割を使用していません。クラスターに関連する役割を引き受けて、必要な Amazon EKS 管理オペレーションを実行することができませんでした。役割が存在し、必要な信頼ポリシーが適用されていることを確認してください。 | クラスター IAM 役割 | はい |
| PERMISSION\$1ACCESS\$1DENIED | クラスターは Amazon EKS サービスにリンクされた役割を使用していません。クラスターに関連付けられている役割では、Amazon EKS に必要な管理操作を実行するための十分なアクセス許可が付与されていません。クラスター役割にアタッチされているポリシーを確認し、別の拒否ポリシーが適用されているかどうかを確認してください。 | クラスター IAM 役割 | はい |
| ASSUME\$1ROLE\$1ACCESS\$1DENIED\$1USING\$1SLR | Amazon EKS クラスター管理サービスにリンクされた役割を引き受けることができませんでした。役割が存在し、必要な信頼ポリシーが適用されていることを確認してください。 | Amazon EKS サービスにリンクされた役割 | はい |
| PERMISSION\$1ACCESS\$1DENIED\$1USING\$1SLR | Amazon EKS クラスター管理サービスにリンクされた役割は Amazon EKS に必要な管理操作を実行するための十分なアクセス許可を付与しません。クラスター役割にアタッチされているポリシーを確認し、別の拒否ポリシーが適用されているかどうかを確認してください。 | Amazon EKS サービスにリンクされた役割 | はい |
| OPT\$1IN\$1REQUIRED | アカウントに Amazon EC2 サービスのサブスクリプションがありません。アカウント設定ページでアカウントサブスクリプションを更新してください。 | 該当なし | はい |
| STS\$1REGIONAL\$1ENDPOINT\$1DISABLED | STS リージョナルエンドポイントは無効になっています。Amazon EKS のエンドポイントで必要なクラスター管理操作を実行できるようにします。 | 該当なし | はい |
| KMS\$1KEY\$1DISABLED | クラスターに関連付けられている AWS KMS キーは無効になっています。クラスターを復元するにはキーを再度有効にします。 | KMS Key Arn | はい |
| KMS\$1KEY\$1NOT\$1FOUND | クラスターに関連付けられている AWS KMS キーが見つかりませんでした。クラスターを削除して再作成する必要があります。 | KMS Key ARN | いいえ |
| KMS\$1GRANT\$1REVOKED | クラスターに関連付けられた AWS KMS キーの付与は取り消されます。クラスターを削除して再作成する必要があります。 | KMS Key Arn | いいえ |
| ETCD\$1DB\$1SIZE\$1EXCEEDED | Amazon EKS クラスターが etcd データベースのサイズ制限を超えました。etcd は、Kubernetes コントロールプレーンで実行され、クラスターの設定と状態を維持するキーと値のデータストアです。クラスターがパフォーマンス低下状態にならないようにするには、不要な Kubernetes オブジェクトを削除して etcd データベースのサイズを減らしてください。データベースサイズに寄与するオブジェクトの特定とクリーンアップに関するガイダンスについては、「[Amazon EKS クラスターでの etcd データベースサイズの管理](https://aws.amazon.com/blogs/containers/managing-etcd-database-size-on-amazon-eks-clusters/)」を参照してください。クリーンアップ後も問題が解決しない場合は、AWS サポートにお問い合わせください。 | クラスター ARN | はい |