KubeCon CloudNativeCon

Pause Cloud & DevOps – édition spéciale KubeCon Europe

KubeCon Europe – jour 2

Les ponts de Mai vous ont empêché de rejoindre le Danemark ?

Suivez l’actualité de la KubeCon & CNCF Europe 2018 comme si vous y étiez grâce au résumé des consultants d’Objectif Libre présents sur place.

Au menu : du cloud, de l’Open Source, des conteneurs… et du Kubernetes bien sûr :

  • Keynotes d’ouverture
  • PaaS Vs k8s
  • Sécurité
  • Operations
  • Service Mesh
  • Projets CNCF

Bonne lecture !

  • Voir le résumé du jour 1 ici
  • Voir le résumé du jour 3 ici
  • Voir les vidéos en replay sur la chaîne Youtube CNCF ici


Keynotes

k8s project update

Le jour 2 de la KubeCon s’ouvre avec la revue des évolutions et de la roadmap de Kubernetes.

Aparna Sinha, Group Product Manae pour k8s & Google k8s Engine chez Google, décrit les progrès faits par k8s sur les plans de la sécurité, des applications et de l’expérience développeurs… avec un détail très appuyé sur toutes les évolutions liées à la Google Cloud Platform.

Voir la vidéo

Accelerating k8s Native Applications

Ensuite, Brandon Philipes, CTO of CoreOS chez RedHat (maintenant), détaille les outils ‘Operators’ qui visent à simplifier le management des applications dans kubernetes, afin de créer des applications exploitant nativement les APIs de Kubernetes.

Prometheus Operator / etcd Operator sont déjà opérationnels. 2 nouveaux projets Open Source sont annoncés : Operator Framework et Operator SDK.

Voir la vidéo

Switching Horses Midstream : the challenges of migrating 150+ microservices to k8S

Retour d’expérience très intéressant de la migration du Financial Times sur kubernetes, par Sarah Wells, Technical Direction for Operations and Reliability.

Commençons par rappeler l’importance cruciale de la technologie pour le Financial Times, essentiellement consulté en ligne.

Lors de la conférence, Sarah Wells raconte par le menu l’aventure tortueuse du Financial Times vers k8s (« il est rare de commencer un projet de zéro ») et parsème son discours de conseils avisés. Retenons-en 2 en particulier :

  • « Il faut être attentif à bien utiliser ses jetons d’innovation » : on comprend que la dispersion dans l’innovation n’est pas forcément une bonne idée
  • La « boring technology » est adaptée pour l’infrastructure. « Boring isn’t bad. Boring means operating ».

Mi-2015, le Financial Times utilise (déjà !) Docker en production. Fin 2016, ils décident de consolider leur plateforme, sur la base de 2 indicateurs :

  • le temps passé à maintenir les clusters fonctionnels
  • le nombre de commentaires sarcastiques concernant ces mêmes clusters sur les channels Slack.

k8s, le standard en phase d’émergence, est choisi pour orchestrer les conteneurs.

Ce changement, Sarah Wells le compare au fait de « changer de cheval au milieu d’une rivière » : beaucoup de services tournent et doivent continuer de tourner pendant toute la durée de la migration. C’est très compliqué de tout mener de front.

Les principaux points de décision :

  • Faire les modifications sur une branche séparée ?
  • Déployer sur les 2 environnements en parallèle ou sur une version unique ?
  • Comment procéder aux tests ?

Les enseignements :

  • C’est long, beaucoup de fix à faire.
  • Tout le monde doit être impliqué : au Financial Times, des « Helm Days » permettaient de réunir tout le monde sur ces problématiques.
  • Lorsqu’on migre des services relativement anciens, il peut être tentant d’en profiter pour améliorer ou revoir leur code… et il est bon de résister à cette tentation, au risque de ne jamais finir !
  • Standardiser au maximum est une bonne pratique afin de renforcer les mécaniques de test de bonne santé des services
  • Il faut vraiment s’assurer qu’un service pourra être retrouvé si k8s bouge / est migré / tombe
  • Enfin, la migration effectuée en parallèle du maintien des services opérationnels est longue et coûteuse : s’assurer préalablement que vous avez bien le budget pour !

