Partie 1 Nous déployons l'environnement pour travailler avec des microservices. Partie 1 Installer Kubernetes HA sur du métal nu (Debian)

Bonjour, chers lecteurs de Habr!

Dans un article précédent , j'ai expliqué comment déployer un cluster de basculement Kubernetes. Mais le fait est que dans Kubernetes, il est pratique de déployer des applications sans état qui n'ont pas besoin de conserver leur état ou de travailler avec des données. Mais dans la plupart des cas, nous devons enregistrer les données et ne pas les perdre lors du redémarrage des foyers.
Kubernetes utilise des volumes à ces fins. Lorsque nous travaillons avec des solutions cloud Kubernetes, il n'y a pas de problèmes particuliers. Il nous suffit de commander le volume requis auprès de Google, Amazon ou d'un autre fournisseur de cloud et, guidé par la documentation , de connecter les volumes reçus aux pods.
Lorsque nous traitons de métal nu, les choses sont un peu plus compliquées. Aujourd'hui, je veux parler d'une des solutions basées sur l'utilisation de ceph.

Dans cette publication, je dirai:

• comment déployer le stockage distribué ceph
• Comment utiliser Ceph lorsque vous travaillez avec Kubernetes

Présentation

Pour commencer, je voudrais expliquer à qui cet article sera utile. Tout d'abord, pour les lecteurs qui ont déployé le cluster selon ma première publication afin de continuer à construire une architecture de microservices. Deuxièmement, pour les personnes qui souhaitent essayer de déployer un cluster ceph par leurs propres moyens et d'évaluer ses performances.

Dans cette publication, je n'aborderai pas le sujet de la planification de cluster pour tous les besoins, je ne parlerai que des principes et concepts généraux. Je ne m'attarderai pas sur le "tuning" et le deep tuning, il existe de nombreuses publications sur ce sujet, notamment sur le Habr. L'article sera de nature plus introductive, mais en même temps, il vous permettra d'obtenir une solution de travail que vous pourrez adapter à vos besoins à l'avenir.

1. Liste des hôtes, des ressources hôtes, des versions du système d'exploitation et des logiciels
2. Structure du cluster Ceph
3. Configurer les nœuds de cluster avant l'installation
4. Installer ceph-deploy
5. Création d'un cluster ceph
6. Configuration du réseau
7. Installer les packages ceph
8. Installation et initialisation de moniteurs
9. Ajout d'OSD
10. Connectez ceph à kubernetes
11. Création d'un pool de données
12. Création d'un secret client
13. Déployer ceph rbd provisioner
14. Création d'une classe de stockage
15. Test du ligament de Kubernetes + ceph
16. Liste des matériaux utilisés dans la préparation de l'article

Liste d'hôtes et configuration système requise

Lors de la rédaction d'un article, j'utilise des machines virtuelles avec cette configuration

Chacun a un OS Debian 9.5 installé. Ce sont des machines de test, chacune avec deux disques, le premier pour l'OS, le second pour l'OSD cef.

Je déploierai le cluster via l'utilitaire ceph-deploy. Vous pouvez déployer un cluster ceph en mode manuel, toutes les étapes sont décrites dans la documentation, mais le but de cet article est de dire à quelle vitesse vous pouvez déployer ceph et commencer à l'utiliser dans kubernetes.
Ceph est assez gourmand pour les ressources, en particulier la RAM. Pour une bonne vitesse, il est conseillé d'utiliser des disques SSD.

Vous pouvez en savoir plus sur les exigences dans la documentation officielle de ceph.

Structure du cluster Ceph

