Dans un Sta­te­ful­Set Ku­ber­netes, chaque pod possède un nom d’hôte unique et stable ainsi qu’une identité DNS complète. Cette ID est conservée au fil des re­dé­mar­rages et des mises à l’échelle.

Qu’est-ce qu’un Sta­te­ful­Set Ku­ber­netes ?

Les Sta­te­ful­Sets Ku­ber­netes sont des entités spéciales per­met­tant de gérer des ap­pli­ca­tions qui ont des exigences par­ti­cu­lières en matière de données per­sis­tantes et d’identités fixes. Ces ensembles ga­ran­tis­sent que les pods avec des réplicas sont démarrés dans un ordre précis. Ils at­tri­buent à chaque pod Ku­ber­netes un iden­ti­fiant unique ainsi qu’un accès au stockage per­sis­tant. De telles fonctions sont utiles pour les bases de données qui dépendent de relations stables entre les instances et qui doivent stocker des données durables. Un Sta­te­ful­Set re­pré­sente donc une solution efficace pour l’or­ches­tra­tion et l’ex­ploi­ta­tion d’ap­pli­ca­tions complexes dans Ku­ber­netes.

Conseil

Managed Ku­ber­netes dans le Cloud IONOS offre une pla­te­forme puissante pour les ap­pli­ca­tions basées sur des con­te­neurs. La dis­tri­bu­tion géo-re­don­dante assure une sécurité maximale contre les pannes et des res­sources hautement dis­po­nibles. Avec des fonctions de contrôle intégrées et des mises à jour au­to­ma­ti­sées, Managed Ku­ber­netes permet une con­fi­gu­ra­tion sans effort et sécurisée dans votre en­vi­ron­ne­ment de pro­duc­tion.

Créer un Sta­te­ful­Set Ku­ber­netes

Tout d’abord, nous com­men­çons par définir un fichier de con­fi­gu­ra­tion YAML, dans lequel nous dé­fi­nis­sons les pro­prié­tés sou­hai­tées du Sta­te­ful­Set et créons des pods Ku­ber­netes. Après la con­fi­gu­ra­tion, le Sta­te­ful­Set surveille en per­ma­nence l’état du cluster, ainsi que si le nombre prédéfini de pods est toujours en état de marche et dis­po­nible. En cas de panne d’un pod ou d’éloig­ne­ment du nœud, le Sta­te­ful­Set détecte au­to­ma­ti­que­ment les dé­fail­lances et prend les mesures né­ces­saires : il initie alors le dé­ploie­ment d’un nouveau pod avec le même iden­ti­fiant unique. Ce nouveau pod est connecté au stockage per­sis­tant déjà existant et reçoit la con­fi­gu­ra­tion identique à celle du pod initial. Cela inclut les demandes et les limites de res­sources.

Cette gestion précise des pods et de leur identité est es­sen­tielle pour que les clients qui étaient au­pa­ra­vant servis par le pod in­dis­po­nible puissent être redirigés vers le nouveau pod sans in­ter­rup­tion. L’accès au stockage per­sis­tant garantit que les opé­ra­tions con­ti­nuent de fonc­tion­ner sans problème.

Voici un fichier YAML complet qui illustre les étapes de la création d’un Sta­te­ful­Set Ku­ber­netes pour Nginx :

apiVersion: apps/v1
kind: StatefulSet
metadata:
    name: nginx-statefulset
spec:
    serviceName: nginx
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
            - name: nginx
                image: nginx:latest
                volumeMounts:
                - name: nginx-config
                    mountPath: /etc/nginx/conf.d
                - name: nginx-html
                    mountPath: /usr/share/nginx/html
    volumeClaimTemplates:
    - metadata:
            name: nginx-html
        spec:
            accessModes: [ "ReadWriteOnce" ]
            resources:
                requests:
                    storage: 1Gi
    - metadata:
            name: nginx-config
        spec:
            accessModes: [ "ReadWriteOnce" ]
            resources:
                requests:
                    storage: 1Gi
yaml

Ce document YAML définit un Sta­te­ful­Set Ku­ber­netes pour Nginx avec trois réplicas. Il utilise un objet de service appelé « nginx » et des éti­quettes pour iden­ti­fier cor­rec­te­ment les pods. Ces derniers utilisent la dernière image de Nginx et ont deux volumes pour la con­fi­gu­ra­tion et les fichiers HTML. Les VolumeClaimTemplates assurent un stockage per­sis­tant pour ces volumes d’une taille de 1 Go et per­met­tent l’accès Read­Wri­teOnce.

Débogage d’un Sta­te­ful­Set

Le débogage des Sta­te­ful­Sets dans Ku­ber­netes nécessite des étapes spé­ci­fiques pour vérifier que les pods sont cor­rec­te­ment ini­tia­li­sés et vous permettre d’iden­ti­fier et de corriger les erreurs si né­ces­saire.

Étape 1 : lister les pods

Avant de commencer le débogage d’un Sta­te­ful­Set, vous devez contrôler l’état des pods.

Ouvrez la ligne de commande et utilisez la commande suivante pour lister tous les pods dans le Sta­te­ful­Set souhaité :

kubectl get pods -l app=statefulset-label
shell

La sortie sera alors :