Sarah Wells semble satisfaite des résultats :

  • La migration s’est très bien passée ave seulement quelques bugs mineurs sur des usages à la marge et rapidement résolus
  • une plateforme plus stable : de 17 incidents / mois avant migration à 3 incidents mineurs
  • Des coûts d’hébergement et de support réduits
  • Et beaucoup moins de commentaires sarcastiques sur Slack!

Voir la vidéo (recommandé)

Shaping the Cloud Native Future

Abby Kearns, Executive Director Cloud Foundry Foundation, revient dans son intervention sur l’importance croissante du Cloud dans tous les domaines, même pour les entreprises et ce dans tous les secteurs, même les plus inattendus..

Au fil de sa présentation, elle donne en exemple 3 entreprises hors secteur numérique pour lesquelles ces changements, c’est maintenant :

  • Volkswagen : a engagé 100 développeurs depuis 2 ans.
  • US Air Force : ont économisé 600M$ en migrant toutes leurs applications et bases de données sur le cloud, économies qu’ils ont massivement ré-investi dans de nouveaux développements, qu’ils peuvent accélérer.
  • Home Depot : ont embauché +2500 développeurs depuis 2 ans, ont +2k apps en production et ont réduit leurs déploiements de 6 semaines à 15 minutes. La seule manière de résister à Amazon.

Software’s Community

Dave Zolotusky, Software Engineer chez Spotify, clôt la keynote avec un témoignage sur ses 1ers pas communautaires.

Le mieux dans la communauté, dit-il, c’est de s’engager !

Chez Objectif Libre, nous sommes forcément d’accord avec cette assertion, puisque comme le dit souvent Christophe Sauthier : « Nous vivons de l’Open Source, il faut faire vivre l’Open Source ».

Il livre ensuite ses interrogations (légitimes) de débutant communautaire : Comment commencer à contribuer ? Comment trouver les bons interlocuteurs ?

Malgré ces difficultés, il est persuadé que l’engagement communautaire est crucial, pour les raisons suivantes :

  • Obtenir sur support : accéder à des retours d’utilisateurs, des retours d’expériences. Via les channels spécifiques, c’est immédiat !
  • Prendre des conseils : l’appel à la communauté fonctionne ! On n’obtient généralement pas de réponse toute faite, mais énormément de retours d’expériences de grandes sociétés, c’est très enrichissant.
  • Savoir ce qui ce passe : état de l’art de ce qui existe autour, ce qui marche le mieux, qui travaille sur quels outils…

Ses conseils :

  • Identifiez avec qui vous avez envie d’échanger
  • Débarrassez-vous d’un éventuel syndrome de l’imposteur et ayez le cran de poser les questions et de solliciter la communauté : ça vaut le coup !

Voir la vidéo

PaaS

From PaaS to Kubernetes – Combining the Power of k8s with the Most innovative features of PaaS.

Par William Dennis, Product Manager, Google k8s Engine – Beginner level.

Cette conférence commence par un rappel des mérites respectifs des plateformes PaaS et de k8s.

Pour le PaaS :

  • c’est facile de démarrer sur du PaaS
  • l’aspect « git push to deploy » est puissant : on pousse le code, et la plateforme le déploie toute seule
  • il n’y a pas d’infrastructure à manager pour les développeurs
  • Il existe beaucoup de compléments intéressants qui améliorent l’expérience : « companion SaaS add-ons »

Pour k8S :

  • la souplesse du langage
  • c’est une solution indépendante (moins de vendor lock-in)
  • les ressources sont optimisées
  • c’est facile à adapter et à customiser
  • il existe beaucoup de complément (add-ons) open source très intéressants : Prometheus est un bon exemple
  • il est possible de déployer plus que des applications qui suivent le principe des 12 facteurs : des applis statefull par exemple.

Un petit focus est fait ensuite sur les différences concernant la courbe d’apprentissage des 2 approches :

  • Paas : l’apprentissage initial est très rapide. Lorsque la maîtrise augmente, il arrive un moment où on ne peut plus faire exactement ce qu’on veut… et on peut rencontrer une « falaise de désespoir »
  • k8s : on démarre plus lentement ; en contrepartie, on peut faire tellement plus de choses après avoir maîtrisé…

Conseil du speaker : se méfier de la simplicité apparente qui peut rendre les choses complexes… encore plus complexes ! « Be wary of things that make the simple easier and the complex « .

