Ces derniers jours, nous vous présentions sur ce blog les retours sur la KubeCon + CloudNativeCon EU 2020, et plus précisément sur le « Jour 0 » ainsi que la première réelle demie-journée de conférence.
Il est désormais l’heure de vous parler de la deuxième après-midi de cette KubeCon + CloudNativeCon, toujours sous la formule « keynotes pertinentes + 4 talks + take away » !
- Keynotes
- Kubernetes Project Update – Vicki Cheung, KubeCon + CloudNativeCon Europe 2020 Co-Chair & Engineering Manager, Lyft
- How to Love K8s and Not Wreck the Planet – Holly Cummins, Worldwide IBM Garage Developer Lead, IBM
- Keep It Simple (Sponsored) – A Human Approach to Coping with Complexity – Hannah Foxwell, Director – Platform Services, VMware Pivotal Labs
- Talks
- [Horgix] Banking on Kubernetes, the Hard Way, in Production – Miles Bryant & Suhail Patel, Monzo Bank
- [Olivier] Multi-Tenant Clusters with Hierarchical Namespaces – Adrian Ludwin, Google
- [Rami] Managing Multi-Cluster/Multi-Tenant Kubernetes with GitOps – Chris Carty
- [Jonathan] Seccomp Security Profiles and You: A Practical Guide – Duffie Cooley, VMware
Keynotes
Les keynotes de cette journée étaient plutôt light en contenu. On ne vous propose ici que celles qui nous ont paru les plus pertinentes, d’où leur nombre limité. Espérons qu’elles soient plus riches demain !
Kubernetes Project Update – Vicki Cheung, KubeCon + CloudNativeCon Europe 2020 Co-Chair & Engineering Manager, Lyft
C’est Vicki Cheung qui ouvre cette keynote du deuxième jour et vient nous présenter les dernières innovations de Kubernetes 1.18.
Au programme, 38 améliorations :
- 15 sur le fil stable ;
- 11 en beta ;
- 12 en alpha.
On notera en particulier :
- Les “Raw Block Devices” en GA : cette fonctionnalité offre la possibilité d’utiliser un périphérique en mode bloc sans qu’il soit consommé par une abstraction Kubernetes et présenté à un plus haut niveau. Il est par exemple maintenant possible de consommer un périphérique de stockage (physique ou virtuel : fourni par le réseau) en direct et d’effectuer des opérations bas niveau alors que l’unique façon de le consommer auparavant aurait été sous la forme d’un volume déjà monté par le nœud. Très utile pour déléguer des opérations de bas niveau à des pods.
- Le CSI est désormais supporté par Windows. Cette abstraction qui vise à uniformiser le support des volumes à travers les différents fournisseurs de stockage a gagné en popularité et en adoption chez ces derniers. Il est donc légitime de la voir supportée sous Windows également. C’est un gage d’uniformité sur un cluster hybride comportant à la fois des nœuds Linux et Windows
- HPA Controls : si vous avez déjà mis en place un Horizontal Pod Autoscaler, vous avez forcément eu à vous battre pour le paramétrer correctement et éviter des phénomènes comme le « flapping » (scale up, puis down, puis up, etc.) Cette fonctionnalité apporte des réglages encore plus fins comme la vitesse de scaling, définissables sous forme de profils et consommables par le contrôleur HPA. Reste à voir si cela nous aidera à converger plus facilement vers un comportement attendu ou bien rendra les réglages plus compliqués de par leur minutie…
kuberctl alpha debug: il n’est pas rare d’ajouter un conteneur sidecar de débogage à un pod pour faciliter l’introspection et l’accès au tooling qui ne figurerait pas dans le conteneur d’origine. Cela évite de surcharger une image de production ou même de provoquer des effets de bords indésirables sur son fonctionnement. Depuis quelques temps, il est déjà possible d’utiliser les conteneurs éphémères pour démarrer un conteneur de débogage à l’intérieur d’un pod déjà existant (plutôt que d’avoir à en recréer un et perdre le contexte d’une situation parfois difficilement reproductible). Mais cela demeurait peu accessible (nécessité de patcher le pod avec le conteneur de débogage représenté au format JSON).kuberctl alpha debugs’utilise avec des paramètres similaires àkuberctl execce qui facilitera certainement son adoption.- PodTopologySpread et Node Topology Manager en beta : ces dernières nouveautés du scheduler permettent de distribuer des pods sur des zones de disponibilités afin de minimser l’impact d’un incident touchant un élément critique tel qu’une CPU, un nœud ou bien une zone ou région chez un fournisseur de cloud. Il est également possible paramétrer le comportement en cas d’impossibilité d’affectation, en utilisant par exemple le PodBudgetDisruption.
kubectl diff: nombre d’outils proposent des simulations entre l’état actuel et l’état qu’apporterait l’application d’une série de manifests. Cette opération est maintenant supportée par la Cluster API au cœur même de Kubernetes et est rendue accessible viakubectl diff. Difficile d’obtenir une information plus fiable à ce niveau !
Pour de plus amples informations, nous vous invitons à consulter l’annonce officielle ou les notes de version.
How to Love K8s and Not Wreck the Planet – Holly Cummins, Worldwide IBM Garage Developer Lead, IBM
Avant de parler de la keynote en elle-même : oui, nous aussi nous sommes demandés ce que pouvait être le “IBM Garage”. Un nom qui saute tout de suite aux yeux et qui change des habituels “Labs”. Il s’avère, au final, qu’il s’agit d’une sorte de service proche de l’incubation de startups mais pour des projets bien particuliers. Mais bon, aider des clients à innover, nous aussi on sait le faire, venez nous voir si ça vous intéresse
Cela dit, le talk de Holly Cummins porte sur tout autre chose que l’innovation, ou éventuellement une de ses conséquences : l’impact environnemental, notamment celui de la scalabilité de services par la multiplication.
On constate en effet que, parfois, certains préféreront mettre à disposition plusieurs clusters Kubernetes (c’est un exemple, il y en a d’autres), un pour chaque équipe, plutôt qu’un seul, mutualisé. Mais ceci ne sort pas forcément de nulle part : il y a en effet beaucoup de points techniques empêchant d’avoir de vrais clusters multi-tenants, pour l’instant. Holly prône donc une nécessite d’avancer sur la capacité à mutualiser proprement des éléments centraux de nos stacks technologiques afin de réduire leur empreinte environnementale.
Cela dit… il y a bel et bien un intérêt à pouvoir gérer de la multi-tenancy proprement, mais où est la limite entre autonomie/innovation des équipes et mutualisation à l’échelle ? Sans aucun doute, la keynote d’Hannah Foxwell que nous vous résumons ci-après viendra apporter un complément à cette vision.
Keep It Simple (Sponsored) – A Human Approach to Coping with Complexity – Hannah Foxwell, Director – Platform Services, VMware Pivotal Labs
Nous vous parlions déjà de Hannah Foxwell lors des Lightning Talks de l’année dernière. Son dada ? Le côté humain et psychologique derrière la gestion des opérations – qu’elle appelle d’ailleurs “HumanOps”.
Cette année, ce n’est pas un simple lightning talk qu’elle présente, mais une keynote dédiée à la gestion de la complexité croissante des systèmes avec lesquels nous travaillons quotidiennement. On retrouve bien évidemment les messages habituels concernant la taille d’une équipe et la complexité de communication croissante associée mais aussi d’autres messages moins communs.
Par exemple, beaucoup d’entre nous ont déjà connu la situation suivante :
- Une équipe (ou une personne) commence à mettre en place un service pour se faciliter la vie, à petite échelle
- Une autre équipe fait la même chose de son côté
- Finalement, l’entreprise décide qu’il s’agit de la voie à suivre et lance un énorme projet pour fournir ce service à l’intégralité de l’entreprise
- Le projet se retrouve à devoir répondre à tout un tas de besoins d’entrée de jeu, coûte cher, met longtemps à sortir, tant et si bien qu’il n’est au final plus utile à personne
- “Rinse & repeat”
Hannah se fait donc ici la porte parole d’une approche que nous prêchons nous-même perpétuellement chez Publicis Sapient Engineering : commencer petit et construire itérativement. En particulier, dans le cas de la mise à disposition d’une plateforme, avec les étapes suivantes :
- Commencer d’entrée de jeu avec un état d’esprit “produit” et une approche qui va avec
- Identifier les (autres) early adopters
- Construire un MVP (dont on est potentiellement/probablement soi-même client)
- Créer une roadmap pour les fonctionnalités futures
- Commencer à fournir cette plateforme comme un service (et oui, seulement maintenant, pas avant !)
- Gérer le run et les évolutions du service
Talks
[Horgix] Banking on Kubernetes, the Hard Way, in Production – Miles Bryant & Suhail Patel, Monzo Bank
Lors de la KCCNC EU 2018, nous avions eu le plaisir de voir Oliver Beattie (Head of Engineering @ Monzo) nous présenter en keynote le post-mortem magistral d’un incident de production lié à Kubernetes et Linkerd. Un retour qui s’était avéré très instructif et avait fait preuve d’une ouverture exceptionnelle, tant sur la dimension organisation que humaine et technique, si bien que nous vous l’avions relaté sur ce blog. À l’époque déjà, nous nous étions fait la réflexion qu’une banque tournant sur Kubernetes en production était une belle démonstration de modernité.
Alors cette année, quand nous avons vu un retour d’expérience de Monzo sur leur utilisation de Kubernetes en production, nous ne pouvions pas passer à côté. Le moins que l’on puisse dire, c’est que nous n’avons pas été déçus !
Commençons par dresser le panorama de l’environnement technique chez Monzo : Entrons maintenant dans le vif du sujet avec un exemple très concret de la vie d’une banque utilisant Kubernetes en production pour les comptes de ses clients. Afin de répondre au mieux aux exigences du monde bancaire en termes de sécurité et d’isolation et de s’approcher au mieux des bonnes pratiques, Monzo souhaitait que TOUS leurs services définissent explicitement leurs interconnexions. Ils ont par conséquence fait un usage intensif des Network Policies afin de spécifier l’intégralité des connexions en entrée (ingress) et en sortie (egress). Sous le chapeau, c’est Calico qui s’occupe de concrétiser ces Network Policies en générant les règles iptables correspondantes. Mais ce n’est pas tout : Monzo voulait également avoir une sorte de “dry run” de ces Network Policies avant de les imposer concrètement, de manière a ainsi éviter les mauvaises surprises. Ils ont donc utilisé les options de logging d’ Ils ont donc commencé à logger les drops de paquets sans réellement activer ceux-ci. Et afin d’avoir une vue globale sur la progression de leur définition de Network Policies, les ingénieurs de Monzo ont également décidé de remonter des métriques permettant de grapher ces drops. L’idée est la suivante : au fur et à mesure de l’implémentation des Network Policies appropriées, le nombre de drop devrait tendre vers 0. En bref, une approche moderne et propre – que demander de plus ? C’est alors que certaines erreurs sporadiques ont commencées à apparaître (apparemment liées à certaines de leurs applications parlant à des services en dehors de leurs clusters Kubernetes). Pourquoi ? Voyons les détails : Les métriques CPU des nœuds ont rapidement permis de confirmer l’hypothèse : À ce moment, Monzo était déjà passé pleinement sur Calico et a donc décidé d’approcher la résolution du problème en 2 phases : Cette approche résolument moderne et automatisée de chaque étape m’a personnellement beaucoup plu. Les questions/réponses à la fin de la présentation ont également été riches d’informations ! En voici quelques extraits. “Est-ce que Monzo tourne intégralement dans le Cloud (AWS) ?” “Quid de Kubernetes et des certifications bancaires ?” “Vous faites tournez vos bases de données sur Kubernetes ?” Pour conclure le (long) résumé de ce talk, 2 derniers points m’ont particulièrement marqué. Le premier : le niveau d’outillage fourni aux développeurs et rendant leur quotidien plus facile. Par exemple : lorsqu’un développeur chez Monzo lance un service qu’il souhaite déboguer et que ce service en nécessite d’autres en tant que dépendances… ceux-ci sont dynamiquement et automatiquement lancés, dès lors qu’ils sont appelés. Sans avoir quoi que ce soit à faire. Une dynamique cruciale lorsque l’on travaille avec plus de 600 microservices : Le deuxième : la maturité tirée de leur stack technologique “home made”. Lorsque Monzo a choisi Kubernetes comme base de sa stack, les offres de Kubernetes managé (GKE, EKS, AKS, …) n’existaient pas encore ! Adrian Ludwin est développeur chez Google, principalement sur GKE / Anthos et vient aujourd’hui nous parler d’une manière de gérer un cluster multi-tenants via une fonctionnalité en cours de développement : les namespaces hiérarchiques. Cette année, le multi-tenants a le vent en poupe et de nombreux sujets y sont consacrés : Pourquoi en parle-t-on autant ? Peut-être faut-il se rappeler la keynote de Holly Cummins diffusée le même jour ? Les 2 principales raisons selon Adrian sont : D’autre part, il est parfois utile de ségréguer les usages par équipe et restreindre les droits au strict minimum (principe du least-privilege) ou encore appliquer des politiques globales de séparation entre différentes applications ou de multiples instances d’une même application établies par client. Adrian rappelle à ce titre que le concept de namespace est au centre de la sécurité sur Kubernetes, les mécaniques suivantes s’y rattachent toutes : C’est là que les namespaces hiérarchiques interviennent. Le contrôleur Hierarchical Namespace Controller (HNC) et le plugin kubectl Ainsi, il est maintenant possible d’accorder à un utilisateur l’accès privilégié à un namespace afin qu’il en gère toute la descendance sans pour autant mettre en péril la sécurité du cluster entier. Dans d’importantes structures où l’administration d’un cluster est souvent confiée à un nombre restreint de personnes, cette fonctionnalité va permettre de déléguer la gestion d’un sous-ensemble de namespaces et d’autonomiser les équipes d’utilisateurs ! Amazing to see all the impact and limitations of namespaces and how hierarchical namespaces can help with multi-tenancy @aludwin talk at #Kubecon #CloudNativeCon pic.twitter.com/v0GLJJ02qv — Olivier Cloirec (@clook0) August 19, 2020 Pari tenu ? Si HNC est disponible en option depuis la version 1.15 de Kubernetes, l’utilisation de ce concept nécessitera aux applications d’être adaptées (contrôleurs, CRD, opérateurs…) La liste est longue et Adrian nous rappelle que le SIG multi-tenancy recherche des contributeurs. La session de questions / réponses est une bonne manière de se rendre compte des divers efforts qui existent dans le sens du multi-tenants. Le SIG multi-tenancy propose également le concept de Virtual Cluster qui repose sur le principe de partager les nœuds d’un cluster pour y héberger plusieurs instances de Cluster API. On parle alors de « hard multi-tenancy » tandis que HNC est qualifié de « soft multi-tenancy ». Évidemment, chaque implémentation a souvent ses spécificités et trouve sa place dans l’écosystème en rapport avec les besoins de l’utilisateur. Lors de ce talk, Chris Carty a commencé par nous faire un rappel autour du workflow GitOps . Chris prétend que l’approche GitOps a été introduite par Weave en 2017 et se base sur une approche déclarative de l’infrastructure. Bien que la paternité soit discutable, la description qu’ils en font est tout a fait appropriée. GitOps est un workflow pour gérer, par exemple, un cluster Kubernetes et la livraison des applications sur celui-ci. Cela fonctionne en utilisant Git comme la source unique de vérité pour l’infrastructure déclarative. Avec Git au centre des pipelines de livraison, les développeurs utilisent des outils familiers pour effectuer des pull requests afin d’accélérer et de simplifier à la fois les déploiements d’applications et les tâches opérationnelles sur Kubernetes. Au cours de ce talk, Chris Carty nous a présenté Flux qui est un outil introduit par Weave et qui respecte le workflow GitOps. C’est de loin le plus simple des outils Gitops selon lui (comparé à ArgoCD ou encore à JenkinsX). Flux doit être installé dans chaque namespace kubernetes concerné. Avec Flux, on peut aussi faire du Flux est assez léger et très facile à mettre en place, par contre plusieurs fonctionnalités sont encore manquantes : Flux est limité au RBAC K8S et ne permet pas donc de faire du SSO par exemple pour une utilisation d’entreprise (LDAP par exemple). Une seule instance de Flux ne permet pas le support de plusieurs dépôts git, il faut déployer un Flux par dépôt git et par namespace. Lors de ce talk, Duffie Cooley, Cloud Native Architect chez VMWare, nous a parlé des capabilities ainsi que de seccomp dans le contexte de conteneurs Docker et de Kubernetes. Introduit dans le noyau Linux en 2005, seccomp permet de définir des profils afin de bloquer certains appels système (syscalls). Dans le contexte de conteneurs Docker, le profil seccomp par défaut bloque 63 syscalls (parmi eux, nous noterons reboot, qui évite qu’un conteneur puisse redémarrer l’hôte sur lequel il se trouve !) sur 345 actuellement disponibles dans la dernière version du kernel (5.8.2). Docker autorise aussi certaines capabilities, notamment celles de se bind sur un port privilégié (<= 1024) grâce à la capability Le nombre de syscalls bloqué par le profil par défaut de Docker est à comparer avec celui de Kubernetes, qui ne bloque que 22 syscalls, notamment pour des raisons de simplicité. Pour connaître quels syscalls sont utilisés par une application conteneurisée, des outils comme strace, amicontained et docker-slim permettent respectivement d’analyser les appels systèmes et de minifier son image pour n’autoriser que les appels systèmes nécessaires. Pour en revenir à Kubernetes, il est possible de spécifier à un pod ou un conteneur un profil différent de celui par défaut (par exemple, celui par défaut du runtime sous-jacent comme Docker) grâce aux annotations suivantes. Pour un pod : Pour un conteneur : La syntaxe précédente est utilisée pour les versions de Kubernetes < 1.19. Dans la prochaine version (1.19), les profils seront directement intégrés dans le contexte de sécurité d’un pod : ou d’un conteneur : Grâce à l’opérateur seccomp (seccomp-operator), il est possible de spécifier des profils spéciaux à l’aide d’une ConfigMap contenant le profil (format JSON) et d’y faire référence : Cette seconde demi-journée fut riche en enseignements ! Par ailleurs, nous commençons à réaliser que, bien que n’ayant pas de déplacement entre les salles à effectuer, une conférence virtuelle est tout aussi épuisante qu’une conférence “live”. Les pauses entre les talks ont tendance à être mises à profit pour avancer sur des “à-côtés”, pour creuser les sujets découverts, pour écrire le présent article de blog, etc. et bien moins pour échanger autour d’un café dans le hall aux sponsors ; sans même parler des tentatives de suivre 2 talks simultanés, peu fructueuses. Ce que nous retenons de cette après-midi : Et enfin, comme précédemment, quelques liens qui nous ont semblé pertinents :
Une petite histoire en provenance directe des tranchées de Kubernetes
iptables afin de logger les paquets qui auraient été drop pour cause de règles manquantes.
iptables log les drops de paquets localement… ce qui se traduit donc en réalité par du logging sur du stockage attaché via le réseau
Quelques autres points intéressants
Non, mais presque ! Il y a toujours une partie de datacenters physiques où ils doivent gérer l’infrastructure elle-même, notamment pour des raisons d’interconnexion avec les autres systèmes bancaires, mais ceux-ci servent principalement à rediriger vers AWS. Ils ont d’ailleurs une connexion réseau directe entre les datacenters en question et AWS.
La plupart des certifications n’imposent pas de technologies particulières, mais fixent plutôt des objectifs en termes de sécurité, d’isolation, d’auditabilité, etc. Les banques “n’ont qu’a” apporter la preuve qu’elles atteignent l’esprit de ces objectifs, peu importe les couches d’abstraction et l’outillage utilisé.
La base de donnée de choix chez Monzo est Cassandra, qu’ils ne font pas tourner sur Kubernetes. Mais une partie intéressante a justement été de rendre Cassandra davantage conscient de Kubernetes. En effet, contrairement à beaucoup d’autres bases de données, Cassandra se base fortement sur des éléments tels que les adresses IP de ses nœuds et qui doivent par conséquent être principalement statiques… ce qui n’est pas vraiment en phase avec le dynamisme d’environnements Cloud Native et des adresses IP sous-jacentes sans cesse changeantes. En tous cas, Monzo semble satisfait et enthousiaste de la direction que prend la communauté de Cassandra concernant ces problématiques !Touche finale
L’expertise tirée de cette expérience (gérer leurs propres clusters) est inestimable selon les speakers et continuera sans aucun doute à être mise à profit même s’ils choisissent de migrer vers une offre managée, par exemple EKS. D’ailleurs, le fait d’avoir l’intégralité de leur infrastructure décrite “as code” de manière déclarative leur permet d’ores et déjà d’évaluer les offres de Kubernetes managées en condition réelles : avec tous leurs microservices, leurs network plugins, leurs Network Policies, etc.
S’ils avaient à commencer de zéro aujourd’hui, ils choisiraient de déléguer la gestion de leur cluster sans hésiter.[Olivier] Multi-Tenant Clusters with Hierarchical Namespaces – Adrian Ludwin, Google
serviceAccount, secret, RBAC, quotas et networkPolicies (au passage, ces dernières s’appuient sur des labels, en lesquels la confiance est toute relative d’un point de vue sécurité : n’importe quel utilisateur capable de créer un pod pourra lui assigner les labels qui conviennent pour satisfaire des règles définies par label).
Mais comment gérer les accès et une coopération entre de multiples namespaces de manière globale ? Alors que l’utilisation des opérateurs et contrôleurs est adoptée par tous, comment peut-on donner à une application des accès privilégiés à un sous-ensemble de namespaces sans pour autant livrer les clés du cluster complet ?hnc offrent la possibilité de créer et gérer une relation parent-enfant entre 2 namespaces et donc de créer une hiérarchie de namespaces. Le namespace enfant pourra hériter de restrictions ou permissions du parent ainsi que de labels « protégés » qui représentent cette hiérarchie et ne peuvent être modifiés ou usurpés. Ces labels peuvent donc être considérés comme des sources de confiance et on peut aisément s’appuyer dessus pour des outils d’audit ou pour la mise en place de règles de sécurité.
[Rami] Managing Multi-Cluster/Multi-Tenant Kubernetes with GitOps – Chris Carty
Ainsi, la vie de tous les jours des développeurs de l’application est plus simple. Grâce au workflow GitOps, la productivité et la vélocité sont meilleures. Les développeurs de l’application n’auront pas à connaître ce qui se passe à l’intérieur du cluster.
Pour avoir une structure multi-dépôts git, il faut déployer un Flux dans chaque namespace concerné et pointer le dépôt git en question:
Cela peut devenir rapidement laborieux quand il s’agit de plusieurs équipes et plusieurs namespaces. ArgoCD par exemple, un autre projet cloud natif de CD se déploie sur un namespace dédié et peut communiquer à la fois avec plusieurs namespaces, avec plusieurs dépôts git et aussi avec plusieurs clusters.[Jonathan] Seccomp Security Profiles and You: A Practical Guide – Duffie Cooley, VMware
CAP_NET_BIND_SERVICE.1 annotations:
2 seccomp.security.alpha.kubernetes.io/pod: "runtime/default"
1 annotations:
2 container.security.alpha.kubernetes.io/<container-name>: "runtime-default"
1 spec:
2 securityContext:
3 seccompProfile:
4 type: RuntimeDefault
1 spec:
2 containers:
3 securityContext:
4 seccompProfile:
5 type: RuntimeDefault
1 apiVersion: v1
2 kind: ConfigMap
3 metadata:
4 name: test-profile
5 annotations:
6 seccomp.security.kubernetes.io/profile: "true"
7 data:
8 profile-block-all-syscalls.json: |-
9 { "defaultAction": "SCMP_ACT_ERRNO" }
1 apiVersion: v1
2 kind: Pod
3 metadata:
4 [...]
5 spec:
6 [...]
7 securityContext:
8 seccompProfile:
9 type: Localhost
10 localhostProfile: test-profile/profile-block-all-syscalls.json
Take Away