Mises à niveau et migrations des LimitRange Kubernetes : guide pratique de terrain

Introduction

La mise à niveau ou la migration des politiques LimitRange de Kubernetes peut directement affecter la planification des Pods, la quantité de CPU et de mémoire qu'ils reçoivent, et le respect des garde-fous de votre espace de noms. Un changement qui semble anodin sur le papier peut bloquer de nouvelles charges de travail ou modifier silencieusement les valeurs par défaut des ressources pour toute une équipe. Ce guide se concentre sur la mise à niveau et la migration des LimitRange Kubernetes avec des exemples pratiques pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les mises à niveau de version, les migrations, les restaurations et la validation à des commandes concrètes, des sorties attendues, des signaux d'échec et des décisions de récupération.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Vous apprendrez à inventorier votre configuration LimitRange actuelle, à planifier un chemin de migration sûr, à valider les changements dans un espace de noms de test, à diagnostiquer les échecs et à restaurer proprement en cas de problème. Les exemples utilisent Kubernetes 1.26+ et supposent que kubectl est configuré et que jq ou yq est disponible pour analyser la sortie YAML et JSON.

Inventaire de version et d'environnement

Avant de toucher à tout objet LimitRange, vous devez avoir une image claire de ce qui est installé, de la version de Kubernetes que vous exécutez et des espaces de noms soumis à la politique. Commencez par des commandes en lecture seule qui capturent l'état actuel sans apporter de modifications. Cette section explique comment recueillir cet inventaire et les prérequis à vérifier.

Vérifier la version Kubernetes et la disponibilité de l'API

LimitRange est une API stable (v1) et est disponible depuis Kubernetes 1.0, mais les champs plus récents tels que min, max, default, defaultRequest, et maxLimitRequestRatio peuvent se comporter différemment selon la version. Exécutez :

kubectl version --short

La sortie attendue montre à la fois la version du client et du serveur. Par exemple :

Client Version: v1.27.3
Server Version: v1.26.6

Si la version du serveur est antérieure à 1.21, certains champs comme maxLimitRequestRatio peuvent ne pas être pris en charge. Confirmez que l'API est disponible :

kubectl api-resources | grep limitrange

Sortie attendue :

limitranges  limits  v1  true  LimitRange

Lister les LimitRange existants

Listez tous les LimitRange dans tous les espaces de noms :

kubectl get limitranges --all-namespaces

Exemple de sortie :

NAMESPACE    NAME                  CREATED AT
default      cpu-mem-limit-range   2023-11-01T10:00:00Z
team-a       dev-limits            2023-10-15T14:30:00Z

Pour voir la définition complète d'un LimitRange spécifique, utilisez :

kubectl get limitrange cpu-mem-limit-range -n default -o yaml

Cette sortie inclut le tableau spec.limits avec toutes les règles. Faites attention au champ type : il peut être Container, Pod, PersistentVolumeClaim, ou EphemeralStorage. Chaque type a des contraintes différentes.

Capturer l'état actuel avec des horodatages

Avant toute migration ou mise à niveau, enregistrez un instantané. C'est votre point de restauration et votre piste d'audit. Utilisez un répertoire horodaté :

mkdir -p limitrange-backup-$(date +%Y%m%d-%H%M%S)
kubectl get limitranges --all-namespaces -o yaml > limitrange-backup-$(date +%Y%m%d-%H%M%S)/all-limitranges.yaml

Vérifiez que le fichier contient vos définitions LimitRange :

head -n 20 limitrange-backup-*/all-limitranges.yaml

Protéger les informations d'identification et le matériel privé

Votre YAML LimitRange ne doit pas contenir de secrets, mais si vous utilisez des outils de modélisation comme Helm ou Kustomize, assurez-vous que les fichiers de valeurs ou les correctifs ne sont pas stockés en texte brut dans des dépôts publics. Utilisez un modèle d'espace réservé dans vos exemples :

apiVersion: v1
kind: LimitRange
metadata:
  name: my-limitrange
  namespace: my-namespace
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

Ne commitez jamais de véritables informations d'identification cloud ou de clés privées. Si vous devez référencer une valeur gérée par secret, utilisez une ConfigMap ou une référence de secret dans votre pipeline GitOps, pas dans le fichier LimitRange lui-même.

