For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/backing-up-volumes-stash.md.

Sauvegarder des volumes persistants avec Stash

Voir en Markdown

Sauvegarder des volumes persistants avec Stash

Dans ce tutoriel, nous utilisons Stash pour sauvegarder et restaurer des volumes persistants sur un cluster Managed Kubernetes OVHcloud.

Stash est un outil open source permettant de sauvegarder et restaurer en toute sécurité, d'effectuer une reprise aprÚs sinistre et de migrer des volumes persistants Kubernetes.

Nous utilisons le Swift Object Storage de notre Public Cloud avec l'API Swift S3 comme backend de stockage pour Stash. Stash utilise le protocole Amazon S3 pour stocker les sauvegardes du cluster sur un stockage objet compatible S31.

Avant de commencer

Ce tutoriel suppose que vous disposez déjà d'un cluster Managed Kubernetes OVHcloud fonctionnel, ainsi que de connaissances de base sur son fonctionnement. Pour en savoir plus sur ces sujets, consultez le guide de démarrage rapide du Managed Kubernetes Service OVHcloud.

Vous devez également avoir Helm installé sur votre poste de travail et sur votre cluster ; consultez le tutoriel Comment installer Helm sur un Managed Kubernetes Service OVHcloud.

Créer le bucket Object Storage pour Stash

Stash a besoin d'un bucket Object Storage comme backend de stockage pour stocker les données de votre cluster.
Dans cette section, vous allez créer votre bucket Object Storage sur Swift.

Préparer votre environnement de travail

Avant de créer votre bucket Object Storage, vous devez :

Vous devriez maintenant avoir accĂšs Ă  votre fichier RC OpenStack, avec un nom de fichier du type <user_name>-openrc.sh, ainsi qu'au nom d'utilisateur et au mot de passe de votre compte OpenStack.

DĂ©finir les variables d'environnement OpenStack

Définissez les variables d'environnement en sourçant le fichier RC OpenStack :

source <user_name>-openrc.sh

Le shell vous demandera votre mot de passe OpenStack :

$ source <user_name>-openrc.sh
Please enter your OpenStack Password for project <project_name> as user <user_name>:

Créer les identifiants EC2

Les tokens Object Storage sont différents ; vous avez besoin de 2 paramÚtres (access et secret) pour générer un token Object Storage.

Ces identifiants seront stockés en toute sécurité dans Keystone. Pour les générer avec le client python-openstack :

openstack ec2 credentials create

Notez les paramĂštres access et secret :

$ openstack ec2 credentials create
+------------+----------------------------------------------------------------------------------------------------------------------------+
| Field      | Value
+------------+----------------------------------------------------------------------------------------------------------------------------+
| access     | 5a4d8b8d88104123a862c527ede5a3d3
| links      | {u'self': u'https://auth.cloud.ovh.net/v3/users/d74d05ff121b44bea9216495e7f0df61/credentials/OS-EC2/5a4d8b8d88104123a862c527ede5a3d3'}
| project_id | 20e124b71be141299e111ec26b1892fa
| secret     | 925d5fcfcd9f436d8ffcb20548cc53a2
| trust_id   | None
| user_id    | d74d05ff121b44bea9216495e7f0df61
+------------+----------------------------------------------------------------------------------------------------------------------------+

Configurer le client awscli

Installez le client awscli :

pip install awscli

Complétez et enregistrez la configuration pour awscli dans ~/aws/config :

[profile default]
aws_access_key_id = <access fetched in previous step>
aws_secret_access_key = <secret fetched in previous step>
region = <public cloud region in lower case>
endpoint_url = https://s3.<public cloud region without digit>.cloud.ovh.net
s3 =
  signature_version = s3v4
  addressing_style = virtual

Créer un bucket Object Storage pour Stash

Créez un nouveau bucket :

aws --profile default s3 mb s3://s3-stash

Créer un Secret Kubernetes pour stocker les identifiants Object Storage

Pour donner Ă  Stash accĂšs au bucket Object Storage, vous devez placer les identifiants (access_key et secret_access_key) dans un Secret Kubernetes.

