Planification de capacité des demandes de signature de certificats Kubernetes : guide pratique

Introduction

Les clusters Kubernetes dépendent de certificats X.509 pour les communications sécurisées entre les composants du plan de contrôle, les nœuds et les charges de travail. L'API Certificate Signing Request (CSR) permet aux clients de demander des certificats que le plan de contrôle Kubernetes doit approuver et signer. Dans les clusters de grande taille ou dynamiques, le volume de CSR peut croître rapidement. Sans planification délibérée de la capacité, vous pouvez vous retrouver avec un arriéré de CSR en attente. Cet arriéré peut empêcher de nouveaux nœuds de rejoindre le cluster, bloquer l'émission de jetons de compte de service et laisser les applications sans les informations d'identification dont elles ont besoin. Ce guide vous propose une approche pratique, étape par étape, pour estimer le volume de CSR, configurer le gestionnaire de contrôleurs en fonction de votre charge de travail, surveiller les signaux de mise à l'échelle et maintenir des marges de sécurité. À la fin, vous serez en mesure de planifier, vérifier et exploiter la capacité de CSR pour vos clusters en toute confiance.

Le traitement des CSR est un chemin critique pour les opérations du cluster. Lorsqu'il fonctionne, tout démarre et s'authentifie sans accroc. Lorsqu'il échoue, les symptômes sont souvent déroutants : nœuds bloqués en NotReady, pods qui ne démarrent pas ou erreurs d'authentification mystérieuses. Ce guide se concentre sur l'API CertificateSigningRequest de Kubernetes, les contrôleurs qui approuvent et signent ces demandes, et comment les dimensionner correctement.

Inventaire des versions et de l'environnement

Avant de calculer la capacité, documentez votre environnement Kubernetes. L'API CSR et le comportement des contrôleurs ont évolué au fil des versions. Ce guide suppose Kubernetes v1.22 ou version ultérieure, où l'API CertificateSigningRequest est stable sous certificates.k8s.io/v1. Si vous utilisez une version plus ancienne, effectuez d'abord une mise à niveau ou consultez la documentation pertinente, car les noms de signataires et les options des contrôleurs diffèrent.

Composants clés impliqués dans le traitement des CSR

Plusieurs composants participent au traitement des CSR. Comprendre chacun d'eux vous aide à savoir où chercher en cas de problème.

Pour vérifier la version de votre cluster, exécutez :

kubectl version --short

Sortie attendue :

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

Enregistrez les éléments suivants dans votre plan de capacité :

