KubeCon CloudNativeCon

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

KubeCon Europe – jour 1

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
  • Use Cases et retours d’expériences
  • Service Mesh
  • Sécurité
  • Conteneur Runtime
  • CI/CD

Bonne lecture !

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


Keynotes

C’est Dan Kohn, Directeur Executif de la Cloud Native Computing Foundation, qui ouvre la journée.

Après les traditionnels remerciements aux sponsors et l’annonce du planning (chargé), il met d’emblée l’accent sur la croissance de la manifestation. Pour citer un seul chiffre, ce sont 4300 participants qui sont à Copenhague, soit 3 fois plus qu’à Berlin l’année passée.

How Good is Our Code ? – par Dan Kohn

La 1ère intervention tourne autour de cette question : « comment savoir si le code est de qualité ? »

Dan Kohn rend d’abord hommage à l’Open Source qui permet à des milliers de développeurs de tester les lignes de code. Pour autant : « les patchs sont utiles uniquement lorsqu’ils sont poussés en production. » Il vante ainsi tous les mérites de la CI.

Quels types de tests sont nécessaires ? – Tous, et même plus, répond-il. Il cite en exemple le « Smoke test » : on casse, puis on regarde d’où vient la fumée.

A retenir de cette intervention : le code n’est jamais assez bon ! Il doit être testé, testé, testé. Pour conclure : Kubernetes, c’est bien. Mais s’il n’y a pas de CI, k8s sera le cadet de vos soucis.

Quelques liens intéressants à consulter :

Voir la vidéo (Introduction générale – talk à partir 4′)

 

CNCF project updates – Par Liz Rice, Technology Evangelist, Aqua security.

L’évolution des projets du CNCF est importante : de 8 projets seulement il y a 1 an, on passe à 20 projets aujourd’hui.

Les projets sont classés selon leur stade de maturité, en 3 catégories (sandbox / incubation / graduated), stades qui peuvent être rapprochés des niveaux de maturité du modèle « chasm » : Innovators / Early adoptors / Early majority.

Liz Rice balaie ensuite les nouveautés de l’ensemble des projets, projets que vous pouvez retrouver en détail ici : https://www.cncf.io/projects

A noter en particulier : 2 projets qui étaient en phase de « Sandbox » lors de la dernière KubeCon sont passés au stade « Incubation » ; ce sont CoreDNS et Linkerd.

Pour sa part, Kubernetes est le 1er projet à atteindre le stade « Graduated », ce qui prouve la maturité du projet.

Voir la vidéo (après introduction sur le No Code par Keylsey Hightower)

 

CERN Experiences with Multi-cloud federated Kubernetes – Par Ricardo Rocha / Clenimar Filemon du CERN

Le CERN nous propose, au cœur de la Keynote, un petit tour assez fascinant dans ses activités quotidiennes : matière, anti-matière, collisions d’atomes à grande vitesse… ceci toujours associé à des chiffres incroyables sur la quantité de données générées par toutes ces expériences.

Les données brutes se comptent en PB/seconde ; 320k coeurs sur l’OpenStack ; 4300 projets ; 250Pbytes de données annuelles ; 3,3k utilisateurs ; 10k hyperviseurs ; 210 clusters k8s, certains jusqu’à +1k nœuds.

Même avec ces ressources, ce n’est pas suffisant pour traiter toutes les données, d’où l’utilisation d’une architecture distribuée (hybride) pour atteindre environ 700k coeurs.

A retenir, leurs 3 motivations principales pour fédérer :

• Les pics périodiques de charge, pendant les conférences scientifiques internationales par exemple.
• La simplification au niveau du monitoring, de la gestion du cycle de vie, des alarmes, avec l’ajout d’outils qui s’intègrent nativement dans les infrastructures.
• Le déploiement : API uniformisée, réplication, load balancing.

Voir la vidéo

 

