ハンズオン内容

0. ハンズオン準備

0-1. codespaceの起動

左上のボタンをクリックし、「Codespaces」をクリックします。

「New codespace」をクリックします。

Repositoryにて

k8s-meetup-novice/eks-handson-20250218

を選択し、「Create codespace」をクリックします。

0-2. IAMユーザーの作成

AWSマネジメントコンソールにルートユーザーでログインします。

画面左上の検索ウィンドウに

iam

と入力し、Servicesから「IAM」を選択します。

「Users」 > 「Create user」を選択します。

「User name」に

eks-wakaran-user

を指定し、「Next」を選択します。

「Attach policies directly」を選択し、検索ウィンドウに

AdministratorAccess

を入力します。入力後、検索条件に合致したポリシー一覧が表示されるため、「AdministratorAccess」にチェックを入れ、「Next」を選択します。

確認画面が表示されるため、「Create user」を選択します。

Usersの一覧に作成したeks-wakaran-userが表示されていることを確認します。

0-3. AWSの認証情報払い出し

Usersの一覧にてeks-wakaran-userを選択し、詳細画面に移動します。「Security credentials」タブを選択後「Access keys」までスクロールダウンし、「Create access key」を選択します。

「Command Line Interface (CLI)」を選択し、一番下のチェックボックスにチェックを入れ、「Next」を選択します。

「Description tag value」に

eks-wakaran-handson

と入力し、「Create access key」を選択します。

表示された「Access key」および「Secret access key」を控え、「Download .csv file」を選択した後、「Done」を選択します。

eks-wakaran-userの詳細画面にて、Access keysが作成されたことを確認します。

1. EKSおよびECR, S3の作成

以下のコマンドを用いて、環境変数を設定します。

export AWS_ACCESS_KEY_ID=<Access keyを入力>
export AWS_SECRET_ACCESS_KEY=<Secret access keyを入力>
export AWS_DEFAULT_REGION=ap-northeast-1
export TF_VAR_aws_access_key="${AWS_ACCESS_KEY_ID}"
export TF_VAR_aws_secret_key="${AWS_SECRET_ACCESS_KEY}"

以下のコマンドを実行します。

cat << EOF
AWS_ACCESS_KEY_ID:      ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY:  ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION:     ${AWS_DEFAULT_REGION}
TF_VAR_aws_access_key:  ${TF_VAR_aws_access_key}
TF_VAR_aws_secret_key:  ${TF_VAR_aws_secret_key}
EOF

コマンドを実行した結果、以下のように環境変数に認証情報が設定されていることを確認します。

AWS_ACCESS_KEY_ID:      *********************************************
AWS_SECRET_ACCESS_KEY:  *********************************************
AWS_DEFAULT_REGION:     ap-northeast-1
TF_VAR_aws_access_key:  *********************************************
TF_VAR_aws_secret_key:  *********************************************

以下のコマンドを実行し、正しく認証が行えることを確認します。

aws sts get-caller-identity

認証が正しく行えた場合は、以下のような出力が得られます。

{
    "UserId": "**************************",
    "Account": "***************",
    "Arn": "********************"
}

なお、認証が正しく行えなかった場合は、以下のようなエラーが出力されます。 Access keyおよびSecret access keyが正しく設定されているか再度確認してください。

An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

以下のコマンドを用いて、リソース作成計画が「Plan: 62 to add, 0 to change, 0 to destroy.」という形で表示されることを確認します。

cd tffiles
make plan

次に、make applyコマンドを用いてリソースの作成を実行します。

make apply

以下のような確認が求められるのでyesと入力します。

...
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes <--- ここでyesと入力してください

コマンドの実行が正常に完了すると、以下のように表示されます。(コマンドの実行には約10~15分程度要します。)

Apply complete! Resources: 62 added, 0 changed, 0 destroyed.

Outputs:

cluster_endpoint = "https://XXXXXXX.ap-northeast-1.eks.amazonaws.com"
cluster_name = "eks-wakaran-handson-cluster"
cluster_security_group_id = "sg-XXXXXXXXX"
region = "ap-northeast-1"

AWSマネジメントコンソールにて、EKSおよびECR, S3バケットが作成されたことを確認します。

