Chart Helm KEDA : installation, configuration et exploitation

Le chart Helm KEDA est la méthode officielle pour installer KEDA, l'autoscaler événementiel de Kubernetes (Kubernetes Event-Driven Autoscaler), dans votre cluster. Une seule commande helm install déploie tout ce dont KEDA a besoin pour dimensionner vos workloads en fonction d'événements : l'opérateur, le serveur de métriques, les webhooks d'admission et les ressources personnalisées qui vous permettent de définir vos règles de scaling.

Ce guide passe le chart en revue en profondeur. Vous découvrirez ce qu'il déploie, comment l'installer et le vérifier, les paramètres clés de values.yaml, comment exécuter KEDA en haute disponibilité, comment le sécuriser et le superviser, comment le gérer via GitOps, et comment le mettre à jour ou le désinstaller sans laisser de ressources orphelines derrière vous.

Sécuriser l'installation

Deux réglages permettent de renforcer la sécurité de KEDA en production : la limitation de l'accès aux secrets et la gestion des certificats. Voyons cela :

a. Limiter l'accès aux secrets : par défaut, KEDA peut lire les secrets dans tous les namespaces qu'il surveille. Les paramètres permissions.operator vous permettent de restreindre cet accès afin que l'opérateur ne puisse lire que les secrets de son propre namespace de release, ou uniquement certains secrets nommés. Cela réduit les données auxquelles un opérateur compromis pourrait accéder.

b. Gérer les certificats : KEDA génère ses propres certificats auto-signés, les stocke dans un secret nommé kedaorg-certs et les monte dans ses composants. KEDA effectue également la rotation automatique de ces certificats et met à jour les ressources Kubernetes nécessaires pour qu'ils soient approuvés.

c. Si votre organisation exige des certificats issus d'une autorité de certification gérée, activez certificates.certManager.enabled afin que cert-manager émette et renouvelle les certificats à la place de KEDA. Pour la plupart des installations, les certificats générés automatiquement suffisent.

Déployer le chart via GitOps

Si vous gérez votre cluster avec Argo CD ou Flux, vous pouvez déployer le chart KEDA via GitOps. Le point de vigilance principal, ce sont les CRD.

Les CRD de KEDA sont volumineuses, et un apply Kubernetes classique peut échouer parce que l'annotation générée devient trop grande. Pour éviter cela, configurez votre outil GitOps de manière à remplacer les CRD plutôt que de les fusionner. Dans Flux : définissez crds: CreateReplace dans la HelmRelease. Dans Argo CD : utilisez Replace=true ou le server-side apply pour les CRD afin qu'elles soient appliquées correctement.

Si les CRD ne sont pas configurées correctement, l'installation de KEDA gérée par GitOps peut échouer.

Vous pouvez également utiliser helm template pour générer le chart sous forme de fichiers YAML Kubernetes classiques et versionner ces fichiers dans Git, si votre workflow privilégie la gestion de manifests rendus plutôt qu'une release Helm active.

Quelle que soit l'approche retenue, gardez le label app.kubernetes.io/managed-by cohérent afin que votre outil GitOps et Helm n'entrent pas en conflit sur la propriété des ressources.

Créer votre premier ScaledObject après l'installation

Une fois KEDA installé, un ScaledObject vous permet de vérifier que KEDA peut réellement dimensionner un workload. L'exemple ci-dessous utilise un trigger cron, qui ne nécessite donc aucun système externe. Il augmente le nombre de réplicas d'un Deployment pendant une plage horaire planifiée, puis le réduit lorsque la plage se termine.

Créez d'abord un Deployment à dimensionner, puis appliquez le ScaledObject :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: nginx-cron
  namespace: default
spec:
  scaleTargetRef:
    name: nginx
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 5
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Kolkata
        start: 0 9 * * *
        end: 0 17 * * *
        desiredReplicas: "5"

pollingInterval indique à KEDA la fréquence, en secondes, de vérification du trigger. minReplicaCount: 0 active le scale-to-zero. En dehors de la plage 9 h – 17 h, le Deployment peut descendre à zéro pod. Pendant la plage planifiée, il monte à cinq réplicas.

Appliquez le ScaledObject et vérifiez ce que KEDA a créé :

kubectl get scaledobject
kubectl get hpa

Vous devriez voir un HPA nommé keda-hpa-nginx-cron. KEDA crée et gère ce HPA pour effectuer le scaling proprement dit. Cela confirme que KEDA est bien connecté au workload et que la configuration de scaling planifié fonctionne.

Superviser l'installation de KEDA

Une fois KEDA en fonctionnement, vérifiez qu'il est en bonne santé et se comporte comme prévu.
KEDA expose des métriques Prometheus pour l'opérateur comme pour le serveur de métriques. Ces métriques montrent l'activité des scalers, les erreurs et les valeurs remontées par KEDA.

Si vous utilisez le Prometheus Operator, le chart KEDA peut créer un ServiceMonitor pour le serveur de métriques et un PodMonitor pour l'opérateur. Vous pouvez les activer via les paramètres prometheus dans values.yaml, afin que Prometheus collecte les métriques automatiquement.

Les logs de l'opérateur sont également précieux quand un ScaledObject précis ne fonctionne pas comme prévu. Ils montrent comment le scaler lit son trigger et les erreurs qu'il rencontre.

Vous pouvez consulter les logs de l'opérateur avec :

kubectl logs -n keda deploy/keda-operator

Le right-sizing des workloads dimensionnés par KEDA

KEDA excelle à ajuster le nombre de pods en fonction de la demande. Mais il ne décide pas de la quantité de CPU et de mémoire que chaque pod doit demander.