Le reste de la présentation porte sur comment les outils développés par Google, notamment Skaffold, permettent de porter assez facilement dans k8s les avantages clés du PaaS et rendre le même niveau de service.

 

Sécurité

Good enough for the Finance Industry : achieving High security at Scale with Microservices in k8s – By Ygrene Energy Fund.

La conférence est un témoignage du Ygrene sur la manière dont ils sécurisent k8s pour être conforme aux normes de sécurité de la Finance.

Intéressons-nous en particulier à la partie code & conteneurs.

Les risques de sécurité liés aux conteneurs sont les suivants :

  • des conteneurs qui tournent en production sans qu’on s’y attende
  • des fuites de données dans les conteneurs
  • des vulnérabilités dans l’OS du conteneur ou au niveau de l’application

Le 1er conseil est d’appliquer des politiques de sécurité renforcées AVANT que le conteneurs soient poussés dans un dépôt.

Les intervenants détaillent les actions prises à chaque étape :
1. Dockerfile policy : doit remplir les standards CISP de Docker ET les politiques de sécurité internes. Notamment : éviter d’utiliser le tag « latest » pour savoir quelle version tourne
2. App Dep. Check : être sûr à 100 % de ce qui tourne DANS le conteneur, notamment les vulnérabilités des dépendances. Ils utilisent pour cela des outils standards d’analyse de code et de vulnérabilités.
3. Build : utilisent uniquement des images signées utilisant Docker Content Trust. Et utiliser la construction d’images multi-stages pour nettoyer les images de run et réduire leur surface d’attaque.
4. Security testing : scan de l’OS pour chercher des vulnérabilités. Ensuite, attaque du conteneur avec OWASP Zaproxy.
5. Signing and Push : politiques d’identification. Toutes les images sont signées. Les devs peuvent construire des images et les faire tourner en local mais seuls les « build servers » peuvent construire des images qui tourneront en production.

Sur la partie cluster / cloud, ils présentent ensuite les risques, puis les outils, liés à k8s ou externes, qui permettent de réduire ces risques.
Ils conseillent notamment d’utiliser un service managé, ou si c’est impossible, un outil comme Kops.

En savoir + en lisant les slides (notamment la liste des outils utilisés) :

https://schd.ws/hosted_files/kccnceu18/78/Good%20Enough%20for%20the%20Finance%20Industry_.pdf

Voir la vidéo

 

Applying Least Privileges through Kubernetes Admission Controllers – Benjy Portnoy, Aqua Security

De plus en plus, les clusters kubernetes sont ciblés pour exploiter des vulnérabilités (exemple récent de Tesla: un dashboard k8s accessible depuis internet anonymement utilisé pour une campagne de crypto-mining).

Kubernetes a fait beaucoup de progrès concernant la sécurité, mais la plupart des installations ne sont pas sécurisées par défaut.
De plus, certaines pratiques sont à risques :
`kubectl create -f anything.yml` est le nouveau `curl anything.sh | bash`

Il est nécessaire de sécuriser son cluster (NDR : si vous nous suivez, vous retrouvez beaucoup d’éléments vus lors de nos webinaires, petits-déjeuners…).

La documentation sur les bonnes pratiques de sécurité est très bien faite, mais la plupart des mesures ne sont pas activées par défaut.
Une des bonnes pratiques est l’activation des contrôles d’admission, permettant à l’administrateur de mettre en place un certain nombre de vérifications lorsque des utilisateurs font des requêtes d’API.

Il faut voir les contrôles d’admission comme un mécanisme de défense en profondeur. Certains contrôles sont indispensables, mais pas actifs par défaut :

  • AlwaysPullImage : empêche un attaquant de lancer une image sensible par attaque sur le meme hôte.
  • DenyEscalatingExec
  • PodSecurityPolicy : mise en place de politiques de sécurité au niveau cluster
  • NodeRestriction : empêche un kubelet de modifer des noeuds ou des pods ne résidant pas sur son nœud
  • RessourceQuota : mise en place de quota pour éviter les dénnis de service
  • ImagePolicyWebhook

Ce dernier contrôle est intéressant car il permet de créer sa propre politique d’admission d’image dans le cluster. Cette politique peut ainsi empêcher les images contenant des vulnérabilités, des secrets, ou encore des applications utilisant l’utilisateur privilégié (root).

