Kubernetes - Volumes
Dans Kubernetes, un volume peut être considéré comme un répertoire accessible aux conteneurs d'un pod. Nous avons différents types de volumes dans Kubernetes et le type définit comment le volume est créé et son contenu.
Le concept de volume était présent avec le Docker, mais le seul problème était que le volume était très limité à un pod particulier. Dès que la vie d'un pod s'est terminée, le volume était également perdu.
D'un autre côté, les volumes créés via Kubernetes ne sont limités à aucun conteneur. Il prend en charge tout ou partie des conteneurs déployés à l'intérieur du pod de Kubernetes. L'un des principaux avantages du volume Kubernetes est qu'il prend en charge différents types de stockage dans lesquels le pod peut en utiliser plusieurs en même temps.
Types de volume Kubernetes
Voici une liste de quelques volumes Kubernetes populaires -
emptyDir- C'est un type de volume qui est créé lorsqu'un pod est affecté pour la première fois à un nœud. Il reste actif tant que le pod fonctionne sur ce nœud. Le volume est initialement vide et les conteneurs du pod peuvent lire et écrire les fichiers dans le volume emptyDir. Une fois que le pod est supprimé du nœud, les données du emptyDir sont effacées.
hostPath - Ce type de volume monte un fichier ou un répertoire du système de fichiers du nœud hôte dans votre pod.
gcePersistentDisk- Ce type de volume monte un disque persistant Google Compute Engine (GCE) dans votre pod. Les données dans ungcePersistentDisk reste intact lorsque le pod est supprimé du nœud.
awsElasticBlockStore- Ce type de volume monte un Elastic Block Store Amazon Web Services (AWS) dans votre pod. Juste commegcePersistentDisk, les données dans un awsElasticBlockStore reste intact lorsque le pod est supprimé du nœud.
nfs - Un nfsvolume permet à un NFS (Network File System) existant d'être monté dans votre pod. Les données dans unnfsle volume n'est pas effacé lorsque le pod est supprimé du nœud. Le volume n'est que démonté.
iscsi - Un iscsi volume permet à un volume iSCSI (SCSI sur IP) existant d'être monté dans votre pod.
flocker- Il s'agit d'un gestionnaire de volume de données de conteneur en cluster open source. Il est utilisé pour gérer les volumes de données. UNEflockervolume permet à un ensemble de données Flocker d'être monté dans un pod. Si l'ensemble de données n'existe pas dans Flocker, vous devez d'abord le créer à l'aide de l'API Flocker.
glusterfs- Glusterfs est un système de fichiers en réseau open source. Un volume glusterfs permet de monter un volume glusterfs dans votre pod.
rbd- RBD signifie Rados Block Device. Unrbdvolume permet à un volume Rados Block Device d'être monté dans votre pod. Les données restent conservées après la suppression du pod du nœud.
cephfs - Un cephfsvolume permet à un volume CephFS existant d'être monté dans votre pod. Les données restent intactes après la suppression du pod du nœud.
gitRepo - Un gitRepo volume monte un répertoire vide et clone un git référentiel dedans pour que votre pod puisse l'utiliser.
secret - Un secret le volume est utilisé pour transmettre des informations sensibles, telles que des mots de passe, aux pods.
persistentVolumeClaim - Un persistentVolumeClaimvolume est utilisé pour monter un PersistentVolume dans un pod. Les PersistentVolumes sont un moyen pour les utilisateurs de «revendiquer» un stockage durable (tel qu'un GCE PersistentDisk ou un volume iSCSI) sans connaître les détails de l'environnement cloud particulier.
downwardAPI - Un downwardAPIle volume est utilisé pour rendre les données API descendantes disponibles aux applications. Il monte un répertoire et écrit les données demandées dans des fichiers texte brut.
azureDiskVolume - Un AzureDiskVolume est utilisé pour monter un disque de données Microsoft Azure dans un pod.
Réclamation de volume persistant et de volume persistant
Persistent Volume (PV)- C'est un élément de stockage réseau qui a été provisionné par l'administrateur. C'est une ressource du cluster qui est indépendante de tout pod individuel qui utilise le PV.
Persistent Volume Claim (PVC)- Le stockage demandé par Kubernetes pour ses pods est appelé PVC. L'utilisateur n'a pas besoin de connaître le provisionnement sous-jacent. Les revendications doivent être créées dans le même espace de noms où le pod est créé.
Création d'un volume persistant
kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
name: pv0001 ------------------> 2
labels:
type: local
spec:
capacity: -----------------------> 3
storage: 10Gi ----------------------> 4
accessModes:
- ReadWriteOnce -------------------> 5
hostPath:
path: "/tmp/data01" --------------------------> 6Dans le code ci-dessus, nous avons défini -
kind: PersistentVolume → Nous avons défini le genre comme PersistentVolume qui indique à kubernetes que le fichier yaml utilisé est de créer le volume persistant.
name: pv0001 → Nom du PersistentVolume que nous créons.
capacity: → Cette spécification définira la capacité de PV que nous essayons de créer.
storage: 10Gi → Cela indique à l'infrastructure sous-jacente que nous essayons de réclamer un espace de 10Gi sur le chemin défini.
ReadWriteOnce → Cela indique les droits d'accès du volume que nous créons.
path: "/tmp/data01" → Cette définition indique à la machine que nous essayons de créer un volume sous ce chemin sur l'infrastructure sous-jacente.
Création de PV
$ kubectl create –f local-01.yaml
persistentvolume "pv0001" createdVérification PV
$ kubectl get pv
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
pv0001 10Gi RWO Available 14sDécrire PV
$ kubectl describe pv pv0001Création d'une revendication de volume persistant
kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
name: myclaim-1 --------------------> 2
spec:
accessModes:
- ReadWriteOnce ------------------------> 3
resources:
requests:
storage: 3Gi ---------------------> 4Dans le code ci-dessus, nous avons défini -
kind: PersistentVolumeClaim → Il indique à l'infrastructure sous-jacente que nous essayons de réclamer une quantité d'espace spécifiée.
name: myclaim-1 → Nom de la revendication que nous essayons de créer.
ReadWriteOnce → Ceci spécifie le mode de la revendication que nous essayons de créer.
storage: 3Gi → Cela indiquera à Kubernetes la quantité d'espace que nous essayons de réclamer.
Créer du PVC
$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" createdObtenir des détails sur le PVC
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
myclaim-1 Bound pv0001 10Gi RWO 7sDécrivez le PVC
$ kubectl describe pv pv0001Utilisation du PV et du PVC avec POD
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
name: frontendhttp
spec:
containers:
- name: myfrontend
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts: ----------------------------> 1
- mountPath: "/usr/share/tomcat/html"
name: mypd
volumes: -----------------------> 2
- name: mypd
persistentVolumeClaim: ------------------------->3
claimName: myclaim-1Dans le code ci-dessus, nous avons défini -
volumeMounts: → C'est le chemin dans le conteneur sur lequel le montage aura lieu.
Volume: → Cette définition définit la définition de volume que nous allons revendiquer.
persistentVolumeClaim: → En dessous, nous définissons le nom du volume que nous allons utiliser dans le pod défini.