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.

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

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.

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.

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).