Comparons Kubernetes et Swarm
Rédigé par uTux 2 commentairesAttention, cet article va exploser le compteur de buzzwords.
J'utilise Docker en standalone depuis bientôt 3 ans, d'ailleurs mon blog tourne dessus à l'aide de deux images : PluXml et OpenSMTPD - pour le formulaire de contact - que j'ai moi-même réalisé. Sans dire que je maîtrise Docker, j'ai un niveau bien avancé. A côté de cela je travaille régulièrement avec OpenShift (la distribution Kubernetes commerciale de Red Hat) et même si je suis bien moins à l'aise qu'avec Docker, j'ai tout de même pas mal de connaissances.
Docker seul est un peu limité, on ne peut pas faire de clustering, ce qui est bien dommage car les containers et les micro-services s'y prêtent fortement. Il existe heureusement Swarm qui étend Docker au support d'une infrastructure à plusieurs nœuds.
D'un autre côté, le monde entier a les yeux rivés sur Kubernetes, le grand concurrent à Docker conçu dès le départ pour les clusters et la haute disponibilité. Ce dernier est très puissant mais aussi beaucoup plus complexe que Docker Swarm (surtout les RBAC dont je ne parlerai pas). Il faut aussi comprendre qu'on ne télécharge pas Kubernetes, on télécharge une distribution Kubernetes, et il en existe plusieurs. Dans le test de performances plus bas dans cet article je vais utiliser k3s, fourni par Rancher et grandement allégé et simplifié.
Alors, faut-il utiliser Swarm ou Kubernetes ?
Architecture
Docker Swarm
Le cluster se compose de nodes manager et workers. Les premiers sont chargés de piloter le cluster, les second exécutent les containers. Les commandes doivent être exécutées sur un des managers. Un système d'encapsulation UDP est en place entre les nodes, il permet aux réseaux des containers de se propager.
Dans Swarm on déclare des services, soit en cli soit en yaml (docker-compose). Le scheduler va ensuite provisionner les containers nécessaires au service sur un ou plusieurs workers, selon le nombre de replica demandé. Exemple :
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
sb40x4z1zqkb httpd replicated 1/1 httpd:latest
owq6yurtagjg traefik replicated 1/1 traefik:2.1 *:80->80/tcp, *:443->443/tcpOn peut augmenter ou diminuer manuellement le nombre de replicas, il y a un load balancer interne qui va répartir le trafic de manière transparente. Un système d'affinités permet de lier les containers à une node en particulier, très pratique. Les services peuvent être mis à jour en rolling update, c'est à dire qu'on ne restart pas tous les containers d'un coup mais les uns après les autres, ce qui permet de ne pas interrompre le service. Un rollback est possible.
Et... c'est à peu près tout. Simple et efficace, mais aussi un peu limité il faut l'avouer. Swarm est un bon choix pour un usage personnel de part sa simplcité. Par contre on va voir que pour les cas d'usage avancés, Kubernetes est plus adapté.
Kubernetes
Accrochez-vous. Commençons avec l'architecture Infra.
Le cluster est composé de nodes Control Plane (les masters ou managers) ainsi que des workers. Les Control Planes pilotent le cluster et l'API Kubernetes, à l'aide d'un système de configuration centralisé, qui est souvent basé sur etcd (selon les distributions) mais pas toujours. Par exemple, k3s utilise sqlite. Les workers ont un agent (kubelet) qui reçoit les instructions du scheduler. Là encore une encapsulation UDP est prévue entre les nodes pour permettre la propagation des réseaux des containers.
Attaquons maintenant le fonctionnement des ressources. Dans le cluster Kubernetes, tout est objet, tout est yaml ou json. C'est avec ça que l'on contrôle comment nos containers sont déployés et fonctionnent. Les types (kind) d'objets les plus courants sont :
- Pod : Un espace logique qui exécute un ou plusieurs containers.
- Service : Sert à exposer un ou plusieurs ports pour un pod, attaché à une IP privée ou publique.
- DeploymentConfig : Défini ce qu'on déploie. Typiquement l'image à utiliser, le nombre de replica, les services à exposer, les volumes...
- ReplicaSet : un contrôleur qui va vérifier que le nombre de pods en place correspond au nombre de replicas attendu. Scaling automatique possible.
- PV, PVC : système d'attribution (automatique ou pas) de volumes persistants.
- ConfigMap : objet permettant de stocker de la configuration, qui peut être ensuite lue et utilisée par les containers.
- Namespace : Séparation logique des ressources, seules les ressources affectées au namespace en cours sont visibles.
Exemple d'utilisation :
$ kubectl -n web get all
NAME READY STATUS RESTARTS AGE
pod/svclb-httpd-rw7k5 1/1 Running 0 5s
pod/httpd-8647457dd7-s2j4d 1/1 Running 0 5s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/httpd LoadBalancer 10.43.80.117 10.19.2.73 80:30148/TCP 5s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/svclb-httpd 1 1 1 1 1 5s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/httpd 1/1 1 1 5s
NAME DESIRED CURRENT READY AGE
replicaset.apps/httpd-8647457dd7 1 1 1 5s Par souci de simplification je ne parle pas du système de RBAC qui permet une granularité dans la gestion des droits, au prix d'une complexité (très) importante.
Kubernetes n'est pas aussi simple que Swarm mais il permet de faire beaucoup plus de choses. En fait on peut presque dire qu'on peut tout faire avec. Les namespaces sont une fonctionalité très pratique, tout comme le scaling auto et la possibilité d'éditer les objets avec la commande edit. En environnement pro, où vous allez gérer plusieurs clients, beaucoup d'applications et de fortes charges, Kubernetes est quasiment indispensable.
Fonctionnalités
| Swarm | Kubernetes | |
|---|---|---|
| Configuration yaml ou json |
Oui | Oui |
| Commandes Docker |
Oui | Non |
| CLI distant |
Oui | Oui |
| Network inter-containers & DNS |
Oui | Oui |
| Replicas | Oui | Oui |
| Scaling manuel | Oui | Oui |
| Auto-scaling | Non | Oui |
| Health probes |
Non | Oui |
| Modification d'objets en ligne |
Non | Oui |
| RBAC | Oui (EE) | Oui |
| Namespaces | Non | Oui |
| Volumes self-service |
Non | Oui |
Kubernetes est indéniablement plus complet, mais à quel point ces fonctionnalités sont-elles indispensables, surtout pour un usage en perso ? Et bien il y a à mon sens deux points que je trouve excellents dans Kubernetes et qui me manquent dans Swarm:
- La modification d'objets en ligne. J'entends par là que la commande
kubectl edit type/objectpermet de faire une modification à la volée, par exemple changer un port ou une version d'image dans un DeploymentConfig. Cela n'est à ma connaissance pas possible dans Docker, sauf avec docker-compose (stack dans le cas de Swarm) à condition d'avoir encore les fichiers yaml et que ceux-ci soient à jour. - Les namespaces. Pour éviter de mélanger plusieurs ressources de projets qui n'ont rien à voir, Kubernetes propose un système de namespaces. Par exemple je peux créer un namespace utux dans lequel je vais déployer mes images PluXml et OpenSMTPD, ce qui permet de s'y retrouver mais aussi de tout supprimer plus facilement si besoin. Les namespaces sont aussi très utiles lorsque vous partagez ou louez votre Cluster Kubernetes, chaque utilisateur a ainsi son espace dans lequel il ne voit que ses ressources.
Cependant Docker et Docker Swarm sont beaucoup plus simples et n'utilisent que des composant upstream.
Consommation de ressources
Tests effectués sur des instances DEV-1S de chez Scaleway (2 vcpu, 2GiB RAM, no swap). Le système d'Exploitation est Debian 10 Buster x86_64.
- Système seul: RAM 70.9M/1.94G
- Swarm seul: RAM 155M/1.94G
- Swarm + Traefik + PluXml (apache): 209M/1.94G
- k3s seul: RAM 619M/1.94G
- k3s + Traefik + PluXml (apache): 678M/1.94G
Si vous comptez monter un cluster de Raspberry Pi avec 1GB de mémoire, vous pouvez oublier k3s/Kubernetes qui en consomme déjà presque 75% à vide. Si vous avez les moyens de payer des serveurs de calcul un peu plus costauds, avec 16 ou 32GB de mémoire, la différence sera alors négligeable.
Les pré requis pour certaines distributions comme OpenShift sont beaucoup plus importants: 4 vcpus et 16GiB de ram pour chaque master (x3), 2 vpus et 8GiB de ram pour les workers (à multiplier par 4 si vous montez l'infra de logging ElasticSearch). C'est la raison pour laquelle je ne l'ai pas utilisé dans ce comparatif, il est hors compétition.
Exemple
Docker Swarm
Exemple simple avec la création d'un container apache vide :
version: '3'
services:
web:
image:
httpd:latest
ports:
- 8080:80
Création :
$ docker stack deploy -c web.yaml testVérifications :
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
8pxc580r3yh6 test_web replicated 1/1 httpd:latest *:8080->80/tcp
$ curl http://127.0.0.1:8080
<html><body><h1>It works!</h1></body></html>Kubernetes
Reprenons notre container apache vide :
apiVersion: v1
kind: Service
metadata:
name: web
labels:
app: web
spec:
ports:
- port: 80
selector:
app: web
tier: frontend
type: LoadBalancer
---
apiVersion: apps/v1 #
kind: Deployment
metadata:
name: web
labels:
app: web
spec:
selector:
matchLabels:
app: web
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: web
tier: frontend
spec:
containers:
- image: httpd:latest
name: web
ports:
- containerPort: 80
name: webChargons ces objets :
$ kubectl create namespace test
$ kubectl -n test create -f web.yamlVérifions :
# kubectl -n test get all NAME READY STATUS RESTARTS AGE pod/svclb-web-jqs6j 0/1 Pending 0 7m17s pod/web-774f857549-dstkz 1/1 Running 0 7m17s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/web LoadBalancer 10.43.109.5280:30452/TCP 7m17s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/svclb-web 1 1 0 1 0 7m17s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/web 1/1 1 1 7m17s NAME DESIRED CURRENT READY AGE replicaset.apps/web-774f857549 1 1 1 7m17s $ curl http://10.43.109.52 <html><body><h1>It works!</h1></body></html>
Conclusion
Kubernetes est plus complet que Swarm mais aussi plus compliqué. Il n'est pas toujours facile de choisir entre les deux, mais je vous donne les conseils suivants :
- Pour un usage personnel, Docker standalone ou Docker Swarm sera votre choix par défaut, même si rien ne vous empêche d'essayer Kubernetes :)
- Si vous êtes pragmatique ou que vous souhaitez travailler sur les containers, alors ce sera Kubernetes. C'est l'outil en vogue plébiscité par tout le monde et c'est ce que vous devez avoir sur votre CV.
- Pour un usage en entreprise, Kubernetes sera incontournable car il y a de nombreuses offres dans le Cloud et On-Premise. Aks ou OpenShift sur Azure, Eks chez Aws, pour ne citer que les plus connus. Tout l'écosystème des containers est focalisé sur Kubernetes et les namespaces vous serons indispensables dans un contexte multi-client.
Pour finir, un court retour d'expérience sur l'utilisation de Kubernetes en entreprise. Tout d'abord, soyez conscient que votre cluster, vos clients et vos utilisateurs vous poseront de nombreux défis. Ne pensez pas que Kubernetes va résoudre magiquement tous vos problèmes et que vos admins vont se tourner les pouces, bien au contraire. Dans le cas d'une plateforme On-Premise, prévoyez 2 admins à temps plein au minimum. Ensuite, vous devez disposer de compétences dans quasiment tous les domaines : réseau, stockage, système, middlewares et surtout avoir une bonne maitrîse de la Elastic Stack (ELK ou EFK) puisque vous aurez à gérer les logs de vos nodes et containers.
Avec cet article j'espère avoir bien présenté les différences entre Docker Swarm et Kubernetes et fourni quelques pistes à ceux qui hésitent :)