Identifier les dépendances : ResourceQuota, Namespace, Pod

Les LimitRange fonctionnent souvent avec les ResourceQuota. Un ResourceQuota fixe des limites strictes sur les ressources totales qu'un espace de noms peut consommer, tandis qu'un LimitRange fixe des valeurs par défaut et des contraintes par objet. Ils doivent être compatibles : si un LimitRange définit une demande par défaut qui dépasse le ResourceQuota, les Pods peuvent échouer à planifier. Vérifiez les ResourceQuota dans le même espace de noms :

kubectl get resourcequota -n my-namespace

Considérez également comment les Pods existants sont affectés. Si vous modifiez un LimitRange, les Pods existants ne sont pas rétroactivement modifiés. Seuls les nouveaux Pods sont soumis aux nouvelles valeurs par défaut et contraintes. Donc, pendant la migration, vous devez décider s'il faut redémarrer les déploiements existants pour appliquer les changements de valeurs par défaut.

Vérifications Kubernetes pratiques

• kubectl get pods -o wide pour voir sur quels nœuds les Pods se trouvent et leur statut.
• kubectl describe pod <name> pour les événements liés aux violations de LimitRange (par exemple, Failed to create pod sandbox: pods "x" is forbidden: maximum cpu usage per Container is 1, but limit is 2).
• kubectl logs <name> --previous pour vérifier si un Pod a été tué en raison de la limite de ressources.
• kubectl rollout status deployment/<name> pour confirmer qu'un déploiement est entièrement déployé après un changement.

Pour un test local, appliquez un manifeste, inspectez les ressources générées et vérifiez le trafic avec kubectl port-forward ou un service de type NodePort avant de passer à un équilibreur de charge cloud ou à un contrôleur d'entrée.

Chemin de configuration sûr

La mise à niveau ou la migration des LimitRange doit suivre une approche par étapes : comprendre la politique actuelle, concevoir la nouvelle politique, tester dans un espace de noms hors production, puis déployer avec un plan de restauration. Cette section décrit le chemin de configuration sûr avec des exemples concrets.

Comprendre la politique actuelle

Supposons que vous ayez un LimitRange existant dans l'espace de noms default qui fournit des demandes et limites CPU et mémoire par défaut :

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: default
spec:
  limits:
  - default:
      cpu: "1"
      memory: "1Gi"
    defaultRequest:
      cpu: "500m"
      memory: "512Mi"
    max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    type: Container

Cette politique garantit que chaque conteneur de l'espace de noms default obtient une demande par défaut de 500m CPU et 512Mi mémoire, une limite par défaut de 1 CPU et 1Gi mémoire, et ne peut pas demander plus de 2 CPU ou 2Gi mémoire ni moins de 100m CPU ou 128Mi mémoire.

Maintenant, supposons que vous vouliez migrer cette politique vers un nouvel espace de noms team-a avec des valeurs différentes, ou que vous deviez mettre à niveau la politique pour ajouter un maxLimitRequestRatio afin d'empêcher le sur-engagement.

Concevoir la nouvelle politique

Une nouvelle politique pourrait ressembler à :

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - default:
      cpu: "750m"
      memory: "768Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    maxLimitRequestRatio:
      cpu: "4"
      memory: "3"
    type: Container

Ici, nous ajoutons maxLimitRequestRatio : le rapport limite/demande ne peut pas dépasser 4 pour le CPU et 3 pour la mémoire. Cela empêche un conteneur de demander une petite demande mais une limite énorme, ce qui aide à la gestion de l'utilisation du cluster.

Tester dans un espace de noms bac à sable

Créez un espace de noms bac à sable et appliquez la nouvelle politique :

kubectl create namespace team-a-sandbox
kubectl apply -f team-a-limits.yaml  # après avoir changé namespace en team-a-sandbox

Ensuite, créez un Pod de test sans spécifier de ressources pour voir les valeurs par défaut appliquées :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: team-a-sandbox
spec:
  containers:
  - name: test-container
    image: nginx

Appliquez-le :

kubectl apply -f test-pod.yaml

Vérifiez les ressources effectives du Pod :

kubectl get pod test-pod -n team-a-sandbox -o jsonpath='{.spec.containers[0].resources}'

La sortie attendue doit montrer les demandes et limites par défaut telles que définies :