kubectl create namespace nginx-example
echo -n '<access-key>' > AWS_ACCESS_KEY_ID
echo -n '<secret_access_key>' > AWS_SECRET_ACCESS_KEY
echo -n '<a_password>' > RESTIC_PASSWORD
kubectl create secret generic -n nginx-example s3-secret \
     --from-file=./RESTIC_PASSWORD \
    --from-file=./AWS_ACCESS_KEY_ID \
    --from-file=./AWS_SECRET_ACCESS_KEY

Dans notre exemple :

$ kubectl create namespace nginx-example
namespace/nginx-example created

$ echo -n 'xxxxxxxxxxxxxxxxxxx' > AWS_ACCESS_KEY_ID

$ echo -n 'yyyyyyyyyyyyyyyyyyy' > AWS_SECRET_ACCESS_KEY

$ echo -n 'zzzzzzzzzzzzzzzzzzz' > RESTIC_PASSWORD

$ kubectl create secret generic -n nginx-example s3-secret \
>     --from-file=./RESTIC_PASSWORD \
>     --from-file=./AWS_ACCESS_KEY_ID \
>     --from-file=./AWS_SECRET_ACCESS_KEY
secret/s3-secret created

Installer Stash

La maniÚre la plus simple d'installer Stash est via Helm, en utilisant le chart du dépÎt AppsCode Charts.

Tout d'abord, vous devez obtenir une licence.

Remarque : si vous souhaitez utiliser une Ă©dition entreprise, suivez plutĂŽt ce lien.

Vous devriez recevoir votre licence par e-mail. Enregistrez-la, vous en aurez besoin dans la commande helm install.

Commencez par ajouter le dépÎt :

helm repo add appscode https://charts.appscode.com/stable/
helm repo update

Recherchez ensuite la derniĂšre version de stash :

helm search repo appscode/stash --version v2021.11.24

Et installez-la avec le nom de release stash-operator :

helm install stash appscode/stash          \
  --version v2021.11.24                \
  --namespace kube-system                     \
  --set features.community=true               \
  --set-file global.license=<PATH_TO_YOUR_STASH_LICENSE>

Dans notre exemple :

$ helm repo add appscode https://charts.appscode.com/stable/

"appscode" has been added to your repositories

$ helm repo update

Hang tight while we grab the latest from your chart repositories...
[...]
...Successfully got an update from the "appscode" chart repository
[...]
Update Complete. ⎈Happy Helming!⎈

$ helm search repo appscode/stash --version v2021.11.24

NAME                  	CHART VERSION	APP VERSION	DESCRIPTION
appscode/stash        	v2021.11.24  	v2021.11.24	Stash by AppsCode - Backup your Kubernetes nati...
appscode/stash-catalog	v2021.11.24  	v2021.11.24	Stash Catalog by AppsCode - Catalog of Stash Ad...
appscode/stash-crds   	v2021.11.24  	v2021.11.24	Stash Custom Resource Definitions
appscode/stash-metrics	v2021.11.24  	v2021.11.24	Stash State Metrics

$ helm install stash appscode/stash          \
  --version v2021.11.24                \
  --namespace kube-system                     \
  --set features.community=true               \
  --set-file global.license=stash-community-license-c187ab99-64a1-4f65-9871-7e5168f48e8f.txt
W1221 14:36:32.478119   35817 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1221 14:36:35.308665   35817 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1221 14:36:35.484798   35817 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1221 14:36:35.526044   35817 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1221 14:36:35.838301   35817 warnings.go:70] spec.template.spec.nodeSelector[beta.kubernetes.io/arch]: deprecated since v1.14; use "kubernetes.io/arch" instead
W1221 14:36:35.838468   35817 warnings.go:70] spec.template.spec.nodeSelector[beta.kubernetes.io/os]: deprecated since v1.14; use "kubernetes.io/os" instead
NAME: stash
LAST DEPLOYED: Tue Dec 21 14:36:31 2021
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Get the Stash operator pods by running the following command:

  kubectl --namespace kube-system get pods

VĂ©rifier l'installation

Comme suggéré pendant l'installation du chart, pour vérifier que les pods de l'opérateur Stash ont bien démarré, nous pouvons exécuter la commande suggérée et l'adapter afin de ne voir que notre pod stash :

