Skip to content

Kubernetes quick reference

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

Etymologie: mot grec qui signifie "capitaine, pilote de navire". Sinon on peut dire K8S.

En bref:

  • On peut le voir comme un "OS pour containers" (ou un "vSphere pour containers")
  • Moteur pour faire converger 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 modulable

  • 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.

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.

Installation

Bare Metal: plus rapide (calculs GPU, Machine Learning)

Virtualisé: le plus courant

Environnements de dev

Pour les enviros de dev, il est conseillé d'installer Minikube en virtualisé (virtualbox) et non pas en bare metal!

Multi Tenancy

  • 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

Optimisations

RancherOS, CoreOS/FlatCar

Vue d'ensemble

Control Plane = Master Kubernetes

Container Runtime = Docker la plupart du temps

Kubectl = outil CLI d'administration (il existe un dashboard mais avec très peu de features)

Node = VM la plupart du temps

Pods

Grouper dans un pod tous les containers qui doivent fonctionner ensemble

Exemple: container FOV + container Nginx + container Redis

  • Ephémères
  • IP unique, qui change à chaque redémarrage
  • 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

Exemple de sélecteur: le pod "fov" ne tournera que sur les nodes répondant aux labels type=web_application

Services

  • Durable
  • IP statique dans le cluster (on peut aussi ajouter un nom DNS)
  • 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

Volumes

Persistent Volume: à la création du cluster (administrateur), on alloue le volume disponible sur le cluster, par type de StorageClass

Persistent Volume Claim: permet d'allouer des resources du cluster (défini en PV) en tant que volume pour les containers d'un pod

Operators

Plugin Kubernetes qui permet d'automatiser un maximum de tâches manuelles

  • Backup
  • Manager des clusters d'applications spécifiques: Grafana, Kafka, Rabbitmq

API Kubernetes

Le serveur d'API tourne sur le master.

Tous les clients (Terraform, Helm, Kubectl, clients propriétaires AWS ECS etc...) communiquent avec l'API

API versionnée. stable, beta (fonctionnalités sujettes à changement), alpha (feature buggée). (valable surtout en upstream kubernetes)

Les fichiers YAML à générer sont des demandes de création/modification à l'API Server.

Configuration YAML

Pod Template

Décrit les specs des pods: quels containers sont dedans, les labels et selecteurs

Sont ensuite réutilisés dans les deployment.

Replica Set

Décrit le nombre d'instances d'un pod

Deployment

Un fichier deployment (YAML) permet de définir des Pods répliqués dans Kubernetes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-example
spec:
  replicas: 3
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: nginx
      env: prod
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    <pod template>

revisionHistoryLimit: combien d'anciens deployments on garde (pour les rollbacks)

La section strategy définit comment le pod doit être updaté (ex: nouvelle version d'un des containers). Stratégies possibles:

  • RollingUpdate = les pods sont updatés les uns après les autres.
  • Recreate = on éteint tous les pods puis on recrée les nouveaux

Readiness & Liveness probes:

  • routes accessibles sur les containers
  • permet à Kubernetes de savoir si le container a démarré, et s'il reste vivant

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

Job

Bypasse également le cycle de vie standard du pod: le pod n'a le droit d'être supprimé que si le job a été terminé.

Parallélisation out of the box

Stateful Set

Convention de nommage stable.

Le pod devient persistant: hostname, réseau et stockage!

Ecosysteme

Personne ne crée des fichiers de conf YAML kubernetes à la main.

Helm

Version: 3 (version 2 déconseillée!)

Package manager (CNCF).

  • Charts (YAML): définition d'applications déployables sur Kubernetes via helm install
  • Ajoute également des fonctionnalités de rollback sans utiliser kubectl

Terraform

Version: 0.12.x

Infra as Code (Hashicorp)

  • Pas limité qu'à Kubernetes (multiples providers)
  • Langage HCL
  • Gestion de différents workspaces (= environnements)
  • Terraform est capable par exemple d'installer un cluster complet (Helm nécessite un cluster pré-installé)
  • Helm provider for Terraform déconseillé (redondance gestion d'état)
  • Terraform Cloud: SaaS avec GUI + sauvegarde centralisée de l'état

Commandes

terraform init: installe les providers demandés terraform plan: calcule la différence entre l'état demandé via les fichiers HCL et l'état actuel du système terraform apply: applique les diffs

Jenkins X

Jenkins X ne fonctionne que sur environnement Kubernetes

Jenkins X permet d'utiliser (au choix) deux backends d'exécution:

  • Tekton CI/CD (CNCF) + Tekton YAML Pipelines
  • Jenkins dockerisé + Groovy Pipelines

Features

  • Preview environments générés pour chaque PR
  • Full CLI (jx tool)
  • Promotion Gitops
  • Peut installer son propre cluster (??)
  • Importation Jenkinfile
  • 1 namespace par équipe

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