LUN
Un moniteur est un démon qui agit en tant que coordinateur à partir duquel le cluster commence. Dès que nous avons au moins un moniteur fonctionnel, nous avons un cluster Ceph. Le moniteur stocke des informations sur la santé et l'état du cluster en échangeant diverses cartes avec d'autres moniteurs. Les clients se tournent vers les moniteurs pour savoir sur quel OSD écrire / lire les données. Lorsque vous déployez un nouveau stockage, la première chose que vous faites est de créer un moniteur (ou plusieurs). Le cluster peut vivre sur un seul moniteur, mais il est recommandé de réaliser 3 ou 5 moniteurs afin d'éviter la chute de l'ensemble du système due à la chute d'un seul moniteur. L'essentiel est que le nombre de ceux-ci soit impair afin d'éviter les situations de cerveau divisé. Les moniteurs fonctionnent dans un quorum, donc si plus de la moitié des moniteurs tombent, le cluster sera bloqué pour éviter l'incohérence des données.
Mgr
Le démon Ceph Manager fonctionne avec le démon moniteur pour fournir un contrôle supplémentaire.
Depuis la version 12.x, le démon ceph-mgr est devenu nécessaire pour un fonctionnement normal.
Si le démon mgr n'est pas en cours d'exécution, vous verrez un avertissement à ce sujet.
OSD (périphérique de stockage d'objets)
OSD est une unité de stockage qui stocke les données elles-mêmes et traite les demandes des clients en échangeant des données avec d'autres OSD. Il s'agit généralement d'un disque. Et généralement, pour chaque OSD, il existe un démon OSD distinct qui peut s'exécuter sur n'importe quelle machine sur laquelle ce disque est installé.

Les trois démons fonctionneront sur chaque machine de notre cluster. En conséquence, surveillez et gérez les démons en tant que démons de service et OSD pour un lecteur de notre machine virtuelle.

Configurer les nœuds de cluster avant l'installation

La documentation de ceph spécifie le workflow suivant:

Je travaillerai à partir du premier nœud du cluster ceph01-test, ce sera Admin Node, il contiendra également des fichiers de configuration pour l'utilitaire ceph-deploy. Pour que l'utilitaire ceph-deploy fonctionne correctement, tous les nœuds de cluster doivent être accessibles via ssh avec le nœud Admin. Pour plus de commodité, j'écrirai dans les hôtes des noms courts pour le cluster

10.73.88.52 ceph01-test 10.73.88.53 ceph02-test 10.73.88.54 ceph03-tset 

Et copiez les clés sur les autres hôtes. Toutes les commandes que j'exécuterai depuis root.

 ssh-copy-id ceph02-test ssh-copy-id ceph03-test 

Documentation d'installation

Installer ceph-deploy

La première étape consiste à installer ceph-deploy sur la machine de test ceph01

 wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add - 

Ensuite, vous devez choisir la version que vous souhaitez mettre. Mais ici il y a des difficultés, actuellement ceph pour Debian OS ne supporte que les paquets lumineux.
Si vous voulez mettre une version plus récente, vous devrez utiliser un miroir, par exemple
https://mirror.croit.io/debian-mimic/dists/

Ajouter un référentiel avec mimic sur les trois nœuds

 apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-deploy 

Si lumineux vous suffit, alors vous pouvez utiliser les dépôts officiels

 echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list apt-transport-https apt update apt install ceph-deploy 

Nous installons également NTP sur les trois nœuds.

 apt install ntp 

Assurez-vous d'activer le service NTP. Assurez-vous que chaque nœud Ceph utilise le même serveur NTP. Vous pouvez voir plus de détails ici

Création d'un cluster ceph

Créer un répertoire pour les fichiers de configuration et les fichiers ceph-deploy

 mkdir my-cluster cd my-cluster 

Créons une nouvelle configuration de cluster, lors de la création, indiquons qu'il y aura trois moniteurs dans notre cluster

 ceph-deploy new ceph01-test ceph02-test ceph03-test 

Configuration du réseau

Maintenant, le point important, il est temps de parler du réseau pour ceph. Ceph utilise deux réseaux publics et un réseau de clusters pour fonctionner

Comme vous pouvez le voir sur le diagramme du réseau public, il s'agit du niveau utilisateur et application, et le réseau de cluster est le réseau à travers lequel les données sont répliquées.
Il est hautement souhaitable de séparer ces deux réseaux l'un de l'autre. En outre, le réseau de cluster de vitesse de réseau est souhaitable d'au moins 10 Go.
Bien sûr, vous pouvez tout garder sur le même réseau. Mais cela se heurte au fait que dès que le volume de réplication entre les OSD augmente, par exemple, lorsque de nouveaux OSD (disques) tombent ou sont ajoutés, la charge du réseau augmentera TRÈS. La vitesse et la stabilité de votre infrastructure dépendront donc grandement du réseau utilisé par ceph.
Malheureusement, mon cluster de virtualisation n'a pas de réseau séparé et j'utiliserai un segment de réseau commun.
La configuration réseau du cluster se fait via le fichier de configuration, que nous avons généré avec la commande précédente.

 /my-cluster# cat ceph.conf [global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx 

Comme nous pouvons le voir, le déploiement cef n'a pas créé les paramètres réseau par défaut pour nous, donc j'ajouterai le paramètre public network = {public-network / netmask} à la section globale de la configuration. Mon réseau est 10.73.0.0/16, donc après avoir ajouté ma configuration ressemblera à ceci

 [global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 public network = 10.73.0.0/16 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx 

Si vous souhaitez séparer le réseau de clusters du public, ajoutez le paramètre cluster network = {cluster-network / netmask}
Vous pouvez en savoir plus sur les réseaux dans la documentation.

Installer les packages ceph

En utilisant ceph-deploy, nous installons tous les packages ceph dont nous avons besoin sur nos trois nœuds.
Pour ce faire, sur ceph01-test, exécutez
Si la version est mimétique,

 ceph-deploy install --release mimic ceph01-test ceph02-test ceph03-test 

Si la version est lumineuse alors

 ceph-deploy install --release luminous ceph01-test ceph02-test ceph03-test 

Et attendez que tout soit établi.

Installation et initialisation de moniteurs

Une fois tous les packages installés, nous allons créer et lancer les moniteurs de notre cluster.
C ceph01-test, procédez comme suit

 ceph-deploy mon create-initial 

Des moniteurs seront créés au cours du processus, des démons seront lancés et ceph-deploy vérifiera le quorum.
Maintenant, dispersez les configurations sur les nœuds du cluster.

 ceph-deploy admin ceph01-test ceph02-test ceph03-test 

Et vérifiez l'état de notre cluster, si vous avez tout fait correctement, alors l'état devrait être
HEALTH_OK

 ~/my-cluster# ceph status cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: no daemons active osd: 0 osds: 0 up, 0 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 0 B used, 0 B / 0 B avail pgs: 

Créer mgr

 ceph-deploy mgr create ceph01-test ceph02-test ceph03-test 

Et vérifiez à nouveau le statut

 ceph -s 

Une ligne devrait apparaître

 mgr: ceph01-test(active), standbys: ceph02-test, ceph03-test 

Nous écrivons la configuration à tous les hôtes du cluster

 ceph-deploy admin ceph01-test ceph02-test ceph03-test 

Ajout d'OSD

Nous avons actuellement un cluster fonctionnel, mais il n'a pas encore de disques (osd dans la terminologie ceph) pour stocker les informations.

L'OSD peut être ajouté avec la commande suivante (vue générale)

 ceph-deploy osd create --data {device} {ceph-node} 

Dans mon banc d'essai, disk / dev / sdb est alloué sous osd, donc dans mon cas, les commandes seront les suivantes

 ceph-deploy osd create --data /dev/sdb ceph01-test ceph-deploy osd create --data /dev/sdb ceph02-test ceph-deploy osd create --data /dev/sdb ceph03-test 

Vérifiez que tous les OSD fonctionnent.

 ceph -s 

Conclusion

  cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: ceph01-test(active) osd: 3 osds: 3 up, 3 in 

Vous pouvez également essayer quelques commandes utiles pour l'OSD.

 ceph osd df ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS 0 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 1 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 2 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 TOTAL 15 GiB 3.0 GiB 12 GiB 20.05 

et

 ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.01469 root default -3 0.00490 host ceph01-test 0 hdd 0.00490 osd.0 up 1.00000 1.00000 -5 0.00490 host ceph02-test 1 hdd 0.00490 osd.1 up 1.00000 1.00000 -7 0.00490 host ceph03-test 2 hdd 0.00490 osd.2 up 1.00000 1.00000 

Si tout va bien, alors nous avons un cluster ceph fonctionnel. Dans la partie suivante, je dirai comment utiliser ceph avec kubernetes

Connectez ceph à kubernetes

Malheureusement, je ne serai pas en mesure de décrire en détail le fonctionnement des volumes Kubernetes dans cet article, je vais donc essayer de tenir dans un paragraphe.
Kubernetes utilise des classes de stockage pour travailler avec des volumes de données, chaque classe de stockage a son propre provisionneur, vous pouvez le considérer comme une sorte de «pilote» pour travailler avec différents volumes de stockage de données. La liste complète qui prend en charge kubernetes se trouve dans la documentation officielle .
Kubernetes lui-même prend également en charge le travail avec rbd, mais l'image officielle de kube-controller-manager n'a pas de client rbd installé, vous devez donc utiliser une image différente.
Il convient également de noter que les volumes (pvc) créés en tant que rbd ne peuvent être que ReadWriteOnce (RWO) et, ce qui signifie que vous pouvez monter le volume créé UNIQUEMENT sur un seul foyer.

Pour que notre cluster puisse fonctionner avec des volumes ceph, nous avons besoin de:
dans un cluster Ceph:

• créer un pool de données dans le cluster ceph
• créer un client et une clé d'accès au pool de données
• obtenir ceph admin secret

Pour que notre cluster puisse fonctionner avec des volumes ceph, nous avons besoin de:
dans un cluster Ceph:

• créer un pool de données dans le cluster ceph
• créer un client et une clé d'accès au pool de données
• obtenir ceph admin secret

dans le cluster Kubernetes:

• créer le secret administrateur ceph et la clé client ceph
• installez ceph rbd provisioner ou remplacez l'image kube-controller-manager par une image qui prend en charge rbd
• créer un secret avec la clé client ceph
• créer une classe de stockage
• installer ceph-common sur les notes de travail de kubernetes

Création d'un pool de données

Dans le cluster ceph, créez un pool pour les volumes kubernetes

 ceph osd pool create kube 8 8 

Ici, je vais faire une petite explication, les chiffres 8 8 à la fin sont les nombres de pg et pgs. Ces valeurs dépendent de la taille de votre cluster ceph. Il existe des calculatrices spéciales qui calculent la quantité de pg et de pgs, par exemple, officielle de ceph
Pour commencer, je recommande de le laisser par défaut, si à l'avenir ce montant peut être augmenté (il ne peut être réduit qu'à partir de la version Nautilus).

Création d'un client pour un pool de données

Créer un client pour le nouveau pool

 ceph auth add client.kube mon 'allow r' osd 'allow rwx pool=kube' 

Nous recevrons une clé pour le client, à l'avenir nous en aurons besoin pour créer un kubernetes secret

 ceph auth get-key client.kube AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg== 

Obtenir la clé d'administration

Et obtenez la clé d'administration

 ceph auth get client.admin 2>&1 |grep "key = " |awk '{print $3'} AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA== 

