Amazon EKS に Container Insights を導入する手順をまとめてみた
Amazon EKS には、Amazon CloudWatch Container Insights (以降、Container Insights )を導入できます。 Container Insights を導入すると、Amazon EKS クラスターやノード、Pod などといった単位でメトリクスを収集し、Amazon CloudWatch アラームを設定できます。またログを収集して Amazon CloudWatch Logs で参照・分析することもできるので、AWS に慣れた人には Amazon EKS のモニタリングやロギングを行う仕組みとして取り組みやすいのではないでしょうか。
Amazon EKS クラスターに Container Insights を導入する手順は下記の AWS のドキュメントに記載されています。
ただこのドキュメントに目を通していて、個人的に「おや？」と思いました。 というのも、メトリクスやログを収集する Agent に Amazon CloudWatch へのアクセスを許可するという重要な部分の設定については他のドキュメントを読んで実施してね、という流れになっているからです。
個人的には、何かを操作する手順をドキュメントに記載するときには、そのページに必要な説明や手順をすべて掲載し、読者は 1つのページを上から下に読めば必要な手順を理解・実行できるようにすべきと思っています。 なので、自分のメモ用に、もしくは他の人への説明用に、具体的な手順をまとめておこうと思い立ちました。
なお、今回まとめた手順は、2023年4月時点の検証に基づいています。 Amazon EKS クラスターと、Amazon EC2 インスタンスを使用するマネージドノードグループも作成済です。また、メトリクスやログを収集する Agent として CloudWatch Agent と Fluent Bit の Agent を使用する前提とします。
目次
- Agent への Amazon CloudWatch へのアクセスの許可について
- 手順 1. クイックスタートセットアップの実施
- 手順 2. IRSA（IAM Roles for Service Accounts）による既存の Service Accountのオーバーライド
- 手順 3. 動作確認
- 今回の所感
Agent への Amazon CloudWatch へのアクセスの許可について
Amazon EKS では、 CloudWatch Agent と Fluent Bit の Agent は Kubernetes の DaemonSet で管理される Pod として実行されます。これらの Agentに Amazon CloudWatch へのアクセスを許可する方法は 2種類です。 どちらも AWS IAM の管理ポリシーである CloudWatchAgentServerPolicy を設定した IAM ロールを使用しますが、その IAM ロールの適用方法が異なります。
1. ノードである EC2 インスタンスに IAM のロールを設定する。
この方法は設定自体はシンプルですが、Agent 以外の Pod にも Amazon CloudWatch へのアクセスを許可してしまうことになります。これは最小権限の原則の観点から望ましくありません。
2. Agent の Pod に IAM ロール と関連付けた Service Account を設定する。
この方法の場合、Service Account を設定した Pod だけに Amazon CloudWatch へのアクセスを許可できます。よって今回は、こちらの方法を使用する前提とします。
手順 1. クイックスタートセットアップの実施
この手順は、次のドキュメント通りに実施することで完了できます。
下記は、クラスター名が test-cluster という東京リージョンの Amazon EKS クラスターにクイックスタートセットアップを実施する例です。
ClusterName=test-cluster RegionName=ap-northeast-1 FluentBitHttpPort='2020' FluentBitReadFromHead='Off' [[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On' [[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On' curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/;s/{{region_name}}/'${RegionName}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -
この手順により amazon-cloudwatch という名前の Namespace が作成され、主要なオブジェクトが作成されます。
Agent となる Pod の起動を次のコマンドで確認します。
kubectl get pods -n amazon-cloudwatch
Pod は DaemonSet で管理されているので、ノード数分の Pod が表示されれば OK です。
NAME READY STATUS RESTARTS AGE cloudwatch-agent-5b4hb 1/1 Running 0 2m22s cloudwatch-agent-6n5qc 1/1 Running 0 2m22s fluent-bit-d2gfh 1/1 Running 0 2m22s fluent-bit-hncw9 1/1 Running 0 2m22s
手順 2. IRSA（IAM Roles for Service Accounts）による既存の Service Accountのオーバーライド
次に Agent の Pod に Amazon CloudWatch へのアクセスを許可します。
手順 1. が完了した段階で、CloudWatch Agent の Pod には、cloudwatch-agent という Service Accountが、Fluent Bit の Agent には fluent-bit という Service Account が設定されています。
これらの Service Account に、AWS IAM のロールを関連付ける必要があります。 これは、Amazon EKS でサポートされている IRSA（IAM Roles for Service Accounts） という仕組みを使用することで実現できます。
IRSA を使用するには、まず Amazon EKS クラスターの OpenID Connect プロバイダ (OIDC プロバイダ）を AWS IAM に登録します。 これは次のコマンドにて行えますが、クラスター毎に 1 回実施すれば OK です。
eksctl utils associate-iam-oidc-provider --cluster ${ClusterName} --approve
次に Service Account cloudwatch-agent に CloudWatchAgentServerPolicy を設定した IAM ロールを設定します。
eksctl create iamserviceaccount \ --name cloudwatch-agent \ --namespace amazon-cloudwatch \ --role-name ${ClusterName}-cloudwatch-agent-role \ --cluster ${ClusterName} \ --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \ --override-existing-serviceaccounts \ --approve
Service Account fluent-bit にも同じように CloudWatchAgentServerPolicy を設定した IAM ロールを設定します。
eksctl create iamserviceaccount \ --name fluent-bit \ --namespace amazon-cloudwatch \ --role-name ${ClusterName}-fluent-bit-role \ --cluster ${ClusterName} \ --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \ --override-existing-serviceaccounts \ --approve
ここで ポイント になるのは、7 行目の --override-existing-serviceaccounts オプションです。
手順 1. のクイックスタートセットアップですでに Service Account は作成されています。--override-existing-serviceaccounts オプションを付けることで作成済の Service Account に AWS IAM のロールを設定できます。
この後、Agent の Pod の再起動が必要になるので、DaemonSet をリスタートしておきましょう。
kubectl rollout restart ds cloudwatch-agent -n amazon-cloudwatch kubectl rollout restart ds fluent-bit -n amazon-cloudwatch
手順 3. 動作確認
この後 1～2分ほど待って、Container Insights が使用できるか確認してみます。
AWS マネジメントコンソール で Amazon CloudWatch のページ左側のメニューから [ インサイト ] - [ Container Insights ] を選択します。 下図では、[ パフォーマンスのモニタリング ] で test-cluster のメトリクスの表示を確認しています。
他にも、様々な切り口でメトリクスを確認してみて下さい。
また、ログの収集も確認してみます。Amazon CloudWatch のページ左側のメニューから [ ログ ] - [ ロググループ ] を選択します。 下図では、test-cluster のロググループが作成されていることを確認しています。
今回の所感
今回紹介した手順でポイントになるのは、手順 2. です。手順 2. については、AWS の Container Insights のドキュメントには具体的な記載がありません。ただ、手順 2.の実施においては、Kubernetes の RBAC や Service Account、Amazon EKS の IRSA の仕組みの理解が必要になるので、AWS のドキュメントのように他のページで確認して下さい、という記述になるのは、仕方がない部分もあるのかもしれません。
とはいうものの、Container Insights を導入する具体的な手順は明確に示しておくことは必要かと思いますので、この記事でそれをまとめることができてよかったと思ってます！
kubesec で AWS KMS のキーを使って Secret を暗号化・復号してみる
Kubernetes の Secret リソースでマニフェストで作成するとき、Secret として秘匿したいデータを Base 64 でエンコードして指定します。
ただ、Base 64は単なるエンコードなので、そのままでマニフェストを保存することは、セキュリティ上避けたいですよね。そのため、Secret のデータの暗号化や復号を行う kubesec や SealedSecrets などのツールが提供されています。
これまで「kubesecとか使えば暗号化や復号はできるよね」と頭でしか理解してなかったんですが、kubesec を実際に触ってみようと思い立ったので、そのときのメモをここに書いておきたいと思います。
なお、今回は 下図のように AWS KMS のキーを使用して暗号化・復号する前提とします。
目次
1. AWS KMS のキーの作成
今回、暗号化や復号に必要なキーを AWS KMS を使用して生成しますので、AWS KMSにアクセスできるようにする必要があります。そのため、使用しているAWS IAM のユーザーまたはロールに、AWS IAM のポリシーを設定します。
今回は、使用している AWS IAM のユーザーに AWSKeyManagementServicePowerUser という管理ポリシーを設定する前提としますが、実際に使用する際は最小権限の原則に基づいて設定して下さい。
AWS KMS を操作する上での AWS IAM のポリシーについては次のドキュメントに例があるので参考にしましょう。
AWS KMS キーの作成は AWS マネジメントコンソールからでも行えますが、今回は AWS CLI のコマンドで作成してみます。
aws kms create-key --description "demo for kubesec"
--description オプションで指定する文字列の値は任意です。
キー作成が完了すると、次のような 出力が表示されるので、この中の Arn の値をメモしておきましょう。
{ "KeyMetadata": { "AWSAccountId": "000000000000", "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "Arn": "arn:aws:kms:ap-northeast-1:000000000000:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "CreationDate": "2023-03-25T09:31:57.061000+00:00", "Enabled": true, "Description": "demo for kubesec", "KeyUsage": "ENCRYPT_DECRYPT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT", "KeySpec": "SYMMETRIC_DEFAULT", "EncryptionAlgorithms": [ "SYMMETRIC_DEFAULT" ], "MultiRegion": false } }
2. kubesec のインストール
kubesec のインストール方法などについては、下記を参考にしました。
今回は Linux の環境にインストールしますので、次のコマンドを実行します。
curl -sSL https://github.com/shyiko/kubesec/releases/download/0.9.2/kubesec-0.9.2-linux-amd64 \ -o kubesec && chmod a+x kubesec && sudo mv kubesec /usr/local/bin/
その後、確認のため次のコマンドを実行します。
kubesec --version
0.9.2 のようにバージョン ID が出力されれば OK です。
3. Secret のマニフェストの暗号化
ではいよいよ、Secret のマニフェストを暗号化してみます。
今回は、次の内容を secret.yaml として保存して使用します。
apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque data: username: YWRtaW4= password: YWRtaW4xMjM0
kubesec で AWS KMS のキーを使用して暗号化するときは、--key オプションに キーの ARN を指定します。
次の例では、secret.yaml を暗号化したマニフェストを 標準出力 に表示します。
kubesec encrypt --key=aws:<ARN of AWS KMS key> secret.yaml
実行すると次のような内容が表示されます。
apiVersion: v1 data: password: (暗号化された値） username: (暗号化された値） kind: Secret metadata: name: my-secret type: Opaque # kubesec:v:3 # kubesec:aws:arn:aws:kms:ap-northeast-1:0000000000001:key/xxxxx # kubesec:mac:xxxxx
data: 以下の username や password の値が暗号化されていることを確認できました。
また、-i オプションを付けると、指定したマニフェストファイルに暗号化した値を直接変更します。
kubesec encrypt -i --key=aws:<ARN of AWS KMS key> secret.yaml
上記を実行すると、secret.yaml の data: 以下の username や password の値が直接変更されたことが確認できます。
4. Secret のマニフェストの復号
暗号化されたマニフェストを復号する場合は、decrypt を使用します。
次の例では、暗号化されている secret.yaml を復号して標準出力に表示します。
kubesec decrypt secret.yaml
実行すると次のような内容が表示されます。
apiVersion: v1 data: password: YWRtaW4xMjM0 username: YWRtaW4= kind: Secret metadata: name: my-secret type: Opaque
また、暗号化と同じように -i オプションを付けると、暗号化されたファイルに復号した値を直接変更します。
kubesec decrypt -i secret.yaml
上記を実行すると、暗号化された secret.yaml の data: 以下の username や password の値が直接変更されたことが確認できます。
5.今回の所感
kubesec と AWS KMS のキーを使用して Secret の値を暗号化・復号する仕組み自体は、とてもシンプルです。
GitOps のように Kubernetes のマニフェストを Git リポジトリに保存・管理してデプロイする場合は、Secret は kubesec のようなツールを使い、暗号化して保存し、Kubernetes クラスタに適用する際に自動的に復号するような仕組みを考えたいと思いました。
一方で、AWS KMS のキーの権限の管理は厳格に行う必要があります。キーを作成できる権限、キーを使用して暗号化・復号できる権限などは IAMのユーザーまたはロールごとに最小権限の原則に基づいて設定する必要があるので、その管理や運用を漏れなく実施する必要性を強く感じました。
今回は 暗号化・復号のツールとして kubesec を使ってみましたが、他にも SealedSecrets といった便利なツールもあるので、また別の機会に触ってみたいです！
Amazon EKS にて Ingress で SSL を有効化してみる
Amazon EKS クラスターでは、AWS Load Balancer Controller を導入すると Ingress オブジェクトを作成時に、ELB のロードバランサーを作成できます。
今回は、IngressからSSL を有効化したELB ( Application Load Balancer ) を作成する手順をまとめてみます。
これは、2022年 10 月 1 日時点で試した内容です。
前提
Amazon EKS クラスターは構成済で、AWS Load Balancer Controller も導入済です。
このクラスターに接続できる クライアントも用意できています。
また、サーバー証明書を発行するのに必要なドメインの管理者であり、Amazon Route 53 でドメインレコードを設定できる前提です。
目標
次のような構成で、https://ingress.nobelabo.net で Pod にアクセスできるようにすることが目標です。
AWS Certificate Manager ( ACM ) でサーバー証明書を発行
AWS マネジメントコンソールから、完全修飾ドメイン名を指定してパブリック証明書のリクエストを発行します。
Eメールまたは DNSによる検証を行うと証明書が発行されます。
検証は、ドメインの管理者である証明としてEメールを受信、または 対象のDNSに検証用のレコードを追加します。詳細は、次のドキュメントを参照しましょう。
発行された証明書の ARN をメモしておきます。
Deployment の作成
ingress からアクセスする Pod 用の Deployment を作成します。
次はあくまで例であり個人的に作ったコンテナイメージを指定してますが、もっとシンプルに nginx などを使っても良いと思います。
ここでは、deployment.yaml に保存した前提とします。
apiVersion: apps/v1 kind: Deployment metadata: name: python-web-ec2-deployment spec: replicas: 2 selector: matchLabels: app: python-web-ec2 template: metadata: labels: app: python-web-ec2 spec: containers: - name: python-web-ec2 image: tnobe/python-web-ec2 ports: - containerPort: 8000
マニフェストが用意出来たら、作成して Pod が起動したことを確認します。
kubectl apply -f deployment.yaml
kubectl get pods
Ingress と Service の作成
ではいよいよ Ingress と Service を作成します。
次のようなマニフェストを用意します。
ここでは、ingress.yaml に保存した前提とします。
apiVersion: v1 kind: Service metadata: name: my-service-ingress-ssl spec: ports: - port: 80 targetPort: 8000 protocol: TCP type: ClusterIP selector: app: python-web-ec2 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress-alb-ip-ssl annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]' alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-1:000000000000:certificate/6654fefe-7976-4ce7-8cad-44455fc79291 spec: rules: - http: paths: - path: / pathType: Prefix backend: service: name: my-service-ingress-ssl port: number: 80
annotations で alb.ingress.kubernetes.io/listen-ports を指定し、HTTPS: 443 も使用するように指定します。
また、alb.ingress.kubernetes.io/certificate-arn で発行した ACM の証明書の ARN を指定します。
マニフェストが用意出来たら、作成して ingress が起動したことを確認します。
kubectl apply -f ingress.yaml
kubectl get ingress
次は、出力から抜粋した例です。
NAME CLASS HOSTS ADDRESS my-ingress-alb-ip-ssl <none> * xxxxx.ap-northeast-1.elb.amazonaws.com
ADDRESS 列に表示されているのが、Application Load Balancer (ALB) のDNS名になります。
この段階で、ブラウザから http://(ALBのDNS名） で Pod にアクセスできることを確認しておきます。
DNS に 別名レコードを追加
今回は 個人的に管理している 別の AWS アカウントのRoute 53 のホストゾーンで DNS レコードを管理しているので、 AWS マネジメントコンソールから CNAME レコードを追加します。
レコード名： ingress.nobelabo.net
レコードタイプ： CNAME
値： ALBのDNS名
ルーティングポリシー：シンプル
これで、https://ingress.nobelabo.net で Pod にアクセスできるようになりました！
（現在は、https://ingress.nobelabo.net はアクセスできないようにしています。）
最後に
Amazon EKS に AWS Load Balancer Controller を導入したとき Ingress で SSL でリスニングする時の方法について、これまで日本語で説明されたドキュメントを見つけることができなかったので、このブログを自分用のメモにしておきたいと思います。
Amazon EKS で Pod から AWS Secrets Manager のシークレットを取得する
今回は、AWS Secrets Manager で管理しているシークレットの情報を Amazon EKS の Pod から取得させてみます。
これを実現するために、AWS Secrets and Config Provider (ASCP) を使用します。
下図がそのイメージです。
ASCP については、次の AWS ブログの記事や、AWS のドキュメントにも情報があるので、併せてご参照ください。
ここに記述している内容は、2022 年 9 月13 日時点で動作を確認しています。
また、対象にしている Kubernetes のバージョンは 1.23 です。
前提と環境
今回は、大阪リージョンの「 ASCP-cluster 」という名前の EKS クラスター (バージョンは 1.23 ) を使う前提とします。
kubectl や eksctl 、AWS CLI 、Helm、git が使用でき、対象のクラスターに接続できる Amazon Linux2 の環境で実施していきます。
AWS Secrets and Config Provider (ASCP) のインストール
これは、AWS のドキュメントに基づいて行います。
まず Helm を使って Secrets Store CSI ドライバーをインストールします。
helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
helm install -n kube-system csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver
次に ASCP をインストールします。
kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml
環境変数の作成
このあとの手順でよく利用する情報を環境変数に格納しておきます。
REGION=ap-northeast-3 CLUSTERNAME=ASCP-cluster
AWS Secrets Manager のシークレットの作成
今回は、ユーザー名: admin とパスワード: admin1234 という値をシークレットとして作成します。
aws --region "$REGION" secretsmanager create-secret --name ascp-demo-secret --secret-string '{"username":"admin", "password":"admin1234"}'
作成後に表示されるシークレットの ARN をメモしておきましょう。
Service Account の作成
Amazon EKS の Pod には、 AWS Secrets Manager のシークレットを取得するための権限を付与する必要があるので、Service Account を作成します。
まず 作成したシークレットの取得を許可する IAM ポリシーを作成します。次の例では、ポリシー名を ascp-demo-secret-policy にしています。
下記で、 <作成したシークレットのARN> の部分に、メモしておいた ARN を記載します。
POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn --output text iam create-policy --policy-name ascp-demo-secret-policy --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"], "Resource": ["<作成したシークレットのARN>"] } ] }')
次に EKS クラスターの OIDC プロバイダを AWS IAM に関連付けます。これはクラスター単位で 1回行うだけで OK です。
eksctl utils associate-iam-oidc-provider --region="$REGION" --cluster="$CLUSTERNAME" --approve
そして、Service Account を作成します。次の例では、Service Account 名を ascp-demo-secret-sa にしています。
eksctl create iamserviceaccount --name ascp-demo-secret-sa --region="$REGION" --cluster "$CLUSTERNAME" --attach-policy-arn "$POLICY_ARN" --approve --override-existing-serviceaccounts
SecretProviderClass の作成
SecretProviderClass を作成するためのマニフェストを用意します。
次の例では、secret-provider-class.yaml というファイルで作成しています。
このマニフェストの objectName に作成したシークレットの名前を指定します。
apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: ascp-demo-secrets-provider-class spec: provider: aws parameters: objects: | - objectName: "ascp-demo-secret" objectType: "secretsmanager"
マニフェスト作成後、適用します。
kubectl apply -f secret-provider-class.yaml
Deployment の作成
それでは、Pod から シークレットの情報を取得してみます。
まず Deployment のマニフェストを作成します。Pod の spec には、Service Account や SecretProviderClass を正しく指定しましょう。
次の例では、/mnt/secrets-store をマウントに指定し、シークレットを取得できるようにして example-deployment.yaml というファイルに保存しています。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: serviceAccountName: ascp-demo-secret-sa volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "ascp-demo-secrets-provider-class" containers: - name: nginx-deployment image: nginx ports: - containerPort: 80 volumeMounts: - name: secrets-store-inline mountPath: "/mnt/secrets-store" readOnly: true
マニフェスト作成後、適用します。
kubectl apply -f example-deployment.yaml
無事に Deployment の Pod が作成されたことを確認します。
kubectl get deploy nginx-deployment
次の出力例ように、2つの Pod が READY になっていれば OK です。
出力例
NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 2/2 2 2 15s
もし Pod が作成されない場合は、kubectl describe で イベントに エラー情報が出力されているか確認しましょう。
kubectl get pods kubectl describe pod <Pod名>
Pod が作成されたら、シークレットの値を参照してみます。
まず、Pod 名を確認します。
kubectl get pods
次に Pod 名を指定して コンテナのシェルに接続します。
kubectl exec -it <Pod名> -- /bin/bash
シェルに接続したらシークレットの情報を参照してみます。
cat /mnt/secrets-store/ascp-demo-secret
次の例のように表示されれば OK です。
出力例
{"username":"admin", "password":"admin1234"}
最後に
Kubernetes には Secrets というリソースがありますが、Amazon EKS にて Pod から AWS Secrets Manager を使い、認証情報などのシークレットを取得したい場合は、この AWS Secrets and Config Provider (ASCP) が役立ちそうですね。
Amazon EKS で Amazon EFS CSI ドライバー を使ってみる
今回は、Amazon EKS で Amazon EFS CSI ドライバー を使って、Podから EFSボリュームにアクセスしてみます。
手順としては前回の「Amazon EKS で Amazon EBS CSI ドライバー を使ってみる 」の記事の内容と似ているところが多いので、今回の記事も内容や構成が似ていることはご容赦下さいww
ここに記述している内容は、2022 年 9 月11 日時点で動作を確認しています。
また、対象にしている Kubernetes のバージョンは 1.23 です。
今後の Update により、手順等が変更される可能性があることをご留意ください。
なお、下記のドキュメントを参考にしていますので、こちらも併せてご参照ください。
前提と環境
今回は、東京リージョンの「 test123-cluster 」という名前の EKS クラスター (バージョンは 1.23 ) を使う前提とします。
kubectl や eksctl 、AWS CLI 、git が使用でき、対象のクラスターに接続できる Amazon Linux2 の環境で実施していきます。
記事の中で出てくる AWS アカウント ID は、12 桁すべてゼロで表記しています。
Amazon EFS CSI ドライバー用の Service Account の作成
Amazon EFS CSI ドライバーには、Amazon EFS のファイルシステムを操作する権限を付与する必要があります。
その権限を付与するため、AWS の IAM ロールと関連づいた Kubernetes の Service Account を作成します。
まず、クラスター用に IAM OpenID Connect (OIDC) プロバイダーを用意します。 （もし前に IAM ロールと関連付けた Service Account を作成したことがあるなら、すでに実施済のはずなので、その場合は不要です。）
eksctl utils associate-iam-oidc-provider --cluster test123-cluster --approve
次に、IAM ロール に付与する許可ポリシーを作成します。
ここでは、ポリシー名を AmazonEKS_EFS_CSI_Driver_Policy にしています。
curl -o iam-policy-example.json https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json aws iam create-policy \ --policy-name AmazonEKS_EFS_CSI_Driver_Policy \ --policy-document file://iam-policy-example.json
ダウンロードした iam-policy-example.json にも目を通しておくと、どのようなポリシーが必要か確認できます。
そして、Service Account を作成します。
ここでは、Service Account 名を ebs-csi-controller-sa に、IAM ロール名を AmazonEKS_EBS_CSI_DriverRole にしています。
eksctl create iamserviceaccount \ --cluster test123-cluster \ --namespace kube-system \ --name efs-csi-controller-sa \ --attach-policy-arn arn:aws:iam::000000000000:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --approve \ --region ap-northeast-1
Amazon EFS CSI ドライバー を Amazon EKS アドオンとしてインストールする
インストールではHelm も使用できますが、今回は kubectl でマニフェストを使って行います。
また、マニフェストで参照するイメージは、パブリック Amazon ECR レジストリに保存されているイメージを使う前提とします。
最初にマニフェストを取得します。
kubectl kustomize \ "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.4" > public-ecr-driver.yaml
public-ecr-driver.yaml ファイルを編集して、次の行を削除します。
これは、Service Account は前の手順ですでに作成しているためです。
この作業は注意して下さい。ファイル内に Service Account のマニフェストが複数存在している場合、削除する対象を間違えないようにしましょう。
apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system ---
これでマニフェストの準備が完了したので、適用します。
kubectl apply -f public-ecr-driver.yaml
インストールを確認します。
kubectl get deploy efs-csi-controller -n kube-system
次の出力例のように、efs-csi-controller の Deployment が起動できていることを確認します。
NAME READY UP-TO-DATE AVAILABLE AGE efs-csi-controller 2/2 2 2 3m1s
EFS ファイルシステムを作成する
EFS ファイルシステムを作成するために、まずは VPC の情報を環境変数に入れておきます。
vpc_id=$(aws eks describe-cluster \ --name test123-cluster \ --query "cluster.resourcesVpcConfig.vpcId" \ --output text)
cidr_range=$(aws ec2 describe-vpcs \ --vpc-ids $vpc_id \ --query "Vpcs[].CidrBlock" \ --output text)
次に EFS ファイルシステムのマウントポイントに適用するセキュリティグループを作成します。 今回は、セキュリティグループ名を MyEfsSecurityGroup にしています。
security_group_id=$(aws ec2 create-security-group \ --group-name MyEfsSecurityGroup \ --description "My EFS security group" \ --vpc-id $vpc_id \ --output text)
作成したセキュリティグループに イングレスルールを設定します。
今回は、アクセス元がクラスターの VPC の CIDR であれば NFS トラフィックを許可するルールにします。
aws ec2 authorize-security-group-ingress \ --group-id $security_group_id \ --protocol tcp \ --port 2049 \ --cidr $cidr_range
これで EFS ファイルシステムを作成する準備ができました。
リージョンを指定して EFS ファイルシステムを作成します。
file_system_id=$(aws efs create-file-system \ --region ap-northeast-1 \ --performance-mode generalPurpose \ --query 'FileSystemId' \ --output text)
EFS ファイルシステムのマウントターゲットを作成します。
そのために、まず EKS クラスターのVPCのサブネットの ID を取得します。
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$vpc_id" \ --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \ --output table
出力された表形式の内容から、EKS で EFS ファイルシステムをマウントするノードのサブネットの ID をメモしておきます。
そのサブネット ID を指定して、EFS のマウントターゲットを作成します。 次の例では、サブネット ID を subnet-0b10aaaaaaaaaaaaa と指定しています。
aws efs create-mount-target \ --file-system-id $file_system_id \ --subnet-id subnet-0b10aaaaaaaaaaaaa \ --security-groups $security_group_id
サンプルアプリケーションで確認する
では、Pod から EFS ファイルシステムにアクセスできるかをサンプルアプリケーションを使って試していきます。
まず、作成した EFS ファイルシステムの ID をメモしておきます。 これまでの手順で、$file_system_id という環境変数で参照できます。
echo $file_system_id
aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text
次に、EFS の StorageClass を作成するためのマニフェストを入手します。
curl -o storageclass.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
ダウンロードした storageclass.yaml を編集し、fileSystemId: 部分をメモしておいた ファイルシステム ID に変更します。
次の例では、ファイルシステム ID として fs-54321abc を指定してます。
fileSystemId: fs-54321abc
これで準備ができたので、StorageClassを作成します。
kubectl apply -f storageclass.yaml
Storage Class の情報を表示してみます。NAME に efs-sc 、PROVISONER に efs.csi.aws.com の Storage Class が表示されることを確認します。
kubectl get sc
次にサンプルアプリケーションを取得します。
curl -o pod.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
今回は、動的に EFS のボリュームをプロビジョニングするサンプルを動かしていきます。
ダウンロードしたマニフェスト pod.yaml を適用することで、Persistent Volume、Persistent Volume Claim、それを指定するサンプルの Pod が作成されます。
kubectl apply -f pod.yaml
Persistent Volume と Persistent Volume Claim の STATUS が Bound になっていることを確認します。
kubectl get pv kubectl get pvc
efs-app というPod の STATUS が Running になっていることを確認します。
kubectl get pod efs-app
次のコマンドを実行し、このサンプルアプリケーションの Pod のマニフェストをみてみます。
cat pod.yaml
次のように、Persistent Volume Claim を指定し、/data というパスにボリュームをマウントしています。
そして、echo コマンドを使用し、/data/out に日時を繰り返し書き込んでいます。
apiVersion: v1 kind: Pod metadata: name: efs-app spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out; sleep 5; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim:
では、この Pod が EFS ボリュームに書き込み出来ているかを確認してみましょう。
kubectl exec efs-app -- bash -c "cat data/out"
次のような表示が確認できれば OK です。
出力例
Sun Sep 11 03:15:25 UTC 2022 Sun Sep 11 03:15:30 UTC 2022 Sun Sep 11 03:15:35 UTC 2022 Sun Sep 11 03:15:40 UTC 2022 Sun Sep 11 03:15:45 UTC 2022 Sun Sep 11 03:15:50 UTC 2022 Sun Sep 11 03:15:55 UTC 2022
ここで、もう1つ、同じ EFS のマウントターゲットを使用するPod を作成してみます。
次のマニフェストを作成して、nginx.yaml として保存します。
apiVersion: v1 kind: Pod metadata: name: efs-app-nginx spec: containers: - name: nginx image: nginx volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: efs-claim
この Pod を作成します。
kubectl create -f nginx.yaml
作成した Pod のシェルに接続してみます。
kubectl exec efs-app-nginx -it -- /bin/bash
次のコマンドを実行し、efs-app の Pod が書き込んだファイルを参照できることを確認します。
cat /data/out
出力例
Sun Sep 11 03:15:25 UTC 2022 Sun Sep 11 03:15:30 UTC 2022 Sun Sep 11 03:15:35 UTC 2022 Sun Sep 11 03:15:40 UTC 2022 Sun Sep 11 03:15:45 UTC 2022 Sun Sep 11 03:15:50 UTC 2022 Sun Sep 11 03:15:55 UTC 2022
これで EFS なので、2つのコンピューティング環境から同時にマウントしてアクセスできることが確認できました！
確認出来たら、シェルを終了します。
exit
サンプルアプリケーションを停止する場合は、次を実行します。
これで、EFS ボリュームも削除されます。（ EFS ファイルシステムは削除されません）
kubectl delete po efs-app-nginx
kubectl delete -f pod.yaml
最後に
前回と今回の記事で、Amazon EKS の CSI ドライバーを使用して Amazon EBS や Amazon EFS のボリュームをプロビジョニングして Pod から使用する手順を確認しました。 AWS の公式のドキュメント の内容をベースにしていますが、少し補足しつつ、よりシンプルに確認できる手順にしたつもりです。 これがどなたかのお役に立てば嬉しいです。
Amazon EKS で Amazon EBS CSI ドライバー を使ってみる
今回は、Amazon EKS で Amazon EBS CSI ドライバー を使って、Podから EBSボリュームにアクセスしてみます。
ここに記述している内容は、2022 年 9 月1 日時点で動作を確認しています。
また、対象にしている Kubernetes のバージョンは 1.23 です。
今後の Update により、手順等が変更される可能性があることをご留意ください。
なお、下記のドキュメントを参考にしていますので、こちらも併せてご参照ください。
前提と環境
今回は、東京リージョンの「 test123-cluster 」という名前の EKS クラスター (バージョンは 1.23 ) を使う前提とします。
kubectl や eksctl 、AWS CLI 、git が使用でき、対象のクラスターに接続できる Amazon Linux2 の環境で実施していきます。
記事の中で出てくる AWS アカウント ID は、12 桁すべてゼロで表記しています。
Amazon EBS CSI ドライバー用の Service Account の作成
Amazon EBS CSI ドライバーには、Amazon EBS のボリュームを作成したり削除する権限を付与する必要があります。
その権限を付与するため、AWS の IAM ロールと関連づいた Kubernetes の Service Account を作成します。
まず、クラスター用に IAM OpenID Connect (OIDC) プロバイダーを用意します。 （もし前に IAM ロールと関連付けた Service Account を作成したことがあるなら、すでに実施済のはずなので、その場合は不要です。）
eksctl utils associate-iam-oidc-provider --cluster test123-cluster --approve
次に、IAM ロール に 付与する許可ポリシーを作成します。
ここでは、ポリシー名を AmazonEBSCSIDriverPolicy にしています。
curl -o example-iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/v0.9.0/docs/example-iam-policy.json aws iam create-policy --policy-name AmazonEKS_EBS_CSI_Driver_Policy --policy-document file://example-iam-policy.json
ダウンロードした example-iam-policy.json にも目を通しておくと、どのようなポリシーが必要か確認できます。
そして、Service Account を作成します。
ここでは、Service Account 名を ebs-csi-controller-sa に、IAM ロール名を AmazonEKS_EBS_CSI_DriverRole にしています。
eksctl create iamserviceaccount \ --name ebs-csi-controller-sa \ --namespace kube-system \ --cluster test123-cluster \ --attach-policy-arn arn:aws:iam::000000000000:policy/AmazonEKS_EBS_CSI_Driver_Policy \ --approve \ --role-only \ --role-name AmazonEKS_EBS_CSI_DriverRole
Amazon EBS CSI ドライバー を Amazon EKS アドオンとしてインストールする
インストールは、AWS マネジメントコンソール や AWS CLI も使用できますが、今回は eksctl を使用します。
eksctl create addon --name aws-ebs-csi-driver --cluster test123-cluster --service-account-role-arn arn:aws:iam::000000000000:role/AmazonEKS_EBS_CSI_DriverRole --force
インストールできたか確認してみます。
eksctl get addon --name aws-ebs-csi-driver --cluster test123-cluster
STATUS が ACTIVE と表示されることを確認します。
出力例 (UPDATE AVAILABLE 列は省略しています。）
NAME VERSION STATUS ISSUES IAMROLE aws-ebs-csi-driver v1.10.0-eksbuild.1 ACTIVE 0 (IAMロールのARN)
サンプルアプリケーションで確認する
では、Pod から EBS ボリュームにアクセスできるかをサンプルアプリケーションを使って試していきます。
まず、サンプルアプリケーションを取得します。
git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver.git
今回は、動的に EBS ボリュームをプロビジョニングするサンプルを動かしていきます。
次を実行することで、Storage Class、Persistent Volume Claim、それを指定するサンプルの Pod が作成され、さらに Persistent Volume として EBS ボリュームも動的に作成されます。
cd aws-ebs-csi-driver/examples/kubernetes/dynamic-provisioning/ kubectl apply -f manifests/
Storage Class の情報を表示してみます。NAME に ebs-sc 、PROVISONER に ebs.csi.aws.com の Storage Class が表示されることを確認します。
kubectl get sc
Persistent Volume Claim、Persistent Volumeは、STATUS が Bound になっていることを確認します。
kubectl get pv kubectl get pvc
次のコマンドを実行し、このサンプルアプリケーションの Pod のマニフェストをみてみます。
cat manifests/pod.yaml
次のように、Persistent Volume Claim を指定し、/data というパスにボリュームをマウントしています。
そして、echo コマンドを使用し、/data/out.txt に日時を繰り返し書き込んでいます。
apiVersion: v1 kind: Pod metadata: name: app spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: ebs-claim
では、この Pod が EBS ボリュームに書き込み出来ているかを確認してみましょう。
kubectl exec -it app -- cat /data/out.txt
次のような表示が確認できれば OK です。
出力例
Thu Sep 1 01:59:12 UTC 2022 Thu Sep 1 01:59:17 UTC 2022 Thu Sep 1 01:59:22 UTC 2022 Thu Sep 1 01:59:27 UTC 2022 Thu Sep 1 01:59:32 UTC 2022 Thu Sep 1 01:59:37 UTC 2022 Thu Sep 1 01:59:42 UTC 2022
ここで、このPod だけを削除してみます。
kubectl delete pod app
Pod を削除しても、Persistent Volume Claim が削除されない限り、EBS ボリュームは残っています。
その後、他の Pod を起動し、この EBSボリュームにマウントしてみます。
次のマニフェストを作成して、nginx.yaml として保存します。
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: ebs-claim
この Pod を作成します。
kubectl create -f nginx.yaml
作成した Pod のシェルに接続してみます。
kubectl exec -it nginx -- /bin/bash
次のコマンドを実行し、削除した 前の Pod が書き込んだファイルを参照できることを確認します。
cat /data/out.txt
出力例
Thu Sep 1 01:59:12 UTC 2022 Thu Sep 1 01:59:17 UTC 2022 Thu Sep 1 01:59:22 UTC 2022 Thu Sep 1 01:59:27 UTC 2022 Thu Sep 1 01:59:32 UTC 2022 Thu Sep 1 01:59:37 UTC 2022 Thu Sep 1 01:59:42 UTC 2022
確認出来たら、シェルを終了します。
exit
サンプルアプリケーションを停止する場合は、次を実行します。
これで、EBS ボリュームも削除されます。
app という Pod はすでに削除していますので、NotFoundのエラーが出ても無視して下さい。
kubectl delete po nginx
kubectl delete -f manifests/
最後に
Amazon EKS を触りだして間もないころは、Amazon EBS CSI ドライバーの構成方法はドキュメントをみてもよくわからなかたったり、上手くいかなかったりしたのですが、今回ようやくサンプルアプリケーションを動作させる手順をまとめることができました。 次は、Amazon EFS CSI ドライバーの構成方法の記事を書きたいと思います。
eksctl で Kubernetes 1.23 の Amazon EKS クラスターを作成する
2022年8月11日に、Amazon Elastic Kubernetes Service ( Amazon EKS ) で Kubernetes のバージョン 1.23 がサポートされました。
そこで、早速 バージョン 1.23 の EKS クラスターを作成しようと思ったのですが、その時点ではまだ eksctl が対応していないことが判明しました。
1.23 のサポートがアナウンスされた後に、eksctl のバージョンはアップグレードしたのですが、次のように、eksctl のバージョンが 1.0.8 以下の場合、eksctl で EKS クラスターを作成しようとすると指定バージョンが対象外であるとエラーになります。
$ eksctl version 0.108.0 $ eksctl create cluster \ > --name test123-cluster \ > --vpc-public-subnets subnet-0b10715b2edf27dde,subnet-023105dfe3f0a2bdb \ > --nodegroup-name test123-nodes \ > --node-type t3.small \ > --nodes 2 \ > --nodes-min 1 \ > --nodes-max 3 \ > --managed \ > --version 1.23 \ > --region ap-northeast-1 2022-08-26 13:28:34 [ℹ] eksctl version 0.108.0 2022-08-26 13:28:34 [ℹ] using region ap-northeast-1 Error: invalid version, supported values: 1.19, 1.20, 1.21, 1.22
EKS で サポートされる Kubernetes のバージョンが追加されたからといって、同時に そのバージョンに対応した eksctl がリリースされているわけではないんですね。
で、約 2週間ほど経って、 eksctl のリリース情報を確認すると、どうやら バージョン 1.109.0 で Kubernetes のバージョン 1.23 に対応したことがわかりました。
この eksctl のリリース情報をみると、EKS で 1.23 のサポートがアナウンスされてから、約 1週間後 くらいにリリースされたようです。
AWS の Amazon EKS のドキュメントで eksctl のインストールの説明部分をみると、英語版の方では、バージョンの表示例が 1.0.9 になっていました。(2022年8月27日現在）
Installing or updating eksctl - Amazon EKS
If you have eksctl installed in the path of your device, the example output is as follows. If you want to update the version that you currently have installed with a later version, complete the next step, making sure to install the new version in the same location that your current version is in.
0.109.0
ただし、日本語の方では、バージョンの表示例は まだ 1.0.5 になっていました。(2022年8月27日現在）いずれ更新されると思います。
eksctl のインストールまたは更新 - Amazon EKS
eksctl がデバイスのパスにインストールされている場合、出力例は次のようになります。現在インストールされているバージョンを新しいバージョンで更新する場合は、次の手順を完了し、新しいバージョンを現在のバージョンと同じ場所にインストールするようにします。
0.105.0
ともあれ、eksctl で バージョン 1.23 の EKS クラスターを作成できるようになったのは、嬉しい事です。
早速、eksctl のバージョンを 1.109.0 にアップグレードして、EKSクラスター 1.23 の作成を試してみました。
$ eksctl version 0.109.0 $ eksctl create cluster \ > --name test123-cluster \ > --vpc-public-subnets subnet-0b10715b2edf27dde,subnet-023105dfe3f0a2bdb \ > --nodegroup-name test123-nodes \ > --node-type t3.small \ > --nodes 2 \ > --nodes-min 1 \ > --nodes-max 3 \ > --managed \ > --version 1.23 \ > --region ap-northeast-1 2022-08-26 13:15:16 [ℹ] eksctl version 0.109.0 2022-08-26 13:15:16 [ℹ] using region ap-northeast-1 2022-08-26 13:15:16 [ℹ] using existing VPC (vpc-0260526e8e00b9bb6) and subnets (private:map[] public:map[ap-northeast-1a:{subnet-0b10715b2edf27dde ap-northeast-1a 10.0.0.0/24 0} ap-northeast-1c:{subnet-023105dfe3f0a2bdb ap-northeast-1c 10.0.10.0/24 0}]) 2022-08-26 13:15:16 [!] custom VPC/subnets will be used; if resulting cluster doesn't function as expected,make sure to review the configuration of VPC/subnets 2022-08-26 13:15:16 [ℹ] nodegroup "test123-nodes" will use "" [AmazonLinux2/1.23] 2022-08-26 13:15:16 [ℹ] using Kubernetes version 1.23 2022-08-26 13:15:16 [ℹ] creating EKS cluster "test123-cluster" in "ap-northeast-1" region with managed nodes 2022-08-26 13:15:16 [ℹ] will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup 2022-08-26 13:15:16 [ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-northeast-1 --cluster=test123-cluster' 2022-08-26 13:15:16 [ℹ] Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "test123-cluster" in "ap-northeast-1" 2022-08-26 13:15:16 [ℹ] CloudWatch logging will not be enabled for cluster "test123-cluster" in "ap-northeast-1" 2022-08-26 13:15:16 [ℹ] you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g. all)} --region=ap-northeast-1 --cluster=test123-cluster' 2022-08-26 13:15:16 [ℹ] 2 sequential tasks: { create cluster control plane "test123-cluster", 2 sequential sub-tasks: { wait for control plane to become ready, create managed nodegroup "test123-nodes", } } 2022-08-26 13:15:16 [ℹ] building cluster stack "eksctl-test123-cluster-cluster" 2022-08-26 13:15:16 [ℹ] deploying stack "eksctl-test123-cluster-cluster" 2022-08-26 13:15:46 [ℹ] waiting for CloudFormation stack "eksctl-test123-cluster-cluster" (中略） 2022-08-26 13:29:18 [ℹ] building managed nodegroup stack "eksctl-test123-cluster-nodegroup-test123-nodes" 2022-08-26 13:29:18 [ℹ] deploying stack "eksctl-test123-cluster-nodegroup-test123-nodes" 2022-08-26 13:29:18 [ℹ] waiting for CloudFormation stack "eksctl-test123-cluster-nodegroup-test123-nodes" (中略） 2022-08-26 13:33:01 [ℹ] waiting for the control plane availability... 2022-08-26 13:33:03 [ℹ] saved kubeconfig as "/home/ssm-user/.kube/config" 2022-08-26 13:33:03 [ℹ] no tasks 2022-08-26 13:33:03 [ℹ] all EKS cluster resources for "test123-cluster" have been created 2022-08-26 13:33:03 [ℹ] nodegroup "test123-nodes" has 2 node(s) 2022-08-26 13:33:03 [ℹ] node "ip-10-0-0-138.ap-northeast-1.compute.internal" is ready 2022-08-26 13:33:03 [ℹ] node "ip-10-0-10-72.ap-northeast-1.compute.internal" is ready 2022-08-26 13:33:03 [ℹ] waiting for at least 1 node(s) to become ready in "test123-nodes" 2022-08-26 13:33:03 [ℹ] nodegroup "test123-nodes" has 2 node(s) 2022-08-26 13:33:03 [ℹ] node "ip-10-0-0-138.ap-northeast-1.compute.internal" is ready 2022-08-26 13:33:03 [ℹ] node "ip-10-0-10-72.ap-northeast-1.compute.internal" is ready 2022-08-26 13:33:05 [ℹ] kubectl command should work with "/home/ssm-user/.kube/config", try 'kubectl get nodes' 2022-08-26 13:33:05 [ℹ] EKS cluster "test123-cluster" in "ap-northeast-1" region is ready $
期待通り、問題なく作成できました！
EKS クラスターは、eksctl 以外でも、AWS マネジメントコンソール や AWS CLI でも作成できますが、私は、EKS クラスターを作成する場合は、eksctl を使う派ですので、ようやく バージョン1.23 を eksctl で作成することができた、と感じています。
Amazon EKS でサポートされる バージョンが追加されたとき、どれくらいのタイムラグで、そのバージョンに対応した eksctl がリリースされるのかは、今後も注目していきたいと思います。