• Nombre de nœuds et taux de rotation prévu des nœuds (par exemple, 5 nœuds remplacés par jour en raison de l'autoscaling).
• Durées de vie des certificats utilisées (la valeur par défaut est souvent 8760h = 1 an pour les certificats client kubelet, mais vérifiez les options de votre gestionnaire de contrôleurs).
• Taux prévu de CSR de jetons de compte de service si vous utilisez l'ancien contrôleur de jetons (la plupart des clusters modernes utilisent des jetons projetés à la place, donc ce taux peut être nul).
• Tout flux de travail CSR personnalisé, tel qu'un approbateur externe qui signe les CSR pour les certificats utilisateur.

Ces informations alimentent directement votre estimation de capacité dans la section suivante.

Chemin de configuration sûr

Le gestionnaire de contrôleurs possède plusieurs options qui affectent directement le débit des CSR. Configurez-les délibérément après avoir compris votre charge attendue.

Options de base pour le traitement des CSR

La concurrence est souvent le premier levier à ajuster. La valeur par défaut de 5 travailleurs est suffisante pour les petits clusters, mais si vous avez des milliers de nœuds qui renouvellent leurs certificats quotidiennement, vous devrez peut-être l'augmenter. Cependant, une concurrence accrue consomme plus de CPU et de mémoire ; vous devez donc l'associer à des demandes de ressources adéquates.

Exemple de configuration du gestionnaire de contrôleurs

Voici un extrait de la spécification du pod kube-controller-manager d'un cluster géré par kubeadm. En production, ces options se trouvent généralement dans /etc/kubernetes/manifests/kube-controller-manager.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --cluster-signing-duration=8760h
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --controllers=*,bootstrapsigner,tokencleaner
    - --concurrent-csr-signers=10
    image: registry.k8s.io/kube-controller-manager:v1.27.3
    resources:
      requests:
        cpu: 250m
        memory: 256Mi
      limits:
        cpu: 500m
        memory: 512Mi

Cette configuration augmente la concurrence à 10 et définit des demandes de ressources explicites. Commencez prudemment et augmentez en fonction de la latence observée, pas seulement du nombre de CSR en attente.

Estimation du volume de CSR

La planification de la capacité commence par une estimation réaliste du nombre de CSR que votre cluster générera par jour. Une formule simple pour les CSR de nœuds :

CSR de nœuds quotidiens = Nombre de nœuds / (durée de vie du certificat en jours x facteur de renouvellement)

Le facteur de renouvellement est la fraction de la durée de vie à laquelle les nœuds renouvellent généralement leur certificat. Kubelet renouvelle son certificat client à 80 % de la durée de vie par défaut, donc le facteur est de 0,8. Par exemple :

• 1000 nœuds
• Durée de vie du certificat de 30 jours
• Renouvellement à 80 % = 24 jours

CSR quotidiens = 1000 / (30 x 0,8) = 1000 / 24 ≈ 41,7 CSR par jour

Cela signifie environ 42 CSR par jour uniquement pour les renouvellements de certificats de nœuds. Ajoutez les demandes de certificats utilisateur et les éventuels CSR de jetons de compte de service. Les demandes de certificats utilisateur varient considérablement ; dans un cluster d'entreprise très actif, vous pourriez voir 10 à 20 CSR supplémentaires par jour. Dans un cluster utilisant des jetons de compte de service hérités, chaque nouveau pod pourrait déclencher un CSR de jeton, mais ce modèle est déconseillé au profit des jetons projetés.

Mesurez le taux réel à l'aide de l'API Kubernetes. La commande suivante compte les CSR créés au cours des dernières 24 heures (nécessite jq et date) :

kubectl get csr -o json | jq '[.items[] | select(.metadata.creationTimestamp > (now - 86400 | strftime("%Y-%m-%dT%H:%M:%SZ")))] | length'

Comparez votre estimation à la valeur mesurée. Si le taux mesuré est nettement supérieur, recherchez les sources de CSR que vous auriez pu négliger, comme un renouvellement fréquent des nœuds ou un composant défaillant.

Définition des demandes et limites de ressources

Une fois que vous connaissez le taux de CSR, dimensionnez le gestionnaire de contrôleurs de manière appropriée. Une référence pour une charge modérée (environ 50 CSR par jour) est de 100m de CPU et 128Mi de mémoire. Pour des taux plus élevés ou une concurrence plus importante, augmentez les ressources. L'opération de signature est gourmande en CPU en raison des opérations cryptographiques ; surveillez donc l'étranglement du CPU. Si le gestionnaire de contrôleurs est constamment limité, augmentez sa demande de CPU.

Utilisez la requête Prometheus suivante pour surveiller l'étranglement du CPU :

rate(container_cpu_cfs_throttled_seconds_total{namespace="kube-system", pod=~"kube-controller-manager.*"}[5m])

Si le résultat est constamment supérieur à 0, le conteneur est limité. Augmentez la demande de CPU ou réduisez la concurrence.

Approche de mise à l'échelle progressive

Ne passez pas de la valeur par défaut à la concurrence maximale d'un seul coup. Augmentez progressivement tout en surveillant le nombre de CSR en attente et la latence de signature. Une approche sûre :

1. Commencez avec la valeur par défaut --concurrent-csr-signers=5.
2. Surveillez le nombre de CSR en attente et la latence de signature pendant une semaine.
3. Si le nombre de CSR en attente augmente ou si la latence dépasse votre objectif de niveau de service (par exemple, 1 seconde), augmentez la concurrence de 2.
4. Répétez jusqu'à ce que le nombre de CSR en attente reste proche de zéro et que la latence soit stable.

Le gestionnaire de contrôleurs exécute également d'autres contrôleurs ; une concurrence excessive sur la signature des CSR peut donc affamer les autres contrôleurs. Utilisez des instances de gestionnaire de contrôleurs séparées si vous devez isoler des charges de travail CSR lourdes, mais cela constitue une configuration avancée.

Vérification et diagnostic

Après la configuration, vérifiez que le traitement des CSR fonctionne de bout en bout, puis mettez en place la surveillance et les alertes.

Test de bout en bout

Créez un CSR de test pour confirmer l'ensemble du flux : création, approbation, signature et récupération. Utilisez openssl pour générer une clé et un CSR, puis soumettez-le via kubectl.

# Générer une clé privée
openssl genrsa -out test.key 2048

# Créer un CSR avec le sujet CN=test-user
openssl req -new -key test.key -out test.csr -subj "/CN=test-user"

# Encoder en base64 le CSR et créer l'objet CSR Kubernetes
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: test-csr
spec:
  request: $(cat test.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
EOF

Approuvez le CSR et vérifiez son statut :

kubectl certificate approve test-csr
kubectl get csr test-csr

Sortie attendue :

NAME       AGE   SIGNERNAME                      REQUESTOR          CONDITION
test-csr   10s   kubernetes.io/kube-apiserver-client   user           Approved,Issued

Si le CSR reste en attente, inspectez les journaux du gestionnaire de contrôleurs :

kubectl logs -n kube-system -l component=kube-controller-manager | grep -i csr

Recherchez des messages d'erreur tels que failed to sign CSR, no signer found ou certificate key mismatch. Ceux-ci indiquent des problèmes de configuration.

Métriques de surveillance et alertes

Le gestionnaire de contrôleurs expose des métriques via le port sécurisé (10257 par défaut). Métriques clés pour la planification de la capacité des CSR :

Exemple de règle d'alerte Prometheus :

groups:
- name: csr-alerts
  rules:
  - alert: HighPendingCSRs
    expr: csr_controller_manager_pending_csrs > 10
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Nombre élevé de CSR en attente"
      description: "{{ $value }} CSR sont en attente depuis plus de 5 minutes."

Créez un tableau de bord affichant les CSR en attente, la latence de signature et le taux de création de CSR. Examinez-le chaque semaine.

Modes de défaillance et récupération

Malgré la planification, des défaillances surviennent. Connaissez les modes de défaillance courants et comment récupérer rapidement.

Nombre élevé de CSR en attente

Cause : Le gestionnaire de contrôleurs ne peut pas suivre le taux de CSR entrants. Cela peut être dû à un CPU insuffisant, une concurrence faible ou un arriéré après une panne.

Récupération :

1. Vérifiez le nombre de CSR en attente :

kubectl get csr --field-selector=status.certificate="" | wc -l

1. S'il est élevé, augmentez les ressources du gestionnaire de contrôleurs et --concurrent-csr-signers comme décrit précédemment.
2. Vérifiez les journaux du gestionnaire de contrôleurs pour détecter les erreurs.
3. Si l'arriéré est dû à une rafale temporaire (par exemple, de nombreux nœuds ont redémarré simultanément), vous pouvez approuver manuellement les CSR pour aider à vider la file d'attente :

kubectl get csr -o name | xargs kubectl certificate approve

Utilisez l'approbation manuelle avec prudence ; elle contourne les contrôles d'autorisation normaux.

Échecs de signature

Cause : Le certificat de signature ou le fichier de clé est manquant, invalide ou a des permissions incorrectes. Cela se produit souvent après une rotation de l'autorité de certification.

Récupération :

1. Vérifiez les journaux du gestionnaire de contrôleurs pour détecter les erreurs de signature.
2. Vérifiez que les fichiers existent et sont lisibles par le processus du gestionnaire de contrôleurs :

ls -l /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/ca.key

1. Si l'autorité de certification a été renouvelée, mettez à jour les options --cluster-signing-cert-file et --cluster-signing-key-file pour pointer vers la nouvelle autorité de certification.
2. Redémarrez le gestionnaire de contrôleurs.

Stockage etcd plein

Cause : Les anciens CSR s'accumulent et consomment de l'espace etcd. Cela peut entraîner une dégradation des performances ou une défaillance d'etcd.

Récupération :

1. Vérifiez l'utilisation du stockage etcd.
2. Supprimez les anciens CSR. La commande suivante supprime les CSR de plus de 24 heures (nécessite date et xargs) :

kubectl get csr -o json | jq -r '.items[] | select(.metadata.creationTimestamp < (now - 86400 | strftime("%Y-%m-%dT%H:%M:%SZ"))) | .metadata.name' | xargs kubectl delete csr

1. Mettez en place une politique de rétention. Un simple CronJob peut supprimer les CSR de plus de N jours. Exemple de manifeste CronJob :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: csr-cleanup
  namespace: kube-system
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: csr-cleanup
          containers:
          - name: cleanup
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              kubectl get csr -o json | jq -r '.items[] | select(.metadata.creationTimestamp < (now - 172800 | strftime("%Y-%m-%dT%H:%M:%SZ"))) | .metadata.name' | xargs -r kubectl delete csr
          restartPolicy: OnFailure

Ce CronJob nécessite un ServiceAccount avec les autorisations de suppression des CSR.

Procédure de restauration

Si un changement de configuration interrompt le traitement des CSR, revenez à la configuration précédente et redémarrez le gestionnaire de contrôleurs. Conservez toujours des sauvegardes du manifeste du gestionnaire de contrôleurs et des clés de signature. Dans les clusters kubeadm, le manifeste se trouve dans /etc/kubernetes/manifests/kube-controller-manager.yaml ; il suffit de restaurer le fichier précédent et le kubelet redémarrera automatiquement le pod.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour maintenir la santé des CSR. Attribuez un responsable pour chaque élément et une fréquence de révision.

Pour chaque élément, le responsable est chargé d'accomplir la tâche et de signaler les anomalies. La fréquence de révision doit être ajustée en fonction de la maturité du cluster ; un cluster en croissance rapide peut nécessiter des révisions plus fréquentes.

Commandes opérationnelles supplémentaires à inclure dans les scripts :

# Compter les CSR en attente
kubectl get csr --field-selector=status.certificate="" | wc -l

# Lister les CSR triés par heure de création (les plus anciens en premier)
kubectl get csr --sort-by=.metadata.creationTimestamp

# Afficher les détails des CSR avec leur statut
kubectl get csr -o custom-columns=NAME:.metadata.name,AGE:.metadata.creationTimestamp,CONDITION:.status.conditions[*].type

Documentez votre plan de capacité et mettez-le à jour après des changements importants du cluster, comme l'ajout de nombreux nœuds, la modification des durées de vie des certificats ou l'activation de nouveaux flux de travail CSR.

Pièges courants et comment les éviter

Même les opérateurs Kubernetes expérimentés peuvent trébucher sur la planification de la capacité des CSR. Voici les pièges les plus courants et comment les éviter.

Piège 1 : Ignorer le renouvellement des nœuds dans les estimations de capacité

De nombreuses équipes calculent le volume de CSR en fonction du nombre de nœuds en régime permanent, en oubliant que les remplacements de nœuds génèrent des CSR. Par exemple, un cluster de 1000 nœuds avec une durée de vie de certificat de 30 jours génère environ 42 CSR par jour, mais si vous remplacez également 50 nœuds par jour en raison de l'autoscaling ou des instances spot, vous ajoutez 50 CSR supplémentaires par jour, ce qui double presque la charge. Incluez toujours le renouvellement dans votre estimation.

Comment éviter : Suivez les taux de création et de suppression des nœuds pendant une semaine. Ajoutez le nombre quotidien de renouvellements à votre estimation de CSR. Si le renouvellement est élevé, envisagez des durées de vie de certificat plus longues pour réduire la fréquence de renouvellement.

Piège 2 : Définir une concurrence trop élevée sans marge de ressources

Augmenter aveuglément --concurrent-csr-signers peut affamer les autres contrôleurs. Le gestionnaire de contrôleurs exécute des dizaines de contrôleurs, et la signature des CSR est gourmande en CPU. Si vous définissez la concurrence à 20 sur un gestionnaire de contrôleurs avec seulement 100m de CPU, vous verrez un étranglement du CPU et des retards sur tous les contrôleurs, car le gestionnaire est un processus unique.

Comment éviter : Surveillez l'utilisation du CPU de l'ensemble du gestionnaire de contrôleurs, pas seulement les métriques spécifiques aux CSR. N'augmentez la concurrence qu'après avoir confirmé une marge de CPU. Utilisez des instances de gestionnaire de contrôleurs séparées si vous devez isoler des charges de travail lourdes.

Piège 3 : Ne pas configurer d'alertes pour les CSR en attente

Un afflux soudain de CSR peut passer inaperçu jusqu'à ce que les nœuds ne parviennent pas à rejoindre le cluster. Sans alertes, vous ne découvrirez peut-être le problème que lorsque les utilisateurs se plaindront. Par exemple, une partition réseau qui empêche le gestionnaire de contrôleurs d'atteindre le serveur d'API peut provoquer silencieusement un arriéré de CSR en attente.

Comment éviter : Configurez une alerte Prometheus pour csr_controller_manager_pending_csrs > 10 pendant plus de 5 minutes. Alertez également sur les redémarrages du processus du gestionnaire de contrôleurs, car un plantage peut interrompre le traitement des CSR.

Piège 4 : Ne pas nettoyer les anciens CSR

Les objets CSR s'accumulent indéfiniment s'ils ne sont pas supprimés. Au fil des mois, cela peut consommer un espace etcd important et ralentir les requêtes API. Dans un cas réel, un cluster avait plus de 100 000 CSR dans etcd, provoquant des pics de latence de l'API.

Comment éviter : Mettez en place une politique de rétention à l'aide d'un CronJob comme indiqué précédemment. Supprimez les CSR de plus de 48 heures comme point de départ.

Piège 5 : Supposer que la durée de vie par défaut des certificats est optimale

La valeur par défaut de --cluster-signing-duration est de 8760h (1 an). Des durées de vie longues signifient moins de renouvellements mais aussi une exposition plus longue en cas de compromission d'une clé. Pour les clusters à fort renouvellement, des durées de vie plus courtes peuvent augmenter inutilement la charge de CSR. Équilibrez sécurité et capacité.

Comment éviter : Évaluez vos exigences de sécurité et votre capacité opérationnelle. Par exemple, si vos nœuds sont éphémères (autoscaling), une durée de vie de 30 jours peut être plus appropriée. Recalculez le volume de CSR lors de la modification des durées de vie.

Piège 6 : Ne pas tester le flux de CSR après les mises à niveau

Les mises à niveau de Kubernetes peuvent modifier les noms de signataires par défaut ou les options des contrôleurs. Après une mise à niveau, votre flux de travail CSR existant peut se briser silencieusement. Par exemple, le nom de signataire kubernetes.io/kube-apiserver-client pourrait être déprécié au profit d'un nouveau.

Comment éviter : Incluez un test de bout en bout des CSR dans votre liste de vérification post-mise à niveau. Exécutez les étapes de création et d'approbation du CSR de test manuellement ou via un script automatisé.

Conclusion

La planification de la capacité pour les demandes de signature de certificats Kubernetes n'est pas une tâche ponctuelle. À mesure que votre cluster grandit et évolue, vous devez revoir vos hypothèses. Commencez par documenter votre environnement et estimer un volume de CSR réaliste. Configurez le gestionnaire de contrôleurs avec la concurrence et les ressources appropriées en fonction de cette estimation. Vérifiez avec un test de bout en bout et mettez en place la surveillance et les alertes pour les CSR en attente et la latence de signature. Préparez-vous aux modes de défaillance courants tels que les nombres élevés de CSR en attente, les échecs de signature et le gonflement d'etcd. Suivez la liste de contrôle opérationnelle avec des responsabilités claires et des fréquences de révision. Enfin, évitez les pièges qui font trébucher de nombreuses équipes en tenant compte du renouvellement des nœuds, en faisant évoluer les ressources avec la concurrence et en nettoyant régulièrement les anciens CSR. Grâce à ces pratiques, vous pouvez maintenir l'émission de certificats de votre cluster fiable et réactive, même à grande échelle.