Comment tester le trafic à l'aide d'un contrôleur Kubernetes personnalisé : un guide étape par étape

Contrôleurs et opérateurs K8s

Dans le monde de K8, chaque ressource est créée via un contrôleur. Comme s'il existe des contrôleurs intégrés pour les pods, les déploiements, les jeux de répliques, etc. Donc, fondamentalement, les contrôleurs ne sont rien d'autre qu'une boucle de contrôle qui surveille en permanence l'état du cluster et prend des mesures pour amener le cluster dans l'état souhaité. Les ressources ont une spécification qui fournit l'état souhaité. Le contrôleur vérifie les états actuels. S'il ne correspond pas à l'état souhaité, il apportera les changements ou modifications appropriés pour le rapprocher de l'état souhaité.

Différents types de Kube-Controller-Manager

• ReplicaSet Controller : ce contrôleur est chargé de maintenir un ensemble stable de répliques de pods en cours d'exécution à tout moment. Il est souvent utilisé conjointement avec les déploiements pour garantir qu'un nombre spécifié de répliques de pods sont exécutées à tout moment, même en cas de panne de nœud ou d'arrêt de pod.

• Contrôleur de déploiement : ce contrôleur fournit des mises à jour déclaratives pour les pods et les ReplicaSets. Il permet une mise à l’échelle, des mises à jour progressives et des restaurations d’applications faciles. Le contrôleur de déploiement gère la création et la suppression des ReplicaSets pour garantir que le nombre souhaité de pods est toujours en cours d'exécution.

• StatefulSet Controller : ce contrôleur est utilisé pour gérer les applications avec état, telles que les bases de données. Il fournit une identité unique (un nom d'hôte stable) à chaque pod de l'ensemble et maintient l'ordre et le caractère unique de ces pods. Il est particulièrement utile lorsque vous avez besoin d'identifiants de réseau stables, d'un stockage persistant stable, ainsi que d'un déploiement et d'une mise à l'échelle ordonnés et gracieux.

• Contrôleur de service : Ce contrôleur est chargé de maintenir une adresse IP et un nom DNS stables pour un ensemble de pods. Il agit comme un équilibreur de charge et achemine le trafic vers les pods appropriés en fonction du sélecteur de service. Cela garantit que les services disposent d'un point de terminaison stable pour accéder aux pods en cours d'exécution, même lorsqu'ils sont créés, détruits ou déplacés dans le cluster.

Comportement et architecture

Donc, avant de nous lancer dans les tests, nous devons comprendre l'architecture de base d'un contrôleur standard. Dans l'architecture client-serveur de Kubernetes, les contrôleurs jouent un rôle crucial en tant que clients qui effectuent des appels API, principalement HTTP, vers le serveur API Kubernetes. Leur objectif principal est de réconcilier les objets de l’API Kubernetes avec les ressources système réelles. Un composant essentiel de cette architecture est l’utilisation d’Informers. Les informateurs sont chargés de surveiller tout changement dans le cluster, ce qui est crucial car des interrogations continues pour récupérer des informations sur les ressources peuvent dégrader considérablement les performances du serveur API.

Les informateurs fonctionnent en interrogeant les données des ressources et en les stockant dans un cache local. Une fois les données stockées, un événement est généré uniquement lorsqu'il y a un changement dans l'état d'un objet (ou d'une ressource). Cette approche garantit que le système n'est pas submergé par des événements inutiles et que le contrôleur n'est averti que lorsqu'un changement pertinent se produit.

Un autre concept important dans cette architecture est la version des ressources. Cette version change à chaque opération d'écriture et est utilisée pour le contrôle de concurrence optimiste. Il garantit que les mises à jour des ressources sont gérées de manière à éviter les conflits et à maintenir la cohérence dans l'ensemble du système. En comprenant et en exploitant ces mécanismes, les contrôleurs Kubernetes peuvent gérer et réconcilier efficacement l'état des ressources dans un cluster.

CRD et contrôleurs personnalisés dans Kubernetes

Kubernetes permet la création de définitions de ressources personnalisées (CRD), qui sont des extensions de l'API Kubernetes qui permettent aux utilisateurs de définir des ressources personnalisées. Ces ressources personnalisées ne sont pas disponibles dans une installation Kubernetes par défaut et sont utilisées pour répondre aux cas d'utilisation spécifiques au domaine et aux exigences d'application complexes.