Enfin, certains outils permettent d’auditer la sécurité d’un cluster :

  • Kubebench : le cluster est-il déployé selon les bonnes pratiques de sécurité ?
  • Kubehunter : à voir comme un nmap pour kubernetes : un canner d’IPs d’un cluster
  • kubesec.io : analyse les manifests yaml pour donner un score de sécurité
  • microscanner : scanner d’image gratuit fourni par Aqua et annoncé lors de la Kubecon (NDR: il existe d’autres outils de ce type)

 

Operations

Managing Kubernetes – Day 2 operations – Par Craig Tracey (Heptio)

Craig Tracey travaille quotidiennement sur des déploiements de Kubernetes avec des clients. Des problématiques similaires sont apparues, quelle que soit la taille de l’entreprise, sur la gestion de Kubernetes après le déploiement initial. Cette conférence est un retour d’expérience sur ces problématiques, et les solutions pour les éviter.

Craig a abordé 2 grands axes : les utilisateurs et leur lien à l’existant, et les choses à faire lors du déploiement.

Utilisateurs

L’adoption de k8s nécessite des changements techniques, mais aussi des changements culturels. Quelques pistes pour aider ce second changement :

  • « Don’t boil the ocean » : ne pas tout changer soudainement, mais procéder par étapes
  • Par exemple, autant continuer avec les outils qui ont fonctionné avant la mise en place de k8s

Autre idée intéressante : Kubernetes a une architecture simple, les utilisateurs doivent envisager des déploiements simples. Le schéma comparatif entre les architectures OpenStack et Kubernetes a vraiment mis en avant la simplicité de k8s.

Déploiement

Beaucoup des écueils découverts lors du « Day 2 » (phase de run) peuvent être évités en planifiant mieux l’architecture du cluster. Quelques pistes :

  • Envisager la vie du cluster : reserver des resources aux kubelets (un peu de tuning), envisager le cycle de vie des composants (par exemple en isolant etcd et ses données, plutôt qu’en l’installant sur les masters)
  • Se poser la question du niveau de disponibilité de la plateforme (1 cluster par AZ, ou 1 cluster réparti sur 2 AZ ? Est-ce qu’il est vraiment grave de perdre la CI au milieu de la nuit ?)
  • L’authentification et les contrôles d’accès (RBAC) sont indispensables à mettre en œuvre
  • La logique métier mérite d’être analysée, et éventuellement implémentée par des développements spécifiques (dynamic control admission) grâce à des scripts maison, et éventuellement des contrôleurs spécifiques, qui peuvent aujourd’hui étendre l’API k8s avec quelques lignes de code.

Il est intéressant de voir à quel point Kubernetes est mature : un déploiement correctement planifié permet d’obtenir une plateforme d’une grande stabilité.

Kubespray

Il existe des solutions alternatives à kops, kubeadm ou autres solutions commerciales pour créer des clusters Kubernetes prêts à l’emploi : par exemple Kubespray.

Ce projet OpenSource est bien supporté par la communauté : https://github.com/kubernetes-incubator/kubespray/

Il repose sur Ansible exclusivement, un outil bien connu de la communauté. Le playbook est validé par une chaine d’intégration continue qui teste plus de 20 configurations de cluster différents, déployés dans de vrais clusters chez GCE et DigitalOcean.

Le processus de déploiement avec Kubespray est :

  • les machines (physiques ou VMs) doivent être créées en amont
  • les rôles des machines est défini dans l’inventaire Ansible
  • les choix de plugin (réseau, stockage) et de configuration (plages IPs, …) sont renseignés dans un fichier de configuration (variables)
  • le déploiement se fait grâce à l’inévitable commande `ansible-playbook`.

La force de kubespray est d’être hautement compatible avec plusieurs environnements, des cloud privées aux solutions tel que Vagrant.

Kuberspray fonctionne sur les principaux providers (OpenStack, bare metal, KVM, VMware …), une large gamme d’OS (Suse, Debian, RHEL, ContainerLinux, Atomic…) et est compatible avec plusieurs solutions réseaux (Weave, Flannel, Calico, Contiv…). Il est également compatible avec plusieurs technologies de conteneurisation : docker, rkt.

