Amazon EKS でマネージドノードグループの作成が失敗した際にトラブルシューティングを行う方法を教えてください。

所要時間3分
0

Amazon Elastic Kubernetes Service (Amazon EKS) マネージドノードグループの作成に失敗しました。ノードがクラスターに参加できず、 「インスタンスがkubernetesクラスターに参加できませんでした」というエラーが表示されました。

簡単な説明

Amazon EKS マネージドノードグループの作成が失敗した場合、解決するには次の手順を実行します:

  • AWS Systems Manager オートメーションランブックを使用して、一般的な問題を特定します。
  • ワーカーノードセキュリティグループのトラフィック要件を確認します。
  • ワーカーノードの ID とAccess Management (IAM) のアクセス許可を確認します。
  • クラスターの Amazon Virtual Private Cloud (Amazon VPC) が DNS ホスト名および DNS 解決をサポートしていることを確認します。
  • aws-auth ConfigMap をワーカーノードの NodeInstanceRole で更新します。
  • ワーカーノードのタグを設定します。
  • ワーカーノードの Amazon VPC サブネットに使用可能な IP アドレスがあることを確認します。
  • ワーカーノードがクラスターの API サーバーエンドポイントに到達できることを確認します。
  • Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Registry (Amazon ECR)、および Amazon Simple Storage Service (Amazon S3) の API エンドポイントが AWS リージョンに到達できることを確認します。

解決方法

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください

Systems Manager オートメーションのランブックを使用して、一般的な問題を特定する

AWS Support-TroubleshootEksWorkerNode ランブックを使用して、ワーカーノードがクラスターに参加できない一般的な問題を特定します。

重要: オートメーションが機能するには、ワーカーノードに Systems Manager へのアクセス許可があり、Systems Manager が実行されている必要があります。アクセス許可を付与するには、AWS 管理ポリシー AmazonSSMManagedInstanceCore を EC2 インスタンスプロファイルに対応する IAM ロールにアタッチします。これは、eksctl を使用して作成される Amazon EKS マネージドノードグループのデフォルト設定です。

  1. ランブックを開きます
  2. AWS マネジメントコンソールの AWS リージョンがクラスターと同じリージョンに設定されていることを確認します。
    注: ランブックの詳細については、ランブックの「ドキュメントの詳細」セクションを参照してください。
  3. [入力パラメータ] セクションの [ClusterName] フィールドでクラスターの名前を指定し、[WorkerID] フィールドでインスタンス IDを指定します。
  4. (オプション) AutomationAssumeRole フィールドに、Systems Manager にアクションの実行を許可する IAM ロールを指定します。指定しない場合、現在の IAM エンティティの IAM アクセス許可を使用してランブックのアクションが実行されます。
  5. [実行] を選択します。
  6. [出力] セクションを確認して、ワーカーノードがクラスターに参加していない理由と、それを解決するための手順を確認します。

ワーカーノードセキュリティグループのトラフィック要件を確認する

コントロールプレーンのセキュリティグループとワーカーノードセキュリティグループが、インバウンドトラフィックとアウトバウンドトラフィックの推奨設定で設定されていることを確認します。デフォルトでは、ノードとコントロールプレーン間の通信を容易にするため、Amazon EKS ではノードグループ内のインスタンスにクラスターセキュリティグループが適用されます。マネージドノードグループの起動テンプレートでカスタムセキュリティグループを指定した場合、Amazon EKS ではクラスターセキュリティグループは追加されません。

ワーカーノードの IAM アクセス許可を確認する

ワーカーノードに関連付けられている IAM インスタンスロールに AmazonEKSWorkerNodePolicy および AmazonEC2ContainerRegistryReadOnly ポリシーがアタッチされていることを確認します。

注: Amazon 管理ポリシー AmazonEKS_CNI_Policy を IAM ロールにアタッチする必要があります。ポリシーはノードインスタンスロールにアタッチできます。ただし、kube-system 名前空間の aws-node Kubernetes サービスアカウントに関連付けられているロールにポリシーをアタッチするのがベストプラクティスです。詳細については、「サービスアカウントの IAM ロールを使用する Amazon VPC CNI plugin for Kubernetes の設定」を参照してください。

