Commit 8745c60d authored by Rémi Cailletaud's avatar Rémi Cailletaud
Browse files

add jres-2019

parent 395e26ca
Osez Kubernetes !
== Introduction ==
Kubernetes a la réputation -- pas toujours imméritée, d'être un système complexe et difficile à appréhender. Il n'aurait d'utilité que dans le cadre d'infrastructures conséquentes, se limiterait à la fourniture de services web... Il n'est pas rare d'entendre qu'y exécuter des applications statefull est compliqué, voire inconscient.
Et pourtant... Kubernetes apporte certes des concepts nouveaux qu'il faut s'approprier, mais il n'est rien d'autre qu'un orchestrateur de conteneurs tirant partie de fonctionnalités connues et éprouvées du noyau Linux.
En s'appuyant sur l'exemple du maquettage puis de la mise en production d'un cluster Kubernetes au sein de l'Observatoire des Sciences de l'Univers de Grenoble (OSUG), nous allons démontrer que cet outil n'est ni opaque ni magique, qu'il est adapté à des organisations de toutes tailles, aussi bien pour des tâches d'administration système que dans le cadre de pratiques DevOps. Nous verrons aussi comment il facilite le travail en équipe et la mise en place d'infrastructures programmables (Infrastructure as Code) à l'aide d'intégration et de déploiement continus.
== Cadre ==
L'OSUG est une structure fédérative qui regroupe 6 unités de recherche, 5 équipes de recherche associées et 2 unités de services, sous multi-tutelles (CNRS, UGA, IRD, USMB, IFSTTAR, Météo-France, G-INP, Irstea). L’OSUG œuvre dans tous les domaines des Sciences de l’Univers, de la planète Terre et de l’Environnement. Il est engagé dans 28 services nationaux d’observation (SNO) en lien avec les recherches menées au sein de ses laboratoires.
Le service infrastructure de l'UMS OSUG fournit des services et un appui aux différents laboratoires de la structure et aux SNO qui développent des outils à destination des différentes communautés scientifiques. Nous œuvrons donc à la croisée des chemins des administrateurs système et des développeurs.
== Technique ==
Le service infrastructure de l'OSUG exploite un cluster vSphere composé de trois ESX. Il accueille environ 150 VM, qui hébergent des services communs à destination de l'ensemble de la communauté, d'autres à destination de laboratoires en particulier et enfin ceux des SNO. Il n'y a actuellement pas de pratique commune concernant les systèmes et la configuration des VM, qui ne sont pas toutes gérées par un système centralisé. Il en résulte une infrastructure hétérogène, difficile à administrer, nécessitant de nombreuses actions manuelles pas toujours correctement documentées et leur lot d'effets de bord. De plus, nous avions un nombre croissant de demandes d'hébergement de conteneurs et la mise à disposition de VM Docker mutualisées ne nous convenait pas, autant du point de vue de la sécurité que de celui de la gestion.
== Les différentes solutions d'orchestration ==
Nous commencerons par présenter les différentes solutions que nous avons étudiées. Certaines sont très simples, d'autres bien plus complètes. Il nous a paru assez significatif que certaines solutions répandues comme celle de CoreOS (Fleet) ou Rancher Labs (Cattle) abandonnent leur propre moteur d'orchestration pour se tourner vers Kubernetes. Le seul concurrent sérieux restant était Swarm, mais plusieurs points que nous développerons ont fait pencher la balance en sa défaveur : le principal est son développement, uniquement soutenu par Docker Inc., là où Kubernetes est un projet de la Cloud Native Computing Foundation, une partie de la Linux Foundation.
== Présentation générale ==
Nous détaillerons tout d'abord les trois concepts fondateurs de Kubernetes : immutabilité, configuration déclarative et capacité d'auto-réparation. Puis, nous verrons les différents éléments composants le cluster et leur rôle en son sein. Enfin, nous aborderons les abstractions fournies par l'API de Kubernetes : ce sont elles qui nous permettent de décrire notre infrastructure et de traiter notre ensemble de nœuds comme une seule et même machine, découplant ainsi l'applicatif du système et du matériel. Nous comprendrons alors pourquoi Kubernetes est aujourd'hui considéré comme le système d'exploitation du cloud, tant public (Google, Amazon...) que privé (Openstack, vSphere...).
Dans cette partie, nous insisterons, en l'illustrant par des exemples, sur la souplesse du système, qui ne propose pas une solution toute faîte, mais un ensemble de briques de base qui nous permettent de construire notre propre plateforme.
== Les différentes distributions et la mise en oeuvre ==
L'écosystème Kubernetes étant très dynamique, il existe une pléthore de solutions pour déployer un cluster. Dans notre cas, utiliser Pivotal de VMware pouvait paraître comme une évidence, mais nous voulions éviter les dépendances vis-à-vis d'un fournisseur et nous cherchions une solution réellement gratuite et portable. Kubeadm est la solution de référence, mais elle est difficile à mettre en œuvre et demande un travail préliminaire laborieux de provisionnement des nœuds.
Rancher Kubernetes Engine, développée par Rancher Labs, est une solution simple et légère. Les composants du cluster sont conteneurisés, les nœuds ont simplement besoin de Docker. Nous expliquerons succinctement comment et pourquoi nous les provisionnons à l'aide de Salt-Cloud et Salt, puis laissons la main à RKE pour provisionner le cluster lui-même. Monter un cluster ne prend que quelques minutes et y ajouter des nœuds est d'une simplicité enfantine.
Nous présenterons aussi Rancher 2, qui est composé d'une interface web et d'outils permettant de gérer un ou plusieurs clusters Kubernetes : il nous a été très utile pendant les phases de maquettage et de tests. Nous avons d'ailleurs décidé de l'utiliser dans un autre contexte que nous détaillerons, car il apporte des fonctionnalités intéressantes, particulièrement pour la gestion de l'authentification et des autorisations.
Nous aborderons ensuite les choix d'infrastructure que nous avons fait pour notre cluster puis comment nous les avons mis en œuvre : load-balancing L2 avec MetalLB, reverse-proxy avec Traefik, provisionnement dynamique des volumes persistants sur vSAN et NFS, sauvegarde de ces même volumes avec Stash et métriques et alertes avec Prometheus.
Enfin, nous aborderons l'aspect sécurité ainsi que les bonnes pratiques qui ont émergé au cours de ce projet, certaines paraissant assez évidentes, d'autres beaucoup moins.
== Gitops, opérations par Pull Request ==
La configuration du cluster, depuis l'infrastructure sous-jacente jusqu'aux services finaux est gérée de manière déclarative. Nous décrivons simplement l'état souhaité de l'infrastructure avec Salt-Cloud et Salt (pour les VM), RKE (pour le cluster) et Kubernetes (pour les services finaux). Cela nous permet de conserver l'ensemble de la configuration dans des dépôts Git, qui deviennent notre "source de vérité". Cela permet de faciliter la revue de code et d'utiliser Pull Requests et Issues. Nous pouvons aussi bénéficier d'intégration continue pour les déploiements de nos services à l'aide de Gitlab CI. C'est enfin un manière élégante d'assurer un plan de reprise sur accident pour la partie infrastructure.
Nous présenterons les méthodes de déploiement et les outils que nous utilisons pour nous assurer que l'état du cluster correspond à celui du dépôt, comment nous gérons les mises à jour et les éventuels retours en arrière et la manière dont les différents acteurs au sein de l'OSUG peuvent agir sur la configuration des différents composants.
== Bilan ==
Pour conclure, nous dresserons un bilan (spoiler: positif!) du projet, sans toutefois écarter les difficultés que nous avons pu rencontrer. Nous essaierons de communiquer notre enthousiasme pour Kubernetes, qui sous des abords parfois intimidants, est un fabuleux outil d'orchestration, qui s'intègre dans l'infrastructure sous-jacente, vSphere dans notre cas. Aussi surprenant que ça puisse paraître pour un système jeune et dynamique, il est robuste et fiable. Nous n'avons rencontré que peu de problèmes et la communauté est très réactive.
Enfin, nous détaillerons nos plans pour le futur : une éventuelle intégration avec Cisco ACI, la solution de Software Defined Network de Cisco, mais aussi le travail d'évangélisation qui a commencé auprès des développeurs des SNO, afin de comprendre ensemble comment tirer partie de cet outil fantastique pour leurs applications... Et une proposition pour les prochaines JDEV ?
Intro
Avertissement ;)
Contexte
Infrastructure
Gestion de configuration
Des demandes pour des conteneurs
Le choix de Kubernetes
Présentation de Kubernetes
citation
Objectifs
Concepts
API déclarative
Autoréparation
Immutabilité
Architecture (long)
Objets de base
Objets de base
Objets de base
Objets de base
Objets de base
Objets de base
Objets de base
Objets de base
Nos choix
Infrastructure
Services
Le futur
Conclusion
Osez Kubernetes !
Introduction
Kubernetes a la réputation -- pas toujours imméritée, d'être un système complexe et difficile à apréhender. Il n'aurait d'utilité que dans le cadre d'infrastructures immenses, se limiterai à la fourniture de service web... On entend aussi souvent qu'éxécuter des applications statefull sur ce genre de système est au mieux compliqué, si ce n'est inconscient.
Et pourtant... Kubernetes apporte certes un lot de concepts nouveaux qu'il faut incorporer, mais il n'est rien d'autre qu'un orchestrateur de conteneurs se basant sur des fonctionnalités bien connues du noyau Linux.
En s'appuyant sur l'exemple du maquettage puis de la mise en production d'un cluster Kubernetes au sein de l'OSUG, nous allons démontrer que cet outil n'est ni opaque ni magique, qu'il est adapté à des organisations de toutes tailles aussi bien pour des tâches d'administrations système que dans le cadre de pratiques DevOps, mais aussi qu'il est tout indiqué pour le travail en équipe, et la mise en place d'infrastructures programmables (IAC) au travers de l'intégration et du déploiement continu.
1. Cadre
L'OSUG est une structure fédérative qui regroupe 6 unités de recherche, 5 équipes de recherche associées et 2 unités de services, sous multi-tutelles (CNRS, UGA, IRD, USMB, IFSTTAR, Météo-France, G-INP, Irstea). L’OSUG œuvre dans tous les domaines des Sciences de l’Univers, de la planète Terre et de l’Environnement . Il est engagé dans 28 services nationaux d’observation (SNO) en lien avec les recherches menées au sein de ses laboratoires.
Le service ...
OSUG. UMS, 5 labo, SNO,Aspect dev et aspect ASR
2. Tecthnique
L'équipe infrastructure de l'OSUG exploite une cluster VMware composé de trois ESX. Il accueille environ 150 VM, qui hébergent des services communs à destination de l'ensemble de la communauté, des services à destination de laboratoires en particulier, et enfin les services des SNO. Il n'y a à l'heure actuelle pas de pratique commune concernant les OS et la configuration des VM, qui ne sont pas toutes gérées pas un système de gestion de configuration centralisée, et une certaine sédimentation s'est opérée avec le temps, rendant l'infrastructure peu homogène, difficile à administrer, et nécessitant de nombreuses actions manuelles, pas toujours correctement documentées, et leur lot d'effets de bord.
3. L'avenir (ce que l'on cherchait)
4. Présentation générale
Nous commencerons ps présenter les grands princi
Abstractions
"we must treat the datacenter itself as one massive warehouse-scale computer".o
=> abstraire les machines (OS) individuels, et les traîter comme une seule entité logique -> besoin d'un "OS" pour ce système distribué, qui ne ressemble pas à un OS classique... On ne fait pas de ssh !!
Kubernetes est un framework pour construire des plateformes distribuées. Mot-clé: framework, ce n'est pas un système tout prêt avec UI, mais les bases pour construire votre propre plateforme -> souplesse !
Pas simplement de l'automatisation/abstraction, mais plutôt un contrat entre le monde physique et monde applicatif. Découplage de lapplucation et de la machine/noeud -> scheduler.
Marche partout ou marche l'agent (kubelet). L'agent expose les ressources du noeud.
Déclaratif
Conteneurs (attention packaging/runtime pas forcément ientique) permet portabilité.o
Utilisation des ressources : tetris
5. Les différentes solutions et la mise en oeuvre
kubeadm, rke, rancher
6. Infrastructure As Code !
7. DevOps, pour de vrai
Bilano
* The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines
Luiz André Barroso
Jimmy Clidaras
Urs Hölzle
Kubernetes a la réputation d'être un système qui n'aurait d'utilité que dans le cadre d'infrastructures conséquentes, se limiterait à la fourniture de services web... Il n'est pas rare d'entendre qu'y exécuter des applications statefull est compliqué, voire inconscient.
Et pourtant... Kubernetes apporte certes des concepts nouveaux, mais il n'est rien d'autre qu'un orchestrateur de conteneurs tirant partie de fonctionnalités connues et éprouvées du noyau Linux.
En s'appuyant sur l'exemple du maquettage puis de la mise en production d'un cluster Kubernetes au sein de l'Observatoire des Sciences de l'Univers de Grenoble (OSUG), nous démonotrerons que cet outil n'est ni opaque ni magique, qu'il est adapté à des organisations de toutes tailles, aussi bien pour des tâches d'administration système que dans le cadre de pratiques DevOps. Nous verrons aussi comment il facilite le travail en équipe et la mise en place d'infrastructures programmables à l'aide d'intégration et de déploiement continus.
Nous verrons d'abord comment notre choix s'est porté sur Kubernetes puis nous détaillerons les concepts sur lesquels il est bâti, avant de plonger un petit plus dans son fonctionnement interne et son API.
Nous présenterons ensuite les choix techniques que nous avons fait pour le provionnement et le déploiement du cluster, puis les choix d'infrastructure pour le cluster lui-même : équilibrage de charge L2, reverse proxy, provisionnement dynamique des volumes, métriques, monitoring et alertes.
Enfin nous aborderons les bonnes pratiques que les outils présentés permettent de mettre en place. La configuration déclarative du cluster nous permet de tendre vers une infrastructure programmable et de développer les méthodes GitOps. Nous présenterons succintement ces méthodes et les outils utilisés pour la mettre en oeuvre.
This diff is collapsed.
Avant de commencer, je voulais montrer ce petit dessin qu'on retrouve souvent quand on parle des différents orchestrateurs... Le but de cette présentation c'est justement de faire mentir la réputation de système complexe qu'on prête à Kubernetes.
D'abord un peu de contexte, je travaille à l'OSUG, qui est en particulier une fédération qui regroupe plusieurs laboratoires et équipes de recherches, mais aussi des Services Nationaux d'Observations, qui proposent des services à destination de différents communautés scientifiques. Le rôle de mon équipe est d'offrir un soutien aux SI des laboratoire et au Services d'Observations, et nous œuvrons donc à la frontière des métiers d'ASR et de développeurs.
Un petit point rapide sur l'infrastructure, nous exploitons un cluster vSphere, qui a maintenant 5 hôtes. Ils sont reliés au réseau via la solution SDN Cisco ACI, et bénéficient de vSAN et de stockage sur SUMMER, qui est le stockage mutualisé NetApp de l'UGA.
Le cluster héberge actuellement 180 VM, et nous partions d'un double constat : il y a peu de pratiques communues pour la gestion de configuration, voire parfois pas de pratiques du tout et les développeurs perdait beaucoup de temps dans des tâches d'administration qu'ils ne maîtrisent pas toujours.
D'un autre côté, nous avions de plus en plus de demandes d'hébergement de conteneurs, ce qui soulevait de nombreuses question, autant du point de vue de la gestion que de celui de la sécurité...
Nous nous sommes donc mis en quête d'un orchestrateur de conteners...
Tout d'abord, il est intéressant de noter que lors de la phase de veille, deux solutions très répandues ont abanbonné leur orchestrateur pour se tourner vers K8S : CoreOS a abandonnée Fleet début 2017, et Rancher se détourne de Cattle depuis mi-2018 et la version 2.
Si on exclut Mesos qui est un animal particulier, le seul véritable concurrent dans notre contexte était Docker Swarm.
Le choix a été motivé par trois raisons. Les deux premières purement techniques :
- Kubernetes est pensé de manière très modulaire, chaque composant remplissant un rôle précis et reste dans la philosphie KISS d'UNIX ;
- Sa faculté à s'intégrer aux infrastructures sous-jacente (Openstack, vmWare) et à en tirer parti.
Et un raison plus politiques, là où Swarm est un projet de la société derrière Docker, Kubernetes est piloté depuis mi-2018 par la Cloud Native Computing Foundation, qui est une partie de la Linux Foundation.
Kubernetes est issu de deux projets de chez Google, donc Borg qui était écrit en Java.
Il a été réécrit dans un vrai langage de programmation (je tiens à préciser que j'aime bcp le java, hein...), et la version 1.0 a vu le jour en 2015.
Le projet a été piloté par Google puis par la Cloud Native Fountation depuis août 2018.
J'aime beaucoup cette citation tirée d'un papier écrit par des ingénieurs de Google paru en 2009. Les problématiques qu'il aborde peuvent parfois sembler loin de notre quotidien mais on peut en retenir que nous devons aller plus loin dans le niveau d'abstraction de notre infrastructure et pourvoir piloter toute notre infrastructure depuis un point unique.
C'est un des objectifs de Kubernetes, dont le but est donc d'abstraire non seulement la couche matérielle (ce que nous faisions déjà avec la virtualisation), mais aussi la couche sytème.
Parmi les autres objectifs qui on mené à sa conception, on trouve le couplage faible des composants afin de faciliter leur remplacement, un surcout minimal (5%/nœud, 1% pr tout le cluster), et un fonctionnement identique sur machines physiques et virtuelles.
Si ce dernier point est tout à fait exact, il faut bien noter que le terrain de jeu favori de Kubernetes est le cloud, qu'il soit public ou privé. En effet, Kubernetes sait parler aux systèmes sous-jacents pour les piloter, ce qui lui permet de s'intégrer avec élégance et lui a valu le surnom d'OS du cloud...
Kubernetes est bâti autour de trois grands concepts :
- une API déclarative : on définit des contrats, un état désiré et les différents composants du cluster se charge de le faire converger faire cet état.
- Des capacités d'auto-réparation : les composants su cluster s'occupant de le faire converger dans l'état désiré, les services défaillants sont automatiquement relancés, on a donc nativement une servillance au niveau applicatif.
- Une infrastructure immutable : les composants en fonctionnement ne peuvent être modifiés, on les remplace. Animal compagnie / bétail.
La première fois que je me suis retrouvé face à ce type de système c'était CoreOS en 2014, je me suis demandé ce qu'on allait bien pouvoir faire avec ça...
Une fois qu'on a pris le pli, il faut bien dire que cette approche présente de nombreux avantages, en particulier pour les tests, les mises à jours, et les retours en arrière.
Maintenant nous allons entrer un peu plus dans la technique, tout d'abord avec l'architecture de Kubernetes, qui est basée sur une séparation classique du plan de contrôle, à gauche sur le schéma, et du plan de travail, à droite. L'architecture est ici simplifiée, et en particulier on n'aborde pas l'aspect réseau, qui mériterai un exposé à elle toute seule...
L'ensemble de la configuration du cluster s'effectue via un point unique, qui est le serveur d'API.
L'ensemble des composants ignore l'existence des autres, communique uniquement avec l'API. C'est cette architecture qui assure le fameux couplage faible des composants.
Zoom sur le plan de contrôle, avec le serveur d'API qui est donc au centre du système.
Le stockage des données s'effectue via etcd, qui est un système de stockage clé/valeurs dévelopé à la base pour CoreOS qui utilise l'algorithme de consensus Raft, qui a la particularité de converger très rapidement.o
Le controller manager est la boucle de contrôle maître qui exécute les différents contrôleurs. Ce sont eux qui communiquent avec le serveur d'API pour créer, mettre à jour, supprimer les différentes ressources qu'ils gèrent.
L'ordonnanceur est le composant qui choisit le noeud sur lequel doivent tourner les différents charges de travail, en fonction de leurs besoins et de la disponibilité des ressources.
Enfin, un composant contrôle les différentes intégrations à l'infrastructure sous jacente.
Côté plan de contrôle, nous avons un ou plusieurs noeuds qui éxecutent nos charges de travail.
Le kubelet est le composant responsable de s'assurer que les charges de travail sont dans l'état désiré, c'est lui qui les démarre, les stoppe et les surveille selon les ordres du plan de contrôle.
Kube proxy est responsable des règles de forwarding et de l'équilibrage de charge.
Enfin, nous avons évidemment besoin d'un container runtime, qui est généralement docker, mais peut aussi être containerd, rkt, CRI-O, Kata (virtu légère).
Nous avons vu que l'API était la clé de voûte de Kubernetes. Administrateurs, utilisateurs et différents composants du cluster ne communiquent qu'à travers elle. Tout dans Kubernetes est représenté comme un objet dans l'API, qui peut être décrit en JSON ou YAML...
Je vais présenter quelques objets de base...
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment