Kubernetes - données persistantes ?

Table of Contents

Out of the box : pas de persistance de la données dans Kubernetes, quand un pod est détruit toutes ses données le sont avec !

❓ Comment avoir un stockage qui ne dépend pas du cycle de vie du pod ?

❓ Comment disposer du stockage quelque soit le nœud d’exécution ?

C’est parti pour le jeu d’assemblage …

Passage obligé : un peu de vocabulaire !

Petit clin d’œil aux pratiquant de la Wim Hof Method !

Volumes “ephemeral”

👉 Pour le partage de donnée entre containers d’un même pod

👉 Pour le cache d’informations temporaires

👉 Pour le chargement de secrets / de configuration

Persistent Volume (PV)

👉 C’est une ressource du cluster comme la RAM ou le CPU, il n’est donc pas associé à un namespace.

👉 C’est un élément de stockage provisionné par l’administrateur ou provisionné dynamiquement à l’aide de Storage Classes.

👉 Son cycle de vie est indépendant de tout pod qui le consomme.

Persistent Volume Claim (PVC)

👉 C’est une demande de stockage par le développeur

👉 Les PVC consomment des ressources de type PV

👉 Un stratégie d’accès doit être définie en fonction du cas d’usage

✔️ ReadWriteOnce  ➡️ Monté sur un simple POD en lecture & écriture

✔️ ReadOnlyMany  ➡️ Monté sur plusieurs POD en lecture seule

✔️ ReadWriteMany ➡️ Monté sur plusieurs POD en lecture & écriture

Storage Class

👉 Gestionnaire automatique de volumes persistants

👉 De nombreux pilotes locaux ou distants sont disponibles

✔️ NFS

✔️ CephFS

✔️ Glusterfs

✔️ HostPath (Local Storage)

✔️ Longhorn Storage (un bon cheval pour le homelab)

✔️ ….

Sans pratiquer pas évident …

Une petite synthèse “visuelle” avec applications de provisionnement manuel

Provisionning dynamique de stockage NFS

Penchons nous sur une approche plus “scalable” et résiliente avec un provisionnement dynamique sous NFS …

🎯 L’objectif est de disposer d’un répertoire sur le NAS dans lequel on va piocher pour mettre à disposition de l’espace.

Le plan de marche :

Nouvelle notion le RBAC

Je ne vais pas développer ici …

Définition d’une politique pour Persistent Volumes et Persistent Volume Claims

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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: ["create", "update", "patch"]

Définition d’un compte de service que l’on attache à un cluster

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner

Le ClusterRoleBinding attache le ClusterRole et le ServiceAccount ensemble

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

Création d’un rôle supplémentaire pour le ServiceAccount (SA)

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]

Le RoleBinding attache le Role et le ServiceAccount ensemble

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

Déploiement du provisioner NFS, qui va préparer et nous mettre à disposition l’espace

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  namespace: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 172.16.4.1
            - name: NFS_PATH
              value: /kubedata
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.16.4.1
            path: /kubedata

Revenons à nos volumes avec une StorageClass qui sera référence par le PVC pour adresser sa demande d’espace

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner 
parameters:
  archiveOnDelete: "false"
  pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" 
  onDelete: delete

Maintenant nous pouvons commander l’espace

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
  namespace: learn-volume06
spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

Et le consommer :

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: protopod
spec:
  containers:
  - name: test-pod
    image: busybox:stable
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && sleep 60 && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim

Une fois notre POD lancé, le SUCCESS est disponible sur le NAS

Eric
Eric
🛡️ Cybersecurity enthusiast driven by curiosity and the desire to share.

Related