副業？(ボランティア、無報酬)の大学関連の仕事で、オンプレの環境からAWSへ引っ越す必要がでてきた。まぁ、女子大生（少なからず男子もいる）に触らせるのであまり凝ったことはしないから大したことはないのだが。
ちょっとお遊びでEC2のインスタンスにk3sを入れてみた。多分普通に入るのだが、少しハードルを上げてみた。
要件
- AMD64ではなく、ARMにする。（大学のご予算の関係）
- CSIドライバを使いたい。
という条件をつけてみた。
K3sなので、Ubuntu 20.04 ARMをa1.mediumで立ててみた。すごく安い。アーキテクチャーにこだわらないならこれからはARM一択ですね。
動作させた環境はこんな感じだった。
cat /proc/cpuinfo
processor : 0
BogoMIPS : 166.66
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
uname -a
Linux ip-X-X-X-X 5.13.0-1029-aws #32~20.04.1-Ubuntu SMP Thu Jun 9 13:06:11 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
おお。ラズパイやVMware Fusion M1/M2と同じ環境。もはやiPhone/iPadとならんで、数少ない即納されるARM環境。
というわけで早速K3sを導入。キーポイントは、K3sがもつCloud Providerを無効にしておくこと。いろいろググったが、オプションが古すぎて動かない。結局これで動いた。また、今回は、マスターノードだけである。もちろん、今回はARMでやったがAMD64でも普通に動くはず。
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.23 K3S_KUBECONFIG_MODE="644" sh -s - server \
--disable-cloud-controller \
--disable traefik \
--disable servicelb \
--kubelet-arg="provider-id=aws:///$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)/$(curl -s http://169.254.169.254/latest/meta-data/instance-id)"
これで普通に立ち上がる。ただし、Load BalancerもIngressも存在しないK3sであることに注意。
次にAWS EBS CSIドライバをインストールする。基本的に以下の設定を行なった。(IAMの設定は割愛）
以下でXMLを新規作成。key_idとaccess_keyは自分のを入れることをお忘れなく。
cat << EOF> /var/lib/rancher/k3s/server/manifests/aws-ebs-csi.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
name: aws-ebs-csi-driver
namespace: kube-system
spec:
chart: https://github.com/kubernetes-sigs/aws-ebs-csi-driver/releases/download/helm-chart-aws-ebs-csi-driver-2.10.1/aws-ebs-csi-driver-2.10.1.tgz
version: v 2.10.1
targetNamespace: kube-system
valuesContent: |-
enableVolumeScheduling: true
enableVolumeResizing: true
enableVolumeSnapshot: true
extraVolumeTags:
Name: k3s-ebs
anothertag: anothervalue
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: ebs-storageclass
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: Secret
metadata:
name: aws-secret
namespace: kube-system
stringData:
key_id: "AKIXXXXXXXXXXXXXXXXXXXX"
access_key: "6iYYYYYYYYYYYYYYYYYYYYYM"
EOF
少しまってから、以下を実行するとコンテナが作られる。
kubectl get pods -n kube-system | grep ebs
StorageClassの確認
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 11m
ebs-storageclass ebs.csi.aws.com Delete WaitForFirstConsumer false 3m57s
ストレージの作成テストをしてみる。
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
storageClassName: ebs-storageclass
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: storage-test
spec:
containers:
- name: "storage-test"
image: "ubuntu:latest"
command: ["/bin/sleep"]
args: ["infinity"]
volumeMounts:
- name: myebs
mountPath: /mnt/test
volumes:
- name: myebs
persistentVolumeClaim:
claimName: myclaim
EOF
kubectl get pod,pvc
NAME READY STATUS RESTARTS AGE
pod/storage-test 1/1 Running 0 26s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/myclaim Bound pvc-71f85bb0-6e96-4760-84a2-59eedc067657 1Gi RWO ebs-storageclass 26s
これでボリュームが作成された。。。はず。
EC2のダッシュボードを見ると、K3sのノード以外に1GBのボリュームができている。
タグ情報も確認。
マウント状態を確認してみた。ちゃんとマウントされている。
kubectl exec storage-test -- df -h
Filesystem Size Used Avail Use% Mounted on
overlay 7.6G 2.6G 5.0G 35% /
tmpfs 64M 0 64M 0% /dev
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/nvme1n1 976M 2.6M 958M 1% /mnt/test
/dev/root 7.6G 2.6G 5.0G 35% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 3.7G 12K 3.7G 1% /run/secrets/kubernetes.io/serviceaccount
tmpfs 1.9G 0 1.9G 0% /proc/acpi
tmpfs 1.9G 0 1.9G 0% /proc/scsi
tmpfs 1.9G 0 1.9G 0% /sys/firmware
終わるには、インスタンスを消せばいいのだが、インスタンスを消しても、CSIで作ったEBS Volumeは消されないので注意。
というわけで、あっさりできた。K3sのパラメータはめっちゃ重要。
それにしても、AMD64を使う意味がわからなくなってきたぞw