Différences

Ci-dessous, les différences entre deux révisions de la page.

--- veilletechno:kubernetes:iscsi:targetd [2019/02/03 15:33] – madko
+++ veilletechno:kubernetes:iscsi:targetd [2019/02/03 15:56] (Version actuelle) – [Changer la classe de stockage par défaut] madko
@@ Ligne 27: / Ligne 27: @@
 # this must be on eof the volume groups condifgured in targed.yaml, the default is vg-targetd
-# volumeGroup: 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.2017-04.com.example:node1
+  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: "true"
+  chapAuthDiscovery: "false"
 # whether or not to use chap authentication for session operations
-  chapAuthSession: "true"
+  chapAuthSession: "false"
 # This is the filesystem you want your volume to be formatted with, default xfs
@@ Ligne 44: / Ligne 44: @@
 # readonly: false
 </file>
+Puis pour l'appliquer :
+<code>
+kubectl apply -f iscsi-provisioner-class.yaml
+</code>
+===== 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 :
+<code>
+kubectl create secret generic targetd-account --from-literal=username=admin --from-literal=password=secret -n kube-system
+</code>
+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 :
+<file>
+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
+</file>
+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 :
+<code>
+kubectl apply -f iscsi-provisioner-d.yaml -n kube-system
+</code>
+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 :
+<file>
+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
+</file>
+Pour l'appliquer :
+<code>
+kubectl apply -f iscsi-provisioner-pvc.yaml
+</code>
+Pour voir l'état de la demande :
+<code>
+kubectl get pvc
+</code>
+Si tout se passe bien :
+<code>
+NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
+myclaim   Bound    pvc-3445c061-27cb-11e9-8d76-0200c0a8024b   100Mi      RWO            iscsi-targetd-vg-targetd   3s
+</code>
+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 :
+<code>
+[root@node1 ~]# kubectl get sc
+NAME                       PROVISIONER     AGE
+iscsi-targetd-vg-targetd   iscsi-targetd   18m
+</code>
+Pour définir une classe comme classe par défaut :
+<code>
+kubectl patch storageclass iscsi-targetd-vg-targetd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
+</code>
+Résultat :
+<code>
+[root@node1 ~]# kubectl get sc
+NAME                                 PROVISIONER     AGE
+iscsi-targetd-vg-targetd (default)   iscsi-targetd   18m
+</code>