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

この章では、Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。特定の Amazon EKS 領域のトラブルシューティングが必要な場合、別の IAM のトラブルシューティング、Amazon EKS Connector での問題のトラブルシューティング、および「EKS アドオンを使用した ADOT のトラブルシューティング」を参照してください。

その他のトラブルシューティング情報については、AWS re:Postの 「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 内のサブネットを使用して、クラスターを再作成してください。

クラスターを配置できないアベイラビリティーゾーンがあります。サブネットが属するアベイラビリティーゾーンを、サブネットの要件と考慮事項 内のアベイラビリティーゾーンのリストと比較してください。

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

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

• ノードがマネージド型の場合、Amazon EKS はノードグループの作成時に、aws-auth ConfigMap にエントリを追加します。エントリが削除または変更された場合は、再度追加する必要があります。詳細については、ターミナルに eksctl create iamidentitymapping --help を入力してください。現在の aws-auth ConfigMap エントリを確認するには、次のコマンドの my-cluster をクラスターの名前に置き換えて、変更したコマンド eksctl get iamidentitymapping --cluster my-cluster を実行します。指定するロールの ARN には、/ 以外のパスを含めることはできません。例えば、ロールの名前が development/apps/my-role の場合、ロールの ARN を指定するときに my-role に変更する必要があります。ノード IAM ロール ARN (インスタンスプロファイルの ARN ではない) を指定していることを確認してください。

  ノードがセルフマネージド型で、ノードの IAM ロールの ARN のアクセスエントリを作成していない場合は、マネージド型ノード用にリストされているのと同じコマンドを実行します。ノード IAM ロールの ARN のアクセスエントリを作成している場合、そのエントリがアクセスエントリで正しく設定されていない可能性があります。aws-auth ConfigMap エントリまたはアクセスエントリのプリンシパル ARN として、ノード IAM ロール ARN (インスタンスプロファイルの ARN ではない) が指定されていることを確認してください。アクセスエントリの詳細については、「アクセスエントリを管理する」を参照してください。

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

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

  キー	値
  kubernetes.io/cluster/my-cluster	owned

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

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

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

• マネージドノードグループ内のノードが 15 分以内にクラスターに接続しない場合、「NodeCreationFailure」という正常性の問題が出力され、コンソールのステータスが Create failed に設定されます。起動時間が遅い Windows AMI の場合、この問題は高速起動を使用して解決できます。

ワーカーノードがクラスターに参加できない一般的な原因を特定してトラブルシューティングするには、AWSSupport-TroubleshootEKSWorkerNode ランブックを使用できます。詳細については、「AWS Systems Manager Automation ランブックリファレンス」の「AWSSupport-TroubleshootEKSWorkerNode」を参照してください。

許可されていないか、アクセスが拒否されました (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 ファイルを更新してください。詳細については、「Amazon EKS クラスターの kubeconfig ファイルを作成または更新する」を参照してください。

• クラスターが アクセスエントリを管理する の前提条件セクションの最小プラットフォーム要件を満たしている場合、IAM プリンシパルにはアクセスエントリは存在しません。存在する場合、必要な Kubernetes グループ名が定義されていないか、適切なアクセスポリシーが関連付けられていません。詳細については、「アクセスエントリを管理する」を参照してください。

• クラスターが アクセスエントリを管理する の最小プラットフォーム要件を満たしていない場合、IAM プリンシパルのエントリは aws-auth ConfigMap に存在しません。存在しても、Kubernetes Role または ClusterRole にバインドされている、または必要なアクセス許可を持つ Kubernetes グループ名にはマップされません。Kubernetes ロールベース認証 (RBAC) オブジェクトの詳細については、Kubernetes ドキュメントの「RBAC 承認の使用」を参照してください。現在の aws-auth ConfigMap エントリを確認するには、次のコマンドの my-cluster をクラスターの名前に置き換えて、変更したコマンド eksctl get iamidentitymapping --cluster my-cluster を実行します。IAM プリンシパルの ARN を含むエントリが ConfigMap にない場合は、ターミナルに eksctl create iamidentitymapping --help を入力して作成方法を確認してください。

AWS CLI をインストールして設定する場合は、使用する IAM 認証情報を設定できます。詳細については、「AWS CLI ユーザーガイド」の「AWS Command Line Interface の設定。」を参照してください。クラスター上の Kubernetes オブジェクトにアクセスする IAM ロールを引き受ける場合は、IAM ロールを使用するように kubectl を設定することもできます。詳細については、「Amazon EKS クラスターの kubeconfig ファイルを作成または更新する」を参照してください。

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?｣を参照してください。

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

Instances failed to join the Kubernetes cluster

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

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

マネージド型ノードグループでハードウェアのヘルスに問題が発生した場合は、Amazon EKS によって問題の診断に役立つエラーメッセージが返されます。これらのヘルスチェックは Amazon EC2 ヘルスチェックに基づいているため、ソフトウェアの問題は検出されません。次のリストは、エラーコードについての説明です。

AccessDenied

Amazon EKS または 1 つ以上の管理対象ノードが、Kubernetes クラスター API サーバーでの認証または承認に失敗しています。共通のレスポンスヘッダーの詳細については、「AccessDeniedマネージド型ノードグループエラーを修正する」を参照してください。プライベートWindows AMI では、Not authorized for imagesエラーメッセージとともにこのエラーコードが表示されることもあります。詳細については、「Not authorized for images」を参照してください。

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 アドレスを使用してインターネットにアクセス可能です。ノードが存在するサブネットに関連付けられているセキュリティグループが、通信を許可する必要があります。詳細については、サブネットの要件と考慮事項およびAmazon EKS セキュリティグループの要件および考慮事項を参照してください。

• ノードと VPC は、プライベートクラスターの要件 に記載される要件を満たしている必要があります。

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 EKSWindows AMIWindows を使用してマネージドノードグループを起動することです。新しい Windows AMI をリリースすると、AWS は 4 か月以上前の AMI を非公開にし、アクセス不可にします。マネージド型ノードグループがプライベート Windows AMI を使用している場合は、Windows マネージド型ノードグループを更新することを検討してください。非公開になった AMI へのアクセスを可能にできるかは保証できませんが、AWS サポートにチケットを提出することでアクセスをリクエストできます。詳細については、Windows インスタンス用 Amazon EC2 ユーザーガイドの「パッチ、セキュリティアップデート、AMI ID」を参照してください。

ノードが NotReady 状態です

ノードが NotReady 状態になった場合、ノードに異常があり、新しい Pods をスケジュールできない可能性があります。これは、ノードに CPU、メモリ、利用可能なディスクスペースの十分なリソースがないなど、さまざまな理由で発生します。

Amazon EKS 最適化 Windows AMI の場合、kubelet 設定のデフォルトでは、コンピューティングリソースの予約は指定されていません。リソースの問題を防ぐために、kubelet に kube-reserved および/または system-reserved の設定値を指定することで、システムプロセスのコンピューティングリソースを予約できます。これを行うには、ブートストラップスクリプトの -KubeletExtraArgs コマンドラインパラメータを使用します。詳細については、「Kubernetes ドキュメント」の「Reserve Compute Resources for System Daemons」、およびこのユーザーガイドの「ブートストラップスクリプトの設定パラメータ」を参照してください。

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 エラーと承認エラーが表示される場合があります。

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 ロールのエントリが含まれていないかのどちらかです。

   この ConfigMap エントリは、ノードが次の条件のうち 1 つを満たす場合に必要です。

   • 任意の Kubernetes またはプラットフォームバージョンのクラスター内のマネージド型ノード。

   • アクセスエントリを管理する トピックの前提条件セクションに記載されているいずれかのプラットフォームバージョンよりも前のクラスター内のセルフマネージド型ノード。

   この問題を解決するには、次のコマンドの my-cluster をクラスターの名前に置き換えて、変更したコマンド 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 には、/ 以外のパスを含めることはできません。例えば、ロールの名前が development/apps/my-role の場合、ロールの ARN を指定するときに my-role に変更する必要があります。ノード IAM ロール ARN (インスタンスプロファイルの ARN ではない) を指定していることを確認してください。

2. セルフマネージド型ノードが、アクセスエントリを管理する トピックの前提条件に記載されている最小バージョンのプラットフォームバージョンのクラスターにあるものの、ノードの IAM ロールのエントリが aws-auth ConfigMap (前の項目を参照) に記載されていないか、ロールのアクセスエントリが存在しません。この問題を解決するには、次のコマンドの my-cluster をクラスターの名前に置き換えて、変更したコマンド aws eks list-access-entries --cluster-name my-cluster を実行することで、現在のアクセスエントリを確認します。次のコマンドは、ノードの IAM ロールのアクセスエントリを追加します。111122223333 を IAM ロールの AWS アカウント ID に、myAmazonEksNodeRole をノードのロールの名前に置き換えます。Windows ノードを使用している場合は、EC2_Linux を 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 サーバーエンドポイントを継続的に再生成およびテストします。このエラーは、コントロールプレーンでクラスターのローリング更新を行う手順 (設定の変更やバージョンの更新など) で一時的に発生することもあります。

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

InvalidClientTokenId

中国 AWS リージョン でクラスターにデプロイされている 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 Pod 展開のステータスは ContainerCreating のままになります。

データプレーンでレガシー Windows サポートがある場合に問題を解決するには、VPC アドミッションウェブフック証明書の更新 を参照してください。クラスタとプラットフォームのバージョンが Windows サポートの前提条件 に記載されているバージョンよりも遅い場合は、データプレーンでレガシー Windows サポートを削除し、コントロールプレーンで有効にすることをお勧めします。一度行えば、ウェブフック証明書を管理する必要はありません。詳細については、「Amazon EKS クラスター の Windows サポートの有効化」を参照してください。

コントロールプレーンをアップグレードする前に、ノードグループが Kubernetes バージョンと一致する必要があります

コントロールプレーンを新しい Kubernetes バージョンにアップグレードする前に、クラスター内のマネージドノードと Fargate ノードのマイナーバージョンが、コントロールプレーンの現在のバージョンのバージョンと同じである必要があります。Amazon EKS update-cluster-version API は、すべての EKS マネージド型ノードが現在のクラスターバージョンにアップグレードされるまで、リクエストを拒否します。Amazon EKS は、マネージド型ノードをアップグレードするための API を提供します。マネージド型ノードグループの Kubernetes バージョンのアップグレードについては、マネージド型ノードグループの更新 を参照してください。Fargate ノードのバージョンをアップグレードするには、ノードによって表される pod を削除し、コントロールプレーンをアップグレードした後に pod を再デプロイします。詳細については、「Amazon EKS クラスターの Kubernetes バージョンの更新」を参照してください。

多数のノードを起動すると、Too Many Requests エラーが発生します。

多数のノードを同時に起動すると、Amazon EC2 ユーザーデータの実行ログに「Too Many Requests」というエラーメッセージが表示される場合があります。これは、コントロールプレーンが describeCluster 呼び出しで過負荷になっているために発生する可能性があります。過負荷が原因で、スロットリングが発生し、ノードがブートストラップスクリプトを実行できなくなり、ノードが完全にクラスターに参加できなくなります。

--apiserver-endpoint、--b64-cluster-ca、および --dns-cluster-ip 引数がノードブートストラップスクリプトに渡されていることを確認してください。これらの引数を含める場合、ブートストラップスクリプトが describeCluster 呼び出しを行う必要がなくなり、コントロールプレーンが過負荷になるのを防ぐのに役立ちます。詳細については、「Amazon EKS に最適化された Linux/Bottlerocket AMI に含まれる bootstrap.sh ファイルに引数を渡すためのユーザーデータを提供する」を参照してください。

Kubernetes API サーバーリクエストでの HTTP 401 不正エラーレスポンス

これらのエラーは、Pod のサービスアカウントトークンがクラスターで期限切れになった場合に表示されます。

Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンのリクエストは拒否されます。以前の Kubernetes バージョンでは、トークンに有効期限がありませんでした。つまり、これらのトークンに依存しているクライアントは、1 時間以内にトークンを更新する必要があります。無効なトークンが原因で Kubernetes APIサーバーがリクエストを拒否しないようにするには、ワークロードで使用される Kubernetes クライアント SDK のバージョンが、次のバージョンと同じか、それ以降である必要があります。

• Go バージョン 0.15.7 以降

• Python バージョン 12.0.0 以降

• Java バージョン 9.0.0 以降

• JavaScript バージョン 0.10.3 以降

• Ruby master ブランチ

• Haskell バージョン0.3.0.0

• C# バージョン 7.0.5 以降

以前のトークンを使用しているクラスター内の既存の Pods をすべて識別できます。詳細については、「Kubernetes サービス アカウント」を参照してください。

Amazon EKS プラットフォームのバージョンは、現在のプラットフォーム バージョンより 2 つ以上遅れています

これは、Amazon EKS がクラスターの プラットフォームバージョン を自動的に更新できない場合に発生する可能性があります。これには多くの原因がありますが、一般的な原因のいくつかが続きます。これらの問題のいずれかがクラスターに当てはまる場合、それはまだ機能する可能性がありますが、そのプラットフォームバージョンは Amazon EKS によって更新されません。

問題

クラスターIAMロール が削除されました - このロールは、クラスターの作成時に指定されました。次のコマンドで、どのロールが指定されたかを確認できます。my-cluster の部分は、自分のクラスター名に置き換えます。

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

出力例は次のとおりです。

eksClusterRole

ソリューション

同じ名前で新しい クラスター IAM ロール を作成します。

問題

クラスターの作成中に指定されたサブネットが削除されました - クラスターで使用するサブネットは、クラスターの作成中に指定されました。次のコマンドで、指定されたサブネットを確認できます。my-cluster の部分は、自分のクラスター名に置き換えます。

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 を確認できます。my-cluster の部分は、自分のクラスター名に置き換えます。

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 バージョンの更新を開始すると、同じ理由で更新が失敗する可能性があります。

Amazon EKS がクラスターのプラットフォームバージョンを更新しないその他の理由

• クラスターの作成時に指定した各サブネットで、少なくとも 6 つ (ただし、16 をお勧めします) の使用可能な IP アドレスがありません。サブネットに十分な使用可能な IP アドレスがない場合は、サブネット内の IP アドレスを解放するか、十分な使用可能な IP アドレスを持つサブネットを使用するように、クラスターで使用されるサブネットを変更する必要があります。

• クラスターの作成時に シークレットの暗号化 を有効にし、指定した AWS KMS キーが削除されました。Amazon EKS でクラスターを更新する場合は、新しいクラスターを作成する必要があります

クラスターの正常性に関するよくある質問およびエラーコードと解決パス

Amazon 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 Command Line Interface 内から呼び出すことでも確認できます。

この機能を使用する理由は何ですか?

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 Outposts の Amazon EKS クラスターで動作しますか?

はい。クラスターの問題は、AWS Outposts の拡張クラスターと AWS Outposts のローカルクラスターを含む AWS クラウド内の EKS クラスターで検出されます。クラスターヘルスでは、Amazon EKS Anywhere や Amazon EKS Distro (EKS-D) の問題は検出されません。

新しい問題が検出されたときに通知を受けることはできますか?

いいえ、Amazon EKS コンソールを確認するか、EKS DescribeCluster API を呼び出す必要があります。

コンソールにはヘルスの問題に関する警告が表示されますか?

はい。ヘルスに問題があるクラスターには、コンソールの上部にバナーが表示されます。

最初の 2 つの列は API レスポンス値に必要なものです。Health ClusterIssue オブジェクトの 3 番目のフィールドは resourceIds で、返される値は課題タイプによって異なります。

Code	メッセージ	ResourceIds	クラスターは回復可能ですか?
SUBNET_NOT_FOUND	クラスターに現在関連付けられている 1 つ以上のサブネットが見つかりませんでした。Amazon EKS update-cluster-config API を呼び出してサブネットを更新します。	サブネット ID	はい
SECURITY_GROUP_NOT_FOUND	クラスターに現在関連付けられている 1 つ以上のセキュリティグループが見つかりませんでした。Amazon EKS update-cluster-config API を呼び出して、セキュリティグループを更新します	セキュリティグループ ID	はい
IP_NOT_AVAILABLE	クラスターに関連付けられている 1 つ以上のサブネットに、Amazon EKS がクラスター管理操作を実行するための十分な IP アドレスがありません。サブネット内のアドレスを解放するか、Amazon EKS update-cluster-config API を使用して別のサブネットをクラスターに関連付けます。	サブネット ID	はい
VPC_NOT_FOUND	クラスターに関連付けられている VPC が見つかりませんでした。クラスターを削除して再作成する必要があります。	VPC ID	[いいえ]
ASSUME_ROLE_ACCESS_DENIED	クラスターは Amazon EKS サービスにリンクされたロールを使用していません。クラスターに関連するロールを引き受けて、必要な Amazon EKS 管理オペレーションを実行することができませんでした。ロールが存在し、必要な信頼ポリシーが適用されていることを確認してください。	クラスター IAM ロール	はい
PERMISSION_ACCESS_DENIED	クラスターは Amazon EKS サービスにリンクされたロールを使用していません。クラスターに関連付けられているロールでは、Amazon EKS に必要な管理操作を実行するための十分なアクセス許可が付与されていません。クラスターロールにアタッチされているポリシーを確認し、別の拒否ポリシーが適用されているかどうかを確認してください。	クラスター IAM ロール	はい
ASSUME_ROLE_ACCESS_DENIED_USING_SLR	Amazon EKS クラスター管理サービスにリンクされたロールを想定することはできませんでした。ロールが存在し、必要な信頼ポリシーが適用されていることを確認してください。	Amazon EKS サービスにリンクされたロール	はい
PERMISSION_ACCESS_DENIED_USING_SLR	Amazon EKS クラスター管理サービスにリンクされたロールは、Amazon EKS に必要な管理操作を実行するための十分なアクセス許可を付与しません。クラスターロールにアタッチされているポリシーを確認し、別の拒否ポリシーが適用されているかどうかを確認してください。	Amazon EKS サービスにリンクされたロール	はい
OPT_IN_REQUIRED	あなたのアカウントには Amazon EC2 サービスのサブスクリプションがありません。アカウント設定ページでアカウントサブスクリプションを更新してください。	該当なし	はい
STS_REGIONAL_ENDPOINT_DISABLED	STS リージョナルエンドポイントは無効になっています。Amazon EKS のエンドポイントで必要なクラスター管理操作を実行できるようにします。	該当なし	はい
KMS_KEY_DISABLED	クラスターに関連付けられている AWS KMS キーは無効になっています。クラスターを復元するには、キーを再度有効にします。	KMS Key Arn	はい
KMS_KEY_NOT_FOUND	クラスターに関連付けられている AWS KMS キーが見つかりませんでした。クラスターを削除して再作成する必要があります。	KMS Key ARN	[いいえ]
KMS_GRANT_REVOKED	クラスターに関連付けられた AWS KMS キーの付与は取り消されます。クラスターを削除して再作成する必要があります。	KMS Key Arn	[いいえ]