{"limits":{"cpu":"750m","memory":"768Mi"},"requests":{"cpu":"250m","memory":"256Mi"}}

Si la sortie ne montre aucune ressource, le LimitRange peut ne pas être appliqué correctement ; vérifiez si l'étiquette de l'espace de noms correspond à metadata.namespace de votre LimitRange.

Valider les contraintes

Essayez de créer un Pod qui viole le CPU maximal :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-violate
  namespace: team-a-sandbox
spec:
  containers:
  - name: test-container
    image: nginx
    resources:
      limits:
        cpu: "3"
        memory: "1Gi"
      requests:
        cpu: "1"
        memory: "512Mi"

Appliquez et observez l'erreur :

kubectl apply -f test-pod-violate.yaml

La sortie attendue inclut une erreur comme :

Error from server (Forbidden): error when creating "test-pod-violate.yaml": pods "test-pod-violate" is forbidden: maximum cpu usage per Container is 2, but limit is 3.

Cela confirme que le LimitRange est appliqué.

Déployer en production

Une fois la validation passée, appliquez la politique à l'espace de noms réel team-a. Mais avant cela, assurez-vous d'avoir une sauvegarde du LimitRange existant dans team-a (le cas échéant) pour la restauration. Ensuite, appliquez :

kubectl apply -f team-a-limits.yaml

Surveillez le déploiement avec :

kubectl get limitrange team-a-limits -n team-a -o yaml

Garder le test local petit

Testez toujours avec un seul manifeste, inspectez les ressources générées et utilisez kubectl port-forward ou un service NodePort pour vérifier la connectivité avant de passer aux équilibreurs de charge de production. Par exemple, après avoir appliqué le LimitRange, créez un déploiement de test et exposez-le temporairement :

kubectl create deployment test-nginx --image=nginx -n team-a
kubectl expose deployment test-nginx --type=NodePort --port=80 -n team-a
kubectl get svc test-nginx -n team-a

Notez le NodePort et testez localement avec curl ou kubectl port-forward :

kubectl port-forward svc/test-nginx 8080:80 -n team-a

Ensuite, curl localhost:8080 pour vérifier.

Vérification et diagnostic

Après avoir appliqué un LimitRange nouveau ou mis à jour, vous devez vérifier qu'il fonctionne comme prévu et diagnostiquer tout problème qui survient. Cette section couvre les techniques de vérification et les commandes de diagnostic courantes.

Vérifier le statut du LimitRange

Utilisez kubectl describe pour voir les événements et les avertissements :

kubectl describe limitrange team-a-limits -n team-a

La sortie doit montrer les règles sans erreurs. Par exemple :

Name:         team-a-limits
Namespace:    team-a
Type         Resource  Min   Max  Default Request  Default Limit  Max Limit/Request Ratio
----         --------  ---   ---  ---------------  -------------  -----------------------
Container    cpu       50m   2    250m             750m           4
Container    memory    64Mi  2Gi  256Mi            768Mi          3

Si la colonne Max Limit/Request Ratio affiche une valeur, elle est appliquée.

Tester l'application de la politique avec un dry-run

Utilisez kubectl apply --dry-run=client ou --dry-run=server pour tester un Pod sans le créer réellement. Par exemple :

kubectl apply -f test-pod-violate.yaml --dry-run=server -n team-a

Si le Pod serait rejeté, vous voyez la même erreur que ci-dessus. S'il passerait, vous voyez pod/test-pod-violate created (server dry run) (bien qu'il ne soit pas réellement créé).

Vérifier les événements pour les problèmes de LimitRange

Les Pods rejetés en raison d'un LimitRange génèrent des événements. Utilisez :

kubectl get events -n team-a --sort-by=.metadata.creationTimestamp

Cherchez les messages FailedCreate ou Forbidden. Par exemple :

LAST SEEN   TYPE      REASON        OBJECT                 MESSAGE
3m          Warning   FailedCreate  replicaset/test-rs     Error creating: pods "test-rs-abc" is forbidden: maximum memory usage per Container is 2Gi, but limit is 3Gi.

Diagnostiquer pourquoi un Pod n'a pas reçu de valeurs par défaut

Si un Pod qui devrait avoir des ressources par défaut apparaît sans elles, vérifiez :