Pour gérer ces ressources personnalisées, un contrôleur personnalisé est requis. Le contrôleur personnalisé, le CRD et le serveur API Kubernetes forment une relation cohérente où :

• Le CRD définit les ressources personnalisées.

• Le serveur API gère le cycle de vie de ces ressources.

• Le contrôleur personnalisé assure que l'état de ces ressources est maintenu selon la configuration souhaitée.

Cette architecture permet l'extensibilité de Kubernetes, permettant aux utilisateurs d'adapter la plateforme à leurs besoins spécifiques.

Test d'un contrôleur -

S'assurer qu'un contrôleur Kubernetes est prêt à répondre aux requêtes du serveur API Kubernetes est crucial avant de le déployer en production. Il existe plusieurs approches pour tester les contrôleurs Kubernetes. Certains d'entre eux que j'ai mentionnés sont tirés de l'article :

1. Utilisation de faux clients ou d'abstractions de niveau supérieur : cette approche évite d'exécuter une API de support, ce qui la rend adaptée aux tests unitaires de composants individuels de manière isolée.

2. Utilisation du package envtest de Controller-runtime : Ce package fonctionne avec un serveur API épuré pour valider les interactions réelles avec l'API, y compris les synchronisations de synchronisation et de cache, sans interférence des autres contrôleurs. . Il prend en charge à la fois les tests locaux sur une instance simplifiée et les tests sur un cluster entièrement fonctionnel.

3. Exécuter un véritable serveur API : Cette approche convient aux environnements de test ou aux instances comme les types éphémères ou les microk8 pour tester des résultats réels. Il permet de tester les interactions sur un véritable serveur API.

L'avantage d'utiliser un processus externe, comme envtest ou un véritable serveur API, est qu'il prend en compte la latence inhérente à un système distribué. Des bibliothèques comme Gomega peuvent être utilisées pour attendre des conditions spécifiques après qu'une action se soit produite. Les approches ci-dessus conviennent le plus souvent aux tests unitaires et aux tests de niveau d'intégration, où nous testons un composant particulier de manière isolée. soit en falsifiant les données en écrivant des tests

Bien que les techniques ci-dessus soient efficaces pour les tests unitaires et d'intégration, elles peuvent ne pas couvrir les tests de bout en bout (e2e), qui sont cruciales pour garantir la fonctionnalité globale du contrôleur. Une approche des tests e2e consiste à effectuer des mises à jour des ressources et d'autres opérations pour tester l'intégralité du flux du contrôleur dans un environnement contrôlé, en répliquant le processus chaque fois que nécessaire. Cela permet de valider le comportement du contrôleur dans des scénarios réels et de garantir qu'il est prêt pour le déploiement en production.

En résumé, une combinaison de tests unitaires, d'intégration et de bout en bout est essentielle pour garantir la fiabilité et l'efficacité des contrôleurs Kubernetes avant de les mettre en production.

Pourquoi tester les contrôleurs Kubernetes avec Keploy ?

Construire et tester des contrôleurs Kubernetes localement peut s'avérer difficile, en particulier lorsqu'il s'agit d'appels d'API sortants. Cependant, Keploy, en tant qu'outil créant des cas de test et des simulations de données à partir d'appels d'API, de requêtes de base de données, etc., propose une solution. Keploy vous permet d'enregistrer et de rejouer les appels sortants passés par votre contrôleur Kubernetes, ce qui peut être incroyablement utile pour tester et garantir que votre contrôleur se comporte comme prévu.

Vous vous demandez peut-être comment cela est possible sans aucune modification du code. Keploy utilise eBPF pour ajouter des sondes à l'espace du noyau et collecter des données de tampon réseau. Ces données sont ensuite envoyées au proxy de Keploy, qui agit comme un espace utilisateur où tout le traitement du tampon est effectué par différents analyseurs de protocole. Keploy peut capturer le trafic de sortie du contrôleur et stocker la demande et la réponse dans un fichier YAML pour cet événement particulier. En mode relecture, au lieu d'appeler l'API vers le véritable serveur API, Keploy renverra la réponse du fichier YAML stocké pour cette requête particulière. Cela rend le processus indépendant du cluster ou de l'environnement, offrant un moyen pratique et efficace de tester les contrôleurs Kubernetes localement.

Enregistrement des appels sortants

