2 Followers
·
Follow

Kubernetes vs d’Autres Plateformes d’Orchestration de Conteneurs

Image for post
Image for post
Image par Julius Silver de Pixabay

Actuellement, il y a beaucoup de conversations autour de l’utilisation de docker et la conteneurisation dans la data science et le big data en général, avec le souci d’améliorer la productivité des équipes data en simplifiant et en automatisant les déploiements complexes. De plus en plus d’entreprises aujourd’hui utilisent des conteneurs comme élément principal dans leur architecture pour déployer des composants de traitement de données. Ainsi on peut retrouver dans un même système plusieurs dizaines de conteneurs dans des clusters, constituant les différents composants de la stack data.

Face à cette panoplie de conteneurs, il est nécessaire pour garder le système dans de bonnes conditions de fonctionnement, de mettre en place un système de monitoring et d’orchestration des conteneurs. D’où interviennent des plateformes comme Kubernetes. Kubernetes est une plateforme d’orchestration de conteneurs, qui s’impose aujourd’hui comme étant le système d’orchestration de choix des architectes IT. Il permet aux utilisateurs de créer, de planifier et de maintenir eux-mêmes leurs conteneurs. Il réalise nativement l’auto-scaling, le load balancing, la gestion des volumes, et la gestion des clés secrètes.

L’objectif de ce document est de faire une veille technologique sur l’utilisation de Kubernetes et d’autres systèmes d’orchestration de conteneurs dans le déploiement d’architectures big data. Pour cela nous allons :

· Dans un premier temps introduire les notions de conteneur, orchestration de conteneurs, Kubernetes ainsi que l’architecture type de Kubernetes;

· Ensuite nous allons présenter un état de l’art sur les systèmes de gestion de conteneurs en se basant sur des critères préalablement définis, suivi par une discussion sur les différentes solutions d’orchestration et les cas d’usages qui leurs sont le plus appropriés.

Backgrounds

Conteneurs

Un conteneur est une unité logicielle standard qui regroupe le code d’une application et toutes ses dépendances. Cette approche permet d’accroître la flexibilité et la portabilité d’exécution d’une application, laquelle va pouvoir tourner de façon fiable et prévisible sur une grande variété de machines hôtes, que ce soit sur une machine locale, un cloud privé ou public.

Une image de conteneur est un package logiciel exécutable autonome et léger qui comprend tout le nécessaire pour exécuter une application : code, runtime, outils système, bibliothèques système et paramètres. Les images de conteneur deviennent des conteneurs lors de leur exécution [1].

Les conteneurs sont donc proches des machines virtuelles, mais présentent un avantage important. Alors que la virtualisation consiste à exécuter de nombreux systèmes d’exploitation sur un seul et même système, les conteneurs se partagent le même noyau de système d’exploitation et isolent les processus de l’application du reste du système comme on peut le voir sur la figure 1.

Image for post
Image for post
Figure 1 : Conteneurs

Disponible pour les applications Linux et Windows, les logiciels conteneurisés fonctionneront toujours de la même manière, quelle que soit l’infrastructure. Les conteneurs isolent le logiciel de son environnement et garantissent son fonctionnement uniforme malgré les différences entre les environnements (développement, intégration, production).

Docker étant le framework de conteneurisation le plus populaire et le plus utilisé, nous allons l’utiliser dans le reste de nos travaux. Docker a été lancée en 2013 en tant que projet open source Docker Engine. Docker utilise les fonctionnalités du noyau Linux comme les CGroups et les espaces de noms pour isoler différents processus. Par conséquent, plusieurs conteneurs peuvent fonctionner indépendamment et en toute sécurité, sur une même machine hôte. Très utilisé dans le monde Linux, Docker est désormais également utilisé sous Windows.

Kubernetes

Kubernetes est une plate-forme open source pour l’automatisation, la montée en échelle et les opérations de déploiement de conteneurs sur des clusters de machines. Kubernetes s’appuie sur la vaste expérience de Google de plusieurs années de travail avec des conteneurs Linux, et est aujourd’hui assez mature pour être production-ready [2].

Kubernetes vise à fournir les composants et les outils pour alléger la charge de l’exécution des applications dans les clouds publics et privés en regroupant les conteneurs en unités logiques. Leurs points forts résident dans une croissance flexible, une portabilité indépendante de l’environnement et une montée en échelle facile.

Concepts

Les clusters dans Kubernetes comprennent plusieurs composants tels que :