• L'espace de noms du Pod correspond à l'espace de noms du LimitRange.
• Le spec.limits du LimitRange inclut une entrée type: Container (les valeurs par défaut ne s'appliquent qu'aux conteneurs, pas aux Pods ou PVCs sauf indication contraire).
• La spécification du Pod ne spécifie pas déjà des ressources ; si c'est le cas, les valeurs par défaut du LimitRange ne s'appliquent pas, mais les contraintes s'appliquent toujours.

Utilisez kubectl get pod <pod> -n <namespace> -o yaml et inspectez spec.containers[].resources. Si vide, le LimitRange ne s'est pas appliqué.

Vérifiez le metadata.namespace du LimitRange ; une erreur courante est d'appliquer le LimitRange au mauvais espace de noms.

Valider avec une requête JSONPath

Vous pouvez extraire les ressources effectives d'un Pod en utilisant jsonpath :

kubectl get pod test-pod -n team-a -o jsonpath='{.spec.containers[0].resources}'

Comparez avec les valeurs par défaut du LimitRange.

Modes d'échec et récupération

Aucune migration n'est sans risque. Cette section couvre les modes d'échec courants lors de la mise à niveau ou de la migration des LimitRange et comment récupérer.

Mode d'échec 1 : Échecs de planification des Pods après application de nouvelles limites

Symptôme : Les nouveaux Pods échouent à planifier ou sont rejetés avec des messages d'erreur comme forbidden: maximum cpu usage per Container is X, but limit is Y.

Pourquoi cela arrive : Le nouveau LimitRange a introduit des valeurs maximales plus strictes, ou les Pods existants ont été créés sous une politique plus permissive et sont maintenant redémarrés. Les Pods existants ne sont pas modifiés, mais les nouveaux Pods des Deployments ou StatefulSets seront soumis aux nouvelles contraintes s'ils ne spécifient pas de ressources ou spécifient des valeurs dépassant le nouveau maximum.

Récupération :

1. Identifiez les Pods en échec : kubectl get pods -n team-a --field-selector=status.phase=Failed ou kubectl get events pour trouver l'erreur.
2. Assouplissez temporairement le LimitRange ou supprimez-le : kubectl delete limitrange team-a-limits -n team-a (uniquement si vous avez une sauvegarde ; c'est un dernier recours, mais cela arrête l'hémorragie).
3. Corrigez la spécification du Deployment ou du Pod en infraction pour se conformer aux nouvelles limites, ou ajustez le LimitRange à une valeur qui convient à vos charges de travail.
4. Réappliquez le LimitRange prévu et vérifiez.

Mode d'échec 2 : Conflit de ResourceQuota

Symptôme : Les Pods sont rejetés avec un message comme exceeded quota: team-a-quota, requested: cpu=750m, used: cpu=3, limited: cpu=4.

Pourquoi cela arrive : Les valeurs par défaut du LimitRange (ou les demandes explicites des Pods) font dépasser le ResourceQuota total de l'espace de noms.

Récupération :

• Vérifiez le ResourceQuota : kubectl describe resourcequota team-a-quota -n team-a.
• Ajustez soit le ResourceQuota (si autorisé), soit les valeurs par défaut du LimitRange à des valeurs plus basses.
• Supprimez ou réduisez certaines charges de travail existantes pour libérer des ressources.
• Assurez-vous que les valeurs par défaut s'alignent sur le quota : si le quota autorise 4 CPU au total et que chaque demande par défaut de Pod est de 750m, vous ne pouvez exécuter qu'environ 5 Pods. Si vous avez besoin de plus de Pods, baissez la demande par défaut.

Mode d'échec 3 : Violation de maxLimitRequestRatio

Symptôme : La création du Pod échoue avec limit/request ratio for cpu in container test is 5, which exceeds maxLimitRequestRatio of 4.

Pourquoi cela arrive : Le Pod spécifie un rapport limite/demande supérieur à celui autorisé. Cela arrive souvent lorsque les développeurs définissent une demande très basse et une limite élevée.

Récupération :

• Modifiez la spécification du Pod pour soit baisser la limite, soit augmenter la demande pour respecter le rapport.
• Ou, si le rapport est trop strict, ajustez le maxLimitRequestRatio du LimitRange à une valeur plus élevée (ou supprimez-le).