NAME                         READY      STATUS    RESTARTS   AGE 
nginx-statefulset-0           1/1      Running       0       2m 
nginx-statefulset-1           1/1      Running       0       1m 
nginx-statefulset-2           1/1      Running       0       1m
shell
  • NAME : chaque pod reçoit un nom unique, basé sur le schéma de nommage du Sta­te­ful­Set et un numéro sé­quen­tiel.
  • READY : indique combien de con­te­neurs souhaités sont prêts dans le pod. Dans l’exemple, chaque pod a un conteneur, et 1/1 signifie que le conteneur est prêt à être utilisé.
  • STATUS : indique l’état actuel du pod.
  • RESTARTS : indique combien de fois le conteneur a été redémarré dans le pod. Une valeur de 0 signifie qu’il n’y a pas eu de re­dé­mar­rage jusqu’à présent.
  • AGE : indique depuis combien de temps le pod fonc­tionne.

Messages d’état indiquant des erreurs :

  • Failed (échec) : un ou plusieurs con­te­neurs dans le pod ont provoqué une erreur qui a entraîné l’échec du pod. Cela peut être dû à dif­fé­rentes raisons, comme des dé­pen­dances man­quantes ou des problèmes de con­fi­gu­ra­tion.
  • Unknown (inconnu) : l’état du pod n’a pas pu être déterminé. Cela peut indiquer un problème de com­mu­ni­ca­tion entre le cluster Ku­ber­netes et le pod ; des problèmes de réseau, un manque de per­mis­sions ou d’autres facteurs peuvent en être la cause.

Dans les deux cas, il est important d’utiliser des outils de diag­nos­tic précis comme l’examen des logs du pod ou la commande kubectl describe pod pour obtenir plus de détails et dé­ter­mi­ner les causes des erreurs.

Étape 2 : déboguer les pods in­di­vi­duels

Ajouter des an­no­ta­tions à un pod peut être un outil de débogage utile pour in­fluen­cer le processus d’ini­tia­li­sa­tion ou dé­clen­cher des actions spéciales.

Tout d’abord, vous devez iden­ti­fier le nom du pod que vous souhaitez déboguer.

kubectl get pods
shell

Notez le nom du pod que vous voulez déboguer.

Tapez main­te­nant la commande suivante dans le terminal pour définir l’an­no­ta­tion du pod sé­lec­tionné :

kubectl annotate pods [pod-name] pod.alpha.kubernetes.io/initialized="false" --overwrite
shell

Remplacez [pod-name] par le nom réel du pod. Cette an­no­ta­tion met l’état d’ini­tia­li­sa­tion à false, ce qui signifie que le pod est marqué comme non ini­tia­lisé.

Sur­veil­lez le pod pour voir comment l’an­no­ta­tion affecte son com­por­te­ment. En par­ti­cu­lier, vous pouvez vérifier les évé­ne­ments du pod et les logs :

kubectl describe pod [pod-name]
kubectl logs [pod-name]
shell

Regardez s’il y a des évé­ne­ments ou des sorties de logs qui pour­raient dé­clen­cher des problèmes pendant le processus d’ini­tia­li­sa­tion. Lorsque le débogage est terminé et que vous souhaitez rétablir le processus d’ini­tia­li­sa­tion normal, remettez l’an­no­ta­tion à true.

Étape 3 : ini­tia­li­sa­tion

Si le débogage du pod avec les tech­niques décrites pré­cé­dem­ment a échoué, cela peut indiquer des con­di­tions de course pendant le processus d’ini­tia­li­sa­tion (bootstrap) du Sta­te­ful­Set. Pour surmonter ce problème, vous pouvez spécifier initialized="false" dans le manifeste du Sta­te­ful­Set Ku­ber­netes et le créer ensuite dans le cluster avec cette an­no­ta­tion.

apiVersion: apps/v1
kind: StatefulSet
metadata:
    name: [statefulset-name]
spec:
    template:
        metadata:
            annotations:
                pod.alpha.kubernetes.io/initialized: "false"
        ...
yaml

Appliquer le manifeste mis à jour sur votre cluster Ku­ber­netes :

kubectl apply -f statefulset.yaml
shell

Inspectez les pods et iden­ti­fiez les éven­tuelles sources d’erreur. Effectuez le débogage né­ces­saire en vous basant sur les évé­ne­ments et les logs observés. Supprimez éven­tuel­le­ment les pods avec kubectl delete statefulsets ou kubectl delete service.

Une fois le débogage terminé, vous pouvez supprimer l’an­no­ta­tion « ini­tia­li­zed » et mettre à jour le Ku­ber­netes Sta­te­ful­Set dans le cluster :

kubectl annotate pods [pod-name] pod.alpha.kubernetes.io/initialized="true" --overwrite
shell

Cette commande définit l’an­no­ta­tion « ini­tia­li­zed » d’un pod à true, tout en s’assurant que les valeurs exis­tantes sont écrasées. Après avoir vérifié le premier pod, le Sta­te­ful­Set Ku­ber­netes ini­tia­li­sera au­to­ma­ti­que­ment le pod suivant. Vous pouvez alors répéter les étapes de débogage pour chaque autre pod du Sta­te­ful­Set.

Dans notre tutoriel Ku­ber­netes, vous trouverez des in­for­ma­tions dé­tail­lées et pratiques sur la mise en place d’un cluster Ku­ber­netes.

Managed Ku­ber­netes de IONOS Cloud
Or­ches­trez vos charges de travail en toute sécurité

Managed Ku­ber­netes est la pla­te­forme idéale pour des ap­pli­ca­tions de con­te­neurs per­for­mantes et hautement évo­lu­tives.

Aller au menu principal