Pods : il s’agit d’un groupe de conteneurs sur le même nœud qui sont créés, planifiés et déployés ensemble.

Labels : il s’agit de tag de clé-valeur qui sont affectés à des éléments tels que des pods, des services et des replication controller pour les identifier.

Services : ils sont utilisés pour donner des noms aux groupes de pods. En conséquence, ils peuvent agir comme des load balancers pour diriger le trafic vers des conteneurs.

Replication controller : il s’agit de frameworks spécialement conçus pour garantir qu’à un moment donné, un certain nombre de réplicas de pod sont planifiées et en cours d’exécution.

Namespace : il s’agit d’un espace de noms comme un cluster virtuel à l’intérieur du cluster Kubernetes. Il est possible d’avoir plusieurs espaces de noms dans un même cluster Kubernetes, et ils sont tous logiquement isolés les uns des autres. Ils peuvent aider, en termes d’organisation, de sécurité et même de performance.

Service discovery : C’est le processus consistant à déterminer comment se connecter à un service. Bien qu’il existe une option de découverte de service basée sur les variables d’environnement disponibles, la découverte de service DNS est préférable.

Conteneur : il s’agit des conteneurs qui constituent le cluster Kubernetes.

Dans Kubernetes, les conteneurs sont regroupés en modules basés sur des dépendances logiques qui peuvent ensuite être facilement mises à l’échelle lors de l’exécution.

Les fonctionnalités de base de Kubernetes incluent :

  • Mise à l’échelle automatique des conteneurs et gestion des volumes

Architecture type de Kubernetes

L’architecture Kubernetes se compose d’un Kubernetes master et de Kubernetes nodes comme l’illustre la figure 2.

Image for post
Image for post
Figure 2 : Architecture Kubernetes

Passons en revue les principales parties de cette architecture :

  • Kubernetes Master : le master est responsable du maintien de l’état souhaité du cluster. Il gère tous les nœuds du cluster. Comme nous pouvons le voir, le master est un ensemble de quatre processus :

etcd: Le master stocke l’état et les données de configuration de l’ensemble du cluster dans ectd. C’est un entrepôt de données clé-valeur permanent et distribué. Chaque nœud a accès à ectd et, à travers celui-ci, les nœuds apprennent à gérer les configurations des conteneurs qu’ils exécutent [9].

kube-apiserver: c’est le service qui gère l’ensemble du cluster, y compris le traitement des opérations REST, la validation et la mise à jour des objets Kubernetes, l’exécution de l’authentification et de l’autorisation.

kube-controller-manager: c’est le démon qui incorpore la boucle de contrôle principale de Kubernetes. Il apporte les modifications nécessaires pour faire correspondre l’état actuel à l’état souhaité du cluster.

kube-scheduler: ce service recherche les pods non planifiés et les lie aux nœuds en fonction des ressources demandées et d’autres contraintes

  • Kubernetes Node: les nœuds d’un cluster Kubernetes sont les machines qui exécutent les conteneurs. Chaque nœud contient les services nécessaires pour exécuter les conteneurs:

kubelet: il s’agit de l’agent principal de nœud qui garantit que les conteneurs décrits dans PodSpecs fournis par kube-apiserver sont en cours d’exécution et en bonne santé

kube-proxy: il s’agit du proxy réseau qui s’exécute sur chaque nœud et effectue une transmission de flux TCP, UDP, SCTP ou une transmission round robin sur un ensemble de backends

pod: il se compose d’un ou plusieurs conteneurs garantis d’être colocalisés sur la machine hôte et pouvant partager des ressources. Chaque pod se voit attribuer une adresse IP unique au sein du cluster, permettant à l’application d’utiliser les ports sans conflit.

runtime du conteneur: il s’agit du runtime où le conteneur à l’intérieur des pods est exécuté, il existe plusieurs runtimes de conteneur possibles pour Kubernetes, y compris le runtime le plus utilisé, le runtime docker.

Plateformes d’orchestration de conteneurs

Les conteneurs sont devenus populaires grâce à leur souci de cohérence entre les plates-formes, du développement à la production. L’intérêt croissant pour les conteneurs a à son tour entraîné une demande accrue pour leur déploiement et leur gestion. Le besoin d’un meilleur contrôle a attiré un certain nombre d’options logicielles en tant que solutions pour l’orchestration de conteneurs. Ce qui permet l’abstraction de conteneurs individuels vers des services avec un certain nombre d’instances ou de réplicas.

