手持ちの環境は、M1 MacBook Airしかない。。。そうM1のパフォーマンスに驚いて、Intel アーキテクチャのデスクトップとか全部処分してしまった。その時はIntelはいらないと。。。
で、こまった。まだIntel全盛。
そんなところで、M1でKubernetesが動く、Rancher Desktop。こりゃいいやと。Rancher Desktopはライトウェイトで全部入り。
QNAPのKubernetesであるk3sもそう。ただ、仕事の都合上CSI Driverでスナップショットを動かさなきゃならない。
まぁ、VM上でVanilla Kubernetesだろうが、Tanzu Community Editionを動かせばいいのだが、如何せんセットアップに時間がかかる。
といいつつ、自動化しているのでそれほどかからないが。
閑話休題
Rancher Desktopを使いこなす、特にCSI Hostpath Driverを動かそうという企画
ダウンロードは以下
ちなみに、プラットフォームは問わないけど、16GB以上のメモリのマシンでやったほうがいいと思う。
Rancher Dekstopのインストールは普通のアプリケーションなので、インストール方法は割愛。
Rancher Desktopをインストールしたら、Kubernetesは1.22.8 (最新)、CPUは、４コア、メモリは8GBにしておく。CPUとメモリを変更したら、リセット。自分のM1は16GBなので、8GBにしてもあまり影響はない。M1でメモリ追加しておいてよかった。
上記の設定が終わるとこんな感じ。local-pathが入っているのがRancherのいいところ。ただ、CSIドライバーではない。これでもいいんだけどねぇ。
平たくいうと、少し設定がされたKubernetes Kindみたいなもの。（Kubernetes KindもM1で一応動くが。。。)
でいきなり、お仕事の関係でCSI hostpath Driverを入れてみた。
SNAPSHOTTERを最新でいれている。。。これは気分。
SNAPSHOTTER_VERSION=5.0.1
# Apply VolumeSnapshot CRDs
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
# Create Snapshot Controller
kubectl -n kube-system apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v${SNAPSHOTTER_VERSION}/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl -n kube-system apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v${SNAPSHOTTER_VERSION}/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
# Install CSI-Hostpath Driver
git clone https://github.com/kubernetes-csi/csi-driver-host-path --depth 1
cd csi-driver-host-path
./deploy/kubernetes-1.22/deploy.sh
# Define Storage Class
kubectl apply -f ./examples/csi-storageclass.yaml
# Set default Storage Class
kubectl patch storageclass local-path \
-p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
kubectl patch storageclass csi-hostpath-sc \
-p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
これで終わり。CSI DriverとSnapshot Classができた。
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
csi-hostpath-sc (default) hostpath.csi.k8s.io Delete Immediate true 4m52s
local-path rancher.io/local-path Delete WaitForFirstConsumer false 19m
kubectl get csidrivers.storage.k8s.io
NAME ATTACHREQUIRED PODINFOONMOUNT STORAGECAPACITY TOKENREQUESTS REQUIRESREPUBLISH MODES AGE
hostpath.csi.k8s.io true true false <unset> false Persistent,Ephemeral 97s
kubectl get volumesnapshotclasses.snapshot.storage.k8s.io
NAME DRIVER DELETIONPOLICY AGE
csi-hostpath-snapclass hostpath.csi.k8s.io Delete 103s
動作確認
とりあえず、適当なコンテナを作成。あとで消しやすいようにNamespace:Test1につくる。
kubectl create namespace test1
cat << EOF | kubectl --namespace=test1 create -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: csi-hostpath-sc
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
EOF
結果
kubectl -n test1 get pod,pvc
NAME READY STATUS RESTARTS AGE
pod/task-pv-pod 1/1 Running 0 28s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/task-pv-claim Bound pvc-6c9e77ba-a0e2-4c87-8ae2-11716307acd5 1Gi RWO csi-hostpath-sc 28s
うーん、マンダム（化石）。PVCはできとる。スナップショットを撮ってみる。Snapshot Classは、Storage Classではないことに注意。最初のころ何回もはハマった。思い込みは怖い。
cat << EOF | kubectl --namespace=test1 create -f -
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: new-task-pv-snapshot
spec:
volumeSnapshotClassName: csi-hostpath-snapclass
source:
persistentVolumeClaimName: task-pv-claim
EOF
できてる。
リストア
cat << EOF | kubectl --namespace=test1 create -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: restore-task-pv-snapshot
spec:
storageClassName: csi-hostpath-sc
dataSource:
name: new-task-pv-snapshot
kind: VolumeSnapshot
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod-restore
spec:
volumes:
- name: task-pv-storage-restore
persistentVolumeClaim:
claimName: restore-task-pv-snapshot
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage-restore
EOF
リストア後。。。
kubectl -n test1 get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
task-pv-claim Bound pvc-6c9e77ba-a0e2-4c87-8ae2-11716307acd5 1Gi RWO csi-hostpath-sc 7m59s
restore-task-pv-snapshot Bound pvc-51600879-960a-434a-aeec-967ae22a0404 1Gi RWO csi-hostpath-sc 106s
#スナップショットはいらないので消しちゃえ。
kubectl -n test1 delete volumesnapshot new-task-pv-snapshot
volumesnapshot.snapshot.storage.k8s.io "new-task-pv-snapshot" deleted
kubectl -n test1 describe pod task-pv-pod-restore
ーーーーーーー略ーーーーーーーーーーー
Volumes:
task-pv-storage-restore:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: restore-task-pv-snapshot
ReadOnly: false
kube-api-access-2pwdh:
ーーーーーーー略ーーーーーーーーーーー
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 111s default-scheduler 0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
Normal Scheduled 109s default-scheduler Successfully assigned test1/task-pv-pod-restore to lima-rancher-desktop
Normal SuccessfulAttachVolume 110s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-51600879-960a-434a-aeec-967ae22a0404"
Normal Pulling 100s kubelet Pulling image "nginx"
Normal Pulled 98s kubelet Successfully pulled image "nginx" in 1.657837334s
Normal Created 98s kubelet Created container task-pv-container
Normal Started 98s kubelet Started container task-pv-container
ちゃんとSnapshotで作ったVolumeをマウントしている。
ちなみに、CSI-hostpath Driverって、helmから動かすときは、 –set volumePermissions.enabled=true が必要。kubeappでアプリを引っ張るときに、このオプションがないと起動できない。kubeappから指定できないアプリもある。特別扱いしなければいけないので、実はあんまり好きではない。。。
その他
WordPressを作ってみた。Metallbで動く環境をそのまま動かしてみたが、Rancher Desktopでは、そのままだとLoad BalancerがpendingのままでExternal IPは付与されない。
kubectl -n blog1 get pod,pvc,svc
NAME READY STATUS RESTARTS AGE
pod/mysql-release-0 1/1 Running 0 20m
pod/svclb-wordpress-bcl2n 0/1 Pending 0 18m
pod/wordpress-64f6b9f4f4-fcvnf 1/1 Running 0 18m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/data-mysql-release-0 Bound pvc-33ab61f5-a5ec-4238-8f89-d2aea59ca126 8Gi RWO csi-hostpath-sc 20m
persistentvolumeclaim/wp-pv-claim Bound pvc-5dfce715-603a-434e-a6a7-defcb552e993 5Gi RWO csi-hostpath-sc 18m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/mysql-release-headless ClusterIP None <none> 3306/TCP 20m
service/mysql-release ClusterIP 10.43.58.250 <none> 3306/TCP 20m
service/wordpress LoadBalancer 10.43.210.13 <pending> 80:31763/TCP 18m
WordPressを作るのが面倒な人で、Macな人は
以下をダウンロードして、
https://raw.githubusercontent.com/masezou/k8s-study-vanilla/main/P-wordpress.sh
ファイルの先頭にあるパラメータ
FORCE_ONLINE=1
SC=csi-hostpath-sc
として、スクリプトを実行
実は、kubectlでPort ForwardしなくてもUIで簡単にPort Forwardができる。
Port Forwardするとlocalhost:ポート番号でアクセスができる。
Kubectl port-forwadって、どのポートをフォワードしていたか忘れてしまうんですよね。そんないい感じのポート番号は思いつかない。トイレに立っただけで忘れてしまう。
というわけで一通り使ってみた。CSI Hostpath Driverで動かしてみたが、Docker 付属のKubernetesやKindより便利で痒い所に手が届く感じ。Rancher DesktopはM1 Macの上でちょろっと動くので便利だなぁ。
GWに試してみるのはいかがですか？