kubectl get pods -A -l app.kubernetes.io/name=stash-community

Si tout est en ordre, vous devriez obtenir un pod stash-stash-community avec le statut Running.

kubectl get pods -A -l app.kubernetes.io/name=stash-community
NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE
kube-system   stash-stash-community-84b7f84b7f-ctzv7   2/2     Running   0          35s

Maintenant, pour confirmer que les groupes CRD ont bien été enregistrés par l'opérateur, exécutez la commande suivante :

kubectl get crd | grep stash

Vous devriez voir une liste des groupes CRD :

$ kubectl get crd | grep stash

backupblueprints.stash.appscode.com                   2021-12-21T13:36:47Z
backupconfigurations.stash.appscode.com               2021-12-21T13:36:46Z
backupsessions.stash.appscode.com                     2021-12-21T13:36:46Z
functions.stash.appscode.com                          2021-12-21T13:24:18Z
recoveries.stash.appscode.com                         2021-12-21T13:36:46Z
repositories.stash.appscode.com                       2021-12-21T13:36:46Z
restics.stash.appscode.com                            2021-12-21T13:36:46Z
restorebatches.stash.appscode.com                     2021-12-21T13:36:48Z
restoresessions.stash.appscode.com                    2021-12-21T13:36:47Z
tasks.stash.appscode.com                              2021-12-21T13:24:18Z

Installer le plugin kubectl de Stash

Stash fournit une CLI sous forme de plugin kubectl pour travailler rapidement avec les Objects stash. Téléchargez les binaires précompilés depuis la release Github stashed/cli et placez le binaire dans un répertoire de votre PATH.

Snapshot de volume avec Stash

Une explication détaillée du Snapshot de volume avec Stash est disponible dans la documentation officielle.

Dans Kubernetes, un VolumeSnapshot représente un instantané d'un volume sur un systÚme de stockage. Il a été introduit en tant que fonctionnalité Alpha dans Kubernetes v1.12 et est passé au statut Beta dans Kubernetes 1.17.

Pour prendre en charge VolumeSnapshot, vos PersistenVolumes doivent utiliser une StorageClass avec un driver CSI prenant en charge cette fonctionnalité. Le cluster Managed Kubernetes OVHcloud propose actuellement deux de ces StorageClasses : csi-cinder-classic et csi-cinder-high-speed.

Vous avez Ă©galement besoin d'une VolumeSnapshotClass compatible, dans notre cas csi-cinder-snapclass.

Un exemple : serveur Nginx avec logs persistants

Dans ce guide, nous allons utiliser un exemple simple : un petit serveur web Nginx avec un PersistentVolume pour stocker les logs d'accĂšs.

Copiez la description suivante dans un fichier nginx-example.yml :

---
apiVersion: v1
kind: Namespace
metadata:
  name: nginx-example
  labels:
    app: nginx

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nginx-logs
  namespace: nginx-example
  labels:
    app: nginx
spec:
  storageClassName: csi-cinder-high-speed
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: nginx-example
spec:
  strategy:
    type: Recreate
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
        - name: nginx-logs
          persistentVolumeClaim:
            claimName: nginx-logs
      containers:
        - image: nginx:1.27.3
          name: nginx
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: "/var/log/nginx"
              name: nginx-logs
              readOnly: false
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-service
  namespace: nginx-example
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Et appliquez-le Ă  votre cluster :

kubectl apply -f nginx-example.yml
Info

Si vous regardez attentivement la partie deployment de ce manifeste, vous verrez que nous avons défini un .spec.strategy.type. Il spécifie la stratégie utilisée pour remplacer les anciens Pods par de nouveaux, et nous l'avons défini sur Recreate, afin que tous les Pods existants soient supprimés avant que de nouveaux ne soient créés.

Nous procédons ainsi car la Storage Class que nous utilisons, csi-cinder-high-speed, ne prend en charge que le mode ReadWriteOnce : nous ne pouvons donc avoir qu'un seul pod écrivant sur le volume persistant à un instant donné.

Nous pouvons vérifier que le Pod est bien en cours d'exécution :

kubectl get pod -n nginx-example

Attendez d'obtenir une IP externe :

kubectl -n nginx-example get svc nginx-service -w

Et effectuez quelques appels vers l'URL pour générer des logs d'accÚs :

curl -I <EXTERNAL_IP>

Dans notre exemple :

$ kubectl apply -f nginx-example.yml

namespace/nginx-example created
persistentvolumeclaim/nginx-logs created
deployment.apps/nginx-deployment created
service/nginx-service created

$ kubectl get pod -n nginx-example
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-766444c4d9-cxd2p   1/1     Running   0          32s

$ kubectl -n nginx-example get svc nginx-service -w

NAME            TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
nginx-service   LoadBalancer   10.3.39.164   <pending>     80:31734/TCP   49s
nginx-service   LoadBalancer   10.3.39.164   51.210.210.247   80:31734/TCP   3m

$ curl -I 51.210.210.247
HTTP/1.1 200 OK
Server: nginx/1.7.9
Date: Tue, 21 Dec 2021 14:16:20 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Dec 2014 16:25:09 GMT
Connection: keep-alive
ETag: "54999765-264"
Accept-Ranges: bytes

$ curl -I 51.210.210.247
HTTP/1.1 200 OK
Server: nginx/1.7.9
Date: Tue, 21 Dec 2021 14:16:31 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Dec 2014 16:25:09 GMT
Connection: keep-alive
ETag: "54999765-264"
Accept-Ranges: bytes

VĂ©rifier les logs

Nous devons maintenant nous connecter au pod pour lire le fichier de log et vérifier que nos logs sont bien écrits.

Récupérez d'abord le nom du pod Nginx en cours d'exécution :

kubectl -n nginx-example get pods

Puis connectez-vous Ă  celui-ci et consultez vos logs d'accĂšs :

 kubectl -n nginx-example exec <POD_NAME> -c nginx -- cat /var/log/nginx/access.log

Dans notre exemple :

$ kubectl -n nginx-example get pods

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-766444c4d9-cxd2p   1/1     Running   0          28m