Il existe plusieurs acteurs dans développement de l’orchestration de conteneurs. Dans cette partie, nous allons faire une comparaison entre les 4 principales plateformes d’orchestration de conteneurs, qui sont : Kubernetes, Cloud Foundry, Apache Mesos et Docker Swarm.

Critères de comparaison

Les critères que nous utiliserons pour qualifier ces plateformes sont les suivants :

  • Installation et configuration du système d’orchestration : Le degré de difficulté ici varie suivant que ces étapes peuvent être totalement manuelles ou automatiques.

Docker Swarm

Docker Swarm est un standard open source populaire pour le packaging et la distribution d’applications conteneurisées. Il s’agit essentiellement d’un framework d’orchestration de conteneurs natif de Docker. Publié à l’origine en novembre 2015, il est écrit en Go.

Swarm est étroitement intégré à l’API Docker, ce qui le rend parfaitement adapté à une utilisation avec Docker. Les mêmes primitives qui s’appliquent à un cluster Docker à hôte unique sont utilisées avec Swarm. Cela peut simplifier la gestion de l’infrastructure de conteneur, car il n’est pas nécessaire de configurer un moteur d’orchestration distinct ou de réapprendre les concepts Docker pour utiliser Swarm.

Docker Swarm est conçu autour de quatre principes fondamentaux [4] :

  • Une expérience utilisateur simple mais puissante

La promesse d’une compatibilité descendante est particulièrement importante pour les utilisateurs actuels. Tous les outils ou conteneurs qui fonctionnent avec Docker fonctionnent aussi bien dans Docker Swarm.

Apache Mesos

Apache Mesos est une solution d’orchestration de conteneurs open source et multi framework développée à l’origine à UC Berkeley. Il fournit des applications avec des APIs pour la gestion des ressources et la planification à travers le cluster. Mesos nous donne la flexibilité d’exécuter la charge de travail conteneurisée et non conteneurisée de manière distribuée [3]. Contrairement à Swarm et Kubernetes, Mesos est écrit en C ++.

Mesos est quelque peu différent des deux premiers mentionnés ici, en ce qu’il nécessite davantage une approche distribuée pour gérer les ressources du data center et du cloud. Mesos peut avoir plusieurs maîtres qui utilisent Zookeeper pour monitorer l’état du cluster parmi les maîtres et former un cluster à haute disponibilité.

D’autres frameworks d’orchestration de conteneurs peuvent être exécutés au-dessus de Mesos, notamment Kubernetes, Apache Aurora, Chronos et Mesosphere Marathon. Cela signifie que Mesos adopte une approche plus modulaire de la façon dont les conteneurs doivent être gérés, permettant aux utilisateurs d’avoir plus de flexibilité dans les types d’applications et l’échelle sur laquelle ils peuvent s’exécuter.

Comme nous venons de le voir, Mesos est assez flexible et permet aux frameworks de planifier et d’exécuter des tâches via des APIs bien définies. Cependant, il n’est pas pratique d’implémenter ces primitives directement, surtout lorsque nous voulons planifier des applications personnalisées ou complexes. Par exemple, orchestrer des applications packagées sous forme de conteneurs [3]. C’est là qu’un framework comme Marathon peut nous aider. Marathon est un framework d’orchestration de conteneurs qui fonctionne sur Mesos. À cet égard, Marathon sert de cadre au cluster Mesos. Marathon offre plusieurs avantages que nous attendons généralement d’une plateforme d’orchestration comme la découverte de services, le load balancing, les métriques et les APIs de gestion de conteneurs.

Cloud Foundry

Pivotal Cloud Foundry (PCF) est une solution open source de type Platform-As-A-Service (PAAS) pour le déploiement d’applications natives du cloud. PCF est une PAAS orienté application, à la différence des autres framework qui sont plutôt des PAAS orientées conteneurs. Avec PCF nous avons l’abstraction de la plate-forme au niveau de l’application, la construction et le déploiement d’une application entièrement configurée, et d’autre part, nous avons l’abstraction de la plate-forme au niveau du conteneur, la construction et le déploiement de conteneurs dans le cadre d’une application complète [5].

Vous donnez une application à PCF, et la plateforme fait le reste. Elle fait tout, de la compréhension des dépendances des applications à la construction et à la mise à l’échelle des conteneurs et au câblage de la mise en réseau et du routage. Le développeur se concentre uniquement sur le développement de l’application et n’a pas besoin de se soucier du middleware / de l’infrastructure, qui autant que possible lui est transparent(e) et automatisé(e) dans la plateforme.

