こんにちは。
株式会社クラスアクト インフラストラクチャ事業部の大塚です。
今回はAWS EKSを使ってKubernetes環境を作ってきたいと思います。
EKS環境を作るとき、皆様の記事だとAWS CLIを使ってみたりCloud9を使っているイメージが個人的にはかなり強く「管理コンソールから作成できないのか？」と思い、この記事を書いてみました。
環境イメージ
自作したVPC・Subnet・IGW環境にEKS環境を立ち上げていきたいと思います。
構築
IAM Roleの作成
EKS環境を構築するにあたり、
EKS ClusterにアタッチするRoleとそのクラスタで稼働するコンピュート（EC2とFargateが選択可能。今回はEC2を選択しました。これをノードグループと呼びます。Fargateの方だとFargateプロファイルと呼ぶようです。）にアタッチするRoleの2つが必要になります。
EKS Cluster用IAM Role作成
IAMの管理画面にアクセスします。ロールの作成を押下します。
AWSのサービスを選択して、ユースケースでEKS Clusterを選択しました。
デフォルトでポリシが1つ選択されています。AmazonEKSClusterPolicyという名前のものがアタッチされています。そのまま次に進んでください。
今作成しているIAM Roleの名前を決めます。今回はqiita-eks-cluster-iam-roleとしました。この状態で作成します。
node group用IAM Role作成
もうひとつ作成していきます。
AWSサービスを選択して、ユースケースではEC2を選択します。
次の3つのポリシをアタッチしていきます。
- AmazonEKSWorkerNodePolicy
- AmazonEC2ContainerRegistryReadOnly
- AmazonEKS_CNI_Policy
今作成しているIAM Roleの名前を決めます。今回はqiita-eks-cluster-node-group-roleとしました。この状態で作成します。
SGの作成
EKSクラスタにアタッチするSGを作成します。
最低限何を開ければいいのかを確認したところ、以下回答を得ました。
1,2に関しては今まさに作成しようとしているSGのIDが必要とのことで、あとから作りこんでいきます。
1. ノード間通信を許可:
タイプ: カスタムTCP
ポート範囲: 0 - 65535
ソース: クラスターのセキュリティグループID
2. ノードとAPIサーバー間の通信を許可:
タイプ: HTTPS
ポート範囲: 443
ソース: クラスターのセキュリティグループID
3. ノードと外部インターネット間の通信を許可:
タイプ: HTTP
ポート範囲: 80
ソース: 0.0.0.0/0
タイプ: HTTPS
ポート範囲: 443
ソース: 0.0.0.0/0
4. 管理者のkubectlアクセスを許可:
タイプ: HTTPS
ポート範囲: 443
ソース: 管理者のIPアドレス（例: 203.0.113.0/24）
1,2を除いた設定が以下となっております。
4に関してはマイIPを指定してます。この状態でいったん作成していきます。
SGが作成されたことを確認した後、先ほど作れなかった1,2の設定を追加していきます。設定した内容が以下の画面となっております。この状態で更新をかけます。
EKSクラスタの作成
EKSの管理画面を開きます。クラスターの追加を押下します。
EKSのクラスタ名をqiita-eks-clusterとしました。
クラスターサービスロールでは先に作成したqiita-eks-cluster-iam-roleをアタッチします。
ネットワーキングの設定をしていきます。
VPCは自作しているmy-vpcを選択しています。（AWSから払い出されるデフォルトのものでも問題ないと思います。検証していませんが。。。）
サブネットに関してはVPC内で作成している3つのVPCを選択しました。
SGに関しては、これも先ほど作成したqiita-eks-cluster-sgを選択します。
監視系の設定をしていきます。今回は環境構築をし終わったらすぐに削除する予定ですので、何も選択せずにそのまま次に進みます。
アドオンを選択していきます。
それぞれKubernetes環境下のDNS・プロキシ・ネットワーク・認証を司るサービスかなと。
アドオンのバージョンなどを設定します。新しくクラスタを作るのであれば、最新のバージョンを選択すれば問題ないかと思います。
確認画面が表示されます。確認した後作成をしていきます。
クラスタがデプロイ中であることが確認できます。この状態で10分程度待機するとステータスがアクティブとなります。
アクティブになる間、少し色々見てみました。ネットワーキングタブでクラスタに紐づているVPCやSubnet、SGを確認することが出来ます。
Add-ONを確認することも出来ました。グラフィカルでわかりやすいというのと、漁っていけばもっと色々出来そうでした。
リソースタブを見てみます。kubernetesに関わるリソースはここで確認が出来そうです。k8sになじみ深い用語が並んでいます。
コンピューティングタブを確認してみますとクラスタ上でコンピュートするマシンがいないことがわかります。コンピュートさせる方法としてEC2とFargateがあるようですが、今回はEC2を選択します。
ノードグループを作成を押下します。
ノードグループの名前をqiita-eks-cluster-node-groupとしました。
このグループに割り当てるIAM Roleは先ほど作成したqiita-eks-cluster-node-group-roleとしました。
次にクラスタにアサインさせるノードスペックや数を指定していきます。
ここでインスタンスタイプをt3.microという極小のスペックを選択したことでこの後試すdeploymentのデプロイに失敗します笑
Subnetを選択します。今回はクラスタに紐づけている全てのSubnetを紐づけました。
確認画面が表示されます。確認後作成していきます。
正常にデプロイされたことを確認します。
クラスタ側のコンピューティングにインスタンスが2つ紐づていることを確認します。
EC2の管理画面でも確認が出来ます。
※ここでEC2のインスタンスデプロイが上手くいかず、以下のようなエラーを出力してきた場合Subnetの「パブリック IPv4 アドレスを自動割り当て」が”はい”になっていることを確認してください。”いいえ”になっているとこけます。
One or more Amazon EC2 Subnets of [subnet-0308cdef0f9f88dd8, subnet-041e0792bff9086fc, subnet-02954cfcd14210ee3] for node group qiita-eks-cluster-node-group does not automatically assign public IP addresses to instances launched into it. If you want your instances to be assigned a public IP address, then you need to enable auto-assign public IP address for the subnet. See IP addressing in VPC guide: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip
コンピュートの準備が出来るとAdd-ON関係のPodが順次立ち上がっていきます。kubeadmでk8sクラスタを立ち上げるときもこんな感じになりますよね。
EKS環境にdeploymentをデプロイしてみる
作成したEKSクラスタ環境にdeploymentをデプロイしてみます。
AWS管理コンソールの右上の赤枠内のアイコンを押すとCloudShellが立ち上がります。ここからEKSを操作します。（この点ではGKEと近しいUIだと思いました。）
なんとなくrootにスイッチして以下のコマンドを実行していたけど、aws eksのタイミングになったらrootからexitして元のユーザに戻らないとダメでした。
まず、aws --versionとkubectl versionを使うことでEKSを使える状態かを確認しています。
次にaws eksコマンドで自分が作成したEKSクラスタに接続、kubectl get nodeやpodでクラスタに接続できているかを確認しています。
[root@ip-10-130-35-157 ~]# aws --version
aws-cli/2.17.1 Python/3.11.8 Linux/6.1.92-99.174.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023
[root@ip-10-130-35-157 ~]# kubectl version --client
Client Version: v1.29.3-eks-ae9a62a
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
[root@ip-10-130-35-157 ~]# exit
logout
[cloudshell-user@ip-10-130-35-157 ~]$ aws eks --region ap-northeast-1 update-kubeconfig --name qiita-eks-cluster
Added new context arn:aws:eks:ap-northeast-1:310016072763:cluster/qiita-eks-cluster to /home/cloudshell-user/.kube/config
[cloudshell-user@ip-10-130-35-157 ~]$ kubectl get node
NAME STATUS ROLES AGE VERSION
ip-192-168-1-24.ap-northeast-1.compute.internal Ready <none> 17m v1.30.0-eks-036c24b
ip-192-168-3-202.ap-northeast-1.compute.internal Ready <none> 17m v1.30.0-eks-036c24b
[cloudshell-user@ip-10-130-35-157 ~]$ kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system aws-node-jv8hq 2/2 Running 0 17m
kube-system aws-node-nm6zs 2/2 Running 0 17m
kube-system coredns-5d797594d7-4588b 1/1 Running 0 36m
kube-system coredns-5d797594d7-5vhvn 1/1 Running 0 36m
kube-system eks-pod-identity-agent-92t8z 1/1 Running 0 17m
kube-system eks-pod-identity-agent-bh25z 1/1 Running 0 17m
kube-system kube-proxy-bb7nn 1/1 Running 0 17m
kube-system kube-proxy-xx7rd 1/1 Running 0 17m
今回用意したdeploymentのyamlは以下となります。
apiVersion: apps/v1
kind: Deployment
metadata:
name: alpine-deployment
spec:
replicas: 2
selector:
matchLabels:
app: alpine
template:
metadata:
labels:
app: alpine
spec:
containers:
- name: alpine
image: alpine:latest
command: ["sh", "-c", "while true; do sleep 3600; done"]
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
name: alpine-service
spec:
type: NodePort
selector:
app: alpine
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30001
これをCloudShellに持っていきます。
アクションタブからアップロードを選択するとファイルのアップロードをすることが可能です。
アップロード後、kubectl applyコマンドを実行してyamlベースでdeploymentをデプロイします。
[cloudshell-user@ip-10-130-35-157 ~]$ ls -ltr
total 4
-rw-r--r--. 1 cloudshell-user cloudshell-user 736 Jun 30 08:50 alpine-deployment.yaml
[cloudshell-user@ip-10-130-35-157 ~]$ kubectl apply -f alpine-deployment.yaml
deployment.apps/alpine-deployment created
service/alpine-service created
管理コンソールで確認をしてみるとデプロイが出来ているように見えていますが、FailedSchedulingとなっていることがわかります。メッセージを見てみるとノードのスペックが原因であることがわかります。ノードグループで指定したt3.microのスペックが低すぎたのが原因ですね。。。
EKS・Kuberenetesを動かせる環境の作成手順は出来たので、上記のデプロイエラーは見なかったことにします笑
今後もEKSについて勉強していきたいなぁ・・・