Supports de cours

Les cours sont maintenus et donnés par : https://www.alterway.fr/cloud-consulting

• Copyright © 2014 - 2025 Alter Way Cloud Consulting
• Licence : Creative Commons BY-SA 4.0
• Sources : https://github.com/alterway/formations/

Le cloud, c’est large !

• Stockage/calcul distant (on oublie, cf. externalisation)

• Virtualisation++

• Abstraction du matériel (voire plus)

• Accès normalisé par des APIs

• Service et facturation à la demande

• Flexibilité, élasticité

WaaS : Whatever as a Service

• IaaS : Infrastructure as a Service

• PaaS : Platform as a Service

• SaaS : Software as a Service

Le cloud en un schéma

Pourquoi du cloud ? Côté technique

• Abstraction des couches basses

• On peut tout programmer à son gré (API)

• Permet la mise en place d’architectures scalables

Virtualisation dans le cloud

• Le cloud IaaS repose souvent sur la virtualisation

• Ressources compute : virtualisation

• Virtualisation complète : KVM, Xen

• Virtualisation conteneurs : OpenVZ, LXC, Docker, RKT

Notions et vocabulaire IaaS

• L’instance est par définition éphémère

• Elle doit être utilisée comme ressource de calcul

• Séparer les données des instances

Orchestration des ressources ?

• Groupement fonctionnel de ressources : micro services

• Infrastructure as Code : Définir toute une infrastructure dans un seul fichier texte de manière déclarative

• Scalabilité : passer à l'échelle son infrastructure en fonction de différentes métriques.

Positionnement des conteneurs dans l'écosystème Cloud ?

• Facilitent la mise en place de PaaS

• Fonctionnent sur du IaaS ou sur du bare-metal

• Simplifient la décomposition d'applications en micro services

Définition

• Les conteneurs fournissent un environnement isolé sur un système hôte, semblable à un chroot sous Linux ou une jail sous BSD, mais en proposant plus de fonctionnalités en matière d'isolation et de configuration. Ces fonctionnalités sont dépendantes du système hôte et notamment du kernel.

Le Kernel Linux

• Namespaces

• Cgroups (control groups)

Les namespaces

Mount namespaces ( Linux 2.4.19)

• Permet de créer un arbre des points de montage indépendants de celui du système hôte.

UTS namespaces (Linux 2.6.19)

• Unix Time Sharing : Permet à un conteneur de disposer de son propre nom de domaine et d’identité NIS sur laquelle certains protocoles tel que LDAP peuvent se baser.

IPC namespaces (Linux 2.6.19)

• Inter Process Communication : Permet d’isoler les bus de communication entre les processus d’un conteneur.

PID namespaces (Linux 2.6.24)

• Isole l’arbre d’exécution des processus et permet donc à chaque conteneur de disposer de son propre processus maître (PID 0) qui pourra ensuite exécuter et manager d'autres processus avec des droits illimités tout en étant un processus restreint au sein du système hôte.

User namespaces (Linux 2.6.23-3.8)

• Permet l’isolation des utilisateurs et des groupes au sein d’un conteneur. Cela permet notamment de gérer des utilisateurs tels que l’UID 0 et GID 0, le root qui aurait des permissions absolues au sein d’un namespace mais pas au sein du système hôte.

Network namespaces (Linux 2.6.29)

• Permet l’isolation des ressources associées au réseau, chaque namespace dispose de ses propres cartes réseaux, plan IP, table de routage, etc.

Cgroups : Control Croups

CGroup: /
           |--docker
           |  |--7a977a50f48f2970b6ede780d687e72c0416d9ab6e0b02030698c1633fdde956
           |  |--6807 nginx: master process ngin
           |  |  |--6847 nginx: worker proces

Cgroups : Limitation de ressources

• Limitation des ressources : des groupes peuvent être mis en place afin de ne pas dépasser une limite de mémoire.

Cgroups : Priorisation

• Priorisation : certains groupes peuvent obtenir une plus grande part de ressources processeur ou de bande passante d'entrée-sortie.

Cgroups : Comptabilité

• Comptabilité : permet de mesurer la quantité de ressources consommées par certains systèmes, en vue de leur facturation par exemple.

Cgroups : Isolation

