Planification de la capacité des Secrets Kubernetes : guide opérationnel pratique

Introduction

Les Secrets Kubernetes permettent de stocker et de gérer des informations sensibles telles que les mots de passe, les jetons et les clés. Cependant, les Secrets ne sont pas infinis. Chaque Secret a une limite de taille, et stocker trop de Secrets volumineux peut surcharger etcd, le serveur d'API et la mémoire des nœuds. La planification de la capacité des Secrets consiste à déterminer le nombre de Secrets nécessaires, leur taille maximale et comment éviter d'atteindre les limites du cluster.

De nombreuses équipes traitent les Secrets comme un stockage libre et ne découvrent les problèmes que lorsque le serveur d'API rejette une demande de création ou que la latence d'etcd augmente. Ce guide suit une approche structurée : inventorier votre environnement, comprendre les limites réelles, concevoir une configuration sûre, vérifier avec des commandes pratiques, planifier les échecs et maintenir une liste de contrôle opérationnelle. Chaque étape comprend des exemples concrets et des commandes que vous pouvez exécuter pour valider votre propre cluster.

À la fin, vous serez en mesure de dimensionner vos Secrets, de définir des limites appropriées, d'éviter les pièges courants et de récupérer en toute confiance des incidents liés à la capacité.

Inventaire de la version et de l'environnement

La planification de la capacité commence par savoir exactement ce que vous exécutez. Les différentes versions de Kubernetes ont des limites et des comportements par défaut différents pour les Secrets. Cette section montre comment recueillir les informations nécessaires sans apporter de modifications.

Vérifier la version de Kubernetes et la distribution

Exécutez les commandes suivantes pour identifier la version de votre cluster et les détails du serveur d'API :

kubectl version --short
kubectl cluster-info

Exemple de sortie sur un cluster géré :

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.6-gke.500

Connaître la version exacte est important car la taille maximale des Secrets a évolué au fil du temps. Depuis Kubernetes 1.21, la limite est de 1 Mio par Secret. Les clusters plus anciens peuvent autoriser jusqu'à 2 Mio pour les Secrets créés avant l'application de la limite, mais les nouveaux Secrets sont plafonnés à 1 Mio. Vérifiez toujours la version de votre cluster et les éventuelles politiques d'admission personnalisées qui pourraient imposer des limites plus strictes.

Identifier les modèles d'utilisation des Secrets

Ensuite, obtenez un instantané des Secrets actuels dans chaque espace de noms. Utilisez ces commandes en lecture seule :

kubectl get secrets --all-namespaces
kubectl get secrets -n your-namespace -o wide

Pour trouver les Secrets les plus volumineux, vous pouvez inspecter leurs tailles. Cette commande liste les Secrets d'un espace de noms triés par leur taille de données :

kubectl get secrets -n your-namespace -o json | jq -r '.items[] | [.metadata.name, (.data | to_entries | map(.value | @base64d | length) | add)] | @tsv' | sort -k2 -n -r

Cela nécessite jq et suppose que les Secrets stockent les données sous forme de valeurs encodées en base64. La sortie affiche le nom du Secret et la taille totale en clair en octets. Par exemple :

my-large-secret   1048576
api-token         256

Si un Secret approche 1 Mio, il est candidat pour être divisé ou externalisé.

Évaluer la santé d'etcd et du serveur d'API

Les Secrets sont stockés dans etcd, il est donc crucial de surveiller etcd. Vérifiez les métriques etcd si vous y avez accès (souvent via Prometheus ou des points de terminaison de métriques). Les métriques clés incluent la taille de la base de données etcd et la latence des requêtes. Sur un cluster auto-géré, vous pouvez exécuter :

kubectl -n kube-system exec -it etcd-master-node -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint status --write-out=table

Recherchez DB SIZE et RAFT INDEX. Une taille de base de données importante (par exemple, supérieure à 2 Gio) peut indiquer un trop grand nombre de Secrets volumineux ou une compaction insuffisante. Surveillez également la durée des requêtes du serveur d'API pour les écritures de Secrets ; des réponses lentes peuvent signaler une pression sur etcd.

Comprendre le backend de stockage du cluster

