Optimisation des performances des demandes de signature de certificats Kubernetes : guide pratique

Apprenez à identifier et corriger les goulots d'étranglement des performances des demandes de signature de certificats (CSR) Kubernetes. Ce guide couvre le dimensionnement des ressources, les vérifications de latence, le réglage du débit et des flux de travail d'optimisation sûrs avec des commandes concrètes et des sorties attendues.

Introduction

Les clusters Kubernetes reposent sur des certificats pour sécuriser les communications entre les composants. L'API CertificateSigningRequest (CSR) est le moyen standard d'obtenir des certificats signés par l'autorité de certification du cluster. Cependant, à mesure que les clusters grandissent, le pipeline CSR peut devenir un goulot d'étranglement des performances, provoquant des retards dans le démarrage des nœuds, l'émission d'identités de charge de travail et la rotation des certificats de maillage de services. Ce guide fournit des étapes pratiques pour régler les performances des CSR Kubernetes, depuis les mesures de référence jusqu'à l'optimisation et la vérification. En suivant ces étapes, vous pouvez réduire la latence, augmenter le débit et garantir une émission fiable des certificats sous charge.

Inventaire de la version et de l'environnement

Avant de procéder au réglage, documentez votre version de Kubernetes, la configuration du plan de contrôle et les modèles d'utilisation des CSR. L'API CSR fait partie du groupe d'API certificates.k8s.io, et son comportement peut varier selon les versions. Utilisez kubectl version pour vérifier les versions client et serveur :

$ kubectl version --short
Client Version: v1.28.2
Server Version: v1.28.2

Remarque : Dans les versions récentes de Kubernetes, le drapeau --short est obsolète ; utilisez kubectl version sans celui-ci pour obtenir tous les détails.

Identifiez la configuration du gestionnaire de contrôleurs, en particulier les drapeaux --cluster-signing-cert-file et --cluster-signing-key-file, qui déterminent l'autorité de certification utilisée pour signer les CSR. Vérifiez également le drapeau --cluster-signing-duration, qui définit la durée de vie par défaut des certificats. Vous pouvez afficher la spécification du pod du gestionnaire de contrôleurs ou le manifeste du pod statique :

$ kubectl get pod -n kube-system -l component=kube-controller-manager -o yaml | grep -E 'cluster-signing|kube-api'

La sortie attendue comprend des lignes telles que :

- --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
- --cluster-signing-duration=8760h
- --kube-api-qps=20
- --kube-api-burst=40

Évaluez votre charge de travail : les CSR sont-ils générés par le kubelet lors de l'enregistrement des nœuds, par cert-manager pour les certificats de webhook, ou par des contrôleurs personnalisés ? Le volume et la fréquence des CSR guideront les décisions de réglage. Par exemple, un cluster avec une mise à l'échelle automatique fréquente des nœuds aura un fort taux de renouvellement des CSR, nécessitant une approbation et une signature efficaces.

Enfin, établissez des mesures de performance de référence : mesurez la latence d'approbation et de signature des CSR, ainsi que le débit sous charge. Des outils comme kubectl get csr et kubectl certificate approve peuvent être utilisés pour des tests manuels, mais pour une analyse comparative systématique, envisagez d'utiliser un script qui génère plusieurs CSR et mesure le temps jusqu'à l'émission. Voici un script bash simple pour créer un CSR de test et mesurer le temps jusqu'à son approbation et son émission :

#!/bin/bash
# Générer une clé privée et un CSR
openssl req -new -newkey rsa:2048 -nodes -keyout test.key -out test.csr -subj "/CN=test-user/O=test-group"

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

# Enregistrer l'heure de début
START=$(date +%s%N)

# Approuver le CSR
CSR_NAME=$(kubectl get csr -o jsonpath='{.items[?(@.metadata.name=="test-csr-*")].metadata.name}' | tr ' ' '\n' | tail -1)
kubectl certificate approve $CSR_NAME