2. EKSへのアクセス

以下のコマンドを用いて、EKSクラスタ(Kubernetesクラスタ)に対する認証情報(kubeconfig)を取得します。

aws eks update-kubeconfig --name eks-wakaran-handson-cluster

kubectlコマンドを用いてNode一覧が表示されることを確認します。

kubectl get nodes

NAME                                              STATUS   ROLES    AGE   VERSION
ip-172-17-1-126.ap-northeast-1.compute.internal   Ready    <none>   17m   v1.30.8-eks-aeac579
ip-172-17-3-204.ap-northeast-1.compute.internal   Ready    <none>   18m   v1.30.8-eks-aeac579

3. アプリケーションのデプロイ及びLBを用いた外部公開

3-1. Load Balancer Controllerのデプロイ

scriptsディレクトリに移動し、deploy_lb_controller.shを実行します。

cd ../scripts
bash deploy_lb_controller.sh

aws-load-balancer-controllerで始まるPodが作成され、全てのSTATUSがRunningであることを確認します。

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller

NAME                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-6d6c5d67f6-682xv   1/1     Running   0          53s
aws-load-balancer-controller-6d6c5d67f6-s8vkq   1/1     Running   0          53s

3-2. Podのデプロイ

nginxのPodを作成します。

kubectl run nginx --image nginx -n default

Podが正常に起動し、STATUSがRunningであることを確認します。

kubectl get pods nginx

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          97s

3-3. Serviceの作成と外部公開

次に作成したnginxのPodに対して外部からアクセスするためのServiceを作成します。

scriptsディレクトリに格納されているservice.yamlマニフェストファイルを確認します。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
  labels:
    run: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

このマニフェストを適用すると、KubernetesのServiceが作成され、それに紐付くLoadBalancer(Network Load Balancer)が作成されます。

kubectl apply -f service.yaml

kubectlを用いてServiceリソースを参照し、EXTERNAL-IPに表示されているFQDNを確認します。このFQDNが、Serviceを経由して外部からPodにアクセスするためのLoadBalancerのエンドポイントとなります。

kubectl get svc nginx

NAME    TYPE           CLUSTER-IP       EXTERNAL-IP                                                                      PORT(S)        AGE
nginx   LoadBalancer   10.100.136.127   k8s-default-nginx-xxxxxxxxxxxxxxxxxxxxxxxxxxx.elb.ap-northeast-1.amazonaws.com   80:31995/TCP   3m3s

AWSマネジメントコンソールから、Load BalancerのStatusがActiveになったことを確認します。 ※Load BalancerのStatus確認は、検索ウィンドウで「EC2」を検索し、「Load Balancers」を選択することで行えます。

取得したFQDNにアクセスし、nginxの画面が表示されることを確認します。

4. ECRに格納したコンテナイメージの使用

AWSの提供するコンテナレジストリサービスECR(Elastic Container Registry)に格納したコンテナイメージをEKS上で利用します。

Docker Hubからnginxのコンテナイメージを取得します。

docker pull nginx

aws cliとdocker cliを用いて、ECRにログインします。

ACCOUNT_ID=`aws sts get-caller-identity | jq -r '.Account'`
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com

Pullしたコンテナイメージにイメージタグを付与します。

docker tag nginx ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/eks-wakaran-handson-ecr:aws-waiwai

ECRにローカルのコンテナイメージを取得します。

docker push ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/eks-wakaran-handson-ecr:aws-waiwai

AWSマネジメントコンソールから、ECRにコンテナイメージが格納されていることを確認します。 ※ECRの確認は、検索ウィンドウで「ECR」を検索し、「Elastic Container Registry」を選択することで行えます。

最後に、ECRに格納したコンテナイメージをEKS上で利用します。以下のコマンドではECRに格納したコンテナイメージ(eks-wakaran-handson-ecr:aws-waiwai)を指定して、EKSにPodを作成します。

kubectl run nginx-from-ecr --image ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/eks-wakaran-handson-ecr:aws-waiwai

作成したPodが起動していることを確認します。

kubectl get pods nginx-from-ecr