Les applications exécutées sur Cloud Foundry sont déployées, mises à l’échelle et maintenues par BOSH (le composant de gestion d’infrastructure de PCF).

Bien que la courbe d’apprentissage de BOSH soit considérée comme assez élevée, une fois maîtrisée, elle ajoute une valeur considérable en augmentant la productivité de l’équipe [8].

Comparaison

Bien que les 4 orchestrateurs fournissent une grande partie des mêmes fonctionnalités, il existe des différences fondamentales dans leur fonctionnement. Ci-dessous sont énumérés certains des points les plus notables sur lesquels ils divergent :

Installation et configuration du système d’orchestration

  • Kubernetes nécessite un certain nombre de configurations manuelles pour lier ensemble ses composants tels que etcd, kubectl et le moteur docker. Les instructions d’installation diffèrent d’un système d’exploitation à l’autre et d’un fournisseur à l’autre. Kubernetes doit également connaître une grande partie de la configuration du cluster à l’avance, comme les adresses IP des nœuds, le rôle que chaque nœud va prendre et le nombre de nœuds au total. Il existe des systèmes de templating d’application appelé helm charts qui maintiennent un repository de template d’application prêt à être déployé et à être utilisé, avec très peu ou pas de configuration.

Configuration des conteneurs :

  • Kubernetes utilise sa propre API client et ses définitions au format YAML qui diffèrent chacune de celles des équivalents Docker standard. En d’autres termes, vous ne pouvez pas utiliser Docker CLI ni Docker Compose pour définir des conteneurs. Lorsque vous changez de plate-forme, les commandes et les définitions YAML devront être réécrites. Vous pouvez par contre utiliser des images docker pour builder les conteneurs.

Montée en échelle :

  • Kubernetes fournit de solides garanties aux états du cluster au détriment de la vitesse. En effet Kubernetes est davantage une infrastructure tout-en-un pour les systèmes distribués. Sa complexité provient de l’offre d’un ensemble unifié d’API et de solides garanties sur l’état du cluster, ce qui ralentit le déploiement et la mise à l’échelle des conteneurs. La mise à l’échelle peut être faite manuellement ou automatiquement. Kubernetes convient aux clusters de moyennes à grandes échelle. Il est également bien adapté aux applications complexes avec de nombreux conteneurs à l’intérieur des pods.

Haute disponibilité

  • Dans Kubernetes et Docker Swarm, la haute disponibilité est fournie par la réplication des conteneurs et la redondance des services. Kubernetes et Docker Swarm garantissent tous deux une haute disponibilité des services grâce à la réplication. Le même conteneur est déployé sur plusieurs nœuds pour fournir une redondance et redéployé à nouveau si un hôte exécutant le service tombe en panne, ce qui rend les services auto-réparateurs. Bien que l’un ou l’autre des orchestrateurs de conteneurs puisse être exécuté sur un seul serveur, des nœuds supplémentaires sont requis pour une véritable redondance.

Load balancing

  • Avec Kubernetes, l’activation du load balancing nécessite une configuration de service manuelle. Kubernetes autorise une grande partie du load balancing lorsque les pods de conteneurs sont définis en tant que services. Chaque service est accessible via un certain ensemble de pods et de politiques qui permettent la configuration de pods de load balancing pouvant atteindre le service sans se soucier des adresses IP.

Mise à jour et restauration de conteneurs :

  • Kubernetes gère le processus de mise à jour en surveillant progressivement la santé du service pour conserver la disponibilité tout au long du processus de mise à jour en apportant des modifications à un module à la fois, évitant ainsi une panne de service. Le déploiement dans Kubernetes prend en charge la mise à niveau ainsi que la restauration. L’historique du déploiement est conservé par défaut dans Kubernetes, ce qui rend trivial le retour à une révision précédente.

Volumes de données :

  • Kubernetes partage les volumes de données au sein de pods. Les volumes Kubernetes sont une abstraction pour permettre aux conteneurs de partager des données dans le même pod. Les volumes ont une durée de vie explicite, ils sont créés et supprimés en même temps que le pod dans lequel ils sont enfermés. Les volumes fonctionnent en principe comme tout autre répertoire, accessible aux conteneurs du même pod. Kubernetes prend également en charge les gestionnaires de volumes de données externes pour transférer des données entre des modules.