Les services Kubernetes gérés (EKS, GKE, AKS) gèrent etcd pour vous, mais ils ont quand même des quotas et des limites. Par exemple, GKE limite le stockage etcd à une certaine taille par cluster et impose un nombre maximal d'objets. Consultez la documentation de votre fournisseur. Sur les clusters auto-gérés, assurez-vous qu'etcd dispose d'un espace disque et de performances suffisants. Le quota backend etcd est par défaut de 2 Gio, mais il peut être augmenté. Si vous dépassez le quota, etcd cesse d'accepter les écritures, ce qui peut entraîner une panne du plan de contrôle de votre cluster.

Limites pratiques et dimensionnement des Secrets

Cette section détaille les limites concrètes et comment les planifier.

Taille maximale d'un Secret

Comme mentionné, la taille maximale d'un Secret est de 1 Mio (1 048 576 octets) pour la taille combinée de ses champs de données. Cela inclut les valeurs encodées en base64. Par exemple, un Secret avec deux clés, l'une de 500 Kio et l'autre de 524 Kio, totaliserait 1 024 Kio et serait accepté. Mais si le total dépasse 1 Mio, le serveur d'API le rejette avec une erreur comme :

The Secret "too-large" is invalid: data: Too long: must have at most 1048576 bytes

Vous pouvez tester cela en essayant de créer un Secret à partir d'un gros fichier :

# Créer un fichier de 1,1 Mio
head -c 1153433 /dev/urandom > large-file.txt
kubectl create secret generic too-large --from-file=large-file.txt

Vous devriez voir une erreur similaire à celle ci-dessus.

Nombre de Secrets par espace de noms et par cluster

Il n'y a pas de limite stricte sur le nombre de Secrets, mais des limites pratiques existent. Chaque Secret ajoute des objets à etcd, augmente l'utilisation de la mémoire sur le serveur d'API et peut affecter les performances de listage et de surveillance. En règle générale, gardez le nombre total d'objets (y compris les Secrets, ConfigMaps, Pods, etc.) dans un espace de noms en dessous de 10 000 pour des performances optimales. Pour l'ensemble du cluster, rester en dessous de 100 000 objets est conseillé sur les configurations typiques. Dépasser ces seuils peut entraîner des réponses API plus lentes et une pression sur etcd.

Pour compter les Secrets dans un espace de noms :

kubectl get secrets -n your-namespace --no-headers | wc -l

Taille de stockage etcd

Chaque Secret consomme de l'espace etcd. Comme etcd stocke une copie de tout l'état du cluster, y compris les Secrets, un grand nombre de gros Secrets peut rapidement remplir la base de données etcd. Surveillez la taille de la base de données etcd à l'aide de la commande montrée précédemment. En point de départ, prévoyez que les données des Secrets représentent une petite fraction de l'utilisation totale d'etcd, idéalement moins de 20 à 30 %. Si les Secrets poussent etcd au-delà de son quota, envisagez d'utiliser des magasins de secrets externes comme Vault ou les gestionnaires de secrets des fournisseurs cloud.

Mémoire des nœuds et montage des Secrets

Les Secrets sont montés dans les Pods en tant que volumes tmpfs ou variables d'environnement. Chaque Secret monté consomme de la mémoire sur le nœud. Si un Pod monte de nombreux gros Secrets, le nœud peut manquer de mémoire. Une directive courante est de garder les Secrets individuels en dessous de 100 Kio sauf nécessité absolue et de monter uniquement les Secrets dont un Pod a besoin. Pour voir les Secrets montés d'un Pod :

kubectl get pod <pod-name> -o json | jq '.spec.volumes[]?.secret.secretName'

Exemple de dimensionnement concret

Supposons que vous ayez une application de microservices avec 50 services, chacun nécessitant 3 Secrets de configuration (identifiants de base de données, clés API, certificats TLS). La taille moyenne d'un Secret est de 10 Kio, mais certains certificats TLS font 200 Kio. Total des Secrets = 50 × 3 = 150. Taille totale estimée = (140 × 10 Kio) + (10 × 200 Kio) = 1,4 Mio + 2 Mio = 3,4 Mio dans etcd. C'est largement dans les limites d'etcd, mais si vous avez des milliers de tels services, vous devrez adapter en conséquence. Prévoyez la croissance future : si vous prévoyez de doubler les services dans 6 mois, concevez pour 7 Mio de données de Secrets.

Chemin de configuration sûr

Lorsque vous apportez des modifications à la capacité des Secrets, suivez un chemin sûr : commencez petit, testez et vérifiez.