NAME             READY   STATUS    RESTARTS   AGE
nginx-from-ecr   1/1     Running   0          56s

5. IRSA

EKSではIRSAと呼ばれる仕組みにより、KubernetesのServiceAccountにAWSのIAMロールを紐づけることで、PodからAWSのサービスにアクセスすることができます。ここではIRSAを利用して、EKSにデプロイしたPodからS3のバケットにアクセスします。

以下のコマンドを用いて、S3バケット名を取得します。

S3_BUCKET_NAME=$(aws s3 ls | grep eks-wakaran-handson-s3 | awk '{print $3}')

echoコマンドを用いて、S3バケット名が取得できていることを確認します。

echo $S3_BUCKET_NAME

eks-wakaran-handson-s3-*****

S3バケット(eks-wakaran-handson-s3-*****)にtest.txtというファイルを格納します。

touch test.txt
aws s3 cp test.txt s3://${S3_BUCKET_NAME}

upload: ./test.txt to s3://eks-wakaran-handson-s3-*****/test.txt

S3バケットにファイルがアップロードされていることを確認します。 ※S3バケットの確認は、検索ウィンドウで「S3」を検索し、S3バケット名(eks-wakaran-handson-s3-*****)を選択することで行えます。

それでは、PodからS3バケットを参照できるか確認しましょう。以下のコマンドを用いて、マニフェストを作成します。

cat << EOF > pod-before.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-before
  namespace: default
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls', '${S3_BUCKET_NAME}']
  restartPolicy: Never
EOF

pod-before.yamlというマニフェストファイルが、scriptsディレクトリに保存されます。

apiVersion: v1
kind: Pod
metadata:
  name: pod-before
  namespace: default
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls', 'eks-wakaran-handson-s3-*****']
  restartPolicy: Never

このマニフェストを適用します。

kubectl apply -f pod-before.yaml

PodのSTATUSがErrorとなっていることを確認します。

kubectl get pods pod-before

NAME         READY   STATUS   RESTARTS   AGE
pod-before   0/1     Error    0          43s

以下のコマンドを用いてPodのログを確認ます。

kubectl logs pod-before

An error occurred (AccessDenied) ... is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::eks-wakaran-handson-s3-xxxxx" because no identity-based policy allows the s3:ListBucket action

これは、このPodにS3バケットを参照する権限がないことを示しています。

次にIRSAの仕組みを利用して同じことを行います。まず、IAM OIDCプロバイダーを作成します。

eksctl utils associate-iam-oidc-provider --region=ap-northeast-1 --cluster=eks-wakaran-handson-cluster --approve

次にPodからS3バケットの参照が行えるよう、IRSAを利用するためのServiceAccountとIAMロールをeksctlコマンドを用いて作成します。このサービスアカウントに紐づくIAMロールには、「AmazonS3ReadOnlyAccess(S3読み取り許可)」ポリシーをアタッチしています。

eksctl create iamserviceaccount \
  --name eks-wakaran-handson-sa \
  --namespace default \
  --cluster eks-wakaran-handson-cluster \
  --approve \
  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

以下のような結果が出力されることを確認します。

2025-02-17 14:55:35 [ℹ]  created serviceaccount "default/eks-wakaran-handson-sa"

以下のコマンドを用いて、ServiceAccountが正常に作成されたことを確認します。

kubectl get sa eks-wakaran-handson-sa

NAME                     SECRETS   AGE
eks-wakaran-handson-sa   0         119s

それでは、作成したServiceAccountを紐づけたPodを新たに起動します。以下のコマンドを用いて、マニフェストを作成します。

cat << EOF > pod-after.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-after
  namespace: default
spec:
  serviceAccountName: eks-wakaran-handson-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls', '${S3_BUCKET_NAME}']
  restartPolicy: Never
EOF

pod-after.yamlというマニフェストファイルが、scriptsディレクトリに保存されます。

apiVersion: v1
kind: Pod
metadata:
  name: pod-after
spec:
  serviceAccountName: eks-wakaran-handson-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls', 'eks-wakaran-handson-s3-*****']
  restartPolicy: Never

このマニフェストを適用します。

kubectl apply -f pod-after.yaml

作成したPodのStatusがCompletedとなっていることを確認します。

