2020年版 Kubernetes CSIプラグインのテスト
このBlogでは過去にもKubernetesとDRBD SDSの設定方法を紹介していますが、OSやパッケージのバージョンが変わったために、そのままでは動作しなくなりました。本Blogでは入手可能な最新のCSIプラグインを使って、DRBDで冗長化したストレージをKubernetesから利用する方法を紹介します。
1.ソフトウェアのバージョン
OS Ubuntu 20.04 LTS
Kubernetes 1.17.11
DRBD 9.0.24
LINSTOR 1.3.0LINSTORとKubernetesのインストール方法は別のベージで紹介していますので、そちらを参照ください。
２.CSIプラグインのインストール
LINBITのCSIプラグインの開発者からの情報ではここにあります。開発中のCSIプラグインはKubernetes 1.17に対応していますが、1.18でも動作するそうです。今後のKubernetesやLINSTORのバージョンアップで、プラグインも更新されるので、このサイトは時々確認されることを勧めます。yamlファイルをダウンロードして、kubectlコマンドでプラグインをインストールします。
kbadm@node1:~$ wget https://github.com/piraeusdatastore/linstor-csi/blob/master/examples/k8s/deploy/linstor-csi-dev.yaml kbadm@node1:~$ kubectl apply -f linstor-csi-dev.yaml statefulset.apps/linstor-csi-controller created serviceaccount/linstor-csi-controller-sa created clusterrole.rbac.authorization.k8s.io/linstor-csi-provisioner-role created clusterrolebinding.rbac.authorization.k8s.io/linstor-csi-provisioner-binding created clusterrole.rbac.authorization.k8s.io/linstor-csi-attacher-role created clusterrolebinding.rbac.authorization.k8s.io/linstor-csi-attacher-binding created clusterrole.rbac.authorization.k8s.io/linstor-csi-resizer-role created clusterrolebinding.rbac.authorization.k8s.io/linstor-csi-resizer-binding created daemonset.apps/linstor-csi-node created serviceaccount/linstor-csi-node-sa created clusterrole.rbac.authorization.k8s.io/linstor-csi-driver-registrar-role created csidriver.storage.k8s.io/linstor.csi.linbit.com created clusterrolebinding.rbac.authorization.k8s.io/linstor-csi-driver-registrar-binding created clusterrole.rbac.authorization.k8s.io/linstor-csi-snapshotter-role created
インストールが終わったら、linstor-csiのpodが起動しているか確認します。
kbadm@node1:~$ kubectl get all -n kube-system NAME READY STATUS RESTARTS AGE pod/cilium-26qmg 1/1 Running 1 32m pod/cilium-9h99q 1/1 Running 1 32m pod/cilium-operator-6f659d6699-pw69s 1/1 Running 1 32m pod/cilium-operator-6f659d6699-qqvkn 1/1 Running 1 32m pod/cilium-rtmsv 1/1 Running 1 32m pod/coredns-6955765f44-q9tgm 1/1 Running 1 33m pod/coredns-6955765f44-xdcn7 1/1 Running 1 33m pod/etcd-node1 1/1 Running 1 33m pod/kube-apiserver-node1 1/1 Running 1 33m pod/kube-controller-manager-node1 1/1 Running 1 33m pod/kube-proxy-2s4hx 1/1 Running 1 33m pod/kube-proxy-pbl4k 1/1 Running 1 33m pod/kube-proxy-qjjms 1/1 Running 1 33m pod/kube-scheduler-node1 1/1 Running 1 33m pod/linstor-csi-controller-0 0/5 ContainerCreating 0 18s pod/linstor-csi-node-c27d6 0/2 ContainerCreating 0 18s pod/linstor-csi-node-g4284 0/2 ContainerCreating 0 18s
全てのpodがRunningになれば正常です。
pod/linstor-csi-controller-0 5/5 Running 0 51s pod/linstor-csi-node-c27d6 2/2 Running 0 51s pod/linstor-csi-node-g4284 2/2 Running 0 51s
3.動作テスト
StorageClass、PVCの順番に作成して、最後にストレージにアクセスするPODを作成します。
StorageClassを定義します。two-replica-sc.yamlというファイルを作成して内容は次になります。
kbadm@node1:~$ cat two-replica-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: two-replica
provisioner: linstor.csi.linbit.com
parameters:
autoPlace: "2"
storagePool: "linstor-pool"
定義ファイルからStorageClassを作成します。
kbadm@node1:~$ kubectl apply -f two-replica-sc.yaml storageclass.storage.k8s.io/two-replica created
次にPVCを定義します。
my-first-volume-pvc.yaml というファイルを作成して内容は次になります。
kbadm@node1:~$ cat my-first-volume-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: my-first-volume
annotations:
volume.beta.kubernetes.io/storage-class: two-replica
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
定義ファイルからPVCを作成します。
kbadm@node1:~$ kubectl apply -f my-first-volume-pvc.yaml persistentvolumeclaim/my-first-volume created kbadm@node1:~$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-first-volume Bound pvc-5a4a75eb-0... 500Mi RWO two-replica 13s
PVCが作成されたら、LINSTORでリソースが定義されたかlinstorコマンドで確認します。
kbadm@node1:~$ linstor resource list +--------------------------------------------------------------------------------------+ | ResourceName | Node | Port | Usage | Conns | State | CreatedOn | |======================================================================================| | pvc-5a4a75eb-05ef-4a19-.... | node1 | 7000 | Unused | Ok | UpToDate | 2020-09-... | | pvc-5a4a75eb-05ef-4a19-.... | node2 | 7000 | Unused | Ok | UpToDate | 2020-09-... | +--------------------------------------------------------------------------------------+
テスト用のPODとしてFedoraを起動します。Fedoraの定義はfedora.yaml というファイルを作成して内容は次になります。
apiVersion: v1
kind: Pod
metadata:
name: fedora
namespace: default
spec:
containers:
- name: fedora
image: fedora
command: [/bin/bash]
args: ["-c", "while true; do sleep 10; done"]
volumeMounts:
- name: default-my-first-volume
mountPath: /data
ports:
- containerPort: 80
volumes:
- name: default-my-first-volume
persistentVolumeClaim:
claimName: "my-first-volume"
PODを起動しましょう。
kbadm@node1:~$ kubectl apply -f fedora.yaml pod/fedora created kubectl get pods NAME READY STATUS RESTARTS AGE fedora 1/1 Running 0 20s
PODにログインして/dataにストレージがマウントされているかどうかを確認します。
kbadm@node1:~$ kubectl exec fedora -it /bin/bash [root@fedora /]# df Filesystem 1K-blocks Used Available Use% Mounted on overlay 9219412 4936940 3794436 57% / tmpfs 65536 0 65536 0% /dev tmpfs 1017640 0 1017640 0% /sys/fs/cgroup /dev/drbd1000 491456 2318 459245 1% /data /dev/mapper/ubuntu--vg-ubuntu--lv 9219412 4936940 3794436 57% /etc/hosts shm 65536 0 65536 0% /dev/shm tmpfs 1017640 12 1017628 1% /run/secrets/kube... tmpfs 1017640 0 1017640 0% /proc/acpi tmpfs 1017640 0 1017640 0% /proc/scsi tmpfs 1017640 0 1017640 0% /sys/firmware
/dev/drbd1000が/dataにマウントされていることが判りました。
この/dataに何かデータを作成して、別のホストにPODが移動してもデータに参照できるか確認してみてください。