Les prochains développements porteront sur :

  • amélioration du support de certaines plateformes (Azure, bare metal et AWS), en enrichissant la CI
  • auto-scaling des nodes
  • enrichissement de la liste des add-ons disponible, notamment vers des outils tel que Prometheus et les gestionnaires de logs.

 

Autoscale kubernetes workload with Prometheus – Frederic Branczyk – CoreOS

Tout le monde rêve de voir son infrastructure gérer auto-magiquement les pics de charges en augmentant soit :

  • la taille d’un réplica –> autoscaling vertical
  • le nombre de réplicas –> autoscaling horizontal

Pour cela, il est nécessaire de récupérer la bonne métrique offrant la meilleure observabilité de son application distribuée.

Jusqu’à présent, Kubernetes ne proposait que de l’autoscaling horizontal des pods en se basant sur Heapster et uniquement la métrique de consommation CPU.

Hors cette métrique n’est définitivement pas représentative de l’état de charge d’une application: on préfèrera par exemple pour autoscaler un groupe de frontaux web regarder le nombre de requêtes moyennes par frontal.

Le design d’Heapster ne permettant pas de le faire évoluer facilement, un travail de re-spécification du monitoring pour l’autoscaling dans kubernetes a été entrepris depuis la version 1.8:

  • Définition de nouvelles API « Resource » et « Custom »
    • implémentées par les vendeurs de solutions de monitoring
    • renvoyant une simple valeur par métrique
  • Resource metrics API:
    • métriques de base couvrant CPU/RAM pour pod/service/déploiement
    • les devs kubernetes proposent une implémentation type, metrics-server s’appuyant sur l’api stats fourni par kubelet
  • Custom metrics API:
    • même sémantique
    • permet d’intégrer n’importe quelle métrique nécessaire pour un usecase spécifique
    • doit obligatoirement être associé à un type d’objet kubernetes: pod, déploiement, service
    • exemple d’implémentation basé sur prometheus: github.com/directXMan12/k8s-prometheus-adpater

Le pipeline mis en œuvre est le suivant dans les deux cas:

Autoscaler ——-pull———–> metrics server ———pull————> kubernetes

Une démo montre ensuite comment faire de l’autoscaling horizontal à partir  du nombe de requêtes sur un pod.

Les travaux à venir sur le sujet :

  • Heapster déprécié
  • autosizing (redimensionnement de volume automatique ?)
  • support de l’autoscaling pour les objects custom (CRD)

 

Understanding Distributed Consensus

Cette conférence reprenait le fonctionnement de la base de données distribuée etcd. Cette base de données est notamment utilisée par Kubernetes et joue un rôle majeur dans le fonctionnement du cluster.

Etcd, tout comme Docker Swarm, reste basé sur un algorithme de consensus nommé Raft. Cet algorithme permet de s’assurer de la cohérence des données au sein d’un cluster. L’agorithme peut être décomposé en deux parties : l’élection d’un leader et la réplication du journal.

L’élection permet de déterminer un leader au sein du cluster, les autres nœuds étant des followers. Lorsque l’élection a lieu, chaque nœud vote pour un nœud, et lorsqu’un nœud obtient assez de voix pour atteindre le quorum, il devient le leader.

Les données sont écrites dans un journal. Le leader est le seul à pouvoir écrire des données dans le journal, les followers se contentent de répliquer ce journal.

La perte d’un ou plusieurs nœuds peut engendrer la perte du quorum, aucun leader ne peut être élu, ce qui implique que les opérations d’écriture et de modification du cluster ne peuvent plus avoir lieu. C’est la panne que l’on peut avoir le plus souvent au sein d’un cluster etcd. Pour rétablir le cluster, il suffit de remonter le nœud en panne, quand cela est toutefois possible. Sinon, on est obligé de démarrer un nœud avec les données à jour en forçant la création d’un nouveau cluster à partir du jeu de données existant.

Le sujet était complexe, mais la conférence était agrémentée d’animations permettant de mieux comprendre la logique de l’algorithme Raft. Un must pour administrer des clusters etcd ou Kubernetes.

Lien vers les animations: https://raft.github.io

 

Kubervisor: Pod anomaly detection and eviction using Prometheus Metrics

Le but de la conférence est de présenter une méthode pour automatiser la détection d’anomalies dans un pod, en plus de proposer une méthode automatisée pour solutioner le problème.

