Créer des API Kubernetes dynamiques sans contrôleurs personnalisés

Dans un article publié sur le blog Kubernetes en novembre 2024, Andrei Kvapil d'Ænix a détaillé comment son équipe a construit un serveur d'API d'extension dynamique pour Cozystack. L'article explore l'implémentation technique de la couche d'agrégation de l'API Kubernetes, en la comparant aux définitions de ressources personnalisées (CRD) standard et aux opérateurs.

Ce qui s'est passé

Kvapil a expliqué que si la plupart des extensions Kubernetes reposent sur les CRD et les contrôleurs, cette approche présente des limites pour certains cas d'utilisation spécifiques. Les opérateurs standards excellent dans la réconciliation déclarative de l'état, mais peinent avec la logique impérative, la génération de données en temps réel ou les exigences de validation complexes. Pour combler ces lacunes, l'équipe de Cozystack a mis en œuvre un serveur d'API d'extension personnalisé qui s'intègre directement au framework de l'API Kubernetes via la couche d'agrégation.

Le cœur de cette implémentation consiste à enregistrer un objet APIService au sein du cluster. Cet enregistrement indique au serveur principal de l'API Kubernetes de proxifier les requêtes destinées à des groupes de ressources spécifiques vers le serveur d'extension externe. Dans le cas de Cozystack, cela a permis à la plateforme d'exposer dynamiquement de nouveaux types de ressources basés sur les charts Helm disponibles, sans nécessiter de modifications de code ni de recompilation. Le système associe des types conviviaux, tels que Postgres ou Redis, directement aux releases Helm sous-jacentes, abstrayant ainsi la complexité pour les utilisateurs finaux.

Cette approche a également résolu des défis importants liés au RBAC. Le contrôle d'accès basé sur les rôles (RBAC) standard de Kubernetes ne peut pas filtrer les opérations de liste par étiquettes ou champs de spécification spécifiques, mais uniquement par noms de ressources. En générant des types de ressources distincts pour chaque type de service, Cozystack a pu exploiter les politiques RBAC natives pour restreindre l'accès avec précision. De plus, le serveur d'extension gère la conversion bidirectionnelle entre les nouveaux types personnalisés et les ressources internes HelmRelease, garantissant la compatibilité ascendante avec les tableaux de bord et outils existants.

Comment cela fonctionne

La couche d'agrégation de l'API agit comme un proxy au sein du plan de contrôle Kubernetes. Lorsqu'un utilisateur envoie une requête à l'API Kubernetes pour un groupe de ressources servi par une extension, le serveur API principal transmet cette requête au serveur d'API d'extension. Ce serveur fonctionne indépendamment des composants principaux du plan de contrôle et peut mettre en œuvre sa propre logique métier, ses propres validations et mécanismes de stockage.

Contrairement aux contrôleurs standards qui synchronisent l'état dans etcd, un serveur d'API d'extension peut générer des réponses à la volée. Cela est similaire au fonctionnement du metrics-server, qui récupère des données en temps réel depuis les Kubelets plutôt que de les stocker. Dans le cas de Cozystack, le serveur découvre dynamiquement les services disponibles et les enregistre en tant que ressources API. Il valide les entrées, les convertit en objets HelmRelease et les soumet au cluster, tout en maintenant une séparation nette entre l'API exposée à l'utilisateur et l'implémentation interne.

Détails clés

• La couche d'agrégation de l'API permet aux serveurs d'extension de gérer la logique impérative et les sous-ressources telles que /exec ou /log.
• Les API d'extension sont enregistrées via un objet APIService, qui dirige le trafic des groupes d'API spécifiques vers le serveur externe.
• Contrairement aux CRD, les serveurs d'extension n'ont pas besoin de stocker l'état dans etcd, ce qui permet la génération de données en temps réel et réduit la charge de stockage.
• Cozystack utilise ce modèle pour mapper dynamiquement des types de services comme Postgres vers les charts Helm sous-jacents sans recompiler le code.
• L'implémentation prend en charge la validation complexe côté serveur et le formatage personnalisé des sorties tabulaires, allant au-delà des capacités des CRD.
• Des serveurs d'extension instables peuvent bloquer la suppression des espaces de noms ou augmenter la latence de l'API, la fiabilité est donc cruciale.

Pourquoi c'est important

Pour les ingénieurs de plateforme, comprendre la couche d'agrégation ouvre la voie à des modèles de conception difficiles ou impossibles à réaliser uniquement avec les CRD. Elle permet la création d'API qui se comportent comme des ressources Kubernetes natives, mais fonctionnent avec une logique impérative ou des backends externes. C'est particulièrement utile pour intégrer des systèmes hérités, exposer des métriques en temps réel ou créer des interfaces simplifiées pour des applications complexes.

Cependant, cette puissance comporte des risques opérationnels. Si un serveur d'API d'extension devient indisponible, il peut dégrader les performances de l'ensemble du cluster. Des opérations comme la suppression d'un espace de noms peuvent rester bloquées en attendant que l'extension confirme le nettoyage des ressources. Les ingénieurs doivent peser les avantages d'un comportement d'API personnalisé contre la complexité ajoutée et les impacts potentiels sur la stabilité liés à l'exécution de serveurs API supplémentaires.

Ce que vous pouvez faire

• Évaluez si votre cas d'utilisation nécessite une logique impérative ou des données en temps réel avant de choisir entre les CRD et une API d'extension.
• Utilisez kubectl pour vérifier l'état des APIService et assurez-vous que vos extensions sont correctement enregistrées.
• Mettez en place des tests de robustesse pour simuler l'indisponibilité du serveur d'extension et observer l'impact sur le plan de contrôle.
• Documentez clairement les limites de votre solution pour éviter que les utilisateurs ne tentent des opérations non supportées par la logique impérative.
• Surveillez attentivement la latence de l'API après le déploiement d'une nouvelle extension pour détecter rapidement les problèmes de performance.
• Considérez l'utilisation de la couche d'agrégation principalement pour les besoins où les CRD atteignent leurs limites techniques ou fonctionnelles.