# Attendre que le CSR soit émis
while true; do
  CONDITION=$(kubectl get csr $CSR_NAME -o jsonpath='{.status.conditions[?(@.type=="Approved")].status}')
  if [ "$CONDITION" == "True" ]; then
    ISSUED=$(kubectl get csr $CSR_NAME -o jsonpath='{.status.certificate}')
    if [ -n "$ISSUED" ]; then
      END=$(date +%s%N)
      ELAPSED_MS=$(( (END - START) / 1000000 ))
      echo "CSR émis en ${ELAPSED_MS} ms"
      break
    fi
  fi
  sleep 0.1
done

Exécutez ce script plusieurs fois et enregistrez la latence moyenne. Pour le débit, exécutez le script en parallèle pour un nombre connu de demandes (par exemple, 100 CSR) et mesurez le temps total.

Chemin de configuration sûr

Commencez par des modifications ciblées et réversibles. Le gestionnaire de contrôleurs Kubernetes possède plusieurs drapeaux qui affectent les performances de signature des CSR. Les plus critiques sont :

• --cluster-signing-duration : durée de vie par défaut des certificats. Des durées plus courtes réduisent la fenêtre de compromission mais peuvent augmenter la fréquence de renouvellement. Pour les environnements à fort taux de rotation, une durée plus courte peut être acceptable.
• --kube-api-qps : la limite de débit pour les requêtes du gestionnaire de contrôleurs vers le serveur d'API. L'augmenter peut accélérer le traitement des CSR mais peut surcharger le serveur d'API.
• --kube-api-burst : la taille de rafale pour la limite de débit ci-dessus.

Exemple : Pour augmenter le QPS de l'API pour le gestionnaire de contrôleurs, modifiez son manifeste (par exemple, /etc/kubernetes/manifests/kube-controller-manager.yaml) et ajoutez ou modifiez les drapeaux :

spec:
  containers:
  - command:
    - kube-controller-manager
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --cluster-signing-duration=8760h
    - --kube-api-qps=100
    - --kube-api-burst=200

Après modification, le gestionnaire de contrôleurs redémarrera automatiquement. Surveillez ses journaux pour détecter d'éventuelles erreurs.

Si vous utilisez un signataire externe comme cert-manager, réglez plutôt les ressources de son contrôleur et les limites de débit de l'API. Effectuez toujours une modification à la fois et mesurez avant et après.

Pour cert-manager, vous pouvez ajuster les ressources dans le déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  template:
    spec:
      containers:
      - name: cert-manager
        resources:
          requests:
            cpu: 100m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

De plus, cert-manager possède sa propre limitation de débit pour ACME et d'autres émetteurs ; consultez sa documentation pour un réglage fin.

Vérification et diagnostics

Après le réglage, vérifiez que les CSR sont traités correctement et observez les améliorations de performance. Utilisez kubectl get csr pour lister les CSR en attente et vérifier leurs conditions :

$ kubectl get csr
NAME        AGE   SIGNERNAME                            REQUESTOR          CONDITION
csr-abcde   10s   kubernetes.io/kube-apiserver-client   kubelet-bootstrap   Pending

Approuvez un CSR manuellement :

$ kubectl certificate approve csr-abcde
certificatesigningrequest.certificates.k8s.io/csr-abcde approved

Vérifiez ensuite son statut :

$ kubectl get csr csr-abcde
NAME        AGE   SIGNERNAME                            REQUESTOR          CONDITION
csr-abcde   30s   kubernetes.io/kube-apiserver-client   kubelet-bootstrap   Approved,Issued

Pour mesurer la latence, enregistrez le temps entre la création du CSR et son émission. Pour les tests automatisés, créez un YAML de CSR et soumettez-le en notant l'horodatage. Approuvez ensuite et observez le temps jusqu'à la condition Issued. Par exemple, en utilisant le script ci-dessus, vous pourriez obtenir :

CSR émis en 150 ms

