====== Création d'un fournisseur de LUN iSCSI dans kubernetes ======
Il existe un contrôleur capable de piloter à distance un serveur iSCSI targetd. Cela permet de créer une classe de stockage de type iSCSI targetd, afin d'avoir des volumes utilisant des LUNs iSCSI créés à la volée par ce contrôleur.
===== Classe de stockage =====
Création d'une storage class avec les info de notre serveur targetd :
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: iscsi-targetd-vg-targetd
provisioner: iscsi-targetd
parameters:
# this id where the iscsi server is running
targetPortal: 192.168.2.107:3260
# if you are using multipath, you can specify additional IPs here, default empty
# portals: 192.168.99.101:3260,192.168.99.102:3260
# this is the iscsi server iqn
iqn: iqn.2019-02.org.linux-iscsi.k8s:targetd
# this is the iscsi interface to be used, the default is default
# iscsiInterface: default
# this must be on eof the volume groups condifgured in targed.yaml, the default is vg-targetd
volumeGroup: iscsi
# this is a comma separated list of initiators that will be give access to the created volumes, they must correspond to what you have configured in your nodes.
initiators: iqn.2019-02.org.linux-iscsi.k8s:dockernode0,iqn.2019-02.org.linux-iscsi.k8s:dockernode1,iqn.2019-02.org.linux-iscsi.k8s:dockernode2
# whether or not to use chap authentication for discovery operations
chapAuthDiscovery: "false"
# whether or not to use chap authentication for session operations
chapAuthSession: "false"
# This is the filesystem you want your volume to be formatted with, default xfs
# fsType: xfs
# Whether the volume should be mounted in readonly mode, default false
# readonly: false
Puis pour l'appliquer :
kubectl apply -f iscsi-provisioner-class.yaml
===== Création d'un secret pour les info de connexion à targetd =====
Pour se connecter au serveur targetd, le pod controleur doit connaitre le login et mot de passe. Nous allons stocker ces informations dans un secret de kubernetes :
kubectl create secret generic targetd-account --from-literal=username=admin --from-literal=password=secret -n kube-system
Le login est **admin**.
Le mot de passe est **secret**.
===== Contrôleur =====
Le contrôleur a besoin de quelques autorisations pour surveiller les demandes de volumes persistents, pour créer les LUNs etc
Sa définition yaml est la suivante :
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: iscsi-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "list", "create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-iscsi-provisioner
subjects:
- kind: ServiceAccount
name: iscsi-provisioner
namespace: kube-system
roleRef:
kind: ClusterRole
name: iscsi-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: iscsi-provisioner
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: iscsi-provisioner
spec:
replicas: 1
template:
metadata:
labels:
app: iscsi-provisioner
spec:
containers:
- name: iscsi-provisioner
imagePullPolicy: Always
image: quay.io/external_storage/iscsi-controller:latest
args:
- "start"
env:
- name: PROVISIONER_NAME
value: iscsi-targetd
- name: LOG_LEVEL
value: debug
- name: TARGETD_USERNAME
valueFrom:
secretKeyRef:
name: targetd-account
key: username
- name: TARGETD_PASSWORD
valueFrom:
secretKeyRef:
name: targetd-account
key: password
- name: TARGETD_ADDRESS
value: 192.168.2.107
serviceAccount: iscsi-provisioner
Ce contrôleur a pour but de fournir des volumes, des LUNs ISCSI aux pods demandeurs. Il répond donc aux pvc via des pv créer en tant que LUNs sur le serveur targetd.
Pour appliquer le yaml :
kubectl apply -f iscsi-provisioner-d.yaml -n kube-system
On peut ensuite créer une PVC et un pod utilisateur pour valider l'ensemble.
===== Création d'une demande de volume de test =====
Le but est de valider le travail du contrôleur avec une demande de volume persistent. Définition yaml :
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
annotations:
volume.beta.kubernetes.io/storage-class: "iscsi-targetd-vg-targetd"
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Mi
Pour l'appliquer :
kubectl apply -f iscsi-provisioner-pvc.yaml
Pour voir l'état de la demande :
kubectl get pvc
Si tout se passe bien :
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myclaim Bound pvc-3445c061-27cb-11e9-8d76-0200c0a8024b 100Mi RWO iscsi-targetd-vg-targetd 3s
Sur le serveur targetd, on doit voir une nouvelle LUN (via targetcli) et un nouvel LV qui l'utilise (notre targetd est configuré pour utiliser du LVM via un VG appelé iscsi).
===== Changer la classe de stockage par défaut =====
Nous avons vu que notre test de PVC explicite clairement sa classe de stockage. Si nous voulons que par défaut les pods qui ne précise rien à ce niveau parte sur notre classe de stockage iSCSI, il suffit de définir cette dernière comme classe par défaut.
Pour afficher les classes de stockage :
[root@node1 ~]# kubectl get sc
NAME PROVISIONER AGE
iscsi-targetd-vg-targetd iscsi-targetd 18m
Pour définir une classe comme classe par défaut :
kubectl patch storageclass iscsi-targetd-vg-targetd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Résultat :
[root@node1 ~]# kubectl get sc
NAME PROVISIONER AGE
iscsi-targetd-vg-targetd (default) iscsi-targetd 18m