Ajouter des réplicas ne corrige pas des requests de ressources mal calibrées. Si chaque pod demande beaucoup plus de CPU ou de mémoire qu'il n'en utilise réellement, KEDA peut multiplier ce gaspillage à mesure qu'il ajoute des réplicas. Si chaque pod en demande trop peu, les nouveaux réplicas risquent d'être OOMKilled ou de subir du throttling CPU quand le trafic augmente.

C'est là que les outils d'optimisation des ressources entrent en jeu. PerfectScale observe l'utilisation réelle du CPU et de la mémoire par vos workloads et fournit des recommandations de right-sizing automatisées, applicables manuellement ou automatiquement.

En l'associant à KEDA, vous couvrez les deux volets de l'autoscaling : KEDA ajuste le nombre de pods en fonction de la demande, tandis que PerfectScale veille à ce que chaque pod dispose de la juste quantité de CPU et de mémoire. Cela contribue à éviter le sur-provisionnement tout en préservant la fiabilité des workloads. Vous pouvez l'essayer ou réserver une session technique.

D'autres outils existent : le Vertical Pod Autoscaler (VPA), qui peut ajuster les requests de ressources selon l'utilisation, Goldilocks, qui aide à visualiser les recommandations du VPA, et Karpenter, qui se concentre sur le choix et la gestion des nœuds exécutant vos workloads.

Mettre à jour et désinstaller le chart

Quelques points importants sont à vérifier lors de la mise à jour ou de la désinstallation de KEDA.

Pour mettre à jour KEDA, actualisez d'abord le dépôt Helm, puis effectuez la mise à niveau vers une version de chart épinglée :

helm repo update
helm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>

Le point à surveiller pendant une mise à jour, ce sont les CRD. Comme le chart les gère, un helm upgrade les met à jour avec le reste, mais les versions mineures de KEDA modifient parfois des champs de CRD ou le comportement des scalers. Lisez donc les notes de version avant de mettre à jour un cluster de production, et vérifiez que la nouvelle version de KEDA prend toujours en charge votre version de Kubernetes.

La désinstallation de KEDA demande également de la prudence, car sa suppression peut laisser des ressources derrière elle.

Supprimez d'abord les ressources ScaledObject et ScaledJob :

kubectl delete scaledobject --all --all-namespaces
kubectl delete scaledjob --all --all-namespaces

Puis désinstallez la release Helm :

helm uninstall keda --namespace keda

Supprimer d'abord les ressources ScaledObject et ScaledJob permet à KEDA de nettoyer les HPA qu'il a créés. Cela donne aussi aux workloads réduits à zéro la possibilité de retrouver leur nombre normal de réplicas avant la suppression de KEDA.

Si une ressource reste bloquée en cours de suppression à cause d'un finalizer, vous pouvez le retirer avec :

kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=merge

Résoudre les problèmes courants du chart

Deux problèmes fréquents sont à examiner quand KEDA ne dimensionne pas comme prévu :

a. L'API de métriques externes est indisponible ou la vérification TLS échoue : si kubectl get apiservice v1beta1.external.metrics.k8s.io n'affiche pas Available, le HPA ne peut pas obtenir de métriques externes, et les workloads ne peuvent donc pas être dimensionnés sur cette base. Les causes courantes : un serveur de métriques défaillant, une NetworkPolicy bloquant le trafic, ou un proxy interférant avec la connexion entre le serveur d'API Kubernetes et le serveur de métriques. Vérifiez d'abord le pod du serveur de métriques. Si vous utilisez un proxy, assurez-vous que l'IP de cluster du serveur de métriques figure dans la liste no_proxy du serveur d'API.

b. Un ScaledObject est créé mais le nombre de réplicas ne change pas : commencez par kubectl describe scaledobject <name> et examinez son statut et ses événements. Consultez ensuite les logs de l'opérateur KEDA. Les causes possibles : un trigger mal configuré, une authentification manquante pour la source d'événements, ou un HPA existant ciblant déjà le même workload. Ce HPA existant peut entrer en conflit avec le HPA que KEDA crée et gère.

Bonnes pratiques pour exploiter le chart Helm KEDA

Les pratiques suivantes contribuent à maintenir une installation KEDA stable et sécurisée :

a. Épinglez la version du chart et associez-la à une version applicative de KEDA testée : n'installez pas et ne passez pas systématiquement à la dernière version disponible. Épinglez le chart, testez cette version de KEDA et déployez-la avec précaution, afin de toujours savoir ce qui tourne.

b. Gardez KEDA dans son propre namespace avec son propre quota de ressources : un namespace dédié isole KEDA et facilite l'application d'une ResourceQuota et d'une NetworkPolicy spécifiques à KEDA.

c. Définissez des requests et limits explicites sur les trois composants de KEDA : configurez des ressources appropriées pour l'opérateur, le serveur de métriques et les webhooks, afin que KEDA lui-même ne soit ni throttlé ni évincé quand le cluster est sous pression.

d. Utilisez TriggerAuthentication plutôt que de placer les identifiants directement dans un ScaledObject : gardez les identifiants hors de vos manifests ScaledObject en référençant une TriggerAuthentication ou une ClusterTriggerAuthentication. Cela évite de versionner des identifiants et permet de les réutiliser.

e. Évitez d'associer un ScaledObject à un HPA créé manuellement sur le même workload : deux contrôleurs qui tentent de dimensionner le même workload peuvent entrer en conflit. Laissez KEDA gérer le HPA des workloads qu'il dimensionne.

f. Testez les mises à jour dans un cluster hors production avant de les déployer : les versions mineures de KEDA peuvent inclure des changements de CRD ; testez donc la mise à jour dans un environnement sûr au préalable. Cela permet de détecter les problèmes de compatibilité avant qu'ils n'affectent les workloads de production.