CNCF 20-20 vision – par Alexis Richardson, CEO & Fouder Weaveworks

Pour terminer la Keynote, un peu de prospective avec Alexis Richardson qui nous livre sa vision de l’avenir du CNCF.

Dans une analogie en hommage au Danemark, il compare le CNCF en 2016 à un amas de briques de Lego – en désordre – qui a connu une phase de startup avec k8s.

L’objectif du CNCF est qu’à terme, chacun puisse se servir de chaque brique indépendamment pour construire le service dont il a besoin. Alexis Richardson utilise le terme de « Componentisation » pour reprendre ce principe.

Cette comparaison sera reprise par plusieurs conférences et c’est l’image qui reste de cette keynote.

Comment voit-il la plateforme et le CNCF en 2020 ?

  • Du Cloud d’abord, simple et aussi ouvert que Linux
  • Une vélocité accrue, un faible coût d’entrée, l’explosion des services à valeur ajoutée
  • Une plateforme compatible avec tous les clouds (Cloud-agnostic)
  • Qui comprend : des applications, un marketplace, une plateforme cloud, de la CI et des guides de bonnes pratiques
  • Les développeurs se concentrent sur l’écriture du code, et uniquement ça
  • La convergence du Serverless et de k8s : on dira à k8s « exécute mon code »

Quelques points d’étape clé sur lesquels se concerntrer en 2018-2019 pour y arriver : sécurité / stockage / interfaces.

Comment aller plus vite ?

  • Cloud platform supportée par tous
  • Explosion d’apps sur le marketplace
  • GitOps pour accélérer les livraisons
  • Et k8s comme solution centrale.

Enfin, les développeurs sont au cœur de cette évolution. Ils vont accroître leur liberté et leur pouvoir, et donc aussi leurs responsabilités ! Leur éthique sera clé.

Voir la vidéo

 

Use Cases et retours d’expériences

Kubernetes & Taxes : Lessons learned @ the Norwegian Tax Administration (NTA) – par Bjarte Karlsen

La conférence porte sur le retour de NTA sur leur utilisation du cluster.

Pour rappel, NTA collecte les taxes et impôts en Norvège. C’est donc une entité gouvernementale de taille importante – la partie IT emploie à elle seule plus de 1000 personnes, dont 400 développeurs répartis sur 3 sites.

Pour les citoyens norvégiens, la déclaration d’impôts est extrêmement simple : ils reçoivent un lien, vérifient le document en pdf, et dans 96 % des cas les informations sont correctes et il suffit de valider.

Afin de répondre au double besoin « Développer plus vite et Opérer plus efficacement », la transformation de l’IT a porté sur l’ensemble de la chaîne de production des applications.

Bjarte Karlsen compare, pour chaque étape, le avant / après, les limitations de départ et les raisons et avantages des choix faits : « build » des applications, déploiement, intégration et exploitation.

Pour les détails sur l’architecture et les processus, la conférence méritera d’être visionnée dans son intégralité. A noter : ils ont créé en interne leur propre « wallboard » pour suivre de manière synthétique beaucoup d’applications – là où les outils existants sur Jenkins et k8s donnaient beaucoup d’informations sur peu d’applications.

Ses conclusions en terme de méthodologie sont intéressantes :

  • Créer et diffuser des contrats simples et lisibles pour les équipes utilisatrices : contrat pour construire l’application, pour la déployer, l’intégrer, l’exploiter
  • Respecter le principe du « loose coupling » : lorsque des services doivent communiquer, il est important qu’il n’y ait pas d’attaches fortes entre eux, mais plutôt qu’ils exposent chacun le minimum nécessaire
  • Utiliser le principe « Lego » : K8s, Openshift, etc. doivent être utilisés comme des briques pour créer un système qui soit adapté à votre usage
  • Attention à la hype ! Il conseille d’utiliser ce qui est solide et éprouvé
  • Enfin : une plate-forme doit être… boring ! Elle ne doit pas réserver de suprise. L’infrastructure, ça doit marcher – pas être excitant

