Kubernetes est un gestionnaire de cluster de containeurs, projet initié par Google et soutenu par une paire d'autres boites.
Ça se base sur les archis de micro services, que je vais tenter d'expliquer vite fait.
L'idée, c'est de décrire une archi ( par exemple, une appli web ) sous forme de différents services qui tourne chacun dans un espace séparé et qui communique via une API défini. Par exemple, un site de e-commerce va avoir le serveur web, qui va parler à php-fpm ( un php en dehors du process du serveur web ), un composant qui va se charger de donner les résultats de recherche via une API REST, un composant qui va enregistrer le caddie ( via REST aussi ), etc.
Avec Kubernetes, chaque composant tourne dans un containeur docker, ce qui permet de faire les updates indépendamment du composant du reste de la stack ( modulo le fait que le composant respecte l'API ), ce qui permet aussi de gérer la charge indépendamment de chaque composant ( genre si tout d'un coup, y a plus de recherche, tu rajoutes plus de composant "recherche" et tu t'arranges pour que le code fasse du load balancing ), etc.
Donc Kubernetes, un master prends en entré un fichier json ou yaml qui décrit plusieurs containeurs docker, les groupes dans ce que le projet appelle un pod et se charge de repartir le pod sur une ou plusieurs machines, en reliant les containeurs entre eux pour communiquer, en relancant ce qui sont en panne pour que le service fonctionne, etc, etc.
C'est basé sur les architectures utilisé par les géants du web ( google, facebook, twitter ) pour leur infra web ou de traitement par lots ( ie, les batchs de job ). C'est encore en rapide développement, écrit en go.
Origin, c'est la version 3 de l'architecture d'openshift, un logiciel de PaaS ( Platform as a service ) de Red Hat. Tout comme kubernetes, c'est écrit en go, et ça s'interface devant Kubernetes, en rajoutant des APIs et des services pour être directement utilisable par un développeur pour faire du hosting. Par exemple, il y a une interface web, ça gére les utilisateurs, il y a un workflow pour construire les containeurs docker et les déployer à partir de git, etc etc.
Pour prendre l'exemple du site de ecommerce, tu peux avoir un déploiement du composant de recherche à chaque fois qu'un developpeur fait un commit. Le logiciel va recevoir une notification ( par exemple, via un post-commit git ), va prendre le code, le compiler ( dans un containeur prévu pour ), lancer les tests ( encore dans un containeurs ) et si c'est bon, le déployer automatiquement sur ton cluster. Tout ceci est bien sur configurable ( à terme ) pour par exemple ne déployer que sur 10% pour faire des tests, ou ne déployer qu'à la main, etc, etc.
C'est aussi en rapide développement, et pour faciliter le déploiement, ça embarque tout kubernetes. Ce qui me fait crier dans ma tête, mais bon, c'est vrai que du coup, ça va vite à tester.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 10.
Kubernetes est un gestionnaire de cluster de containeurs, projet initié par Google et soutenu par une paire d'autres boites.
Ça se base sur les archis de micro services, que je vais tenter d'expliquer vite fait.
L'idée, c'est de décrire une archi ( par exemple, une appli web ) sous forme de différents services qui tourne chacun dans un espace séparé et qui communique via une API défini. Par exemple, un site de e-commerce va avoir le serveur web, qui va parler à php-fpm ( un php en dehors du process du serveur web ), un composant qui va se charger de donner les résultats de recherche via une API REST, un composant qui va enregistrer le caddie ( via REST aussi ), etc.
Avec Kubernetes, chaque composant tourne dans un containeur docker, ce qui permet de faire les updates indépendamment du composant du reste de la stack ( modulo le fait que le composant respecte l'API ), ce qui permet aussi de gérer la charge indépendamment de chaque composant ( genre si tout d'un coup, y a plus de recherche, tu rajoutes plus de composant "recherche" et tu t'arranges pour que le code fasse du load balancing ), etc.
Donc Kubernetes, un master prends en entré un fichier json ou yaml qui décrit plusieurs containeurs docker, les groupes dans ce que le projet appelle un pod et se charge de repartir le pod sur une ou plusieurs machines, en reliant les containeurs entre eux pour communiquer, en relancant ce qui sont en panne pour que le service fonctionne, etc, etc.
C'est basé sur les architectures utilisé par les géants du web ( google, facebook, twitter ) pour leur infra web ou de traitement par lots ( ie, les batchs de job ). C'est encore en rapide développement, écrit en go.
Plus d'info sur :
http://kubernetes.io/
https://github.com/googlecloudplatform/kubernetes
http://kubernetesio.blogspot.ca/
Et une distrib qui embarque Kubernetes :
http://www.projectatomic.io/
Donc, ça, c'est Kubernetes.
Origin, c'est la version 3 de l'architecture d'openshift, un logiciel de PaaS ( Platform as a service ) de Red Hat. Tout comme kubernetes, c'est écrit en go, et ça s'interface devant Kubernetes, en rajoutant des APIs et des services pour être directement utilisable par un développeur pour faire du hosting. Par exemple, il y a une interface web, ça gére les utilisateurs, il y a un workflow pour construire les containeurs docker et les déployer à partir de git, etc etc.
Pour prendre l'exemple du site de ecommerce, tu peux avoir un déploiement du composant de recherche à chaque fois qu'un developpeur fait un commit. Le logiciel va recevoir une notification ( par exemple, via un post-commit git ), va prendre le code, le compiler ( dans un containeur prévu pour ), lancer les tests ( encore dans un containeurs ) et si c'est bon, le déployer automatiquement sur ton cluster. Tout ceci est bien sur configurable ( à terme ) pour par exemple ne déployer que sur 10% pour faire des tests, ou ne déployer qu'à la main, etc, etc.
C'est aussi en rapide développement, et pour faciliter le déploiement, ça embarque tout kubernetes. Ce qui me fait crier dans ma tête, mais bon, c'est vrai que du coup, ça va vite à tester.
Plus d'info :
http://www.openshift.org/#v3
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/welcome/index.html