Utiliser des quotas de ressources par espace de noms

L'un des meilleurs moyens de contrôler la capacité des Secrets est de définir des quotas de ressources au niveau de l'espace de noms. Vous pouvez limiter le nombre total de Secrets et le stockage total consommé par les Secrets dans un espace de noms. Exemple de manifeste ResourceQuota :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: secret-quota
  namespace: your-namespace
spec:
  hard:
    secrets: "100"
    requests.storage: "10Mi"

Cela limite l'espace de noms à 100 Secrets et 10 Mio de demandes de stockage totales pour les PVC ; cependant, le stockage des Secrets n'est pas directement compté par requests.storage. Utilisez plutôt une ressource personnalisée ou fiez-vous à la limite de nombre et aux limites de taille individuelles des Secrets. Il n'existe pas de quota intégré pour la taille totale des données des Secrets, mais vous pouvez appliquer des limites de taille individuelles avec un contrôleur d'admission comme OPA Gatekeeper ou Kyverno.

Appliquez le quota et vérifiez :

kubectl apply -f secret-quota.yaml
kubectl get resourcequota secret-quota -n your-namespace -o yaml

Lorsqu'un utilisateur essaie de créer plus de Secrets que permis, il obtient une erreur Forbidden.

Mettre en œuvre des politiques d'admission pour la taille des Secrets

Pour plafonner la taille des Secrets, définissez une politique Kyverno si vous utilisez Kyverno. Exemple de politique qui rejette les Secrets de plus de 500 Kio :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: limit-secret-size
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: check-secret-size
      match:
        any:
        - resources:
            kinds:
            - Secret
      validate:
        message: "Secret size exceeds 500 KiB"
        pattern:
          metadata:
            annotations:
              kyverno.io/secret-size: "*"
        deny:
          conditions:
            any:
            - key: "{{ request.object.data.values(@) | [].length(@) | sum(@) }}"
              operator: GreaterThan
              value: 524288

Cette politique utilise le langage d'expression de Kyverno pour calculer la somme des longueurs des valeurs de données. Ajustez le seuil selon vos besoins. Pour les clusters sans Kyverno, vous pouvez utiliser OPA Gatekeeper avec une politique Rego qui calcule la taille totale.

Chiffrer les Secrets au repos

Assurez-vous que le chiffrement etcd est activé pour les Secrets. Cela les protège si les données etcd sont compromises. Sur les clusters auto-gérés, configurez le chiffrement au repos dans le serveur d'API. Sur les clusters gérés, activez l'option de chiffrement du fournisseur. Par exemple, sur GKE, vous pouvez activer le chiffrement des Secrets au niveau de l'application. Pour EKS, vous pouvez activer le chiffrement d'enveloppe avec KMS. Cela n'affecte pas la capacité, mais est une bonne pratique de sécurité.

Utiliser des magasins de secrets externes pour les grosses données

Pour les secrets très volumineux ou changeant fréquemment, envisagez des magasins externes comme HashiCorp Vault, AWS Secrets Manager ou Google Secret Manager. Intégrez-les à Kubernetes à l'aide d'outils comme External Secrets Operator ou Secrets Store CSI Driver. Cela permet de garder etcd petit et de centraliser la rotation. Par exemple, External Secrets Operator peut synchroniser un secret depuis AWS Secrets Manager vers un Secret Kubernetes, mais vous pouvez aussi configurer les Pods pour monter directement depuis le pilote CSI sans créer de Secret Kubernetes, évitant ainsi le stockage etcd.

Vérification et diagnostics

Après avoir défini des limites ou apporté des modifications, vérifiez que tout fonctionne comme prévu.

Valider les limites de création de Secrets

Essayez de créer un Secret sous la limite et un autre au-dessus, et observez les résultats. Pour une vérification manuelle :

# Créer un petit secret
kubectl create secret generic small-secret --from-literal=key=value
# Créer un gros secret qui devrait échouer (si la politique est définie)
echo $(head -c 600000 /dev/urandom | base64) > big.txt
kubectl create secret generic big-secret --from-file=big.txt

La sortie attendue pour le secret en échec devrait être une erreur de validation du serveur d'API ou du webhook d'admission, pas une acceptation silencieuse.

Surveiller les métriques etcd et du serveur d'API

Utilisez kubectl get --raw /metrics pour scraper les métriques du serveur d'API et rechercher les latences de requêtes liées aux Secrets. Pour etcd, si vous avez un accès direct, vérifiez le point de terminaison des métriques etcd. Par exemple, sur un cluster kubeadm, exécutez :

curl -s https://localhost:2379/metrics -k --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key | grep etcd_debugging_mvcc_db_total_size_in_bytes

La sortie montre la taille actuelle de la base de données en octets. Suivez cela dans le temps pour voir la croissance due aux Secrets.

Vérifier le démarrage des Pods avec des Secrets montés

Si un Secret est trop volumineux pour être monté, le Pod peut échouer à démarrer avec une erreur comme secret is too large ou le kubelet peut journaliser des avertissements. Simulez en créant un gros Secret et en le montant dans un Pod de test (dans vos limites). Observez l'état du Pod :

kubectl get pods
kubectl describe pod <pod-name>

Recherchez des événements indiquant des échecs de montage de volume. Certaines versions de Kubernetes limitent la taille d'un volume secret à 1 Mio, et si le Secret est plus grand, le montage échoue.

Utiliser des conteneurs de débogage

Pour diagnostiquer la taille du contenu d'un Secret, vous pouvez entrer dans un Pod en cours d'exécution avec un conteneur de débogage (si pris en charge) et inspecter les fichiers montés. Par exemple :

kubectl debug -it <pod-name> --image=busybox --target=<container-name>

Ensuite, dans le conteneur de débogage, exécutez ls -lh /etc/secret-volume pour vérifier la taille des fichiers. C'est en lecture seule et ne modifie pas le Secret.

Modes de défaillance et récupération

Les problèmes de capacité peuvent provoquer diverses défaillances. Cette section couvre les modes de défaillance courants et comment récupérer.

Création de Secret rejetée en raison de la taille

Symptômes : kubectl create secret renvoie une erreur Too long: must have at most 1048576 bytes. Les déploiements d'applications qui dépendent de ce Secret échouent.

Récupération :

