Aller au contenu

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) et kube-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 Google 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

Documentation

  • 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


  1. un shim est un process intermédiaire qui sert de process parent au process du container