Donc, pour capturer les tests de vos contrôleurs localement ou à partir de n'importe quel environnement en direct, vous devez d'abord démarrer le cluster Kubernetes et créer votre contrôleur personnalisé pour interagir avec le serveur.

Pour enregistrer votre manette avec Keploy, suivez ces étapes :

1. Définissez votre objet Kubernetes *rest.Config pour qu'il soit non sécurisé et sans fichier CA :
   

   cfg.Insecure = true
   cfg.CAFile = ""
   

2. Créez un RoundTripper personnalisé pour ajouter un champ d'en-tête contenant la version de la ressource. Cet en-tête sert d'identifiant de trace pour faire correspondre les requêtes au cours du même état avec les simulations enregistrées. Voici un exemple de mise en œuvre :
   

   type customRoundTripper struct {
       rt http.RoundTripper
   }
   
   func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
       ctx := req.Context()
       rsv := ctx.Value("ResourceVersion")
   
       if rsv != nil {
           req.Header.Add("keploy-header", rsv.(string))
       }
       return crt.rt.RoundTrip(req)
   }
   
   cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
       return &customRoundTripper{rt: rt}
   }
   

3. Assurez-vous de définir la valeur de la version de la ressource dans context.Context pendant le processus de synchronisation. Ceci est crucial pour transmettre le contexte modifié aux méthodes de mise à jour et de création de votre contrôleur. Par exemple :
   

   func (c *Controller) syncHandler(ctx context.Context, key string) error {
       // set ResourceVersion in ctx
       rv := foo.GetResourceVersion()
       if rv != "" {
           ctx = context.WithValue(ctx, "ResourceVersion", rv)
       }
   }
   

4. Construisez le binaire Go de votre contrôleur Kubernetes :
   

   go build -o sample-controller .
   

