Kubernetes quick reference
Abstract
Document d'introduction aux concepts de Kubernetes, destiné à du personnel technique et/ou intéressé par la technique.
VM vs Container
Container:
- Méthode d'isolation des process, resources disque et réseau basé sur linux cgroups et linux namespaces.
- Des méthodes d'isolement existent déjà depuis longtemps sur Unix:
chroot
! - Tous les containers tournant sur une machine partagent le même OS kernel: plus léger mais moins secure.
VM:
- Véritable isolation
- L'hyperviseur est installé sur le bare metal
Docker
Rappel des commandes
- Dockerfile ->
docker build
-> Image - Image ->
docker run
-> Container - Container ->
docker exec
+ commande -> Commande exécutée dans le container
Autres notions
- Héritage & base image: une image Docker hérite toujours d'une autre image (ou alors de
FROM scratch
). - Volume: exposer un répertoire du host à l'intérieur du container
- Port: exposer un port du container à l'extérieur sur le host
- socket docker: si on partage le socket du daemon Docker du host à l'intérieur d'un container (via un volume), le container peut lui-même appeler Docker: Docker in Docker
Optimisations
- Multi-stage build: permet d'optimiser le temps de build d'une image ainsi que sa taille finale
- Builder pattern: pour les langages compilés, utilisation du multistage build pour obtenir une image
FROM scratch
qui fait tourner le binaire - Base images: permet de choisir l'OS sur lequel tourne le container. Exemple: Alpine Linux
Kubernetes
Contexte:
- origine: mot grec qui signifie "capitaine, pilote de navire". Sinon on peut dire K8S.
- Contexte de failure du modèle "PaaS" (Heroku, Google App Engine etc) car pas le runtime devient alors une boite noire. Kubernetes a été poussé en 2014 suite a l'échec de Google App Engine en 2013.
- K8S peut aussi être défini comme un IPaaS (IaaS + PaaS)
En bref:
- On peut le voir comme un "OS pour containers" (ou un "vSphere pour containers")
- Moteur pour faire converger à tout moment l'état actuel et l'état désiré du cluster
Abstractions logiques: Node, Pod, Service
Fonctionnalités natives:
- autoscaling
- load balancing
- self-healing: recrée les containers qui ont planté, retire les containers qui plantent en boucle etc.
- support cronjobs et jobs
- service discovery
- déploiement blue/green & rollback
Architecture
Un cluster K8S est composé d'un Master et de plusieurs Nodes.
Les containers à déployer sont groupés dans un ou plusieurs Pods.
Pour exposer à l'extérieur du cluster, on utilise la notion de Service.
- Control Plane: Master Kubernetes
- Container Runtime: Docker la plupart du temps
- Kubelet: un agent qui doit tourner sur chaque node
- Kubectl: outil CLI d'administration (il existe un dashboard web mais avec très peu de features)
- Node: VM la plupart du temps, mais on peut utiliser des machines physiques ("bare metal"). Chaque node Kubernetes doit run des tools comme
kubelet
(agent Kubernetes) etkube-proxy
Solutions du marché
OpenShift
On Prem K8S, basé sur Red Hat (enjoy Podman)
Historique: offre PaaS qui s'est upgradée vers K8S.
Excellente GUI et CLI (pour les admins et les devs, genre déploiement de Helm charts depuis la GUI etc)
* outil oc
(openshift CLI) 100% compatible kubectl, mais avec des commandes simplifiées genre oc new-app https://github.com/myapp/myapp.git --name myapp
pour deployer direct
- CNI: Openshift SDN
- Load balancer: HAProxy
- beaucoup de CRDs
- repackaging assez lourd, ne suit pas forcement la version upstream K8S
VMWare Tanzu
Tres proche de l'upstream K8S et totalement intégré au monde VMWare
- ESXi pour le pool de compute
- s'administre via vSphere / vCenter !
GKE, AKS et EKS
Amazon | Microsoft | ||
---|---|---|---|
Service | AWS EKS (Elastic Kubernetes Service) | GKE (Google Kubernetes Engine) | AKS (Azure Kubernetes Service) |
Voir autres offres KaaS sur CNCF
API-driven
Le Master Kubernetes est un serveur d'API gRPC. Chaque node embarque aussi son serveur d'API gRPC sous la forme du container shim 1
API versionnée. stable
, beta
(fonctionnalités sujettes à changement), alpha
(feature buggée). (valable surtout en upstream kubernetes)
- Le kubelet, kubectl etc. sont des clients d'API gRPC.
- Les notions de "Pod", "Service", "Deployment" etc sont des Resources de cette API
Les fichiers YAML à générer sont des demandes de création/modification à l'API Server.
Modularité
- Notion d'interface vs implémentation concrète. Permet d'avoir une architecture modulable (pluggable).
- Le code Kubernetes peut être pris depuis le repo git (upstream kubernetes: version la plus récente à chaque fois) ou repackagé par un vendor (ex: Rancher, OpenShift)
Ces deux éléments permettent la création de distributions. Exemples: GKE, Minikube, OpenShift, etc.
Les distributions doivent passer une étape de certification CNCF pour être utilisables en prod.
Multi Tenancy
Objectif: comment partager un cluster K8S entre plusieurs équipes, projets etc.?
Séparation physique:
- 1 cluster par equipe/projet
Séparation logique:
- Notion de namespace: permet de dédier des nodes / pods à un seul tenant
- Gestion de droits RBAC
- Possibilité de bloquer les accès réseaux entre les namespaces si besoin
Installation
Plusieurs stratégies:
Strategie | Cas d'utilisation |
---|---|
Install bare metal | Possibilité d'utiliser un hardware spécialisé, plus de puissance (ex: calculs GPU, ML etc) |
Install virtualisée | Le plus courant |
Install dockerisée | Pour les machines de dev (ex: k3d ou kind) |
Utilisation d'un K8S managé | Quand on ne souhaite pas installer / opérer soi meme K8S |
Resources
Pods
Groupe de 1 ou plusieurs containers. En général, on groupe ensemble les containers qui fonctionnent ensemble.
Exemple: container PHP + container Nginx + container Redis
Les pods sont ephémères:
- IP unique, qui change à chaque redémarrage
- Pour persister des données, il faut utiliser un volume.
Le networking des pods est simplifié en interne:
- Tous les containers d'un même pod se parlent en mode localhost
- Tous les containers d'un même pod partagent les mêmes storages / volumes
- Tous les pods communiquent avec les autres pods sans besoin de NAT
- Tous les nodes communiquent avec tous les pods sans besoin de NAT
Labels & Sélecteurs
Les labels sont des k/v pour pouvoir identifier et gérer les pods plus facilement (think: huge scale). Exemples de labels possibles dans la documentation
Les sélecteurs permettent de:
- limiter un node pour qu'il exécute uniquement un certain set de labels. (ex: nodes bare metal GPU, environnement type dev ou prod etc)
- créer un service composé uniquement d'un certain type de pods
Services
- Durable
- Unifie l'accès à tous les pods concernés par le sélécteur
Exemple de sélecteur: le service "fov france24 prod" sera composé de tous les pods répondant aux labels app=fov
, lang=france24
et env=prod
Probes
Article source: Most common mistakes K8S
Ce sont des routes accessibles sur les containers
Chaque pod peut disposer de 2 probes (par défaut, 0 probe configurée)
readiness probe:
- Si la probe fail: Déconnecte le pod et n'y envoie plus de trafic.
- Si la probe est OK: indique que le pod est prêt à servir plus de trafic
liveness probe: health check normal
- Si la probe fail: Restart le pod
- Si la probe est OK: retourne health check OK
Grâce à la readiness probe, on peut donc protéger un pod qui a un gros workload en cours de traitement (on ne lui envoie plus de nouvelles requêtes MAIS evidemment on ne le restart pas!)
Scheduler
chargé de répondre à la spécification du cluster à tout moment:
- Assigne les pods à des nodes disponibles
- Vérifie que les pods ne dépassent pas leur allocation
- Applique les directives de policy, QoS et affinité
Operators
Plugin Kubernetes qui permet d'automatiser un maximum de tâches manuelles
- Backup
- Manager des clusters d'applications spécifiques: Grafana, Kafka, Rabbitmq
Daemon Set
Permet d'installer la même chose sur tous les nodes qui répondent à un sélecteur précis.
Bypasse les suppressions liées au pod.
Exemple d'utilisation: health check, log shipping
Bonnes pratiques
12 factor apps
Méthodes pour développer et packager des applicatifs compatibles container & cloud.
GitOps (IaC pielines)
Permet de faire de la CI/CD sur des environnements kubernetes/cloud
Nécessite: le git applicatif + le git d'infra as code.
La pipeline d'infrastructure est tout aussi importante que la pipeline applicative
-
un shim est un process intermédiaire qui sert de process parent au process du container ↩