$ kubectl -n nginx-example exec nginx-deployment-766444c4d9-cxd2p -c nginx -- cat /var/log/nginx/access.log
10.2.2.0 - - [21/Dec/2021:14:16:20 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.64.1" "-"
10.2.0.0 - - [21/Dec/2021:14:16:31 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.64.1" "-"

Créer un Repository

Un Repository est une CustomResourceDefinition (CRD) Kubernetes qui reprĂ©sente les informations de backend de maniĂšre native pour Kubernetes. Vous devez crĂ©er un objet Repository pour chaque cible de sauvegarde. Une cible de sauvegarde peut ĂȘtre un workload, une base de donnĂ©es ou un PV/PVC.

Pour crĂ©er une CRD Repository, vous devez fournir le secret de stockage que nous avons crĂ©Ă© prĂ©cĂ©demment dans le champ spec.backend.storageSecretName. Vous devrez Ă©galement dĂ©finir spec.backend.s3.prefix, pour choisir le dossier dans le backend oĂč seront stockĂ©s les snapshots sauvegardĂ©s.

Créez un fichier repository.yaml, en remplaçant <public cloud region> par la région, sans les chiffres et en minuscules (par exemple gra) :

apiVersion: stash.appscode.com/v1alpha1
kind: Repository
metadata:
  name: s3-repo
  namespace: nginx-example
spec:
  backend:
    s3:
      endpoint: s3.<public cloud region>.cloud.ovh.net
      bucket: s3-stash
      region: <public cloud region>
      prefix: /backup/nginx-demo
    storageSecretName: s3-secret

Et appliquez-le Ă  votre cluster Kubernetes :

kubectl apply -f repository.yaml

Dans notre exemple :

$ kubectl apply -f repository.yaml
repository.stash.appscode.com/s3-repo created

Créer une BackupConfiguration

Une BackupConfiguration est une CustomResourceDefinition (CRD) Kubernetes qui spécifie la cible de sauvegarde, les paramÚtres (planification, politique de rétention, etc.) et un objet Repository qui contient les informations de stockage des snapshots de maniÚre native pour Kubernetes.

Vous devez crĂ©er un objet BackupConfiguration pour chaque cible de sauvegarde. Une cible de sauvegarde peut ĂȘtre un workload, une base de donnĂ©es ou un PV/PVC.

Pour sauvegarder notre PV, nous devrons créer un fichier backup-configuration.yaml, dans lequel nous décrivons les volumes persistants que nous souhaitons sauvegarder, le repository que nous prévoyons d'utiliser et la planification de sauvegarde (au format crontab) :

apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
  name: nginx-backup
  namespace: nginx-example
spec:
  repository:
    name: s3-repo
  schedule: "*/5 * * * *"
  target:
    ref:
      apiVersion: apps/v1
      kind: Deployment
      name: nginx-deployment
    volumeMounts:
      - name: nginx-logs
        mountPath: /var/log/nginx
    paths:
      - /var/log/nginx
  retentionPolicy:
    name: "keep-last-5"
    keepLast: 5
    prune: true

Et appliquez-le Ă  votre cluster Kubernetes :

kubectl apply -f backup-configuration.yaml

Dans notre exemple :

$ kubectl apply -f backup-configuration.yaml
backupconfiguration.stash.appscode.com/nginx-backup created

VĂ©rifier le CronJob

Si tout se passe bien, Stash va créer un CronJob pour prendre des snapshots périodiques du volume nginx-logs du déploiement, selon la planification spécifiée dans le champ spec.schedule de la CRD BackupConfiguration (une sauvegarde toutes les 5 minutes).

Vérifiez que le CronJob a bien été créé :

kubectl -n nginx-example get cronjob

Dans notre exemple

$ kubectl -n nginx-example get cronjob
NAME                        SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
stash-backup-nginx-backup   */5 * * * *   False     0        33s             3m36s

Attendre la BackupSession

Le CronJob stash-backup-nginx-backup déclenchera une sauvegarde à chaque planification en créant une CRD BackupSession.

Attendez la prochaine planification de sauvegarde. Exécutez la commande suivante pour surveiller la CRD BackupSession :

kubectl -n nginx-example get backupsession

Dans notre exemple

$ kubectl -n nginx-example get backupsessions
NAME                      INVOKER-TYPE          INVOKER-NAME   PHASE       AGE
nginx-backup-1586938564   BackupConfiguration   nginx-backup   Succeeded   77s

Nous pouvons voir ci-dessus que la session de sauvegarde a réussi. Nous allons maintenant vérifier que le VolumeSnapshot a bien été créé et que les snapshots ont bien été stockés dans le backend correspondant.

VĂ©rifier les Volume Snapshots dans l'espace client OVHcloud

Les snapshots sont visibles depuis l'. Pour les consulter, accĂ©dez Ă  la section Object Storage, oĂč vous trouverez le bucket Object Storage que vous avez crĂ©Ă©. En cliquant sur le bucket, vous verrez la liste des objets, incluant tous les snapshots commençant par /backup/demo/deployment/stash-demo, tel que dĂ©fini dans le Repository.

Restaurer un PVC depuis un VolumeSnapshot

Cette section vous montre comment restaurer les PVC à partir des snapshots pris dans la section précédente.

ArrĂȘter les snapshots

Avant de procĂ©der Ă  la restauration, nous devons mettre en pause la BackupConfiguration afin d'Ă©viter tout snapshot pendant le processus de restauration. GrĂące Ă  la BackupConfiguration, Stash arrĂȘtera de prendre toute sauvegarde supplĂ©mentaire pour nginx-deployment.

kubectl -n nginx-example patch backupconfiguration  nginx-backup --type="merge" --patch='{"spec": {"paused": true}}'

AprÚs quelques instants, vous pouvez consulter le statut de nginx-backup pour vérifier qu'elle est bien en pause :

kubectl -n nginx-example get backupconfiguration nginx-backup

Dans notre exemple

$ kubectl -n nginx-example patch backupconfiguration  nginx-backup --type=
"merge" --patch='{"spec": {"paused": true}}'
backupconfiguration.stash.appscode.com/nginx-backup patched

$ kubectl -n nginx-example get backupconfiguration nginx-backup
NAME           TASK   SCHEDULE      PAUSED   AGE
nginx-backup          */1 * * * *   true     7m18s

Simuler un sinistre

Simulons un scénario de sinistre, en supprimant tous les fichiers du PVC :

kubectl -n nginx-example exec <POD_NAME> -c nginx -- rm /var/log/nginx/access.log

Et vérifiez que le fichier est bien supprimé :

kubectl -n nginx-example exec <POD_NAME> -c nginx -- ls -al /var/log/nginx/

Dans notre exemple :

$ kubectl -n nginx-example -c nginx exec nginx-deployment-766444c4d9-cxd2p  -- rm /var/log/nginx/access.log

$ kubectl -n nginx-example exec nginx-deployment-766444c4d9-cxd2p -c nginx -- ls -al /var/log/nginx/
total 32
drwxr-xr-x 3 root root  4096 Dec 21 13:42 .
drwxr-xr-x 1 root root  4096 Jan 27  2015 ..
-rw-r--r-- 1 root root  1369 Dec 21 14:15 error.log
drwx------ 2 root root 16384 Dec 21 13:42 lost+found

Créer une RestoreSession

Vous devez maintenant créer une CRD RestoreSession pour restaurer les PVC à partir du dernier snapshot.

Une RestoreSession est une CustomResourceDefinition (CRD) Kubernetes qui spécifie une cible à restaurer et la source des données qui seront restaurées, de maniÚre native pour Kubernetes.

Créez un fichier restore-session.yaml :

apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
  name: nginx-restore
  namespace: nginx-example
spec:
  repository:
    name: s3-repo
  target: # target indicates where the recovered data will be stored
    ref:
      apiVersion: apps/v1
      kind: Deployment
      name: nginx-deployment
    volumeMounts:
      - name: nginx-logs
        mountPath: /var/log/nginx

Et appliquez-le Ă  votre cluster :

kubectl apply -f restore-session.yaml

Et attendez que la RestoreSession réussisse :

kubectl -n nginx-example get restoresession  nginx-restore

Dans notre exemple :

$ kubectl apply -f ./examples/stash/restore-session.yaml
restoresession.stash.appscode.com/nginx-restore created

$ kubectl get restoresession -n nginx-example nginx-restore -w
NAME            REPOSITORY   PHASE       AGE
nginx-restore   s3-repo      Succeeded   50s

Vérifier que les données sont restaurées

Commencez par récupérer le nom du pod :

 kubectl -n nginx-example get pods

Puis vérifiez que le fichier access.log a bien été restauré :

kubectl -n nginx-example exec <POD_NAME> -c nginx -- ls -al /var/log/nginx/
kubectl -n nginx-example exec <POD_NAME> -c nginx -- cat /var/log/nginx/access.log

Dans notre exemple :

$ kubectl -n nginx-example get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-766444c4d9-cxd2p   2/2     Running   0          31s

$ kubectl -n nginx-example exec nginx-deployment-766444c4d9-cxd2p -c nginx -- cat /var/log/nginx/access.log

10.2.2.0 - - [21/Dec/2021:14:16:20 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.64.1" "-"
10.2.0.0 - - [21/Dec/2021:14:16:31 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.64.1" "-"

$ kubectl -n nginx-example exec nginx-deployment-766444c4d9-cxd2p -c nginx -- ls -al /var/log/nginx/

total 32
drwxr-xr-x 3 root root  4096 Dec 21 13:42 .
drwxr-xr-x 1 root root  4096 Jan 27  2015 ..
-rw-r--r-- 1 root root  1686 Dec 21 15:03 access.log
-rw-r--r-- 1 root root  1369 Dec 21 14:55 error.log
drwx------ 2 root root 16384 Dec 21 14:55 lost+found

Suppression (nettoyage)

Pour nettoyer votre cluster, commencez par supprimer le namespace nginx-example :

kubectl delete namespace nginx-example

Puis utilisez simplement Helm pour supprimer votre release Stash.

helm uninstall stash -n kube-system

Dans notre exemple :

$ kubectl delete namespace nginx-example
namespace "nginx-example" deleted

$ helm uninstall stash -n kube-system
release "stash" uninstalled

Aller plus loin

  • Pour une formation ou une assistance technique sur la mise en Ɠuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communautĂ© d'utilisateurs.

1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque maniÚre que ce soit.

Cette page vous a-t-elle aidé ?