kubectl get pods pod-after

NAME        READY   STATUS      RESTARTS   AGE
pod-after   0/1     Completed   0          14s

以下のコマンドを用いてPodのログを確認し、S3バケットを参照できたことを確認します。

kubectl logs pod-after

2025-02-17 14:43:02          0 test.txt

6. クリーンアップ

ECRに格納されているコンテナイメージの削除
S3バケット内にあるファイルの削除
Serviceの削除

cd /workspaces/eks-handson-20250218/scripts
kubectl delete -f service.yaml

コマンドを実行後、GUIでLoad Balancerが削除されていることを確認します。

リソースの削除

cd /workspaces/eks-handson-20250218/tffiles
make destroy

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes <--- ここでyesと入力してください

Note

terraform destroy 実行中にUsersを削除してしまうと terraform destroy が途中で失敗してしまう可能性があるので、これ以降のクリーンアッププロセスは make destroy が完了してから行ってください

IAMのPolicies及びRolesにて、「wakaran」というワードの入った名前のリソースを削除
IAMのUsersにてハンズオンに使用したユーザー(eks-wakaran-user)を削除
IAMのID プロバイダにてハンズオンに使用したIDプロバイダを削除
Resource Groups & Tag Editorにて、Project: eks-wakaranというタグが付与されたリソースを削除(「(補足) リソースが削除されたことの確認方法」参照)
CloudFormationで「eksctl-eks-wakaran-handson-cluster-」というワードの入った名前のスタックを削除
codespaceの削除

Note

codespaceを削除すると tffiles/terraform.tfstate が削除されてしまうため、make destroy によるterraform destroyの実行後に削除してください

(補足) リソースが削除されたことの確認方法

本ハンズオンで作成した全てのリソースにはProject: eks-wakaranというタグが付与されています。 Resource Groups & Tag Editorを用いて該当タグが付与されたリソースを検索し、全てのリソースが削除されていることを確認することができます。

画面左上の検索ウィンドウに

Resource Groups

と入力し、Servicesから「Resource Groups & Tag Editor」を選択します。

「Tag Editor」を選択します。

検索条件に

Regions: All regions
Resource types: All supported resource types
Tag key: Project
Optional tag value: eks-wakaran を入力し、「Search resources」を選択します。

「Resource search results」に何も表示されなければ、ハンズオンに使用した全てのリソースの削除が完了していることになります。 6. クリーンアップを実施後になんらかのリソースが残存しているようであれば、手動でリソースの削除を行なってください。

Name		Name	Last commit message	Last commit date
Latest commit History 13 Commits
.devcontainer		.devcontainer
images		images
scripts		scripts
tffiles		tffiles
.gitignore		.gitignore
README.md		README.md

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Repository files navigation

ハンズオン内容

0. ハンズオン準備

0-1. codespaceの起動

0-2. IAMユーザーの作成

0-3. AWSの認証情報払い出し

1. EKSおよびECR, S3の作成

2. EKSへのアクセス

3. アプリケーションのデプロイ及びLBを用いた外部公開

3-1. Load Balancer Controllerのデプロイ

3-2. Podのデプロイ

3-3. Serviceの作成と外部公開

4. ECRに格納したコンテナイメージの使用

5. IRSA

6. クリーンアップ

(補足) リソースが削除されたことの確認方法

About

Uh oh!

Releases

Packages

Contributors 4

Uh oh!

Languages

k8s-meetup-novice/eks-handson-20250218

Folders and files

Latest commit

History

Repository files navigation

ハンズオン内容

0. ハンズオン準備

0-1. codespaceの起動

0-2. IAMユーザーの作成

0-3. AWSの認証情報払い出し

1. EKSおよびECR, S3の作成

2. EKSへのアクセス

3. アプリケーションのデプロイ及びLBを用いた外部公開

3-1. Load Balancer Controllerのデプロイ

3-2. Podのデプロイ

3-3. Serviceの作成と外部公開

4. ECRに格納したコンテナイメージの使用

5. IRSA

6. クリーンアップ

(補足) リソースが削除されたことの確認方法

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Contributors 4

Uh oh!

Languages

Packages