Réseau et securité :

  • Avec Kubernetes l’authentification TLS nécessite une configuration manuelle pour la sécurité. Kubernetes utilise habituellement le flanel pour réaliser la mise en réseau de conteneurs. Les conteneurs sont joints dans un réseau virtuel et annoncés via etcd. L’authentification TLS est également possible mais nécessite que des certificats soient générés et installés manuellement sur tous les nœuds.

Découverte de service

  • Dans Kubernetes les conteneurs peuvent être définis comme des services facilement détectables. Kubernetes s’appuie sur etcd et des services définis manuellement pour la découverte. Les conteneurs peuvent s’annoncer au démarrage et ajouter les informations pertinentes dans une base de données distribué clé-valeur. Un module complémentaire mais facultatif de cluster pour le serveur DNS est également pris en charge pour faciliter la communication.

Adoption dans le marché

Suivant google, dans le marché des systèmes d’orchestration de conteneurs et cela depuis les 5 dernières années, la plateforme kubernetes est celle qui connait une croissance presque,exponentiel. Tandis que les 3 autres non pas du tout connus de croissance notable en termes de popularité.

De manière générale, par ordre de plopularité dans le moteur de recherche google, on a donc kubernetes qui vient en première position, suivi par docker swann, ensuite cloud foundry et enfin apache mesos.

https://trends.google.com/trends/explore?date=today%205-y&q=kubernetes,docker%20swarm,apache%20mesos,cloud%20foundry

Image for post
Image for post
Figure 3: Adoption trends

Logging et monitoring

Kubernetes intègre désormais des outils built-in pour le logging et le monitoring. Il publie également des informations détaillées relatives à différents objets sous forme de métriques de ressources ou de pipelines de métriques complètes. Une pratique typique consiste à déployer un outil externe comme ELK ou Prometheus + Grafana sur le cluster Kubernetes. Ces outils peuvent ingérer des métriques de cluster et les présenter de manière très conviviale.

Docker Swarm n’offre pas d’outils intégrés pour gérer le logging et le monitoring. Cependant, vous pouvez utiliser des outils tiers pour y parvenir. L’outil ELK en est un exemple.

Apache Mesos dispose d’un utilitaire de diagnostic qui analyse tous les composants du cluster et met à disposition des données relatives à l’intégrité et à d’autres mesures. Les données peuvent être interrogées et agrégées via les API disponibles. Une grande partie de ces données peuvent également être collectée à l’aide d’un outil externe comme Prometheus.

Avec Cloud Foundry on a un logging et agrégation de métriques. Log accessibles sur une console web, et également en ligne de commande sur le terminal avec Cf cli.

Discussion par cas d’usages

Kubernetes

Kubernetes est une abstraction de niveau inférieur dans le monde PaaS, ce qui signifie une plus grande flexibilité pour implémenter des personnalisations et créer vos conteneurs pour les exécuter comme vous le souhaitez. Malheureusement, cela signifie également plus de travail pour vos équipes d’ingénierie et une baisse de productivité comparé aux framework PaaS orienté application comme Cloud Foundry.

Kubernetes a une courbe d’apprentissage un peu plus abrupte et peut demander plus d’efforts de configuration que les autres plateformes. En partie en raison de son intégration plus étroite des fonctionnalités.

  • Avantages

◦ Open source et modulaire

◦ Fonctionne bien sur tous les systèmes d’exploitation

◦ Flexibilité d’implémentation et de personnalisation des conteneurs

◦ Organisation de service facile avec pods

◦ Soutenu par des années d’expérience d’experts

  • Inconvénients

◦ Installation et configuration laborieuses

◦ Incompatible avec les outils Docker CLI et Compose existants

Docker Swarm

Swarm ne prend pas encore en charge la mise à l’échelle automatique native ou du load balancing externe. La mise à l’échelle doit être effectuée manuellement ou via des solutions tierces. Dans la même veine, Swarm inclut le load balancing interne, mais le load balancing externe se ferait grâce à l’utilisation d’un load balanceur tiers tel qu’AWS ELB. Il convient également de noter l’absence d’une interface Web pour Swarm.

  • Avantages

◦Configuration simple et rapide

◦ Fonctionne avec d’autres outils Docker existants

◦ Installation légère

◦ Open source

  • Inconvénients

◦ Fonctionnalité limitée par ce qui est disponible dans l’API Docker