• Isolation : séparation par espace de nommage pour les groupes, afin qu'ils ne puissent pas voir les processus des autres, leurs connexions réseaux ou leurs fichiers.

Cgroups : Contrôle

• Contrôle : figer les groupes ou créer un point de sauvegarde et redémarrer.

Deux philosophies de conteneurs

• Systeme : simule une séquence de boot complète avec un init process ainsi que plusieurs processus (LXC, OpenVZ).
• Process : un conteneur exécute un ou plusieurs processus directement, en fonction de l'application conteneurisée (Docker, Rkt).

Encore plus “cloud” qu’une instance

• Partage du kernel

• Un seul processus par conteneur

• Le conteneur est encore plus éphémère que l’instance

• Le turnover des conteneurs est élevé : orchestration

Container runtime

• Docker

• Rkt

• LXC

LXC

• Conteneur système

• Utilise la liblxc

• Virtualisation d'un système complet (boot)

Docker

• Développé par dotCloud et open sourcé en mars 2013

• Fonctionne en mode daemon : difficulté d'intégration avec les init-process

• Utilisait la liblxc

• Utilise désormais la libcontainer

Rocket (rkt)

• Se prononce “rock-it”

• Développé par CoreOS

• Pas de daemon : intégration avec systemd

• Utilise systemd-nspawn et propose maintenant d'autres solutions (eg. KVM)

• Adresse certains problèmes de sécurité inhérents à Docker

Les conteneurs: conclusion

• Fonctionnalités offertes par le Kernel

• Les conteneurs engine fournissent des interfaces d'abstraction

• Plusieurs types de conteneurs pour différents besoins

Un ensemble de concepts et de composants

• Layers

• Stockage

• Volumes

• Réseau

• Publication de ports

• Service Discovery

Layers

• Les conteneurs et leurs images sont décomposés en couches (layers)

• Les layers peuvent être réutilisés entre différents conteneurs

• Gestion optimisée de l'espace disque.

Layers : une image

Layers : un conteneur

Layers : plusieurs conteneurs

Layers : Répétition des layers

Stockage

• Images Docker, données des conteneurs, volumes

• Multiples backends (extensibles via plugins):
  • AUFS
  • DeviceMapper
  • OverlayFS
  • NFS (via plugin Convoy)
  • GlusterFS (via plugin Convoy)

Stockage : AUFS

• A unification filesystem

• Stable : performance écriture moyenne

• Non intégré dans le Kernel Linux (mainline)

Stockage : Device Mapper

• Basé sur LVM

• Thin Provisionning et snapshot

• Intégré dans le Kernel Linux (mainline)

• Stable : performance écriture moyenne

Stockage : OverlayFS

• Successeur de AUFS

• Performances accrues

• Relativement stable mais moins éprouvé que AUFS ou Device Mapper

Stockage : Plugins

• Étendre les drivers de stockages disponibles

• Utiliser des systèmes de fichier distribués (GlusterFS)

• Partager des volumes entre plusieurs hôtes docker

Volumes

• Assurent une persistance des données

• Indépendance du volume par rapport au conteneur et aux layers

• Deux types de volumes :
  • Conteneur : Les données sont stockées dans ce que l'on appelle un data conteneur
  • Hôte : Montage d'un dossier de l'hôte docker dans le conteneur

• Partage de volumes entre plusieurs conteneurs

Volumes : Exemple

Volumes : Plugins

• Permettre le partage de volumes entre differents hôtes

• Fonctionnalité avancées : snapshot, migration, restauration

• Quelques exemples:
  • Convoy : multi-host et multi-backend (NFS, GlusterFS)
  • Flocker : migration de volumes dans un cluster

Réseau : A la base, pas grand chose...

NETWORK ID      NAME      DRIVER
42f7f9558b7a    bridge    bridge
6ebf7b150515    none      null
0509391a1fbd    host      host

Réseau : Bridge

Réseau : Host

Réseau : None

• Explicite

Réseau : Les évolutions

• Refactorisation des composants réseau (libnetwork)

• Système de plugins : multi host et multi backend (overlay network)

• Quelques exemples d'overlay :
  • Flannel : UDP et VXLAN
  • Weaves : UDP

Réseau : multihost overlay

Publication de ports

• Dans le cas d'un réseau diffèrent de l'hôte

