index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AMaZing stuff</title>
    <link>/</link>
    <description>AMaZing stuff</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>fr-FR</language>
    <lastBuildDate>Fri, 11 Dec 2020 08:15:36 +0100</lastBuildDate>
    
    <atom:link href="/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Interview / Retour d&#39;expérience de l&#39;usage de kubebuilder </title>
      <link>/posts/rex-kubebuilder/</link>
      <pubDate>Fri, 11 Dec 2020 08:15:36 +0100</pubDate>
      
      <guid>/posts/rex-kubebuilder/</guid>
      <description>&lt;h1 id=&#34;introduction&#34;&gt;Introduction&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://www.linkedin.com/in/yassine-tijani/&#34;&gt;Yassine Tijani&lt;/a&gt;, contributeur K8s depuis 4 ans, nous a présenté l&amp;rsquo;architecture générale du code d&amp;rsquo;un opérateur Kubernetes (utilisant le pattern contrôleur) en Go.&lt;/p&gt;
&lt;p&gt;La présentation porte en particulier sur l&amp;rsquo;utilisation de &lt;a href=&#34;https://github.com/kubernetes-sigs/kubebuilder&#34;&gt;kubebuilder&lt;/a&gt; qui fournit (au travers d&amp;rsquo;un outil en ligne de commande) un générateur d&amp;rsquo;échafaudage de &lt;strong&gt;code&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;Merci à Yassine pour son temps et les &lt;a href=&#34;https://github.com/kubernetes-sigs/cluster-api-provider-vsphere&#34;&gt;exemples de code&lt;/a&gt; pour étayer son propos !!&lt;/p&gt;
&lt;h1 id=&#34;kubebuilder-en-5s&#34;&gt;Kubebuilder en 5s&lt;/h1&gt;
&lt;p&gt;Le code produit par kubebuilder est d’un niveau d&amp;rsquo;abstraction assez élevé par rapport aux rouages internes de Kubernetes et de son SDK client. Cela permet d&amp;rsquo;être très productif dans la réalisation de l&amp;rsquo;opérateur en se focalisant rapidement sur le code de réconciliation lui-même, souvent le cœur de la logique à implémenter. Il est donc assez haut niveau mais cela est tout à fait adapté au développement d&amp;rsquo;opérateurs standard. Pour des cas qui nécessitent de se rapprocher des détails de l&amp;rsquo;implémentation interne de K8s, il peut être intéressant de regarder du côté du &lt;a href=&#34;https://github.com/kubernetes/sample-controller&#34;&gt;sample-controller&lt;/a&gt;, mais qui est bien plus difficile d&amp;rsquo;accès.&lt;/p&gt;
&lt;p&gt;L&amp;rsquo;architecture d&amp;rsquo;un contrôleur k8s est centrée sur l&amp;rsquo;observation de ressources en s&amp;rsquo;abonnant à des événements (création, destruction, modification&amp;hellip;) les concernant, en vue d&amp;rsquo;y réagir. Pour ce faire, l&amp;rsquo;utilisation de la librairie &lt;a href=&#34;https://github.com/kubernetes/client-go&#34;&gt;client-go&lt;/a&gt; va permettre de simplifier la mécanique d&amp;rsquo;abonnement, de cache, de reprise sur perte de connexion avec l&amp;rsquo;APIServer&amp;hellip;&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;/images/operator-architecture.png&#34; alt=&#34;Architecture logicielle d&amp;rsquo;un contrôleur&#34; title=&#34;Architecture logicielle d&#39;un contrôleur&#34;&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;L’architecture sous-jacente est loin d’être triviale, fort heureusement, nous n’avons pas nécessairement besoin de tout comprendre pour coder la logique d’un opérateur.&lt;/em&gt;&lt;/p&gt;
&lt;h1 id=&#34;comment-utiliser-kubebuilder-&#34;&gt;Comment utiliser kubebuilder ?&lt;/h1&gt;
&lt;p&gt;Les modes d&amp;rsquo;utilisation du CLI kubebuilder sont multiples, voyons les principaux.&lt;/p&gt;
&lt;h2 id=&#34;initialiser-un-projet-vide&#34;&gt;Initialiser un projet vide&lt;/h2&gt;
&lt;p&gt;Après avoir initialisé un module go avec&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-shell&#34; data-lang=&#34;shell&#34;&gt;$ go mod init tki.fr
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;l’utilitaire va fabriquer le plus gros de la structure de notre opérateur :&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-shell&#34; data-lang=&#34;shell&#34;&gt;$ kubebuilder init --domain tki.fr
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Le code produit est avant tout du code Go bien pensé, mais l&amp;rsquo;on trouve aussi :&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;un joli &lt;code&gt;Makefile&lt;/code&gt; qui est une base de travail bien utile pour construire le projet, mais aussi lancer les tests et packager le produit fini&lt;/li&gt;
&lt;li&gt;des manifestes YAML/kustomize en tout genre bien utiles pour déployer et configurer notre cher opérateur (nous aurons l’occasion d’en reparler plus bas)
À noter que le &lt;code&gt;main.go&lt;/code&gt; généré contient déjà de la logique pour gérer le démarrage concurrent de plusieurs instances de l’opérateur avec un mécanisme d&amp;rsquo;élection pour garantir à la fois la redondance et s’assurer qu’à un instant donné une seule instance n’est active.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Apportons une petite précision sur l’option &lt;code&gt;domain&lt;/code&gt; (qui vaut &lt;code&gt;tki.fr&lt;/code&gt; pour l’exemple ici). C’est un espace de nommage qui va permettre de regrouper nos ressources personnalisées. À titre d’exemple, bon nombre de ressources internes de Kubernetes sont classifiées dans le &lt;em&gt;namespace&lt;/em&gt; &lt;code&gt;k8s.io&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id=&#34;créer-léchafaudage-pour-un-nouveau-type-de-ressources&#34;&gt;Créer l&amp;rsquo;échafaudage pour un nouveau type de ressources&lt;/h2&gt;
&lt;p&gt;L’objectif de cette étape est de faire naître et de gérer un nouveau type de ressources : définition du type (CRD), déclaration des primitives de gestion de la structure associée, notamment le &lt;em&gt;deep copy&lt;/em&gt;, abonnement aux événements relatifs à ce nouveau type de ressource, jusqu&amp;rsquo;à la production d&amp;rsquo;un point d&amp;rsquo;entrée, à compléter par le développeur qui va gérer la réconciliation. C&amp;rsquo;est là qu&amp;rsquo;il va falloir coder un comportement lorsqu&amp;rsquo;une ressource est créée / modifiée / supprimée.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-shell&#34; data-lang=&#34;shell&#34;&gt;$ kubebuilder create api --group myorg --version v1 --kind Wut
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;L’option &lt;code&gt;group&lt;/code&gt; utilisée ici désigne une sous-classification des types de ressources que l’on souhaite organiser. Pour être tout à fait précis, la ressource &lt;code&gt;Wut&lt;/code&gt; créée sera donc connue et enregistrée en tant que &lt;code&gt;Wut&lt;/code&gt;, en version &lt;code&gt;1&lt;/code&gt;, dans l’&lt;code&gt;API group&lt;/code&gt; &lt;code&gt;myorg.tki.fr&lt;/code&gt;. Ces valeurs sont à mettre en regard de ressources natives bien connues comme les &lt;code&gt;NetworkPolicy&lt;/code&gt; dans &lt;code&gt;networking.k8s.io&lt;/code&gt; ou encore &lt;code&gt;StorageClass&lt;/code&gt; dans &lt;code&gt;storage.k8s.io&lt;/code&gt;.&lt;/p&gt;
&lt;h1 id=&#34;un-mot-sur-la-logique-de-réconciliation&#34;&gt;Un mot sur la logique de réconciliation&lt;/h1&gt;
&lt;h2 id=&#34;traiter-les-créations-et-les-modifications-de-la-même-façon&#34;&gt;Traiter les créations et les modifications de la même façon&lt;/h2&gt;
&lt;p&gt;La logique de réconciliation à implémenter dans un opérateur doit pouvoir se comporter correctement dans plusieurs situations : démarrage ou redémarrage de l’opérateur après un arrêt potentiellement long, événements au fil de l’eau via le mécanisme de &lt;em&gt;watch&lt;/em&gt;, reprise sur interruption de la connexion avec l’APIServer… Toutes ces situations peuvent donner l’impression que l’on est face à l’ajout ou la modification d’une ressource, mais il est impossible de distinguer à coup sûr ces deux types d’événements. L’opérateur doit donc se comporter exactement de la même façon.&lt;/p&gt;
&lt;h2 id=&#34;identifier-les-suppressions-et-jouer-avec-les-finalizers&#34;&gt;Identifier les suppressions et jouer avec les finalizers&lt;/h2&gt;
&lt;p&gt;Pour détecter qu’un objet a disparu lors de la réconciliation, il est nécessaire de surveiller le champ &lt;code&gt;deletionTimeStamp&lt;/code&gt; qui contiendra une valeur non nulle à partir de la suppression.&lt;/p&gt;
&lt;p&gt;Si les opérations de suppression nécessitent de garder l’objet présent dans l’APIServer, le temps de faire des opérations précises (suppression de ressources externes par exemple), l’utilisation de &lt;em&gt;finalizers&lt;/em&gt; sera alors pertinente. Tant que l’opérateur décide de ne pas supprimer les &lt;em&gt;finalizers&lt;/em&gt; de l’objet (un champ de type chaîne multi-valué), celui-ci sera marqué comme étant en cours de suppression mais ne disparaîtra pas, ce qui peut être utile pour garder des informations importantes, temporairement.&lt;/p&gt;
&lt;h2 id=&#34;mixer-spec-et-status&#34;&gt;Mixer spec et status&lt;/h2&gt;
&lt;p&gt;En parlant d’informations importantes, la distinction entre la partie &lt;code&gt;spec&lt;/code&gt; et &lt;code&gt;status&lt;/code&gt; des ressources méritent une petite précision : il doit être acceptable de perdre toute information du &lt;code&gt;status&lt;/code&gt; et de le reconstituer uniquement à partir des &lt;code&gt;spec&lt;/code&gt; pour traiter des cas de sauvegarde / restauration, mais aussi destruction / recréation des objets. Le &lt;code&gt;status&lt;/code&gt; n’est qu’une indication que l’opérateur peut fournir en cours de son travail de réconciliation qui lui permet de tracer la progression de son travail de convergence et de garder un cache de son avancement. Mais s’il produit une information qui doit être conservée, celle-ci doit faire partie des &lt;code&gt;specs&lt;/code&gt;, quitte à ce que l’attribut soit facultatif : non fourni par l’utilisateur au moment de la création de l’objet et alimenté plus tard par l’opérateur.&lt;/p&gt;
&lt;h1 id=&#34;un-mot-sur-les-tests-et-la-qualité&#34;&gt;Un mot sur les tests et la qualité&lt;/h1&gt;
&lt;p&gt;Le &lt;code&gt;Makefile&lt;/code&gt; généré contient déjà les cibles pour lancer les tests.&lt;/p&gt;
&lt;p&gt;Le retour d’expérience de Yassine est qu’il joue généralement sur plusieurs typologies de tests complémentaires pour maximiser la qualité de ses opérateurs.&lt;/p&gt;
&lt;h2 id=&#34;tests-unitaires&#34;&gt;Tests unitaires&lt;/h2&gt;
&lt;p&gt;Les premiers tests à faire, en utilisant uniquement de la logique implémentée dans une fonction, ces premiers tests s’écrivent de façon tout à fait classique en suivant les pratiques Go. &lt;strong&gt;kubebuilder&lt;/strong&gt; n’apporte rien de particulier à ce niveau, c’est à vous de réveiller le TTDiste qui sommeille en vous !! L’utilisation de la librairie &lt;code&gt;fakeclient&lt;/code&gt; du SDK client de Kubernetes peut s’avérer cependant très utile. Elle permet de remplir artificiellement le cache du client Kubernetes avec des ressources fictives, comme si elles avaient été présentes dans Etcd et retournées par l’APIserver. Vos interactions avec le cluster sont donc bouchonnées, pensez également à bouchonner également les appels sortants si votre opérateur doit interagir avec des ressources ou API externes au cluster (exemple : réconciliation avec un DNS externe).&lt;/p&gt;
&lt;h2 id=&#34;tests-dintégration&#34;&gt;Tests d’intégration&lt;/h2&gt;
&lt;p&gt;Le squelette généré par &lt;strong&gt;kubebuilder&lt;/strong&gt; produit un début de test d’intégration en utilisant &lt;a href=&#34;http://sigs.k8s.io/controller-runtime/pkg/envtest&#34;&gt;envtest&lt;/a&gt; comme framework. Ce framework offre la capacité de démarrer très rapidement en local un Kubernetes minimaliste (concrètement, un &lt;strong&gt;Etcd&lt;/strong&gt; et un &lt;strong&gt;APIServer&lt;/strong&gt;), d’y déployer des manifestes (concrètement la définition de la CRD par exemple) avant d’effectuer n’importe quel type de commande pour effectuer des actions et procéder à tout type d’assertions. Heureuse coïncidence, l’archive de &lt;strong&gt;kubebuilder&lt;/strong&gt; que l’on peut télécharger embarque les binaires de &lt;code&gt;kubebuilder&lt;/code&gt;, mais aussi &lt;code&gt;kubectl&lt;/code&gt;, &lt;code&gt;etcd&lt;/code&gt; et &lt;code&gt;kube-apiserver&lt;/code&gt;…&lt;/p&gt;
&lt;p&gt;Au travers de cette seconde solution il sera plus pertinent de tester l&amp;rsquo;enchaînement et la cohérence de plusieurs opérations de l’opérateur : &lt;em&gt;webhooks&lt;/em&gt; puis réconciliation, &lt;em&gt;webhooks&lt;/em&gt; puis suppression&amp;hellip;&lt;/p&gt;
&lt;h2 id=&#34;tests-end2end&#34;&gt;Tests End2End&lt;/h2&gt;
&lt;p&gt;Dernière option pour faire des tests de votre opérateur, le déployer dans un vrai cluster Kubernetes, plus complet. C’est notamment nécessaire s’il est nécessaire de tester des opérations qui nécessitent plus de parties mobiles, notamment le &lt;code&gt;scheduler&lt;/code&gt; ou le &lt;code&gt;controller-manager&lt;/code&gt;. Plusieurs solutions sont possibles, mais c’est &lt;a href=&#34;https://github.com/kubernetes-sigs/kind&#34;&gt;kind&lt;/a&gt; qui présente le meilleur compromis temps de démarrage / lourdeur / représentativité dans bien des situations.&lt;/p&gt;
&lt;h1 id=&#34;un-mot-sur-le-yaml&#34;&gt;Un mot sur le YAML&lt;/h1&gt;
&lt;p&gt;Le &lt;code&gt;Makefile&lt;/code&gt; produit par &lt;strong&gt;kubebuilder&lt;/strong&gt; contient une cible nommée &lt;code&gt;manifests&lt;/code&gt; qui permet de générer ou régénérer tout le YAML qui accompagne un opérateur.&lt;/p&gt;
&lt;p&gt;Les types de ressources sont :&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CRD&lt;/li&gt;
&lt;li&gt;des exemples de ressource (CR)&lt;/li&gt;
&lt;li&gt;le déploiement de l&amp;rsquo;opérateur (ressource K8s de type &lt;code&gt;deploy&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;quelques autres petites surprises bien agréables que nous allons découvrir juste après&lt;/li&gt;
&lt;li&gt;les paramétrages RBAC (&lt;code&gt;Role&lt;/code&gt;/&lt;code&gt;ClusterRole&lt;/code&gt;) nécessaires à la correcte exécution de l&amp;rsquo;opérateur&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Sur ce dernier point, il est à noter l&amp;rsquo;utilisation d&amp;rsquo;annotations sous forme de commentaires dans le code qui permet de renseigner &lt;strong&gt;kubebuilder&lt;/strong&gt; dans la génération des manifestes :&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-go&#34; data-lang=&#34;go&#34;&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:rbac:groups=core,resources=secrets,verbs=get;list;watch;create;patch
&lt;/span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:rbac:groups=infrastructure.cluster.x-k8s.io,resources=vsphereclusters,verbs=get;list;watch;create;update;patch;delete
&lt;/span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:rbac:groups=infrastructure.cluster.x-k8s.io,resources=vsphereclusters/status,verbs=get;update;patch
&lt;/span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:rbac:groups=cluster.x-k8s.io,resources=clusters;clusters/status,verbs=get;list;watch
&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Dans cet exemple, tiré de l’opérateur de l’implémentation de la &lt;a href=&#34;https://github.com/kubernetes-sigs/cluster-api-provider-vsphere&#34;&gt;clusterAPI pour VSphere&lt;/a&gt;, on retrouve encodé dans les commentaires les verbes d&amp;rsquo;action (&lt;code&gt;get&lt;/code&gt;, &lt;code&gt;list&lt;/code&gt;, &lt;code&gt;watch&lt;/code&gt;) qui doivent être permises et les ressources concernées.&lt;/p&gt;
&lt;h2 id=&#34;un-mot-sur-la-partie-http&#34;&gt;Un mot sur la partie HTTP&lt;/h2&gt;
&lt;p&gt;Car oui, même si a priori un contrôleur a pour but principal de fonctionner comme un &lt;em&gt;worker&lt;/em&gt; qui s’abonne et réagit à des événements de l’APIServer, il a plusieurs (très bonnes) raisons d’également exposer une tête HTTPS. &lt;strong&gt;Kubebuilder&lt;/strong&gt; fournit toute la structure de code permettant de rapidement implémenter la logique associée au différents endpoints Web exposés.&lt;/p&gt;
&lt;h2 id=&#34;observabilité&#34;&gt;Observabilité&lt;/h2&gt;
&lt;p&gt;Un opérateur doit comme toute application qui se respecte renseigner sur son fonctionnement. Ici, l’approche adoptée est comme bien souvent d’exposer des métriques au format &lt;a href=&#34;https://openmetrics.io/&#34;&gt;OpenMetrics&lt;/a&gt;, format proposé par Prometheus. L&amp;rsquo;opérateur démarre donc en exposant ses métriques sur un endpoint HTTPS, tandis que les manifestes générés par &lt;code&gt;make manifests&lt;/code&gt; contiennent la déclaration du point de collecte (&lt;code&gt;ServiceMonitor&lt;/code&gt;) pour Prometheus.&lt;/p&gt;
&lt;h2 id=&#34;gestion-des-versions-des-ressources&#34;&gt;Gestion des versions des ressources&lt;/h2&gt;
&lt;p&gt;Rares sont les types de ressources dont le schéma (la structure) n’évolue pas au cours du temps. Le concept d’APIVersion présent dans tous les objets K8s permet de désigner la version dudit schéma que l’on souhaite utiliser lorsque l’on manipule une ressource.&lt;/p&gt;
&lt;p&gt;Avec l’apparition progressive de nouvelles versions dans la définition de nos ressources, vient alors la question de leur migration. Un opérateur peut prendre en charge la conversion des ressources pour les faire progressivement monter vers la version en cours (format dit Hub : le plus récent connu et persisté dans Etcd). Cette conversion est déclenchée par l’APIserver qui va invoquer un WebHook que votre opérateur peut implémenter pour effectuer les opérations non triviales des champs des objets lors d’une montée de version.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-shell&#34; data-lang=&#34;shell&#34;&gt;$ kubebuilder create webhook --group myorg --version v1 --kind Wut --conversion
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Pour les valeurs par Défaut, la Validation et la Mutation des ressources&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-shell&#34; data-lang=&#34;shell&#34;&gt;$ kubebuilder create webhook --group myorg --version v1 --kind Wut --defaulting --programmatic-validation
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Autres types de WebHooks qu’un opérateur peut implémenter, ceux qui valident (autorisent ou refusent) ou Modifient (patchent à la volée, en positionnant des valeurs par défaut par exemple) les ressources au moment de leur création ou modification.&lt;/p&gt;
&lt;p&gt;À nouveau, des commentaires dans le code permettent d’aider kubebuilder lorsqu’il va générer les manifestes YAML : il produit les manifestes permettant de déclarer les WebHooks auprès de l’APIServer :&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4&#34;&gt;&lt;code class=&#34;language-go&#34; data-lang=&#34;go&#34;&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:webhook:path=/mutate-myorg-tki-fr-v1-wut,mutating=true,failurePolicy=fail,groups=myorg.tki.fr,resources=wuts,verbs=create;update,versions=v1,name=mwut.kb.io
&lt;/span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;// +kubebuilder:webhook:verbs=create;update,path=/validate-myorg-tki-fr-v1-wut,mutating=false,failurePolicy=fail,groups=myorg.tki.fr,resources=wuts,versions=v1,name=vwut.kb.io
&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;</description>
    </item>
    
  </channel>
</rss>