クラスターの Amazon VPC が DNS ホスト名および DNS 解決をサポートしていることを確認する

EKS クラスターエンドポイントのプライベートアクセスを設定したら、Amazon VPC の DNS ホスト名および DNS 解決を有効にする必要があります。エンドポイントのプライベートアクセスを有効にすると、Amazon EKS により Amazon Route 53 のプライベートホストゾーンが作成されます。その後、ホストゾーンは Amazon EKS によりクラスターの Amazon VPC に関連付けられます。詳細については、「Amazon EKS クラスターエンドポイントアクセスコントロール」を参照してください。

aws-auth ConfigMap をワーカーノードの NodeInstanceRole で更新する

aws-auth ConfigMap がインスタンスプロファイルではなくワーカーノードの IAM ロールで正しく設定されていることを確認します。

ワーカーノードのタグを設定する

ワーカーノードの [タグ] プロパティについては、[key]kubernetes.io/cluster/clusterName に、[value]owned に設定します。

ワーカーノードの Amazon VPC サブネットに使用可能な IP アドレスがあることを確認する

Amazon VPC で IP アドレスが不足している場合は、セカンダリ CIDR を既存の Amazon VPC に関連付けることができます。詳細については、「Amazon EKS VPC およびサブネットの要件と考慮事項」を参照してください。

Amazon EKS ワーカーノードがクラスターの API サーバーエンドポイントに到達できることを確認する

次のゲートウェイを経由するインターネットルートがある場合は、クラスター VPC またはピアリングされたサブネット内の任意のサブネットでワーカーノードを起動できます:

  • NAT
  • インターネット
  • トランジット

制限付きのプライベートネットワークでワーカーノードを起動する場合は、ワーカーノードが Amazon EKS API サーバーエンドポイントに到達できることを確認してください。詳細については、アウトバウンドインターネットアクセスなしで、プライベートクラスターで Amazon EKS を実行するための要件を参照してください。

: NAT ゲートウェイによってバックアップされたプライベートサブネットノードの場合は、パブリックサブネットに NAT ゲートウェイを作成するのがベストプラクティスです。

AWS PrivateLink エンドポイントを使用していない場合は、次の AWS サービスのプロキシサーバー経由で API エンドポイントへのアクセスを確認してください:

  • Amazon EC2
  • Amazon ECR
  • Amazon S3

ワーカーノードが API サーバーにアクセスできることを確認するには、SSH を使用してワーカーノードに接続し、次の netcat コマンドを実行します:

nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443

注: 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com をお使いの API サーバーエンドポイントに置き換えてください。

インスタンスに接続したまま kubelet のログを確認します:

journalctl -f -u kubelet

kubelet ログに問題の原因に関する情報がない場合は、ワーカーノードの kubelet のステータスを確認してください:

sudo systemctl status kubelet

Amazon EKS ログおよびオペレーティングシステムログを収集して、さらにトラブルシューティングを進めてください。

Amazon EC2、Amazon ECR、Amazon S3 の API エンドポイントが AWS リージョンに到達できることを確認する

SSH を使用してワーカーノードの 1 つに接続し、サービスごとに次のコマンドを実行します:

$ nc -vz ec2.region.amazonaws.com 443
$ nc -vz ecr.region.amazonaws.com 443
$ nc -vz s3.region.amazonaws.com 443

注: region をワーカーノードの AWS リージョンに置き換えてください。

ワーカーノードのユーザーデータを設定する

AMI を指定したマネージドノードグループの起動テンプレートの場合、ワーカーノードがクラスターに参加するためのブートストラップコマンドを指定する必要があります。Amazon EKS では、デフォルトのブートストラップコマンドはユーザーデータにマージされません。詳細については、「Amazon EKS マネージドノードグループでの起動テンプレートとカスタム AMI サポートの紹介」と「AMI を指定する」を参照してください。

ブートストラップコマンドを含む起動テンプレートの例:

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments}

注: ${ClusterName} をお使いの Amazon EKS クラスターの名前に置き換えてください。必要に応じて ${BootstrapArguments} を追加のブートストラップ値に置き換えてください。

関連情報

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

ワーカーノードを Amazon EKS クラスターに参加させる方法を教えてください。

コメントはありません

関連するコンテンツ