• Les conteneurs ne sont pas accessible depuis l'extérieur

• Possibilité de publier des ports depuis l'hôte vers le conteneur (iptables)

• L'hôte sert de proxy au service

Publication de ports

Links

• Les conteneurs d'un même réseau peuvent communiquer via IP

• Les liens permettent de lier deux conteneurs par nom

• Système de DNS rudimentaire (/etc/hosts)

• Remplacés par les discovery services

Les concepts: conclusion

• Les composants de Docker sont modulaires

• Nombreuses possibilités offertes par défaut.

• Possibilité d'étendre les fonctionnalités via des plugins

Build

Le conteneur et son image

• Flexibilité et élasticité

• Format standard de facto

• Instanciation illimitée

Construction d'une image

• Possibilité de construire son image à la main (long et source d'erreurs)

• Suivi de version et construction d'images de manière automatisée

• Utilisation de Dockerfile afin de garantir l'idempotence des images

Dockerfile

• Suite d'instruction qui définit une image

• Permet de vérifier le contenu d'une image

FROM alpine:3.4
MAINTAINER Alter Way <docker@alterway.fr>
RUN apk -U add nginx
EXPOSE 80 443
CMD ["nginx"]

Dockerfile : principales instructions

• FROM : baseimage utilisée

• RUN : Commandes effectuées lors du build de l'image

• EXPOSE : Ports exposées lors du run (si -P est précisé)

• ENV : Variables d'environnement du conteneur à l'instanciation

• CMD : Commande unique lancée par le conteneur

• ENTRYPOINT : "Préfixe" de la commande unique lancée par le conteneur

Dockerfile : best practices

• Bien choisir sa baseimage

• Chaque commande Dockerfile génère un nouveau layer

• Comptez vos layers !

Dockerfile : Bad Layering

RUN apk --update add \
    git \
    tzdata \
    python \
    unrar \
    zip \
    libxslt \
    py-pip \

RUN rm -rf /var/cache/apk/*

VOLUME /config /downloads

EXPOSE 8081

CMD ["--datadir=/config", "--nolaunch"]

ENTRYPOINT ["/usr/bin/env","python2","/sickrage/SickBeard.py"]

Dockerfile : Good Layering

RUN apk --update add \
    git \
    tzdata \
    python \
    unrar \
    zip \
    libxslt \
    py-pip \
    && rm -rf /var/cache/apk/*

VOLUME /config /downloads

EXPOSE 8081

CMD ["--datadir=/config", "--nolaunch"]

ENTRYPOINT ["/usr/bin/env","python2","/sickrage/SickBeard.py"]

Dockerfile : DockerHub

• Build automatisée d'images Docker

• Intégration GitHub / DockerHub

• Plateforme de stockage et de distribution d'images Docker

Ship

Ship : Les conteneurs sont manipulables

• Sauvegarder un conteneur :

docker commit mon-conteneur backup/mon-conteneur

docker run -it backup/mon-conteneur

• Exporter un conteneur :

docker save -o mon-image.tar backup/mon-conteneur

• Importer un conteneur :

docker import mon-image.tar backup/mon-conteneur

Ship : Docker Registry

• DockerHub n’est qu’au Docker registry ce que GitHub est à git

• Pull and Push

• Image officielle : registry

Run

Run : lancer un conteneur

• docker run

• -d (detach)

• -i (interactive)

• -t (pseudo tty)

Run : beaucoup d’options...

• -v /directory/host:/directory/container

• -p portHost:portContainer

• -P

• -e “VARIABLE=valeur”

• –restart=always

• –name=mon-conteneur

Run : ...dont certaines un peu dangereuses

• –privileged (Accès à tous les devices)

• –pid=host (Accès aux PID de l’host)

• –net=host (Accès à la stack IP de l’host)

Run : se “connecter” à un conteneur

• docker exec

• docker attach

Run : Détruire un conteneur

• docker kill (SIGKILL)

• docker stop (SIGTERM puis SIGKILL)

• docker rm (détruit complètement)

Build, Ship and Run : Conclusions

• Écosystème de gestion d'images

• Construction automatisée d'images

• Contrôle au niveau conteneurs

Docker Inc.

• Docker Inc != Docker Project

• Docker Inc est le principal développeur du Docker Engine, Compose, Machine, Kitematic, Swarm etc.

• Ces projets restent OpenSource et les contributions sont possibles

OCI

• Créé sous la Linux Fondation

• But : Créer des standards OpenSource concernant la manière de "runner" et le format des conteneurs

• Non lié à des produits commerciaux

• Non lié à des orchestrateurs ou des clients particuliers

• runC a été donné par Docker à l'OCI comme base pour leurs travaux

Les autres produits Docker

Docker-compose

• Concept de stack

• Infrastructure as a code

• Scalabilité

Docker-compose

docker-compose.yml

nginx:
  image: nginx
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "/srv/nginx/etc/sites-enabled:/etc/nginx/sites-enabled"
    - "/srv/nginx/etc/certs:/etc/nginx/certs"
    - "/srv/nginx/etc/log:/var/log/nginx"
    - "/srv/nginx/data:/var/www"

Docker-machine

• "Metal" as a Service

• Provisionne des hôtes Docker

• Abstraction du Cloud Provider

Docker Swarm

• Clustering : Mutualisation d'hôtes Docker

• Orchestration : placement intelligent des conteneurs au sein du cluster

Autour de Docker

• Plugins : étendre les fonctionnalités notamment réseau et volumes

• Systèmes de gestion de conteneurs (COE)

• Docker as a Service :
  • Docker Cloud
  • Tutum

Écosystème Docker : conclusion

• Le projet Docker est Open Source et n'appartient plus a Docker

• Des outils permettent d'étendre les fonctionnalités de Docker

• Docker Inc. construit des offres commerciales autour de Docker

Les distributions traditionnelles

• Debian, CentOS, Ubuntu

• Supportent tous Docker

• Paquets DEB et RPM disponibles

Un peu "too much" non ?

• Paquets inutiles ou out of date

• Services par défaut/inutiles alourdissent les distributions

• Cycle de release figé

OS orientés conteneurs

• Faire tourner un conteneur engine

• Optimisé pour les conteneurs : pas de services superflus

• Fonctionnalités avancées liées aux conteneurs (clustering, network, etc.)

• Sécurité accrue de part le minimalisme

OS orientés conteneurs : exemples

• CoreOS (CoreOS)

• Atomic (Red Hat)

• RancherOS (Rancher)

• Photon (VMware)

• Ubuntu Snappy Core (Ubuntu)

CoreOS : philosophie

• Trois "channels" : stable, beta, alpha

• Dual root : facilité de mise à jour

• Système de fichier en read only

• Pas de gestionnaire de paquets : tout est conteneurisé

• Forte intégration de systemd

CoreOS : fonctionnalités orientées conteneurs

• Inclus :
  • Docker
  • Rkt
  • Etcd (base de données clé/valeur)
  • Flannel (overlay network)
  • Kubernetes Kubelet

• Permet nativement d'avoir un cluster complet

• Stable et éprouvé en production

• Idéal pour faire tourner Kubernetes (Tectonic)

CoreOS : Etcd

• Système de stockage simple : clé = valeur

• Hautement disponible (quorum)

• Accessible via API

CoreOS : Flannel

• Communication multi-hosts

• UDP ou VXLAN

• S'appuie sur un système clé/valeur comme etcd

RancherOS : philosophie

• Docker et juste Docker : Docker est le process de PID 1)

• Docker in Docker : Daemon User qui tourne dans le Daemon System

• Pas de processus tiers, pas d'init, juste Docker

• Encore en beta

Fedora Atomic : philosophie

• Équivalent à CoreOS mais basée sur Fedora

• Utilise systemd

• Update Atomic (incrémentielles pour rollback)

Project Photon

• Développé par VMware mais Open Source

• Optimisé pour vSphere

• Supporte Docker, Rkt et Pivotal Garden (Cloud Foundry)

Docker Hosts : conclusion

• Répond à un besoin différent des distributions classiques

• Fourni des outils et une logique adaptée aux environnements full conteneurs

• Sécurité accrue (mise à jour)

Où déployer ?

• Cloud public:
  • GCE
  • AWS

• Cloud privé: OpenStack

• Bare Metal

Comment ?

• Utilisation de COE (Container Orchestration Engine)

• Utilisation d'infrastructure as code

• Utilisation d'un Discovery Service

Container Orchestration Engine

• Gestion du cycle de vie des conteneurs/applications

• Abstraction des hôtes et des cloud providers (clustering)

• Scheduling en fonction des besoins de l'application

• Quelques exemples:
  • Docker Swarm
  • Rancher
  • Mesos
  • Kubernetes

Infrastructure as a Code

• Version Control System

• Intégration / Déploiement Continue

• Outils de templating (Heat, Terraform, Cloudformation)

Discovery Service

• La nature éphémère des conteneurs empêche toute configuration manuelle

• Connaître de façon automatique l'état de ses conteneurs à tout instant

• Fournir un endpoint fixe à une application susceptible de bouger au sein d'un cluster

Consul

• Combinaison de plusieurs services : KV Store, DNS, HTTP

• Failure detection

• Datacenter aware

• Github

Consul

Exemple :

$ curl -X PUT -d 'docker' http://localhost:8500/v1/kv/container/key1
true
$ curl http://localhost:8500/v1/kv/container/key1 | jq .
[
  {
    "CreateIndex": 5,
    "ModifyIndex": 5,
    "LockIndex": 0,
    "Key": "container/key1",
    "Flags": 0,
    "Value": "ZG9ja2Vy"
  }
]
$ echo ZG9ja2Vy | base64 -d
docker

Consul

• L'enregistrement des nouveaux conteneurs peut être automatisé

• Registrator est un process écoutant le daemon Docker et enregistrant les évènements

Rancher

• Permet de provisionner et mutualiser des hôtes Docker sur différents Cloud Provider

• Fournit des fonctionnalité de COE :
  • Cattle : COE développé par Rancher
  • Kubernetes : COE développé par Google

• Bon compromis entre simplicité et fonctionnalités comparé à Mesos ou Kubernetes

• Encore jeune, adapté aux environnement de taille moyenne (problèmes de passage à l'échelle)

Apache Mesos / Marathon

• Mesos : Gestion et orchestration de systèmes distribués

• A la base orienté Big Data (Hadoop, Elasticsearch...) et étendu aux conteneurs via Marathon

• Marathon : Scheduler pour Apache Mesos orienté conteneur

• Multi Cloud/Datacenter

• Adapté aux gros environnements, éprouvé jusque 10000 nodes

Kubernetes

• COE développé par Google, devenu open source en 2014

• Utilisé par Google pour la gestion de leurs conteneurs

• Adapté à tout type d'environnements

• Devenu populaire en très peu de temps

Quelques autres

• Hashicorp Nomad

• Amazon ECS

• Docker Cloud

• Docker UCP (Universal Control Plane)

Docker en production : conclusion

Quoi monitorer ?

• L'infrastructure

• Les conteneurs

Monitorer son infrastructure

• Problématique classique

Monitorer des serveur est une problématique résolu depuis de nombreuses années par des outils devenus des standards :

• Nagios

• Shinken

• Centreons

• Icinga

Intérêt ?

• Un des principes du cloud computing est d'abstraire les couches basses

• Docker accentue cette pratique

• Est-ce intéressant de monitorer son infra ?

Oui bien sûr ;)

Monitorer ses conteneurs

• Monitorer les services fournis par les conteneurs

• Monitorer l'état d'un cluster

• Monitorer un conteneur spécifique

Problématiques des conteneurs

• Les conteneurs sont des boîtes noires

• Les conteneurs sont dynamiques

• La scalabilité induite par les conteneurs devient un problème

Monitorer les services

• La problématique est différente pour chaque service

• Concernant les web services (grande majorité), le temps de réponse du service et la disponibilité du service sont de bons indicatifs

• Problème adressé par certains services discovery pour conserver une vision du système cohérente (ex : Consul

Monitorer l'état d'un cluster

• Dépends grandement de la technologie employée

• Le cluster se situe t-il au niveau de l'host Docker ou des conteneurs eux mêmes ?

Monitorer, OK mais depuis où ?

• Commandes exécutées dans le container

• Agents à l'intérieur du conteneur

• Agents à l'extérieur du conteneur

Les outils de monitoring

• Docker stats

• CAdvisor

• Datadog

• Sysdig

• Prometheus

Kubernetes : Composants

• Kubernetes est écrit en Go, compilé statiquement.

• Un ensemble de binaires sans dépendances

• Faciles à conteneuriser et à packager

• Peut se déployer uniquement avec des conteneurs sans dépendance d'OS

• k3d, kind, minikube, docker...

Kubernetes : Les noeuds (Nodes)

• Les noeuds qui exécutent les conteneurs embarquent :

  • Un "container Engine" (Docker, CRI-O, containerd...)

  • Une "kubelet" (node agent)

  • Un kube-proxy (un composant réseau nécessaire mais pas suffisant)

• Ancien nom des noeuds : Minions

Kubernetes : Architecture

Kubernetes : Composants du Control Plane

• etcd: magasin de données clé-valeur open source cohérent et distribué

• kube-apiserver : L'API Server est un composant qui expose l'API Kubernetes, l'API server qui permet la configuration d'objets Kubernetes (Pod, Service, Deployment, etc.)

• core services :

  • kube-scheduler : Implémente les fonctionnalités de scheduling
  • kube-controller-manager : Responsable de l'état du cluster, boucle infinie qui régule l'état du cluster afin d'atteindre un état désiré
  • kube-cloud-controller-manager : Est un composant important du plan de contrôle (control plane) de Kubernetes, spécifiquement conçu pour interagir avec l'infrastructure cloud sous-jacente
  • kube-proxy : Permet le forwarding TCP/UDP et le load balancing entre les services et les backends (Pods)

• Le control plane est aussi appelé "Master"

Kubernetes : etcd

• Site : https://etcd.io
• Code : https://github.com/etcd-io/etcd
• Base de données de type Clé/Valeur distribuée (Distributed Key Value Store)
• Haute disponibilité: etcd est conçu pour être hautement disponible, même en cas de panne de certains nœuds
• Cohérence forte: etcd garantit que toutes les données sont cohérentes entre tous les nœuds.
• API simple: etcd offre une API simple et facile à utiliser pour interagir avec les données.
• Surveillance: etcd fournit des outils de surveillance pour suivre l'état du cluster.
• Stocke l'état d'un cluster Kubernetes
• Point sensible (stateful) d'un cluster Kubernetes
• Projet intégré à la CNCF (https://github.com/etcd-io)

Kubernetes : kube-apiserver

Sans le kube-apiserver le cluster ne sert à rien. De plus, il est LE SEUL à interagir avec le cluster etcd, que ce soit en écriture ou en lecture.

• Les configurations d'objets (Pods, Service, RC, etc.) se font via l'API server
• Un point d'accès à l'état du cluster aux autres composants via une API REST
• Tous les composants sont reliés à l'API server
• Roles :
  • Reçoit les requêtes API faites au cluster
  • Authentifie les requêtes
  • Valide les requêtes
  • Récupère, Met à jour les données dans etcd
  • Transmet les réponses aux clients
  • Intéragit avec le kube-scheduler, le controller-manager, le kubelet, etc...
  • C'est une API donc utilisable via des composants externes (kubectl, curl, lens, ...)

Kubernetes : kube-scheduler

Le kube-scheduler est le composant responsable d'assigner les pods aux nœuds "worker" du cluster. Il choisit alors selon les contraintes qui lui sont imposées un nœud sur lequel les pods peuvent être démarrés et exécutés.

• Planifie les ressources sur le cluster
• En fonction de règles implicites (CPU, RAM, stockage disponible, etc.)
• En fonction de règles explicites (règles d'affinité et anti-affinité, labels, etc.)

Kubernetes : kube-controller-manager

Le kube-controller-manager exécute et fait tourner les processus de contrôle du cluster.

• Boucle infinie qui contrôle l'état d'un cluster
• Effectue des opérations pour atteindre un état donné
• De base dans Kubernetes : replication controller, endpoints controller, namespace controller et serviceaccounts controller
• Processus de contrôle :
  • Node Controller : responsable de la gestion des nœuds du cluster et de leur cycle de vie
  • Replication Controller : responsable du maintien du nombre de pods pour chaque objet de réplication dans le cluster
  • Endpoints Controller : fait en sorte de joindre correctement les services et les pods
  • Service Account & Token Controllers : Gestion des comptes et des tokens d'accès à l'API pour l'accès aux namespaces Kubernetes

Kubernetes : kube-cloud-controller-manager

• Fonction principale :

  • Le CCM agit comme une interface entre Kubernetes et le fournisseur de cloud spécifique (comme AWS, Google Cloud, Azure, etc.). Il permet à Kubernetes de gérer les ressources spécifiques au cloud de manière indépendante du reste du cluster.
  • Séparation des responsabilités :
    • Avant l'introduction du CCM, le contrôleur de nœud (node controller), le contrôleur de route (route controller) et le contrôleur de service (service controller) étaient intégrés au contrôleur de gestion Kubernetes (kube-controller-manager). Le CCM a extrait ces fonctionnalités spécifiques au cloud pour les gérer séparément.
  • Contrôleurs spécifiques au cloud : Le CCM implémente plusieurs contrôleurs qui interagissent avec l'API du fournisseur de cloud :
    • Node Controller : Vérifie si les nœuds ont été supprimés dans le cloud après avoir cessé de répondre.
    • Route Controller : Configure les routes dans l'infrastructure cloud pour que les pods sur différents nœuds puissent communiquer.
    • Service Controller : Crée, met à jour et supprime les load balancers du cloud.

Kubernetes : kube-proxy

Le kube-proxy maintient les règles réseau sur les nœuds. Ces règles permettent la communication vers les pods depuis l'intérieur ou l'extérieur de votre cluster.

• Responsable de la publication de services

• Route les paquets à destination des PODs et réalise le load balancing TCP/UDP

• 3 modes de proxyfication :

  • Userspace mode

  • IPtables mode

  • IPVS (IP Virtual Server) mode

Remarque: Par défaut, Kube-proxy fonctionne sur le port 10249. Vous pouvez utiliser un ensemble d'endpoints exposés par Kube-proxy pour l'interroger et obtenir des informations.

Pour voir quel mode est utilisé :

Sur un des noeuds executer la commande :

curl -v localhost:10249/proxyMode;echo

# ex: retourne iptables

Certains plugins réseaux, tel que Cilium, permettent de ne plus utiliser kube-proxy et de le remplacer par un composant du CNI

Kubernetes : kube-proxy Userspace mode

• Userspace mode est ancien et inefficace.
• Le paquet est comparé aux règles iptables puis transféré au pod kube-Proxy, qui fonctionne comme une application pour transférer le paquet aux pods backend.
• Kube-proxy fonctionne sur chaque nœud en tant que processus dans l'espace utilisateur.
• Il distribue les requêtes entre les pods pour assurer l'équilibrage de charge et intercepte la communication entre les services.
• Malgré sa portabilité et sa simplicité, le surcoût de traitement des paquets dans l'espace utilisateur le rend moins efficace pour les charges de trafic élevées.

Kubernetes : kube-proxy IPtables mode

• Le mode iptables est préférable car il utilise la fonctionnalité iptables du noyau, qui est assez mature.
• kube-proxy gère les règles iptables en fonction du fichier YAML du service de Kubernetes.
• Pour gérer le trafic des services, Kube-proxy configure des règles iptables sur chaque nœud.
• Il achemine les paquets vers les pods pertinents en utilisant du NAT (Network Address Translation) iptables.
• Ce mode fonctionne bien avec des volumes de trafic modestes et est plus efficace que le mode espace utilisateur.

Kubernetes : kube-proxy IPVS mode

• IPVS mode équilibre la charge en utilisant la fonctionnalité IPVS du noyau Linux. Par rapport au mode IPtables, il offre une meilleure évolutivité et des performances améliorées.

• IPVS est le mode recommandé pour les installations à grande échelle car il peut gérer de plus gros volumes de trafic avec efficacité. IPtable Non !

Kubernetes : Kubelet

Elle, Il, iel ? 😉

• Agent principal du nœud : Kubelet est le principal agent qui s'exécute sur chaque nœud (machine) d'un cluster Kubernetes.
• Gestion des pods : Elle est responsable de la création, de la mise à jour et de la suppression des pods sur ce nœud, en suivant les instructions du plan de contrôle Kubernetes.
• Communication avec l'API Kubernetes : Kubelet communique en permanence avec l'API Kubernetes pour recevoir les mises à jour de configuration et les commandes.
• Exécution des conteneurs : Il utilise un runtime de conteneur (comme Docker ou containerd) pour lancer et gérer les conteneurs à l'intérieur des pods.
• Permet à Kubernetes de s'auto configurer :
  • Surveille un dossier contenant les manifests (fichiers YAML des différents composant de Kubernetes).
  • Applique les modifications si besoin (upgrade, rollback).
• Surveillance de l'état des pods : Kubelet surveille en permanence l'état des pods et des conteneurs, et signale tout problème au plan de contrôle.
• Gestion des ressources : Il gère l'allocation des ressources (CPU, mémoire) aux pods et assure que les limites de ressources ne sont pas dépassées.
• Intégration avec le système d'exploitation : Kubelet s'intègre avec le système d'exploitation hôte pour gérer les réseaux, les volumes et autres fonctionnalités du système.

Kubernetes : Architecture détaillée

Kubernetes : Cluster Architecture

Kubernetes: Network

Kubernetes n'implémente pas de solution réseau par défaut, mais s'appuie sur des solutions tierces qui implémentent les fonctionnalités suivantes:

• Chaque pods reçoit sa propre adresse IP
• Tous les nœuds doivent pouvoir se joindre, sans NAT
• Les pods peuvent communiquer directement sans NAT
• Les pods et les nœuds doivent pouvoir se rejoindre, sans NAT
• Chaque pod est conscient de son adresse IP (pas de NAT)
• Kubernetes n'impose aucune implémentation particulière
• Quelques exemple d'implémentations :
  • Calico : https://projectcalico.docs.tigera.io/about/about-calico/
  • Cilium : https://github.com/cilium/cilium
  • Flannel : https://github.com/flannel-io/flannel#flannel
  • Multus : Un Multi Network plugin permet d'avoir des pods avec plusieurs interfaces
  • Weave Net : https://www.weave.works/oss/net/
  • Voir les autres : https://kubernetes.io/docs/concepts/cluster-administration/networking/

Kubernetes : Aujourd'hui

Les versions de Kubernetes sont exprimées sous la forme x.y.z, où x est la version majeure, y est la version mineure et z est la version du correctif, conformément à la terminologie du Semantic Versioning.

• Version 1.34.x : stable en production
• Solution complète et une des plus utilisées
• Éprouvée par Google
• https://kubernetes.io/releases/

1.33

Latest Release:1.33.4 (released: 2025-08-12)

End of Life:2026-06-28

Complete 1.33 Schedule and Changelog

OpenShift

• Solution de PaaS développée par Red Hat

• Deux version :
  • Open Source : OpenShift Origin
  • Entreprise : OpenShift Container Platform

• Se base sur Kubernetes en tant qu'orchestrateur de conteneurs

OpenShift VS Kubernetes : Différences et ajouts

• Pas d'Ingress : Router

• Build et Images Stream : Création d'images et pipeline de CI/CD

• Templates : Permet de definir et templatiser facilement un ensemble d'Objet OpenShift

• OpenShift SDN ou Nuage Network pour le réseau

OpenShift : Router

• Quasiment identique à Ingress mais implémentés avant Kubernetes

• Fournissent les même fonctionnalités

• Deux implementations :
  • HAProxy
  • F5 Big IP

OpenShift : Build

• Permet de construire et reproduire des images d'application

• Docker builds : via Dockerfile

• Source-to-Image (S2I) builds : système de build propre à OpenShift qui produit une image Docker d'une application depuis les source

• Pipeline builds : via Jenkins

OpenShift : Image Stream

• Similaires à un dépôt DockerHub

• Rassemble des images similaires identifiées par des tags

• Permet de garder un historique des différentes versions

OpenShift : Conclusion

CKA, CKAD et CKS

• Certified Kubernetes Application Developer (CKAD)
• Certified Kubernetes Administrator (CKA)

• Certified Kubernetes Security Specialist (CKS)

• Les programmes CKAD, CKA et CKS ont été développés par la Cloud Native Computing Foundation (CNCF), en collaboration avec la Linux Foundation, pour faciliter l'extension de l'écosystème Kubernetes grâce à des certifications standardisées.

https://www.cncf.io/certification/ckad/ https://www.cncf.io/certification/cka/ https://www.cncf.io/certification/cks/

A vous de Jouer !