Anatomy of a production outage – par Oliver Beattie, head of engineering, Monzo Bank

Lors de la Keynote de fermeture de la 1ère journée, Oliver Beattie revient sur une panne importante récente qui a affecté Monzo Bank, et partage le Post-Mortem avec les 4000 participants dans la salle.

Les acteurs de la panne : Kubernetes – etcd – Linkerd – et des humains bien sûr.

Point de départ un upgrade d’etcd, de la version 2 à la 3, suivie de la mise en production d’une nouvelle fonctionnalité qui se comportait de manière étrange et a donc été supprimée des services.

Olivier Beattie nous livre le détail minuté de l’enchaînement malheureux des dysfonctionnements, actions et réactions, jusqu’à la panne totale du cluster.

Au final, l’indisponibilité du cluster a duré 1h21 – cependant la majorité des paiements ont continué à fonctionner et il y a eu uniquement 2 plaintes de clients.

Parmi les root causes :

  • Un Bug dans le client gRPC qui a affecté etcd.
  • L’incompatibilité entre Linkerd et k8s dans des versions spécifiques à cause du changement de la désignation d’un empty endpoint de [] à null.
  • L’erreur humaine et de mauvaises décisions, par exemple re-démarrer Linkerd alors que ce n’était pas nécessaire.

Les leçons à tirer de cet événément:

  • L’importance du « Defence in depth » (= empilement des couches de sécurité). Le concept peut s’adapter à la fiabilité. Un système « fallback » existe en cas de panne totale du système pour éviter que les transactions s’arrêtent en cas de panne totale, ce qui a été très utile ici.
  • L’intérêt du « Chaos engineering » utilisé par Netflix. Ce n’est pas fait chez eux, mais il pense que cela aurait pu permettre d’éviter ce type de panne.
  • Plus de monitoring, et le rendre plus visible. Il faut mettre le monitoring sous le nez de tous, au moins pour que ce soit impossible à ignorer.
  • Etre transparent, « embrace the community ». C’est bien l’état d’esprit de leur entreprise. Ce post-mortem a été rendu public afin que tout le monde puisse apprendre de cet erreur. C’est aussi important finalement de parler des échecs que des succès !

Pour en savoir plus, voir les slides ou voir la vidéo (recommandé)

 

 

Service Mesh

Migration de Nginx à Envoy

Turbine Labs a décrit le process de migration de ses proxy, déployés au sein d’un cluster Kubernetes pour ses services, de Nginx à Envoy. Envoy est un proxy de nouvelle génération, adapté aux environnements dynamiques, et en particulier à Kubernetes.

La partie technique de la migration était finalement assez simple, et un des intérêts de cette conférence était le retour d’expérience sur la planification et les bonnes pratiques à mettre en place pour la migration finale.

Notamment :

  • Est-ce qu’Envoy fournit les mêmes fonctionnalités que Nginx ?
  • Pour les fonctionnalités manquantes, est-ce qu’il est facile de les implémenter (la réponse est oui, contribuer au core d’Envoy est plus simple que de contribuer à Nginx) ?
  • Est-ce que les opérateurs auront accès au même outillage (logs, métriques, packaging, …) ?

Une fois les tests effectués et les résultats concluants, le déploiement de la nouvelle solution se fait par étape :

  • Prévoir l’échec (on prévoit en général le succès, mauvaise idée) : comment revenir en arrière, et quels sont les critères qui justifient un retour arrière ?
  • Déploiement partiel (Canary deployment)
  • Déploiement complet
  • La migration a permis à Turbine Labs de grandement simplifier les déploiements, et a également ouvert une porte vers des évolutions futures, plus complexes à mettre en oeuvre rapidement avec Nginx.

Introducing Envoy-Based Service Mesh at Booking.com

Présentation de la solution de service mesh mis en place chez Booking.

