Différences

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

--- veilletechno:kubernetes:iscsi:targetd [2019/02/03 15:39] – madko
+++ veilletechno:kubernetes:iscsi:targetd [2019/02/03 15:56] (Version actuelle) – [Changer la classe de stockage par défaut] madko
@@ Ligne 50: / Ligne 50: @@
 kubectl apply -f iscsi-provisioner-class.yaml
 </code>
 ===== Création d'un secret pour les info de connexion à targetd =====
@@ Ligne 60: / Ligne 61: @@
 Le login est **admin**.
-Le mot de passe est **secret**.\\
+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>