Mode d'échec 4 : Rupture des déploiements existants lors de la mise à niveau

Symptôme : Après la mise à niveau du LimitRange (par exemple, augmentation du CPU minimum), les déploiements existants peuvent échouer lors du déploiement de nouvelles répliques car leurs modèles de Pod tombent en dessous du nouveau minimum.

Pourquoi cela arrive : La demande du modèle de Pod du Deployment est inférieure au nouveau minimum.

Récupération :

1. Mettez en pause le déploiement : kubectl rollout pause deployment/<name>.
2. Mettez à jour les demandes de ressources du Deployment pour atteindre le nouveau minimum.
3. Reprenez le déploiement : kubectl rollout resume deployment/<name>.
4. Si vous ne pouvez pas mettre à jour immédiatement, envisagez de remettre temporairement le minimum du LimitRange à l'ancienne valeur jusqu'à ce que vous puissiez mettre à jour les déploiements.

Stratégie de restauration

Ayez toujours un plan de restauration. La restauration la plus sûre est de restaurer le LimitRange précédent à partir de votre sauvegarde :

kubectl apply -f backup-limitrange.yaml

Si vous n'avez pas de sauvegarde, vous pouvez le reconstruire à partir de votre historique Git ou de la documentation. Si vous devez supprimer le LimitRange entièrement (ce qui peut ne pas être souhaitable mais arrête l'application) :

kubectl delete limitrange <name> -n <namespace>

Ensuite, réappliquez la politique correcte.

Liste de contrôle des opérations

Cette liste de contrôle résume les étapes pour une mise à niveau ou une migration LimitRange sûre. Elle est conçue pour être utilisée comme un runbook.

Liste de contrôle avant mise à niveau

• [ ] Confirmer la version Kubernetes : kubectl version.
• [ ] Lister les LimitRange existants : kubectl get limitranges --all-namespaces.
• [ ] Sauvegarder tous les LimitRange : kubectl get limitranges --all-namespaces -o yaml > limitrange-backup.yaml.
• [ ] Identifier les dépendances : ResourceQuota, Pods existants, Deployments.
• [ ] Concevoir le nouveau LimitRange avec des valeurs par défaut, max, min et ratio clairs (si souhaité).
• [ ] Tester le nouveau LimitRange dans un espace de noms bac à sable.

Liste de contrôle d'exécution de la mise à niveau

• [ ] Appliquer le nouveau LimitRange à l'espace de noms cible : kubectl apply -f new-limitrange.yaml.
• [ ] Vérifier avec kubectl describe limitrange.
• [ ] Tester avec un Pod d'exemple pour s'assurer que les valeurs par défaut sont appliquées.
• [ ] Tester les cas de violation pour s'assurer que les contraintes sont appliquées.
• [ ] Surveiller les événements pour les messages Forbidden ou FailedCreate.
• [ ] En cas de problème, restaurer à l'aide de la sauvegarde.

Liste de contrôle de vérification après mise à niveau

• [ ] Confirmer que les déploiements existants sont toujours sains : kubectl get deployments.
• [ ] Vérifier que les nouveaux Pods reçoivent les valeurs par défaut attendues : kubectl get pod <test-pod> -o jsonpath='{.spec.containers[0].resources}'.
• [ ] S'assurer que le ResourceQuota n'est pas violé : kubectl describe resourcequota.
• [ ] Documenter le changement dans votre runbook ou dépôt Git.

Responsable imputable et fréquence de révision

Attribuez un seul responsable imputable pour les changements de LimitRange, comme le responsable de l'équipe plateforme ou l'ingénieur DevOps. Ce responsable est chargé de :

• Approuver la nouvelle politique.
• Vérifier que la sauvegarde existe.
• Autoriser le déploiement.
• Diriger la restauration si nécessaire.

Révisez les politiques LimitRange trimestriellement ou chaque fois que les modèles d'utilisation des ressources changent de manière significative. Une bonne pratique est de réviser lors de la réunion régulière de planification de capacité de l'équipe. Si vous utilisez GitOps, une pull request avec au moins un réviseur (le responsable) doit être exigée.

Pièges courants et comment les éviter

De nombreux problèmes avec les mises à niveau de LimitRange proviennent d'une mauvaise compréhension de la façon dont la politique interagit avec d'autres ressources. Voici les pièges les plus courants et comment les éviter ou en récupérer.

Piège 1 : Supposer que les Pods existants sont mis à jour

Les changements de LimitRange n'affectent pas les Pods existants. Si vous augmentez la demande ou la limite par défaut, les Pods existants conservent leurs ressources actuelles. Cela peut conduire à un comportement incohérent dans le même espace de noms.

Comment éviter : Après avoir changé les valeurs par défaut, redémarrez explicitement les Deployments ou StatefulSets pour appliquer les nouvelles valeurs par défaut aux charges de travail existantes, mais seulement après les avoir testées. Utilisez kubectl rollout restart deployment/<name> si vous voulez que tous les Pods soient recréés avec les nouvelles valeurs par défaut.

Piège 2 : Ignorer l'interaction avec le ResourceQuota

Un LimitRange qui définit des demandes par défaut élevées peut rapidement épuiser le ResourceQuota d'un espace de noms, provoquant l'échec des nouveaux Pods. Vérifiez toujours le quota avant et après.

Comment éviter : Utilisez kubectl describe resourcequota et calculez le nombre maximum de Pods qui peuvent être créés avec les nouvelles valeurs par défaut. Ajustez au besoin. Par exemple, si le quota autorise 10 CPU et que la demande par défaut est de 500m, vous pouvez exécuter jusqu'à 20 Pods (10 / 0,5). Si vous prévoyez plus de Pods, baissez la demande par défaut ou augmentez le quota.

Piège 3 : Fixer des valeurs max ou min irréalistes

Des valeurs max trop strictes peuvent bloquer des charges de travail légitimes ; des valeurs min trop lâches peuvent conduire à un sur-engagement ou une sous-utilisation. Trouver le bon équilibre nécessite de comprendre l'utilisation réelle de votre équipe.

Comment éviter : Analysez les métriques d'utilisation historiques (par exemple, de Prometheus ou kubectl top) avant de fixer des limites. Utilisez une plage qui couvre le 95e percentile de l'utilisation observée. Révisez trimestriellement.

Piège 4 : Oublier d'inclure defaultRequest pour les Pods Burstable

Si vous définissez uniquement default (limites) sans defaultRequest, les Pods qui ne spécifient pas de demandes obtiendront des demandes égales aux limites, ce qui peut être trop élevé pour votre quota. Inversement, si vous définissez defaultRequest mais pas default, les Pods peuvent obtenir des limites très basses, provoquant potentiellement des OOM kills.

Comment éviter : Définissez toujours à la fois default et defaultRequest sauf si vous avez une raison spécifique. Testez avec un Pod d'exemple.

Piège 5 : Ne pas tester dans un bac à sable

Appliquer un nouveau LimitRange directement en production peut provoquer une panne. Testez toujours dans un espace de noms bac à sable avec des étiquettes et dépendances identiques.

Comment éviter : Créez un espace de noms comme team-a-staging et appliquez le même LimitRange. Exécutez une charge de travail représentative et vérifiez.

Piège 6 : Manque de plan de restauration

Si quelque chose tourne mal, vous devez revenir rapidement. Sans sauvegarde, vous devrez peut-être reconstruire le LimitRange de mémoire, provoquant un temps d'arrêt.

Comment éviter : Sauvegardez toujours avant de changer. Stockez les sauvegardes dans un dépôt versionné ou un stockage d'objets.

Conclusion

Les mises à niveau et migrations des LimitRange Kubernetes sont sûres lorsqu'elles sont abordées méthodiquement : inventorier l'état actuel, concevoir et tester la nouvelle politique, valider les contraintes et avoir un plan de restauration. La clé est d'observer avant de changer et de comprendre les interactions avec les ResourceQuota et les charges de travail existantes.

Comme prochaine étape, choisissez une vérification à faible risque pour votre cluster. Par exemple, créez un espace de noms temporaire, appliquez un nouveau LimitRange avec une valeur par défaut différente et créez un Pod de test pour confirmer que les valeurs par défaut sont appliquées et les contraintes appliquées. Enregistrez l'état actuel, exécutez les vérifications et comparez les résultats. Ensuite, intégrez ces étapes dans le runbook opérationnel de votre équipe.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.