Pour les applications écrites sous forme de microservices, il est courant d’avoir plusieurs échanges effectués entre ces derniers, suite à une requête du client.
Si l’un de ces services est dans un état critique (ex: ne répond pas, ou prend trop de temps pour répondre), toute la chaîne d’appels peut être compromise.
Une réaction en chaîne d’erreurs peut se produire entre les services, récupérant des retours d’erreurs les uns après les autres.

Pour limiter au maximum ce problème, le design pattern « circuit breaker » peut être utilisé. Kubervisor est un programme qui automatise son utilisation.

Prenons l’exemple simple d’un service frontend, type wordpress, utilisant un backend de base de données répliquée.

  • Première solution proposée : la gestion de l’état du conteneur.

Si l’appel du frontend vers le backend échoue, il est possible de marquer l’endpoint comme inactif et attendre que l’état du conteneur s’améliore. On peut alors renvoyer un message à l’utilisateur pour lui demander de réitérer son action ultérieurement. Autrement, il est possible de simplement détruire le pod, et laisser Kubernetes en re-déployer un autre.

  • Seconde solution proposée : la répartition de charge de proximité.

Si le premier appel du frontend vers le réplica numéro 1 du backend échoue, il est possible de rejouer l’appel, mais vers un second réplica.
Si ce second appel réussit, alors la chaîne d’appels pourra reprendre, et le client recevera une réponse sans être informé de l’erreur qui s’est produite.
S’il échoue, on peut alors revenir à la première solution.

Dans le cas de cet exemple, une erreur à ne pas faire est de tenter une vérification de toute la chaîne des services :
si le frontend effectue une vérification sur le réplicat numéro 1, hors-service, il marquera tout l’endpoint comme étant inactif, alors que d’autres réplicats sont potentiellement fonctionnels. Cette réaction est surnommée « le suicide en chaîne des conteneurs ». Une politique de retry peut également être mise en place : un nombre de tentatives peut être défini, tout comme un temps d’attente entre les tentatives.

How we used Jaeger to deliver lightning-fast user queries

Cette conférence vient répondre à un problème précis : une chaîne de requêtes entre microservices trop longue, résultant en un temps d’attente trop important pour le client final.
Pour une application écrite sous forme de microservices distribués, le speaker préconise d’effectuer un certain nombre de mesures.
Il préconise également que le service dispose de ses propres métriques, comme le pourcentage de requêtes reussies, de requêtes en erreur, et les temps de réponse.
Le tout peut être intégré dans Prometheus.

Jaeger est un produit open source qui permet d’investiguer les requêtes entre les microservices, en récupérant les différentes métriques depuis Prometheus.
Grâce à un dashboard et une représentation visuelle des temps de réponse, il est aisé de déterminer les appels les plus longs, dans le but d’améliorer les temps de réponse.

Le speaker propose alors plusieurs solutions d’optimisation, en fonction des cas de figure rencontrés :

  • Premier cas de figure : les requêtes ont différents temps de réponse.
    Dans ce cas, le speaker propose simplement d’optimiser les requêtes les plus longues.
    Par exemple, dans le cas d’une requête SQL, il est sûrement possible de paralléliser certaines sous-requêtes.
  • Second cas de figure : les appels ont tous le même temps de réponse.
    Dans ce cas précis, le speaker explique que nous faisons probablement face à une contrainte de processing, de type timeout.
    La responsabilité est alors au développeur d’améliorer leurs requêtes et/ou de modifier les temps de timeout définis.
  • Troisième cas de figure : toutes les requêtes se terminent en même temps.
    Dans ce dernier cas, le speaker explique que nous faisons probablement face à un problème de (inter)lock, libérant une ressource commune pour toutes les requêtes au même moment.
    Dans ce cas, le design de l’application est sûrement en cause.

 

Projets CNCF

CoreDNS intro – Miek Gieben

Pendant cette session, Miek Gieben, core contributeur à CoreDNS, a décrit rapidement le projet et son intégration avec k8s.

Statut

CoreDNS est un serveur DNS très flexible, grâce à son fonctionnement par plugin. Il supporte plusieurs protocoles de transport, dont TLS, DNS et gRPC. Il a été récemment audité par Cure53, et une faille majeure ainsi que 2 failles mineures ont été découvertes, et rapidement corrigées. Le rythme de release est assez élevé : toutes les 3 à 4 semaines.

