#DevoxxFR Qu’avons nous appris après 1 an passé à développer des opérateurs Kubernetes Etienne Coutaud @etiennecoutaud 1

#DevoxxFR Etienne Coutaud Engineering Manager Cloud @Artifakt https://github.com/etiennecoutaud ⛰ 📍 Bordeaux

#DevoxxFR Un peu de contexte sur Artifakt

#DevoxxFR un PaaS multicloud Console Frontend Backend Platform AWS GCP Azure ● Introduction d’une couche d’abstraction (platform) ● Homogénéiser et standardiser les ressources clouds et leurs cycle de vie ● Offrir un point d’entrée unique pour piloter les clouds provider (API) ● Rendre cette couche portable, modulaire évolutive et cloud agnostique

#DevoxxFR Zoom sur la plateforme (1/2) Kubernetes API CRD CRD CRD CRD controller controller controller controller controller controller controller controller CRD

#DevoxxFR Zoom sur la plateforme (2/2) service.artifakt.io infrastructure.artifakt.io catalog.artifakt.io auth.artifakt.io apps.artifakt.io Cache Database MessagingQuueue ElasticSearch Registry Environment DNSREcord DNSProvider Network KubernetesCluster LoadBalancer NodeGroup GitRepository CloudAccount ApplicationBundle CacheBundle DatabaseBundle MessagingQueueBundle ElasticSearchBundle NodeGroupBundle Application

#DevoxxFR Declarer une database chez Artifakt

#DevoxxFR Enseignements tirés et erreurs commises après 1 an

#DevoxxFR Qu’est ce qu’un controller Kubernetes ? ● controller => opère sur des ressources builtin ● operator => opère sur des ressources custom

No content

#DevoxxFR Prendre le temps de définir sa CRD avec le métier La CRD (Custom Resource Definition) est le contrat d’interface entre les utilisateurs et le controller La ressource CRD contient entre autre: ● le versionning de la ressource ● sa structure ● le typage de chaque champ ● un premier niveau de contrôle ○ typage ○ champ obligatoire ○ enumeration ○ regex ● Le endpoint de conversion https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource- definitions/

#DevoxxFR

#DevoxxFR

#DevoxxFR Utilisez un framework pour construire votre controller ! ● Simplifie l’intégration avec Kubernetes et la mécanique d’indexation et de queue. ● Contient plein de fonction utils ● Génère du code ● Génère la CRD depuis la structure de donnée du code ● Génère les manifests de déploiement Le framework permet de se focaliser uniquement sur ce qui a de la valeur dans le controller : la boucle de reconciliation

#DevoxxFR Sinon … Toute cette partie doit être géré à la main dans l’opérateur en amont de la réconciliation

#DevoxxFR Les frameworks à votre disposition ● Charmed Operator Framework ● Kopf (Kubernetes Operator Pythonic Framework) ● kubebuilder ● KubeOps (.NET operator SDK) ● KUDO (Kubernetes Universal Declarative Operator) ● Metacontroller along with WebHooks that you implement yourself ● Operator Framework ● shell-operator

#DevoxxFR Avant la reconciliation, l’admission controller

#DevoxxFR ValidatingWebhookConfiguration database-controller /validate db-webhook-service k8s api req req response

#DevoxxFR un webhook de validation d’objet

#DevoxxFR

#DevoxxFR MutatingWebhook ● Fonctionnement similaire au ValidatingWebhook ● Permet de faire muter un objet à la volée, transformation des specs ● Exemple : istio utilise la mutation pour injecter les sidecars ● Ne jamais modifer les specs d’un objet dans la reconcilation pour eviter des tour de boucle inutiles

#DevoxxFR MutatingWebhook

#DevoxxFR Conditions et cycle de vie des objets admission controller ETCD predicates obj = getObject(key) obj.isUnderDeletion() obj.deleteFunc() obj.RemoveFinalizer() yes obj.addFinalizer() No reconcile action [...] obj.SetStatus() client.Update(obj)

#DevoxxFR Le finalizer

#DevoxxFR Faire évoluer les CRDs et assurer la compatibilité Un controller n’opère de réconciliation que dans la dernière version il n’y pas de réconciliation distincte en fonction de la version

#DevoxxFR Le ConversionWebhook ETCD db1/V1 db2/V2 db1/V2 db2/V2 db2/V1 convertTo convertFrom

#DevoxxFR

#DevoxxFR Organisation globale du code chez Artifakt ● lib externe “core” qui centralise du code commun à l’ensemble des opérateurs ○ les types d’objet API (structure go) ○ des fonctions utils ○ des bouts de réconciliation commun à nos controllers ○ Evite les dépendances cycliques ● un seul controller peut manipuler plusieurs type de CRD ○ une boucle de réconciliation = 1 seul type d’objet mais des get sont possibles ○ un controller peut supporter plusieurs boucle de réconciliations si cela fait sens ■ exemple notre controller network reconcilie les LBs, les DNSReccord et le Network ● CICD automatique via ArgoCD ● Les libs Kubernetes avancent plus vite que nous ! ● Reflexion autour d’une migration vers un monorepos central générant plusieurs binaires comme ke repos Kubernetes

#DevoxxFR Conclusion ● Ecrire/Maintenir/Deployer un controller va plus loin qu’un simple script, c’est une brique de software ● Go est plus adapté car adopté massivement par la communauté et l’intégration est native mais d’autres langages sont possibles ● Utilisez un framework ● Réflechissez à la structure de votre CRD avec le métier, c’est une interface entre le controller et son utilisateur ● Cette CRD sera amené à évoluer ● L’algorithme de réconciliation est le coeur de votre controller ● Testez votre code, tout est disponible pour mocker ou simuler localement un cluster Kubernetes ● Ouvrez les controllers disponibles sur Github !

#DevoxxFR Merci à tous ! Etienne Coutaud