Sommaire de ce dossier complet KubeCon + CloudNativeCon 2018 à Copenhague par Osones :
La deuxième journée de Kubecon a commencé un peu plus tôt pour quelques courageux Osoniens qui ont tenté (et réussi !), dès 6H30, le défi des 5km organisé à la fraîche par la CNCF. Pour les autres, la journée démarre une fois de plus par la traditionnelle Keynote, dont voici la substance :
Keynotes
Contrairement à hier, une seule keynote aujourd'hui ! On y note les interventions de Aparna Sinha (Group Product Manager, Kubernetes and Google Kubernetes Engine, Google) et de Brandon Philips (CTO chez CoreOS, désormais sous pavillon RedHat).
En tant que Group Product Manager pour Kubernetes, Aparna a insisté sur deux points :
- La maturité de Kubernetes, aussi bien techniquement (Kubernetes est en deuxième place derrière Linux en nombre de pull request et d'issues sur github) que commercialement (54% des entreprises ont déjà essayé Kubernetes - où du moins disent le faire).
- Un gros focus sur la sécurité et l’étanchéité des conteneurs. À cette occasion Aparna nous a présenté [gVisor](https://github.com/google/gvis un projet mis au point par Google qui propose des kernels restreints au userspace, Gvisor permet de disposer d'espaces de "sandbox" en quelques minutes. Nous reviendrons sur gVisor dans la partie "conférences" de cet article.
Brandon Philips, quant à lui, a introduit un nouveau framework : "Operator Framework". Proposé par Redhat et la communauté Kubernetes, cet outil opensource repose sur la notion d' "Operator", une méthode pour packager, déployer et manager plus simplement vos applications Kubernetes - c'est-à-dire une application déployée sur Kubernetes et managée via l'API Kubernetes et les outils kubectl. Si ce framework vous intéresse, rendez-vous sur https://coreos.com/operators.
Enfin, nous retiendrons Dave Zolotusky, Software Engineer chez Spotify, qui nous a proposé un retour d’expérience côté end-user, non pas au niveau de la technologie mais de la communauté : l'entre-aide existe vraiment, les contributeurs/influenceurs sont accessibles et volontaires, et globalement la communauté Kubernetes n'attend que vos questions ! Il a également insisté sur le fait que plus de 80% des développeurs souhaitent contribuer sur des projets open sources, et qu'il faut donc leur donner la possibilité de le faire.
Voilà pour les points essentiels que nous avons retenus. Place désormais aux conférences !
Retours de quelques unes des conférences
Managing Kubernetes Day 2 Operations - Craig Tracey, Staff Field Engineer, Heptio
Vous venez d'installer un cluster Kubernetes pour la première fois ? Bravo, vous avez passé l'étape du jour 1, vos serveurs sont en place et votre cluster est déployé. What now?
Le challenge de la mise en place d'un cluster Kubernetes dans un projet reste avant tout culturel plus que technique, car il faut revoir toute l'approche de développement. Or, malgré l'intérêt porté à Kubernetes, la plupart des administrateurs ont moins de deux ans d'expérience sur cette technologie, et une grande partie des présents dans la salle l'utilisent depuis moins d'un an.
C'est pourquoi Craig Tracey, co-auteur de Managing Kubernetes aux éditions O'Reilly's, nous fait ici un retour d'expérience sur la manière dont il gère la maintenance d'un cluster Kubernetes. C'est ce que l'on appellera ici la stratégie day 2.
Voici quelques conseils à retenir pour la stratégie Day 2 :
- Le principe du KISS (keep it simple, stupid) reste plus que jamais pertinent
- Ne jamais perdre de vue l'expérience client
- Si vous disposez déjà d'outils pertinents (supervision, etc.), ne cherchez pas nécessairement à tout raser : gardez-les !
- Miser sur l'anticipation. Il est important de penser non seulement au déploiement de son infrastructure Kubernetes, mais il l'est tout aussi important d'avoir une stratégie pour la suite des événements et savoir prendre les bonnes décisions dès le début, notamment pour tout ce qui ne peut pas être paramétré à posteriori.
Plus concrètement, Craig commence par adresser l'installation de la plateforme et nous met en garde sur certaines décisions (notamment d'optimisation hardware) que l'on ne pourra plus modifier, et qu'il faut donc bien définir. Un bon conseil peut consister par exemple à sortir etcd du cluster pour qu'il ne dépende pas directement de kubernetes. Il est également pertinent d'anticiper les choix d'architecture dans des environnements multisite : Un seul cluster éclaté sur plusieurs sites au sein d'une même région ? Un cluster par site par région ?
En ce qui concerne le serveur API, il faut avoir dès le début une stratégie concernant :
- la gestion de l'authentification (resources UserInfo, OIDC pour l'utilisation d'un annuaire externe, dashboard pour simplifier la gestion - n'oubliez pas de le protéger avec de l'authentification)
- la gestion des autorisations (RBAC, Secrets, garder en tête que donner accès à un pod pour un utilisateur revient à lui donner accès aux secrets de ce pod). La gestion des policy relatives aux pods doivent être les plus précises possible.
- le contrôle d'admission (Quotas, règles de sécurité par pod, règles métier...)
- Les controleurs "maison" nécessaires (CRD/Aggregate API). Craig nous rappelle qu'on peut déployer son code comme un controller capable de réagir aux changements qui se produisent dans le cluster, pour des problématiques comme la mise à jour des services discovery, par exemple.
La session s'achève avec quelques mentions des futures 'features' kubernetes: il est prévu de pouvoir administrer des cluster kubernetes depuis kubernetes. Enfin, l'objectif et de continuer à rendre les déploiements vers différents acteurs du cloud plus simples et génériques.
En résumé, au jour 2, les sujets à gérer sont relativement les mêmes qu'au jour 1 ou même qu'au jour N, le but étant d'évoluer vers un mode de déploiement continu où chacune de ces problématiques peut être traitée à tout moment.
SIG Storage
Le Special Interest Group Storage est responsable de toutes les problématiques liées au stockage, de la même façon que le SIG Networking s'occupe du réseau. Les features gérées par le SIG incluent les PV (Persistent Volume), PVC (Persistent Volume Claims), Storage Class, dynamic provisionning ainsi que les plugins comme CSI (Container Storage Interface), Secrets et ConfigMap. La communauté comprend une vingtaine de sociétés différentes assurant la viabilité du SIG.
Cette breakout session a pour but principal de présenter les travaux actuels du SIG et les développements futurs. Le focus est actuellement (mais pas uniquement !) mis sur CSI, la future "Container Storage Interface". De la même façon que CNI (Container Network Interface), CSI vise à fournir une interface pour n'importe quel plugin de stockage. La grande différence est que ce code est actuellement intégré au controller manager et doit donc être retiré avec précautions afin de ne pas casser ce dernier. C'est donc un travail long et difficile. Sortir cette partie de Kubernetes a notamment comme but d'accélérer son développement et de décorréler le cycle de release des plugins de celui de Kubernetes.
L'ephemeral storage request API limit fait aussi son arrivée, celle-ci permet de limiter le stockage éphémère consommé par les pods, qui pourrait provoquer un classique no space left on device dans le cas de logs incontrôlés par exemple. L'API permet aussi de limiter la taille des layers d'une image ainsi que la taille de la layer RW du container. Enfin, un système de prévention de suppression de PV si celui-ci est attaché à un pod, avant cette feature, il pouvait s'avérer extrêmement compliqué et périlleux de supprimer des PV encore attachés.
Pour les futures versions 1.11 et 1.12 de Kubernetes, l'accent est mis évidemment sur CSI, sur le stockage local ainsi que sur un nouveau scheduler, le Topology aware volume scheduling qui résoudra notamment les problèmes de placements entre volumes et pods dans le cas d'un cluster réparti sur plusieurs zones de disponibilité. Plusieurs storage class (une par AZ) permettaient de hacker ce problème mais une solution pérenne méritait d'être trouvée.
Machine learning avec Tensorflow et Kubernetes
Le jeu de Go est un exercice très populaire en machine learning car très complexe. Cette conférence nous propose de découvrir MiniGo comme exemple de machine learning utilisant à la fois Tensorflow et Kubernetes. Pour rappel, Tensorflow est un framework de machine learning développé par Google capable de calculer des modèles avec des CPU / GPU ou encore TPU (Tensor processing unit).
Avant toute chose, il faut bien distinguer les trois choses suivantes quand on parle de Machine Learning :
- Les données : serviront d'entrée au modèle
- Le modèle : pour citer "pile de maths" l'intelligence.
- Le résultat : réponse fournie par le modèle.
Ce que l'on appelle entraînement est le fait d'entraîner un modèle afin de l’améliorer, des données sont fournies en entrées, les résultats sont comparés avec des résultats que l'on connait et on recommence. Tout cela dans le but de réduire le taux d'erreur de l'algorithme.
Dans le cas du jeu de Go et de miniGo, l'algorithme fourni deux résultats :
- la policy : le prochain mouvement possible
- la value : qui gagne
On obtient ce que l'on appelle une "reinforcement training loop" : créer de meilleures données afin d'entraîner de meilleures IA, afin de créer de meilleures données :
- Un jeu de données est fourni en entrée
- L'IA joue une partie
- L'IA génère de nouvelles données
- Ces nouvelles données sont utilisées pour entraîner de nouveaux modèles.
Le machine learning est un processus lent lorsqu'il est réalisé sur un CPU, afin d'optimiser les calculs il est courant d'utiliser des GPUs. Pour entraîner ces modèles, il est nécessaire de jouer un nombre conséquent de parties, souvent de l'ordre du million. Multiplier par le temps d'une partie, ce processus peut être très long ! Heureusement, on voit bien que ce processus est facilement parallélisable.
Alors comment peut on passer à l'échelle des millions de partie de Go ? Nous n'avons pas encore parlé de Kubernetes depuis quelques temps donc ...
Kubernetes propose l'API batch qui permet de paralléliser des jobs, ce qui est parfait pour ce cas d'usage. Le workflow est le suivant :
- Les parties (Game files) et les modèles sont stockés sur Google Cloud Storage
- L'application est bien sur conteneurisée.
- Les parties sont parallélisées à l'aide de Kubernetes : 3.1 Kubernetes est utilisé comme une file d'attente : un job télécharge le dernier modèles, joue une partie, upload le nouveau modèle et s'éteint.
- GKE propose des instances avec GPU afin d'optimiser le temps de calcul.
Voila, je ne vous cache pas que le machine learning est un sujet assez nouveau pour nous et si vous souhaitez expérimenter, la démo est disponible ici
From PaaS to Kubernetes : Combining the Power of Kubernetes with the Most Innovative Features of PaaS
William Denniss, Product Manager, Google
Le thème principal posé par William dans cette conférence tourne autour d'une série de questions simples, pour lesquelles les réponses peuvent ne pas être triviales !
Pourquoi le PaaS est-il populaire ?
- car c'est facile pour commencer (il faut juste choisir le bon service de PaaS)
- car il suffit de "git push" pour déployer
- car il n'y a pas besoin de manager l'infrastructure
- car cela se combine facilement avec des services SaaS
Pourquoi Kubernetes est-il populaire ?
- car il est agnostique du langage du programmation de l'application
- car ce n'est pas "vendor locking"
- car cela permet une optimisation des ressources
- car on peut construire ses propres pipelines
- car il y a beaucoup d'add-ons opensource
- car cela permet de déployer plus que simplement des applications dîtes "12 factors"
La courbe d'apprentissage du PaaS permet de résoudre rapidement les problèmes les plus simples, mais on peut rapidement se heurter à d'importantes difficultés lorsqu'on souhaite résoudre des problématiques plus complexes pour lesquelles le PaaS n'était pas prévu. Kubernetes en revanche demande plus d'investissement initial mais permettra de résoudre les problèmes plus complexes.
William fait le constat suivant : Kubernetes permet une abstraction au niveau des workloads, "un workload-level abstraction".
Il a ensuite fait une démonstration présentant le notion de GitOps (ou configuration as code) grâce à divers outils et services de Google Cloud Platform : il lui suffisait de modifier le code source de l'application ou le manifest yaml afin que Skaffold détecte les modifications et rebuild/redéploie l'image/conteneur (si c'est le code source qui a été modifié), ou modifie le déploiement de l'application (si c'est le manifest YAML qui a été modifié).
Il a conclu en nous donnant quelques recommandations :
- il faut tout automatiser
- il faut construire des "packs"
- il faut bien réfléchir au modèle économique que vous choisissez (payer au conteneur ou au compute node)
- il nous recommande d'utiliser Skaffold (détecte les changements de code et/ou de configuration puis rebuild/redéploie l'application)
Happy Helming with Service Catalog - Jeremy Rickard, Microsoft
Les applications à états (stateful) ont toujours posé problème au moment de leur containerisation. Les solutions de stockage et les best practices évoluent, mais on reste assez frileux pour déployer des bases des données au autres applications de ce type dans nos clusters Kubernetes.
Jeremy Rickard de chez Microsoft nous propose d'utiliser au maximum Helm et les charts de la communauté pour résoudre ce problème, au moins pour tout ce qui touche à la partie développement. Des dépendances entre les charts sont définies à l'avance, de façon à être sûr que tous les composants d'une applications seront déployés dans l'ordre et avec la bonne configuration. On peut aussi utiliser les charts de la communauté comme base pour créer nos charts, ce qui rend ce système très puissant.
Maintenant, comme le dit Kelsey Hightower dans son Tweet, manager une application stateful est simplement un cauchemar. C'est là qu'interviennent les services managés des Cloud Providers (publiques ou privés). Seulement, comment conserver une infrastructure homogène tout en ayant des ressources générées de plusieurs manières ? C'est là qu'intervient le Service Catalog.
Ce Service Catalog permet de gérer des ressources externes au cluster Kubernetes... dans Kubernetes !
En effet, on peut ajouter un nouveau service Broker (Open Service Broker) qui saura discuter avec les API du Cloud Provider [CP], et avec lequel saura discuter Kubernetes/Service-Catalog. Ainsi les ressources seront générés depuis des Manifests. Cependant l'évolution des API des CP peut devenir lourde, et il est intéressant de passer par des Helm Chart pour conserver une homogénéité global de ses services/ressources. Les conditions nous permettent aussi de rendre la création de ressources dépendantes les une des autres, et par exemple attendre qu'une base de données managées soit créée et son endpoint retourné pour pouvoir le stocker dans un Secret. Ainsi les autres services peuvent accéder à ce secret afin d'intéragir avec cette ressource managée.
Une live-demo a été effectué durant la présentation avec la Cloud Provider Azure, le tout étant disponible sur ce repo GitHub.
Best Practice for Container Security at Scale - présentation de gVisor
Dawn Chen, Senior Staff Software Engineer, Google Zhengyu He, Staff Software Engineer and Manager, Google
Google lance 4 milliards de conteneurs par semaine. Selon une analyse ESG, 94% des sondés pensent que les conteneurs affectent négativement la sécurité.
Zhengyu He a passé en revue les mécanismes de défense disponibles sous Linux en général, que l'on parle conteneurs ou non :
- Lancer les programmes sous un utilisateur (et non en root)
- Limiter les accès au système de fichiers via les droits UNIX
- Limiter la capacité du programme à envoyer des signaux tels que SIGKILL
- Limiter les capabilities
- Utiliser les cgroups pour contrôler l'utilisation des ressources
- Utiliser les namespaces pour isoler certaines ressources les unes des autres (tables des PID, tables de routage, ...)
- Mettre en place du MAC (Mandatory Access Control) avec des outils tels que SELinux, AppArmor
- Filtrer les syscalls mis à disposition de l'application ou du conteneur avec seccomp-bpf
Malgré toutes ces protections, certaines failles du noyau ou d'un driver sont telles qu'un conteneur ou une application compromise peuvent compromettre l'ensemble de l'ĥôte exécutant le code. Face à ce constat, Dawn Chen nous a présenté gVisor. Son but ? Fournir une isolation suffisamment telle qu'un conteneur de source douteuse ou contenant une application à la sécurité questionnable ne puisse compromettre l'hôte entier. Cette isolation doit pouvoir se faire sans travail excessif ni pénalité de performance.
gVisor est une sandbox pour les applications :
- Une runtime compatible OCI appelé runsc est à utiliser
- ils ont réimplémenté un grand nombre de syscalls en userland : ils en sont pour l'instant à 211 syscalls (soit deux tiers des syscalls possible).
- gVisor ne fait pas que du filtering (comme secconf-bpf)
- Il n'y a pas de filtres à écrire
- Il est écrit en Go
Il est performant (boot time de 150ms, overhead mémoire de 15Mo) mais vise surtout les conteneurs non dignes de confiance. Les workloads utilisant beaucoup de syscalls verront une pénalité de performance, et l'accès direct au hardware sera impossible.
Kubernetes-style APIs of the Future - Daniel Smith, Google
Depuis le début, Kubernetes s'est basé sur des API. Daniel Smith nous explique que l'équipe de développement dont il fait partie a créé un nouveau style d'API sans se baser sur les existants, et justifie son choix : aucun des styles d'API utilisés ne s'adaptait à Kubernetes et faisait exploser la complexité.
Les APIs plus traditionnels comme REST ou même des mécanismes plus modernes comme gRPC, multiplient les combinaisons possibles d'actions et complexifient énormément les états possibles des ressources par leur nature impérative, et ne sont viables que si une documentation très détaillée est disponible. La solution, pour Kubernetes, c'est un style beaucoup plus déclaratif et une action, "apply", qui est capable de calculer les changements à appliquer non seulement aux ressources mentionnées dans les requêtes, mais à toute autre ressource qu'il faudrait modifier par la suite. Cela est possible grâce à la standardisation dans la structure des données et dans les verbes HTTP utilisés. Dans Kubernetes, un utilisateur qui sait créer un pod saura aussi créer un service, par exemple (il lui suffit de connaître la structure de la ressource qu'il va déclarer).
Selon Smith, il y a d'autres éléments en dehors de Kubernetes qui pourraient bénéficier de ce type d'API dont les machines virtuelles, load balancers, bases de données, switches, routers, et même les objets connectés. Autrement dit, tout ce qui peut être dans des différents états ! Parce que nous travaillons sur des systèmes complexes et qu'il est compliqué d'avoir une idée détaillée de son système en tête en permanence, Smith vaticine qu'on commencera à voir ce style d'API ailleurs. Interrogé au sujet de ce que Google prévoit de faire avec des API à la Kubernetes, il a répondu un "wait and see" assez timide mais assez révélateur, so... wait and see!
Building Applications to Increase Kubernetes Adoption, and Make Life Easier Once You've Adopted It - Kate Kuchin, Heptio
Le titre de la session est un peu confus et le speaker avoue que "UIs for k8s" aurait été plus simple. Quoi qu'il en soit, Kate Kuchin défend l'idée d'une bonne UI complète pour Kubernetes, travaillée par des experts en UX. Elle nous avance que sa société, Heptio, travaille sur le sujet et qu'un lancement est imminent, sans pouvoir en dévoiler plus. Elle commence par expliquer que les interfaces graphiques sont un outil précieux pour la formation quand on est débutant. Elle conseille aux "newbernetes" de ne pas se laisser intimider par la complexité de la plateforme. Son message pour ceux qui doivent transmettre les connaissances, par contre, c'est plutôt d'être conscient du niveau de la personne à qui on s'adresse et de se limiter le plus possible aux concepts fondamentaux sans rentrer dans les excentricités, histoire de ne pas décourager les gens !
L'interface graphique a des atouts autres que son intérêt pédagogique : elle est utile pour visualiser des données et comprendre les valeurs dans leur contexte, de façon plus intuitive qu'avec une CLI. Cela ne veut pas dire qu'il faut utiliser une UI pour tout, et Kuchin l'a bien compris : l'importance d'avoir des fichiers de code versionnés qui définissent une infrastructure (et qui sont à jour avec son état) est capitale !
L'exemple à l'appui pour ses arguments : un projet de chez Heptio, appelé Sonobuoy et qui permet de faire un diagnostic de l'état de conformité d'un cluster Kubernetes. Bien qu'utile et complet, cet outil est complexe et produit un résultat avec des milliers de lignes de XML pas faciles à digérer en l'état. Elle présente un nouveau projet, Sonobuoy Scanner, qui permet de simplifier la tâche avec une interface visuelle moins intimidante.
Understanging Distribtes Consensus
Laura Frank, Director of Engineering (CloudBees)
Dans cette conférence très intéressante, il est question de consensus distribué, le mécanisme utilisé dans Docker Swarm, Nomad, Consul ou etcd pour élire un manager ou logguer un évènement de manière répliquée. L'outil sous-jacent dans les deux exemples précédents est Raft, mais il en existe d'autres. Par exemple Zookeeper utilise ZAB (Zooker Atomic Broadcast).
Ces outils reposent sur la notion de quorum, soit le minimum de votes à obtenir
pour exécuter une opération. Cette valeur est toujours égale à (N/2)+1, N étant
le nombre de noeuds candidats du réseau. C'est pour cela qu'on recommande souvent
de ne pas monter de cluster avec un nombre de managers pair. Le nombre magique
recommandé : 5, configuration optimale pour faciliter le bon déroulement de
l'algorithme de consensus distribué.
| Nombre de Manager Nodes | Distribution par AZ |
|---|---|
| 3 | 1-1-1 |
| 5 | 1-2-2 |
| 7 | 3-2-2 |
| 9 | 3-3-3 |
Lors du consensus, un manager peut être dans un des trois états suivants :
- Leader
- Follower
- Candidate
Bien sûr, il peut être également injoignable en cas d'incident.
Pour illustrer l'algorithme utilisé dans les opérations de consensus distribué, une démonstration visuelle est visible à l'adresse suivante : démo
Et pour plus de lecture sur le sujet du consensus appliqué aux logs : logging
Getting Started with Logging in Kubernetes
par Eduardo Silva (Treasure-data.com)
Je ne pense rien vous apprendre si je vous dis que les applications génèrent des logs, ces logs comprenant entre autre un message et un timestamp. Contrairement aux applications sur des architectures classiques qui écrivent dans des fichiers, il est tout à fait envisageable et parfois même conseillé dans un conteneur d'écrire les logs directement dans STDOUT et STDERR.
Lorsque vous écrivez dans une de ces deux sorties dans un conteneur, Docker récupère ces logs et les écrit dans un fichier de log sur le filesystem du node, généralement avec le path : /var/lib/containers/<hash du conteneur>.
Avec un système classique, récupérer ces logs est laborieux. Il faut tout d'abord se connecter à la machine (en ssh par exemple), découvrir les fichiers de logs, les ouvrir, le parser, récupérer les informations intéressantes et les enregistrer.
C'est ici qu'intervient Fluentd de la CNCF. Sans entrer dans les détails techniques, cet outil permet de récupérer les logs, les filtrer, et ajoute des informations de contexte avant de l'enregistrer dans un outil tel que Elasticsearch ou encore Kafka. En effet l'information seule est difficilement exploitable. Une salve d'erreurs n'est exploitable que si nous sommes capables de retrouver un node défectueux.
Voilà qui clos le deuxième jour, mais c'est pas fini !
Si vous n'avez pas encore lu le récit du premier jour, vous le retrouverez en suivant ce lien : https://blog.osones.com/kubecon-europe-2018-a-copenhague-jour-1.html. Vous pouvez aussi passer au jour 3 sur ce lien : https://blog.osones.com/kubecon-europe-2018-a-copenhague-jour-3.html !
La team Osones
Découvrez les derniers articles d'alter way
- kubevpn
- Kubernetes 1.32
- re:Invent 2024 : AWS mise tout sur l'IA pour son Cloud
- OVHcloud Summit 2024 : L’innovation au cœur d’un cloud souverain et performant
- Big Data & AI Paris 2024 : L'IA au cœur de toutes les transformations.
- Un retour vers l'open-source ? Vos outils DevOps préférés et leurs equivalents open-source.