◦ Tolérance aux pannes limitée

◦ Pas de mise à l’échelle automatique

◦ Pas de load balancing externe built-in

Apache Mesos

Mesos a une courbe d’apprentissage plus abrupte que Docker Swarm par exemple. Mais, cette même flexibilité et complexité sont également des atouts qui permettent à des entreprises comme Twitter et Airbnb d’utiliser Mesos pour gérer leurs applications à très grande échelle.

  • Avantages

◦ Flexibilité de personnalisation et d’implémentation de contraintes plus complexes

◦ Supporte de très grandes échelles, jusqu’à 10 000 agents.

◦ Supporte des charges de travail qui sont un mélange de conteneurs et de non-conteneurs.

  • Inconvenients

◦ Installation et configuration pas trivial

Cloud Foundry

La plate-forme Cloud Foundry est une abstraction de niveau supérieur et offre donc un niveau de productivité plus élevé à ses utilisateurs. Cependant, la productivité s’accompagne de certaines limites quant à ce qui peut être personnalisé pendant l’exécution en comparaison avec des systèmes orientés conteneurs comme Kubernetes et docker swarm.

PCF est idéal pour les nouvelles applications, les applications natives du cloud et les applications qui fonctionnent correctement à partir d’un buildpack. Pour les équipes travaillant avec des cycles de vie courts et des versions fréquentes, PCF est un excellent produit.

  • Avantages

◦ Prise en main facile et gain de productivité pour les développeurs

◦ Déploie en utilisant des images docker et des buildpacks

◦ Mise à l’échelle instantanée (horizontal et vertical)

  • Inconvenients

◦ Impossible de personnaliser ses déploiement (pour des cas complexes). Cloud Foundry s’occupe de tout.

Conclusion

En guise de conclusion, il n’y a pas de gagnant ici. Chacune de nos solutions d’orchestration comparées a ses propres avantages. Docker et Cloud Foundry fournissent des solutions simples et rapides pour démarrer, tandis que les solutions comme Kubernetes et Apache Mesos visent à répondre à des demandes plus élevées et plus complexes. Pour la plupart des mêmes raisons, Docker a été populaire parmi les développeurs qui préfèrent la simplicité et les déploiements rapides. Dans le même temps, Kubernetes et Apache Mesos est utilisé dans les environnements de production par de nombreuses sociétés Internet de haut niveau qui gèrent des services très populaires comme Google, Twitter, Airbnb, ebay etc. Un cluster Kubernetes peut évoluer jusqu’à 5000 nœuds tandis que le cluster Marathon sur Mesos est connu pour prendre en charge jusqu’à 10 000 nœuds [3].

En définitive :

  • Si vous pensez à quelque chose de facile à utiliser et plus natif de Docker, et que vous n’avez pas besoin d’aller à grande échelle, utilisez Docker Swarm.

References

1. What is a Container, https://www.docker.com/resources/what-container

2. Docker Swarm vs Kubernetes, https://upcloud.com/community/stories/docker-swarm-vs-kubernetes-comparison-of-the-two-giants-in-container-orchestration/

3. Mesos vs Kubernetes, https://www.baeldung.com/mesos-kubernetes-comparison

4. Kubernetes vs Docker Swarm — A Comprehensive Comparison, https://hackernoon.com/kubernetes-vs-docker-swarm-a-comprehensive-comparison-73058543771e

5. Comparing Kubernetes to Pivotal Cloud Foundry — A Developer’s Perspective, https://medium.com/@odedia/comparing-kubernetes-to-pivotal-cloud-foundry-a-developers-perspective-6d40a911f257

6. DevOps Kubernetes vs. Docker Swarm vs. Apache Mesos: Container Orchestration Comparison, https://www.loomsystems.com/blog/single-post/2017/06/19/kubernetes-vs-docker-swarm-vs-apache-mesos-container-orchestration-comparison

7. Game of cloud technologies: Kubernetes vs. Cloud Foundry, https://developer.ibm.com/blogs/game-of-cloud-technologies-kubernetes-vs-cloud-foundry/

8. Choosing The Right Cloud-Native Application Deployment Platform, https://blog.overops.com/pivotal-cloud-foundry-vs-kubernetes-choosing-the-right-cloud-native-application-deployment-platform/

9. What Is Kubernetes? An Introduction to the Wildly Popular Container Orchestration Platform, https://blog.newrelic.com/engineering/what-is-kubernetes/

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store