Pour le débit, générez plusieurs CSR simultanément à l'aide d'un script et mesurez le taux auquel ils sont émis. Attendez-vous à des améliorations si vous avez augmenté le QPS de l'API ou réduit la durée de signature. Comparez avec les mesures de référence collectées précédemment.

De plus, vérifiez les journaux du gestionnaire de contrôleurs pour toute limitation de débit ou erreur :

$ kubectl logs -n kube-system kube-controller-manager-<node> | grep -i csr

Recherchez des messages tels que « Failed to sign CSR » ou « Error updating CSR status ».

Modes de défaillance et récupération

Le réglage des performances des CSR peut introduire des risques. Modes de défaillance courants :

• Surcharge du serveur d'API : Augmenter trop les limites de débit peut amener le gestionnaire de contrôleurs à submerger le serveur d'API, affectant d'autres contrôleurs. Surveillez la latence du serveur d'API et les taux d'erreur. Si cela se produit, revenez sur les modifications de QPS/burst.
• Expiration des certificats : Réduire --cluster-signing-duration peut entraîner l'expiration des certificats avant leur renouvellement. Assurez-vous que des mécanismes de renouvellement sont en place, comme le renouvellement automatique du kubelet ou cert-manager. Si des certificats expirent prématurément, faites pivoter manuellement les certificats concernés et ajustez la durée.
• Inadéquation de la clé de signature : Changer la clé de signature peut invalider les certificats existants. Ne changez jamais la clé de l'autorité de certification sans un plan de migration. En cas de changement accidentel, restaurez la clé d'origine à partir de la sauvegarde et redémarrez le gestionnaire de contrôleurs.
• Retard d'approbation des CSR : Si l'approbation est manuelle, un arriéré peut se développer. Envisagez d'utiliser un approbateur automatique pour les signataires bien connus, tels que les certificats clients kubelet, avec des restrictions RBAC appropriées.

Retour en arrière : Étant donné que les modifications se trouvent souvent dans les drapeaux du gestionnaire de contrôleurs, revenez à la configuration précédente pour restaurer le comportement d'origine. Conservez une sauvegarde du manifeste avant de le modifier. Pour cert-manager, revenez sur la version Helm ou les modifications du manifeste.

Vérifications de récupération : Après le retour en arrière, vérifiez que les CSR sont émis normalement en créant un CSR de test et en vérifiant qu'il atteint l'état Issued dans le délai attendu. Surveillez la santé du cluster pour les erreurs du serveur d'API.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les examens réguliers des performances des CSR et après tout changement de réglage :

• [ ] Vérifier la version de Kubernetes et les drapeaux du gestionnaire de contrôleurs.
• [ ] Mesurer la latence et le débit de référence des CSR.
• [ ] Identifier les sources de CSR et les modèles de volume.
• [ ] Vérifier l'arriéré de CSR en attente.
• [ ] Examiner l'utilisation des ressources du serveur d'API et du gestionnaire de contrôleurs.
• [ ] S'assurer que les mécanismes de renouvellement des certificats sont fonctionnels.
• [ ] Tester l'émission de CSR avec une demande d'exemple.
• [ ] Surveiller les journaux pour les erreurs de signature.
• [ ] Documenter tout changement de réglage et ses effets.
• [ ] Planifier une réévaluation périodique, surtout après les mises à niveau du cluster ou les changements de charge de travail.

Conclusion

Le réglage des performances des CSR Kubernetes nécessite une approche méthodique : établir une référence, apporter des modifications de configuration incrémentales, vérifier les améliorations et disposer d'un plan de retour en arrière. En suivant les étapes pratiques de ce guide, vous pouvez réduire la latence d'émission des certificats, augmenter le débit et éviter les pièges courants. N'oubliez pas de surveiller en continu et d'ajuster à mesure que votre cluster évolue. Avec un pipeline CSR bien réglé, la sécurité et les opérations de votre Kubernetes fonctionneront plus facilement.