L’idée du service mesh est d’abstraire des applications les problèmatiques et l’infrastructure de communication entre services (en rajoutant des outils de tracing, monitoring bref de l’observabilité).

Le service mesh se divise en deux parties :

  • le plan de données est habituellement assuré par un proxy
  • le plan de contrôle gérant la configuration du plan de données.

Le service mesh fait partie de la transformation numérique de Booking :

  • passage d’applications monolithiques vers des architectures micro-services
  • passage de Bare Metal vers des infrastructures cloud native

Envoy est choisi (par rapport à linkerd) pour son support des redémarrages à chaud sans impact (graceful restart) et son support de TCP (pas uniquement HTTP).

Pour le plan de contrôle, une solution maison est développée (Istio n’étant pas encore disponible au démarrage du projet). La solution est basée sur zookeeper pour le stockage de configuration et la découverte de services. Un service basé sur git permet d’appliquer les changements (avec une politique de canary et la possibilité de rollback).

Autre point essentiel du service mesh : l’observabilité. Une tentative avec graphite a été abandonnée (solution trop lourde, ne tenant pas la charge). La solution retenue est basée sur prometheus

Retours :

  • La mise est place d’envoy rajoute 1 ms de latence en moyenne sur les 100K requêtes par seconde, avec une période plus impactante en HTTPS le temps d’initialiser les sessions SSL.
  • Le graceful restart fonctionne très bien 99% du temps : l’exception arrive lors de mises à jour majeures d’envoy.
  • Il n’y a pas de configuration de keepalive TCP, ce qui entraine des connections bloquées (fonctionnalité arrivant dans la version 1.7 d’envoy)
  • Problème rencontré : un changement de nom d’objets dans la configuration entre les versions 1.5 et 1.6 cluster_name -> cluster_names

Conclusion :

Le service mesh est une brique indispensable pour mettre en place un Service Level Objective (SLO).

 

Sécurité

Securing your kubernetes delivery pipelines with Notary and TUF – IBM

Comment amener de la confiance dans les images déployées dans Kubernetes ? Cette problématique est une des pierres angulaires de la sécurité dans l’orchestration de conteneurs.

IBM présente une idée plutôt intéressante pour répondre à la problématique. Il existe tout ce qu’il faut dans l’ecosystème CNCF : Notary (basé sur TUF) permet de signer et vérifier des images docker. Mais Notary n’est pas directement utilisable dans Kubernetes, il n’y a pas de flexibilité (toutes les images sont vérifiées, ou aucune ne l’est).

Portieris (github.com/ibm/portieris) est un contrôle d’admission « custom » permettant de valider la provenance des images en interrogeant Notary. Le contrôle d’admission est de type « mutate » remplacant l’image classique `name:tag` par `name:tag@sha256:hash`

Il est ensuite possible de mettre en place des politiques d’image à base de :

  • liste blanche
  • sélection de namespace
  • clé de chiffrement spécifique (dans ce cas la clé est stockée comme un secret dans kubernetes)

Pour l’instant le projet ne sait utiliser que des serveurs Notary d’IBM mais le projet est vraiment intéressant. A suivre donc.

Container Runtime

Containerd, what does it mean for me?

Containerd est la couche de base de docker utilisé pour lancer les conteneurs (ie docker épuré des fonctionnalités swarm notamment). Containerd met l’accent sur la simplicité, la robustesse et la portabilité.
Les fonctionnalités de containerd :
  • Support des images conforme à la spécification  OCI
  • Support  du runtime conforme à la spécification OCI
  • Support du cache, du téléchargement et de la publication  (pull et push) d’images
  • Primitives de gestion de réseaux (création, modification, suppression)
  • Gestion des espaces de noms existants pour pemettre aux conteneurs de les rejoindre
Il est possible de manipuler containerd en utilisant le client CLI ctr.
Projets utilisant containerd :
  • Moby
  • LinuxKit
  • Kubernetes
  • LCOW (Linux Containers On Windows)