Sur le cluster ceph, tout le travail est terminé et maintenant nous devons aller sur une machine qui a accès au cluster kubernetes
Je vais travailler avec le master01-test (10.73.71.25) du cluster déployé par moi dans la première publication.

Création d'un secret client

Créez un fichier avec le token client que nous avons reçu (n'oubliez pas de le remplacer par votre token)

 echo AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg== > /tmp/key.client 

Et créer un secret que nous utiliserons à l'avenir

 kubectl create secret generic ceph-secret --from-file=/tmp/key.client --namespace=kube-system --type=kubernetes.io/rbd 

Créer un secret administrateur

Créez un fichier avec un token administrateur (n'oubliez pas de le remplacer par votre token)

 echo AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA== > /tmp/key.admin 

Après cela, créez un secret administrateur

 kubectl create secret generic ceph-admin-secret --from-file=/tmp/key.admin --namespace=kube-system --type=kubernetes.io/rbd 

Vérifiez que des secrets ont été créés

 kubectl get secret -n kube-system | grep ceph ceph-admin-secret kubernetes.io/rbd 1 8m31s ceph-secret kubernetes.io/rbd 1 7m32s 

Méthode déployant d'abord ceph rbd provisioner

Nous clonons le référentiel kubernetes-incubator / external-storage de github, il a tout ce dont vous avez besoin pour faire des amis du cluster kubernetes avec le référentiel ceph.

 git clone https://github.com/kubernetes-incubator/external-storage.git cd external-storage/ceph/rbd/deploy/ NAMESPACE=kube-system sed -r -i "s/namespace: [^ ]+/namespace: $NAMESPACE/g" ./rbac/clusterrolebinding.yaml ./rbac/rolebinding.yaml 

 kubectl -n $NAMESPACE apply -f ./rbac 

Conclusion

 clusterrole.rbac.authorization.k8s.io/rbd-provisioner created clusterrolebinding.rbac.authorization.k8s.io/rbd-provisioner created deployment.extensions/rbd-provisioner created role.rbac.authorization.k8s.io/rbd-provisioner created rolebinding.rbac.authorization.k8s.io/rbd-provisioner created serviceaccount/rbd-provisioner created 

Méthode deux: remplacer l'image kube-controller-manager

Il n'y a pas de support rbd dans l'image officielle de kube-controller-manager, nous devrons donc changer l'image de controller-manager.
Pour ce faire, sur chacun des assistants Kubernetes, vous devez modifier le fichier kube-controller-manager.yaml et remplacer l'image par gcr.io/google_containers/hyperkube:v1.15.2. Faites attention à la version de l'image qui doit correspondre à votre version du cluster Kubernetes.

 vim /etc/kubernetes/manifests/kube-controller-manager.yaml 

Après cela, vous devrez redémarrer kube-controller-manager

 ubectl get pods -A | grep manager kube-system kube-controller-manager-master01-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master02-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master03-test 1/1 Running 9111 103d 

Les pods doivent être mis à jour automatiquement, mais si pour une raison quelconque cela ne s'est pas produit, vous pouvez les recréer manuellement, par suppression.

 kubectl delete pod -n kube-system kube-controller-manager-master01-test kubectl delete pod -n kube-system kube-controller-manager-master02-test kubectl delete pod -n kube-system kube-controller-manager-master03-test 

Vérifiez que tout va bien

 kubectl describe pod -n kube-system kube-controller-manager-master02-test | grep Image: Image: gcr.io/google_containers/hyperkube:v1.15.2 

-

Création d'une classe de stockage

Première méthode - si vous avez utilisé le provisionneur ceph.com/rbd
Créez un fichier yaml avec une description de notre classe de stockage. De plus, tous les fichiers utilisés ci-dessous peuvent être téléchargés dans mon référentiel dans le répertoire ceph

 cat <<EOF >./storage-class.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: ceph.com/rbd parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF 

Et l'inclure dans notre cluster

 kubectl apply -f storage-class.yaml 

Vérifiez que tout va bien

 kubectl get sc NAME PROVISIONER AGE ceph-rbd ceph.com/rbd 7s 

Deuxième méthode - si vous avez utilisé le provisionneur kubernetes.io/rbd
Créer une classe de stockage

 cat <<EOF >./storage-class-hyperkube.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: kubernetes.io/rbd allowVolumeExpansion: true parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF 

Et l'inclure dans notre cluster

 kubectl apply -f storage-class-hyperkube.yaml storageclass.storage.k8s.io/ceph-rbd created 

Vérifiez que tout va bien

 kubectl get sc NAME PROVISIONER AGE ceph-rbd kubernetes.io/rbd 107s 

Test du ligament de Kubernetes + ceph

Avant de tester ceph + kubernetes, vous devez installer le package ceph-common sur CHAQUE code de travail du cluster.

 apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-common 

Créer un fichier yaml PersistentVolumeClaim

 cat <<EOF >./claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: ceph-rbd resources: requests: storage: 1Gi EOF 

Tuez-le

 kubectl apply -f claim.yaml 

Vérifiez que PersistentVolumeClaim est créé.

 bectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim1 Bound pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO ceph-rbd 44m 

Et également créé automatiquement PersistentVolume.

 kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO Delete Bound default/claim1 ceph-rbd 37m 

Créons un pod de test dans lequel nous incluons le pvc créé dans le répertoire / mnt. Exécutez ce fichier /mnt/test.txt avec le texte "Hello World!"

 cat <<EOF >./create-file-pod.yaml kind: Pod apiVersion: v1 metadata: name: create-file-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "echo Hello world! > /mnt/test.txt && exit 0 || exit 1" volumeMounts: - name: pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF 

Nous allons le tuer et vérifier qu'il a terminé sa tâche

 kubectl apply -f create-file-pod.yaml kubectl get pods -w 

Attendons le statut

 create-file-pod 0/1 Completed 0 16s 

Créons-en un autre, connectons notre volume à celui-ci mais déjà dans / mnt / test, et après cela assurez-vous que le fichier créé par le premier volume est en place

 cat <<EOF >./test-pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "sleep 600" volumeMounts: - name: pvc mountPath: "/mnt/test" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF 

Exécutez kubectl get po -w et attendez que le pod soit en cours d'exécution
Après cela, allons-y et vérifions que le volume est connecté et notre fichier dans le répertoire / mnt / test

 kubectl exec test-pod -ti sh cat /mnt/test/test.txt Helo world! 

Merci d'avoir lu jusqu'au bout. Désolé pour le retard dans la publication.
Je suis prêt à répondre à toutes les questions dans des messages personnels ou dans les réseaux sociaux qui sont indiqués sur mon profil.
Dans la prochaine petite publication, je vous dirai comment déployer le stockage S3 en fonction du cluster ceph créé, puis selon le plan de la première publication.

Matériaux utilisés pour la publication

• Documentation officielle Ceph
• Présentation du référentiel Ceph en images
• Documentation officielle de Kubernetes
• incubateur kubernetes / à stockage externe
• référentiel kubernetes-ceph-percona avec des exemples de fichiers