1. Identifiez les grandes données et divisez-les en plusieurs Secrets si cela est logiquement possible (par exemple, un Secret pour le certificat, un pour la clé).
2. Si les données ne peuvent pas être divisées, stockez-les en externe et référencez-les via un Secret plus petit (par exemple, un Secret contenant uniquement un pointeur ou un petit jeton pour récupérer les données).
3. Compressez les données avant de les stocker dans un Secret (si l'application peut décompresser).
4. Recréez le Secret avec la nouvelle approche.

Exemple de division d'un Secret :

# Original : un Secret avec deux grandes clés
# Au lieu de cela, créez deux Secrets :
kubectl create secret generic app-cert --from-file=tls.crt
kubectl create secret generic app-key --from-file=tls.key

Mettez à jour la spécification du Pod pour monter les deux Secrets.

Quota de base de données etcd dépassé

Symptômes : Le serveur d'API renvoie etcdserver: mvcc: database space exceeded ou similaire. L'ensemble du cluster peut devenir en lecture seule.

Récupération :

1. Réduisez immédiatement le stockage etcd en supprimant les objets inutiles, en particulier les gros Secrets et ConfigMaps. Identifiez les gros Secrets à l'aide de la commande précédente.
2. Compactez l'historique etcd (si vous y avez accès) avec etcdctl compact.
3. Défragmentez etcd avec etcdctl defrag.
4. Augmentez le quota etcd en ajustant le drapeau --quota-backend-bytes sur etcd et en redémarrant etcd (c'est une étape de maintenance planifiée).
5. À long terme, déplacez les gros Secrets vers un stockage externe.

Pour les clusters gérés, contactez le support du fournisseur et évitez d'atteindre le quota en surveillant.

Pression mémoire sur les nœuds due aux Secrets montés

Symptômes : Les Pods sont expulsés avec The node was low on resource: memory. Ou kubectl describe node affiche la condition MemoryPressure comme True.

Récupération :

1. Identifiez les Pods qui montent de gros Secrets et réduisez leur empreinte mémoire en ne montant pas les Secrets inutiles.
2. Utilisez des volumes projetés pour monter plusieurs Secrets dans un seul volume ; cela peut ne pas réduire la mémoire mais améliore l'efficacité.
3. Envisagez d'utiliser des variables d'environnement pour les petits Secrets uniquement, mais notez que les variables d'environnement consomment aussi de la mémoire et ne peuvent pas contenir de très grandes valeurs.
4. Si possible, augmentez la mémoire des nœuds ou répartissez les Pods sur plusieurs nœuds.

Pour voir l'utilisation de la mémoire par Pod, utilisez kubectl top pods (nécessite le serveur de métriques).

Secret supprimé accidentellement

Symptômes : Les Pods échouent à démarrer avec MountVolume.SetUp failed for volume "secret" : secret "my-secret" not found.

Récupération :

• Si vous avez une sauvegarde ou que le Secret est géré par External Secrets Operator, il sera recréé automatiquement.
• Sinon, restaurez à partir de votre système de gestion des secrets ou faites pivoter les informations d'identification et recréez le Secret.
• Pour éviter la suppression accidentelle, activez RBAC Kubernetes pour restreindre les autorisations de suppression sur les Secrets, et envisagez d'utiliser des outils comme Velero pour la sauvegarde des Secrets (bien que noter que sauvegarder des Secrets en clair est risqué).

Points clés pour la récupération après défaillance

Ayez toujours un plan de retour en arrière. Pour les changements de Secrets, conservez une copie des données de Secret précédentes dans un emplacement sécurisé (par exemple, chiffré dans votre gestionnaire de secrets) afin de pouvoir revenir rapidement. Testez périodiquement les procédures de récupération.

Liste de contrôle opérationnelle

Cette liste de contrôle fournit un processus reproductible pour gérer la capacité des Secrets. Attribuez un propriétaire à chaque élément et revisitez à la fréquence spécifiée.

Contrôles quotidiens

• [ ] Propriétaire : Ingénieur plateforme - Vérifiez la taille de la base de données etcd et alertez si elle dépasse 70 % du quota. Utilisez des tableaux de bord de surveillance.
• [ ] Propriétaire : Administrateur Kubernetes - Examinez les journaux d'erreurs du serveur d'API pour les erreurs de validation liées aux Secrets (recherchez « trop long » ou « taille de secret »).

Contrôles hebdomadaires

• [ ] Propriétaire : Responsable DevOps - Examinez le nombre de Secrets par espace de noms. Exécutez kubectl get secrets --all-namespaces | awk '{print $1}' | sort | uniq -c | sort -nr. Recherchez les espaces de noms dépassant 500 Secrets.
• [ ] Propriétaire : Ingénieur sécurité - Vérifiez que le chiffrement au repos est activé et que la rotation des clés fonctionne si applicable.

Contrôles mensuels

• [ ] Propriétaire : Architecte plateforme - Auditez les tailles des Secrets à l'aide de la commande jq vue plus tôt. Identifiez les Secrets de plus de 100 Kio et planifiez de les diviser ou de les externaliser.
• [ ] Propriétaire : Responsables d'équipe - Examinez les quotas de ressources et les politiques d'admission ; ajustez les limites en fonction de la croissance réelle de l'utilisation.

Contrôles trimestriels

• [ ] Propriétaire : Architecte plateforme - Effectuez un exercice de planification de la capacité : projetez la croissance des Secrets en fonction des tendances historiques et des fonctionnalités prévues. Mettez à jour le quota etcd et le dimensionnement du cluster.
• [ ] Propriétaire : Ingénieur sécurité - Testez la récupération après suppression de Secret et les scénarios de défaillance etcd dans un environnement de préproduction.

Contrôles annuels

• [ ] Propriétaire : Directeur de l'ingénierie - Évaluez des solutions de gestion des secrets alternatives (par exemple, External Secrets Operator, Vault) et décidez s'il faut migrer hors du stockage etcd direct.

Chaque élément de la liste de contrôle doit avoir un propriétaire clair, pas un groupe, pour garantir la responsabilisation. Réévaluez la fréquence de la liste de contrôle elle-même chaque trimestre pour l'ajuster.

Pièges courants et comment les éviter

1. Traiter les Secrets comme un stockage illimité

Pourquoi cela arrive : Les équipes supposent que puisqu'etcd est une base de données, elle peut tout stocker. Elles mettent de gros fichiers, des certificats ou même des données binaires dans les Secrets.

Comment éviter : Définissez des politiques explicites limitant la taille des Secrets à 1 Mio ou moins. Utilisez un stockage externe pour les grosses données et référencez-les depuis un petit Secret. Éduquez les développeurs sur la limite de 1 Mio.

Récupération : Si vous avez de gros Secrets, auditez-les et divisez-les ou externalisez-les. Utilisez la commande jq pour trouver les contrevenants.

2. Ignorer les quotas d'espace de noms

Pourquoi cela arrive : Les équipes ne définissent pas de quotas parce qu'elles n'anticipent pas la croissance. Une seule équipe de microservices peut créer accidentellement des centaines de Secrets.

Comment éviter : Appliquez des ResourceQuotas pour le nombre de secrets dans chaque espace de noms. Utilisez LimitRange pour définir des tailles par défaut si nécessaire (bien que LimitRange ne s'applique pas aux tailles des Secrets).

Récupération : Appliquez des quotas rétroactivement ; les Secrets existants dépassant le quota resteront, mais les nouveaux seront bloqués. Nettoyez les Secrets obsolètes.

3. Ne pas surveiller la croissance d'etcd

Pourquoi cela arrive : Les métriques etcd ne sont souvent pas exposées ou surveillées, en particulier dans les petits clusters.

Comment éviter : Mettez en place une surveillance Prometheus pour etcd et alertez sur la taille de la base de données. Pour les clusters gérés, activez la surveillance du fournisseur.

Récupération : Si etcd devient trop volumineux, compactez et défragmentez, puis supprimez les Secrets inutiles.

4. Monter des Secrets inutilement

Pourquoi cela arrive : Les développeurs copient les spécifications de Pod et incluent tous les Secrets disponibles pour plus de commodité, ce qui entraîne un gaspillage de mémoire et des fuites potentielles.

Comment éviter : Utilisez RBAC pour limiter les Secrets qu'un Pod peut monter par espace de noms et compte de service. Examinez les spécifications de Pod dans le CI/CD pour s'assurer que seuls les Secrets requis sont référencés.

Récupération : Trouvez les Pods avec des montages excessifs en utilisant kubectl get pods -o json | jq et mettez à jour les déploiements pour supprimer les montages inutiles.

5. Stocker des Secrets en clair dans Git

Pourquoi cela arrive : Les équipes veulent un contrôle de version pour les Secrets et les committent dans les dépôts, violant la sécurité.

Comment éviter : Utilisez sealed-secrets, des secrets externes avec des références chiffrées, ou un gestionnaire de secrets avec intégration GitOps. Ne stockez jamais de Secrets bruts dans Git.

Récupération : Faites pivoter immédiatement tous les Secrets exposés, puis passez à une méthode sécurisée.

6. Oublier le surcoût de l'encodage base64

Pourquoi cela arrive : Les développeurs pensent que la taille du Secret est la taille en clair, mais l'encodage base64 ajoute environ 33 % de surcoût. Un fichier de 800 Kio devient environ 1,06 Mio après encodage, dépassant la limite.

Comment éviter : Calculez toujours la taille encodée en base64 lors de la conception des Secrets. La limite s'applique aux données encodées dans l'objet Secret, pas au clair.

Récupération : Si vous atteignez la limite, compressez le clair avant l'encodage base64 si l'application peut le gérer, ou réduisez la taille des données.

Conclusion

La planification de la capacité des Secrets Kubernetes n'est pas une tâche ponctuelle mais une discipline opérationnelle continue. En comprenant les limites strictes, en surveillant l'utilisation réelle et en mettant en œuvre des garde-fous, vous pouvez prévenir les pannes et garder votre cluster sain.

Commencez par auditer votre paysage de Secrets actuel à l'aide des commandes de ce guide. Mettez en place des quotas de ressources et des politiques d'admission. Surveillez les métriques etcd et du serveur d'API. Ensuite, établissez un processus d'examen de routine avec une propriété claire. Enfin, testez les scénarios de défaillance pour vous assurer de pouvoir récupérer rapidement.

Un plan de capacité réfléchi pour les Secrets améliorera à la fois la sécurité et la fiabilité, garantissant que vos applications disposent des secrets nécessaires sans submerger votre cluster. Rappelez-vous : des Secrets petits, gérés et surveillés sont la clé d'opérations sans heurts.

Comme prochaine étape, choisissez une vérification à faible risque dans cet article, exécutez-la dans votre cluster de développement, enregistrez les résultats et partagez les conclusions avec votre équipe.