Le projet Moby est l’ecosystème opensource issu du projet docker contenant les briques :
  • Docker engine
  • RunC
  • SwarmKit
  • HyperKit
  • LinuxKit
  • InfraKit
Containerd contient depuis la dernière version (1.1) un plugin CRI intégré permettant de s’interfacer directement avec Kubernetes.
Comment K8s et containerd intéragissent ? [Kubelet] –(CRI)–> [(CRI plugin) containerd] –> [(gestion des conteneurs) runC]

 

CRI: the second blossom of container runtimes

Historiquement, kubernetes a été développé au-dessus de l’API de Docker, celui-ci étant le seul moteur de conteneurs exploitable en 2014.

Cependant, Kubernetes n’a pas vocation à être intrinsèquement lié à Docker et peut théoriquement utiliser les nouveaux challengers comme rkt ou hypersh … d’autant que Docker a évolué au-délà du simple moteur de conteneurs et embarque de nombreuses fonctionnalités inutilisées dans Kubernetes (comme l’orchestration swarm, la gestion réseaux ou le stockage par ex).

Devant les difficultés d’intégration rencontrées, les développeurs de Kubernetes ont décidé de créer une interface générique de pilotage de moteurs de conteneurs (CRI – Container Runtime Interface):

  • API basée sur gRPC (opensource et potentiellement plus performante que HTTP/REST)
  • décrit ce que kubelet attend d’un moteur pour la construction de conteneurs: créer le bac à sable du Pod, créer les conteneurs, démarrer les conteneurs, etc.

Depuis la version 1.7 de kubernetes, Docker est utilisé au travers de CRI et plusieurs alternatives sont disponibles:

  • Cri-o: développé principalement par Redhat
  • Containerd (avec le plugin CRI): développé par Moby et Kubernetes, déjà utilisé par Docker en interne
  • Frakti: developpé par Hyper.sh pour piloter le moteur katacontainer
  • La suite de la présentation reprend en détail le design de chaque implémentation

En conclusion, les administrateurs et installeurs de Kubernetes ont la possibilité de choisir le moteur de conteneurs le plus adapté à leur besoin… ou d’en intégrer un nouveau le plus simplement possible.

CI / CD

Jenkins X : CI/CD sous Kubernetes facile

Vous avez une application conteneurisée. Vous faites vos déploiements dans le cloud, dans un cluster Kubernetes. Vous avez opté pour un déploiement continu automatisé sur le principe de GitOps.

La solution Jenkins X est à envisager :

  • http://jenkins-x.io/
  • http://github.com/jenkins-x/jx

Le principe est d’installer un environnement de déploiement continu prêt à l’emploi dédié à chaque équipe.

Les principales étapes sont simples :

  • installation de Jenkins X, un binaire qui installe l’application jx dans un cluster Kubernetes existant ou un minikube. Le seul pré-requis est d’avoir activé les RBAC du cluster. Jenkins X est également capable de créer un cluster sous GKE, AKS ou minikube ;
  • initialisation du projet : un ensemble d’outils dédiés au déploiement continu est installé : Helm, Scaffolds, Kaniko, Jenkins, KSync, Monocular, Nexus… prêts à l’emploi dans Kubernetes, et création d’une arborescence incluant les charts Helm (https://jenkins-x.io/demos/create_cluster/) ;
  • création d’un projet git pour l’application, la configuration permet d’automatiser l’ensemble des étapes : de la création du projet dans Github au déploiement de l’application.

Le principe est d’avoir un processus entièrement automatisé allant du build des images docker, aux charts Helm et au pipeline (des tests à la mise en production). La seule étape manuelle restante est la validation des pull requests. Le projet met également l’accent sur un feedback important sur le déroulement du pipeline et l’évolution du code, dans slack par exemple.

Voir la vidéo