5. Pour enregistrer les appels sortants via Keploy, enveloppez la commande de votre contrôleur avec la commande d'enregistrement de Keploy. Remarque - Cette fonctionnalité de keploy est en version bêta et n'est pas encore publiée dans la version principale. Ceci a été spécifiquement créé comme une expérience pour que les passionnés de Kubernetes puissent essayer de donner leur avis. Vous devez donc procéder au paiement dans cette branche spécifique et créer le binaire keploy à l'aide de la commande go build. https://github.com/keploy/keploy/pull/1342.

   1. Paiement dans la succursale spécifiée.

      1.
      

            git checkout kube-controller
          ```
      {% endraw %}
      

   1. Construire le binaire keploy pour cette branche.
      {% brut %}

      go build -o keploy && sudo mv keploy  /usr/local/bin
      

1. Ajoutez les drapeaux nécessaires en fonction de votre configuration kube :
   

   sudo -E env PATH=$PATH keploy record -c "./sample-controller -kubeconfig=$HOME/.kube/config"  --mtls-cert-path "$HOME/.minikube/profiles/minikube/client.crt" --mtls-key-path "$HOME/.minikube/profiles/minikube/client.key"  --mtls-host-name 192.168.49.2:8443
   

2. Vous pouvez voir keploy/test-set-0/mocks.yaml créé dès que Keploy commence à intercepter les appels sortants. Chaque version de ressource possède un fichier fictif distinct désigné par mocks_ "".

Remarque - Une chose que je souhaite clarifier est que la fonctionnalité ci-dessus ne vous aide pas en TDD (développement piloté par les tests). Mais vous pouvez toujours keploy lors de l'écriture de tests unitaires en tirant parti de la capacité de génération de stub de keploy. Ainsi, au lieu de créer un serveur API fictif ou d'écrire un stub pour un test unitaire particulier, vous pouvez une fois lire ce test dans votre environnement réel. Keploy stockera toutes les interactions dans un fichier fictif et utilisera ces données lors de la prochaine exécution des tests.

Tests avec des simulations enregistrées

Pour tester votre contrôleur avec des simulations enregistrées :

1. Exécutez Keploy en mode test avec l'indicateur mockAssert défini sur true et fournissez le binaire de votre contrôleur. Keploy créera automatiquement une fausse configuration de Kube pour vous :
   

   cfg.Insecure = true
   cfg.CAFile = ""
   

2. En option, vous pouvez définir votre propre temps de relecture, qui tentera de rejouer votre session enregistrée dans le temps imparti : un exemple complet d'application intégrée à keploy est donné ici.
   

   type customRoundTripper struct {
       rt http.RoundTripper
   }
   
   func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
       ctx := req.Context()
       rsv := ctx.Value("ResourceVersion")
   
       if rsv != nil {
           req.Header.Add("keploy-header", rsv.(string))
       }
       return crt.rt.RoundTrip(req)
   }
   
   cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
       return &customRoundTripper{rt: rt}
   }
   

3. Notez que le processus de relecture réduit l'intervalle de temps des événements suffisamment grand à une durée moyenne précise entre les deux événements des informateurs. Cela permet d'envoyer les événements plus tôt qu'ils ne se sont produits dans l'enregistrement, facilitant ainsi une relecture plus rapide.

4. Cela peut vous aider à rejouer toute la session d'appels API produits par le contrôleur, mais cette fois, vous n'avez pas besoin d'un vrai serveur K8s ou d'une source externe pour obtenir la réponse. Toutes les réponses seront renvoyées par le keploy lui-même agissant comme un serveur fictif ou un intermédiaire. Cela peut donner la confiance nécessaire pour l'exécuter dans vos pipelines CI-CD.

5. Par exemple - Vous travaillez dans une grande organisation de cloud computing et pour déployer tout cela, cela nécessite beaucoup de virtualisation et nécessite une opération gourmande en ressources. Il est donc quasiment impossible de le tester dans un environnement réel. Ici, un outil de type Keploy peut être très utile car il a déjà la réponse que vous souhaitez obtenir en cas de déploiement réussi de cette ressource. Cela peut donc être un fonctionnement rapide, fiable et économique car il vous suffit de capturer le bon flux de votre service de contrôleur une seule fois. Et pouvez réutiliser le replay keploy dans vos versions ultérieures.

Conclusion

Les tests locaux des contrôleurs Kubernetes peuvent être rendus plus efficaces et plus fiables avec des outils comme Keploy. En enregistrant et en rejouant les appels sortants, vous pouvez vous assurer que votre contrôleur se comporte correctement dans divers scénarios, améliorant ainsi la qualité globale de vos applications Kubernetes. Étant donné que keploy prend en charge natif les frameworks de test comme gotest , il est également possible d'obtenir la couverture de ligne de n'importe quelle application, même de votre contrôleur Kube. Explorez Keploy et améliorez le flux de travail de test de votre contrôleur Kubernetes !

FAQ

Quels sont les avantages d'utiliser Keploy pour tester les contrôleurs Kubernetes ?

Keploy simplifie les tests des contrôleurs Kubernetes en :

• Enregistrement et relecture des appels d'API sortants : cela élimine le besoin d'environnements en direct pendant les tests.

• Efficacité améliorée : en utilisant des simulations stockées, les tests deviennent plus rapides et indépendants du cluster Kubernetes réel.

• Économies de coûts et de ressources : il réduit la dépendance à l'égard d'environnements gourmands en ressources pour la validation, ce qui le rend idéal pour les pipelines CI/CD dans les opérations à grande échelle.

Comment Keploy gère-t-il les appels d'API sortants pour les contrôleurs Kubernetes ?

Keploy utilise des sondes eBPF pour intercepter les appels sortants et stocke les paires requête-réponse dans des fichiers fictifs. Pendant le mode relecture :

• Les appels sont interceptés et mis en correspondance avec des simulations précédemment enregistrées.

• Les réponses sont renvoyées par ces simulations au lieu de contacter le serveur API réel.
  
  Ce mécanisme garantit que les tests peuvent s'exécuter sans avoir besoin d'un cluster Kubernetes actif.

Keploy peut-il être utilisé pour le développement piloté par les tests (TDD) avec les contrôleurs Kubernetes ?

Bien que la fonction d'enregistrement et de relecture de Keploy ne soit pas conçue spécifiquement pour TDD, elle peut toujours être utilisée efficacement :

• Génération de stub : exécutez une fois le contrôleur dans un environnement réel pour capturer les interactions. Keploy créera des simulations pour une utilisation ultérieure.

• Prise en charge des tests unitaires : en tirant parti de ces simulations, vous pouvez éviter d'écrire des stubs manuellement et vous concentrer sur l'exécution des tests.
  
  Keploy complète les flux de travail TDD existants en rationalisant la création de maquettes et en réduisant les frais de développement.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!