Un auditeur a posé une question pertinente : « pourquoi un autre serveur DNS ? ». La réponse : les autres produits sont anciens et difficile à maintenir ou modifier. La facilité de maintenance et le système de plugin sont des bases pour le développement de CoreDNS.

Roadmap

Le core et les plugins de base sont très stables et voient peu de changement.

Quelques fonctionnalités en cours de développement :

  • support de etcd3
  • support de stockage en base de données (SQL)
  • « watch feature » : notifications envoyées aux applications lors de changements d’enregistrements sur des zones surveillées

CoreDNS dans k8S

CoreDNS devrait commencer à remplacer kube-dns dans k8s 1.11. C’est la première fois qu’un composant core de k8s sera remplacé par un composant externe.

Plugins

De nombreux plugins sont déjà disponibles (et documentés !) :

  • health check, pour intégration dans un mode conteneur
  • prometheus pour exporter les métriques
  • proxy => possibilité de faire suivre les requêtes vers un dns externe si CoreDNS n’a pas de réponse
  • cache : avec possibilité de pré-fetching avant expiration / stocke également le succès des réponses (positive/négative)
  • kubernetes : service discovery / recherche inverse (PTR) / gestion du domaine cluster.local
  • log
  • debug

Pour k8s :

  • le transfert de zone peut être autorisé, avec des règles de sécurité
  • l’export d’un endpoint de santé est intéressant : CoreDNS exécute une requête DNS sur lui-même et se considère en échec si la réponse prend trop de temps

Code d’exemple d’un plugin

Miek a détaillé l’écriture d’un plugin CoreDNS : tellement simple qu’il serait dommage de ne pas en écrire si le besoin se présente !

Et pour finir, une citation à retenir : « It’s DNS, there’s weird thing happening everywhere »

 

Service Mesh

GitOps for Istio – Manage Istio Config like Code – Varun Talwar, Stealth Startup & Alexis Richardson, WeaveWorks

Cette conférence avait pour but de décrire le principe de GitOps avec un cas concrêt : Istio.

L’idée du gitops est de stocker l’état attendu d’un cluster et des applications dans des dépôts git. Le principe fondateur est de modifier du code, et non des conteneurs : les pipelines de CI/CD qui vont ensuite déployer des conteneurs et autres éléments nécessaires à l’exécution du code applicatif. Les opérations sur le cluster sont déclenchées par des pull request.

Les configurations n’échappent pas à la règle, elles sont stockées également dans git et versionnées.
Ces configurations sont déclaratives et ce sont les outils qui se chargent de faire la différence entre l’état actuel du cluster et l’état attendu. Et bien sûr, les actions adéquates sont réalisées en cas de divergence.

Les changements sont poussées sur la branche staging, ce qui déclenche vos pipelines CI.
Une pull request est nécessaire pour passer de la branche staging à la branche prod. C’est la branche prod qui contient l’état souhaité et qui déclenche les opérations sur le cluster.

Un opérateur Kubernetes a été développé pour réaliser la partie gitops : Weave Flux. Cet opérateur surveille les changements dans git et réalise les déploiements sur le cluster.

Bénéfices :

  • tout changement passe par une revue git (l’utilisation de kubectl par un humain est proscrite)
  • les mises à jour sont des transactions atomiques avec un principe de « succeed or fail cleanly »
  • git fournit un journal de transactions permettant de revenir en arrière et de faire des audits
  • les pull requests agissent comme des firewalls entre la CI et la Production

Quel est l’intéret pour Istio ?

Istio permet de gérer les interactions entre services (plan de contrôle pour un service mesh). Toutes les actions engendrées sur le plan de données sont pilotées par des configurations. Il est donc naturel d’appliquer le gitops à Istio.

Une première démonstration lors de la conférence a montré le déploiement d’un canary via un « push » git.

La deuxième démonstration a montré la capacité à automatiser le « push » de patch (version mineure d’image) :

  • Weave flux détecte une nouvelle image (version mineure) poussée par le pipeline CI sur le registre
  • Weave flux réalise un git commit pour prendre en compte cette mise à jour
  • L’opérateur pousse automatiquement le canary avec la mise en jour