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/

• Initialement développé par Google (Borg), devenu open source en 2014
• 1.0 le 10 Juillet 2015
• Adapté à tout type d'environnement
• Devenu populaire en très peu de temps
• Premier projet de la CNCF

CNCF

The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.

Avoir son projet porté par la CNCF

• Alignement avec les Objectifs de la CNCF
  • Technologies Cloud Natives: Votre projet doit être étroitement lié aux technologies cloud natives, telles que les conteneurs, les orchestrateurs de conteneurs (Kubernetes), les services de réseau, les systèmes de stockage distribués, et les outils de gestion du cycle de vie des applications cloud natives.
  • Open Source: Le projet doit être open source sous une licence approuvée par la CNCF (comme Apache 2.0 ou MIT).
  • Communauté Active: Il est essentiel de démontrer l'existence d'une communauté active autour du projet, avec des contributions régulières de développeurs et des utilisateurs.
• Maturation du Projet
  • Code de Qualité: Le code source doit être bien structuré, documenté et suivre les meilleures pratiques de développement.
  • Tests Unitaires et d'Intégration: Une couverture de tests solide est nécessaire pour garantir la qualité et la stabilité du projet.
  • Documentation Complète: Une documentation claire et complète est indispensable pour permettre aux autres développeurs de comprendre et d'utiliser le projet.

CNCF : Les rôles

• Hébergement de Projets Open Source:
  • La CNCF héberge un grand nombre de projets open source populaires, tels que Kubernetes, Prometheus, Envoy, et bien d'autres. Ces projets sont au cœur de l'infrastructure cloud native moderne.
  • Elle fournit un cadre de gouvernance et un environnement de collaboration pour ces projets.
• Définition de Standards:
  • La CNCF travaille à la définition de standards et de meilleures pratiques pour les technologies cloud natives.
  • Elle favorise l'interopérabilité entre les différents projets et outils.
• Promotion de l'Écosystème:
  • La CNCF organise des événements, des conférences et des meetups pour promouvoir les technologies cloud natives et rassembler la communauté.
  • Elle favorise l'adoption de ces technologies par les entreprises et les développeurs.
• Incubation de Nouveaux Projets:
  • La CNCF offre un programme d'incubation pour les nouveaux projets qui répondent à ses critères.
  • Elle aide ces projets à se développer et à atteindre la maturité nécessaire pour rejoindre la CNCF en tant que projet hébergé.
• Collaboration avec l'Industrie:
  • La CNCF travaille en étroite collaboration avec les principaux acteurs de l'industrie du cloud, tels que les fournisseurs de cloud public, les entreprises technologiques et les universités.
• Elle contribue à façonner l'avenir du cloud computing.

OCI

• Créé sous la Linux Fondation
• Standardisation : Le but principal de l'OCI est de créer des standards ouverts pour les formats de conteneurs et leurs runtimes. Cela permet d'assurer l'interopérabilité entre différentes plateformes et outils.
• Portabilité : En établissant des spécifications communes, l'OCI vise à rendre les conteneurs portables entre différents environnements d'exécution, clouds et systèmes d'exploitation.
• Compatibilité : L'initiative cherche à garantir que les conteneurs créés selon ses spécifications fonctionneront de manière cohérente, quel que soit l'outil utilisé pour les créer ou les exécuter.
• Innovation : Tout en maintenant des standards, l'OCI encourage l'innovation dans l'écosystème des conteneurs en fournissant une base commune sur laquelle les entreprises et les développeurs peuvent construire.
• Sécurité : L'OCI travaille également sur des spécifications liées à la sécurité des conteneurs, visant à améliorer la sécurité globale de l'écosystème.
• Collaboration industrielle : L'initiative favorise la collaboration entre de nombreuses entreprises et acteurs majeurs du secteur technologique pour définir ces standards.
• runC a été donné par Docker à l'OCI comme implémentions de base

Kubernetes : Projet

De nombreuses sources d'informations et de contributions disponibles :

• Docs : https://kubernetes.io/docs/

• Slack : http://slack.k8s.io/

• Discuss : https://discuss.kubernetes.io

• Stack Overflow : https://stackoverflow.com/questions/tagged/kubernetes

• Serverfault https://stackoverflow.com/questions/tagged/kubernetes

Kubernetes : Projet (suite)

• Hébergé sur Github : https://github.com/kubernetes/kubernetes :

  • Issues : https://github.com/kubernetes/kubernetes/issues

  • Pull Requests https://github.com/kubernetes/kubernetes/pulls

  • Releases : https://github.com/kubernetes/kubernetes/releases

• Projets en incubation :

  • https://github.com/kubernetes-sigs/

Kubernetes : Cycle de développement 1/3

• Chaque release a son propre planning, pour exemple : https://github.com/kubernetes/sig-release/tree/master/releases/release-1.30#timeline

• Fréquence des releases :
  • Kubernetes suit généralement un cycle de release trimestriel
  • Il y a habituellement 3 releases majeures par an
• Structure de versionnage :
  • Format : vX.Y.Z (par exemple, v1.26.0)
  • X : Version majeure (rarement changée)
  • Y : Version mineure (mise à jour trimestrielle)
  • Z : Version de patch (mises à jour de sécurité et corrections de bugs)
• Phases du cycle de release :
  • Planification
  • Développement
  • Code Freeze
  • Tests et stabilisation
  • Release

Kubernetes : Cycle de développement 2/3

• Durée du cycle :
  • Environ 12 à 14 semaines pour une release complète
• Support des versions :
  • Les 3 dernières versions mineures sont généralement supportées
  • Chaque version est supportée pendant environ 9 mois
• Types de fonctionnalités :
  • Alpha : Expérimentales, peuvent être instables
  • Beta : Plus stables, mais pas garanties pour la production
  • Stable : Prêtes pour la production

Kubernetes : Cycle de développement 3/3

• Processus communautaire :
  • Développement piloté par la communauté open-source
  • Implication de divers Special Interest Groups (SIGs)
• Compatibilité :
  • Effort pour maintenir une compatibilité ascendante entre les versions
• Documentation :
  • Mise à jour avec chaque nouvelle release
• Communication :
  • Annonces anticipées des dates de release et des changements majeurs
  • Publication de notes de release détaillée

Kubernetes : Communauté

• Contributor and community guide : https://github.com/kubernetes/community/blob/master/README.md#kubernetes-community

• Décomposée en [Special Interest Groups] : https://github.com/kubernetes/community/blob/master/sig-list.md

• Les SIG (Special Interest Groups) sont une partie essentielle de la structure organisationnelle de la communauté Kubernetes. Ils jouent un rôle crucial dans le développement et la maintenance de différents aspects de Kubernetes.

Kubernetes : Sig (suite)

Kubernetes : KubeCon

La CNCF organise 3 KubeCon par an :

• Amérique du Nord (San Diego, Seattle, etc)
• Europe (Berlin, Barcelone, Amsterdam etc)
• Chine

Thèmes abordés :

• Les Kubecon couvrent un large éventail de sujets liés à Kubernetes, tels que :
• Les dernières fonctionnalités et évolutions de Kubernetes
• Les meilleures pratiques pour déployer et gérer des applications conteneurisées
• L'intégration de Kubernetes avec d'autres technologies cloud-native (Istio, Helm, etc.)
• Les cas d'utilisation de Kubernetes dans différents secteurs (finance, retail, etc.)
• Les défis et les solutions liés à la sécurité, la performance et la scalabilité des clusters Kubernetes

Pour plus d'informations, Consulter le site officiel de la Cloud Native Computing Foundation (CNCF), l'organisation à l'origine de Kubernetes : https://www.cncf.io/

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

Kubernetes Local : Poste Personnel

Kubernetes Local : Minikube

• Installation : https://minikube.sigs.k8s.io/docs/start

• Créer un cluster
  • minikube start
• Les cluster sont ajoutés automatiquement au fichier ~/.kube/config de votre poste de travail

• Les cluster sont supprimés automatiquement au fichier ~/.kube/config avec la commande minikube delete [--all]

• Supporte de nombreux drivers
  • (HyperKit, Hyper-V, KVM, VirtualBox, but also Docker and many others)
• Beaucoup de plugins (addons)
  • minikube addons list

Kubernetes Local : k3s

Pré-requis : - Linux - Raspberry

• Installation : https://docs.k3s.io/installation

ou plus simplement : curl -sfL https://get.k3s.io | sh -

• K3s est conçu pour être très léger, nécessitant seulement environ 512 Mo de RAM pour fonctionner. Cela le rend idéal pour les environnements avec des ressources limitées.

Kubernetes Local : kind

• Kubernetes-in-Docker
• Il faut un serveur docker
• Fonctionne aussi avec podman
• Créer un cluster
  • kind create cluster
• Possibilité de créer plusieurs clusters
• Possibilité de créer des clusters de plusieurs noeuds (avec un fichier de config yaml)

Kubernetes Local : Docker Desktop

• Installation : https://www.docker.com/products/docker-desktop/

• Licence obligatoire si autre utilisation que personnelle (https://www.docker.com/pricing/)

Kubernetes Local : Rancher Desktop

• Installation : https://rancherdesktop.io/
• Configuration Simple
• Port-Forwarding simple
• Build et Run de container (nerdctl ou Docker CLI)
• Choix des version de kubernetes

Kubernetes Local : Podman Desktop

• Installation : https://podman-desktop.io/
• Docker ou Kubernetes au choix
• docker-compose (podman compose) doisponible
• Configuration simple
• Utilisation de contextes multiples
• Création de clusters kubernetes locaux avec kind

Installation de Kubernetes

• De nombreuses ressources présentes pour le déploiement de Kubernetes dans un environnement de production

Kubeadm est un outil qui facilite le déploiement de Kubernetes en automatisant les tâches d'initialisation et de configuration d'un cluster.

Installation de Kubernetes avec kubeadm

• Certains pré-requis sont nécessaires avant d'installer Kubernetes :
  • Désactiver le swap (Support alpha depuis la 1.22)
  • Assurer que les ports requis soient ouverts : https://kubernetes.io/docs/setup/independent/install-kubeadm/#check-required-ports
  • Installer une Container Runtime compatible CRI (containerd, CRI-O, Docker, ...)

kubeadm

• Installer les composants Kubernetes (kubeadm, kubectl, kubelet) : https://kubernetes.io/docs/setup/independent/install-kubeadm/
• Exécuter :
  • kubeadm init sur le noeud master(control plane)
  • kubeadm join sur les autres noeuds (worker) (avec le token fournit par la commande kubeadm init)
• Copier le fichier de configuration généré par kubeadm init
• Installer le plugin Réseau
• Optionnellement: Tester le déploiement d'un pod

kubeadm demo

kubeadm fonctionnalités

• En plus de l'installation de Kubernetes, kubeadm peut :

  • Génération des fichiers de configuration: Crée les fichiers de configuration nécessaires pour les composants du cluster.

  • Gestion des certificats: Génère et distribue les certificats nécessaires pour sécuriser les communications entre les composants du cluster.

  • Gestion des tokens: Crée des tokens d'authentification pour les nœuds qui rejoignent le cluster.

  • Vérification de la configuration: Valide que le système et les configurations sont compatibles avec Kubernetes.

  • Mises à jour et modifications: Facilite les mises à jour des versions de Kubernetes et les modifications de la configuration du cluster.

Kubernetes managés "as a Service" Majeurs

• Plateformes Cloud Majeures :
  • Amazon Elastic Kubernetes Service (EKS):
    • Documentation : https://aws.amazon.com/fr/eks/
    • Offre une solution entièrement gérée pour déployer, gérer et mettre à l'échelle des clusters Kubernetes sur AWS.
  • Google Kubernetes Engine (GKE):
    • Documentation : https://cloud.google.com/kubernetes-engine
    • Propose une plateforme hautement disponible et entièrement gérée pour exécuter des applications conteneurisées sur Google Cloud Platform.
  • Azure Kubernetes Service (AKS):
    • Documentation : https://azure.microsoft.com/fr-fr/services/kubernetes-service/
    • Permet de déployer et gérer des clusters Kubernetes sur Azure avec une intégration profonde avec les autres services Azure.

Kubernetes managés "as a Service" Populaires

• Autres Plateformes Populaires :
  • DigitalOcean Kubernetes:
    • Documentation : https://www.digitalocean.com/products/kubernetes/
    • Offre une solution simple et abordable pour déployer des clusters Kubernetes sur DigitalOcean.
  • Rancher Kubernetes Engine (RKE):
    • Documentation : https://rancher.com/docs/rke/latest/en/
    • Solution open-source pour gérer des clusters Kubernetes multi-cloud et sur site.
  • Platform9 Managed Kubernetes:
    • Documentation : https://platform9.com/docs/
    • Plateforme de gestion de Kubernetes hybride et multi-cloud.
  • Red Hat OpenShift:
    • Documentation : https://www.openshift.com/
    • Plateforme containerisée complète basée sur Kubernetes, offrant une large gamme de fonctionnalités pour les entreprises.
  • Scaleway Kapsule :
    • Documentation : https://www.scaleway.com/fr/kubernetes-kapsule/
  • Alibaba Container Service for Kubernetes (ACK)
    • Documentation : https://www.alibabacloud.com/fr/product/kubernetes

Autres Installateurs de Kubernetes

• Via Ansible : kubespray https://github.com/kubernetes-sigs/kubespray

• Via Terraform : https://github.com/poseidon/typhoon

• Il existe d'autres projets open source basés sur le langage Go :
  • kube-aws : https://github.com/kubernetes-incubator/kube-aws
  • kops : https://github.com/kubernetes/kops
  • rancher : https://rancher.com/docs/rancher/v2.5/en/
  • tanzu : https://github.com/vmware-tanzu
  • clusterAPI : https://cluster-api.sigs.k8s.io/

Conformité kubernetes

Voici quelques outils permettant de certifier les déploiements des cluster kubernetes en terme de sécurité et de respects des standards

• Sonobuoy
  • https://github.com/vmware-tanzu/sonobuoy
• Popeye
  • https://github.com/derailed/popeye
• kube-score
  • https://github.com/zegl/kube-score
• kube-bench
  • https://github.com/aquasecurity/kube-bench
• Kube-hunter:
  • https://github.com/aquasecurity/kube-hunter

Kubectl : Usage avancé

• Certaines commandes qui modifient un déploimement accepte un flag optionnel --record
• Ce flag stocke la ligne de commande dans le déploiement
• Et est copié aussi dans le replicaSet (annotation)
• Cela permet de suivre quelle commande a créé ou modifié ce replicatset

$ kubectl create -f nginx.yaml --record
deployment.apps/nginx created

# Voir les informations
kubectl rollout history

Kubectl : Usage avancé

• Utiliser le flag --record

# déployer l'image worker:v0.2
kubectl create deployment worker --image=dockercoins/worker:v0.2

# Roll back `worker` vers l'image version 0.1:
kubectl set image deployment worker worker=dockercoins/worker:v0.1 --record

# Le remettre sur la version 0.2:
kubectl set image deployment worker worker=dockercoins/worker:v0.2 --record

# Voir l'historique des changement:
kubectl rollout history deployment worker

Kubectl : Usage avancé

• Il est possible d'augmenter le nombre de pods avec la commande kubectl scale :

kubectl scale --replicas=5 deployment nginx

• Il est possible de changer l'image d'un container utilisée par un Deployment :

kubectl set image deployment nginx nginx=nginx:1.15

Kubectl : Usage avancé

• Dry run. Afficher les objets de l'API correspondant sans les créer :

kubectl run nginx --image=nginx --dry-run=client
kubectl run nginx --image=nginx --dry-run=server

• Démarrer un container en utilisant une commande différente et des arguments différents :

kubectl run nginx --image=nginx \
--command -- <cmd> <arg1> ... <argN>

• Démarrer un Cron Job qui calcule π et l'affiche toutes les 5 minutes :

kubectl run pi --schedule="0/5 * * * ?" --image=perl --restart=OnFailure \
-- perl -Mbignum=bpi -wle 'print bpi(2000)'

Kubectl : Usage avancé

• Se connecter à un container:

kubectl run -it busybox --image=busybox -- sh

• S'attacher à un container existant :

kubectl attach my-pod -i

• Accéder à un service via un port :

kubectl port-forward my-svc 6000

• Mettre en place de l'auto-scaling ex: Mise à l'échelle automatique avec un minimum de 2 et un maximum de 10 réplicas lorsque l'utilisation du processeur est égale ou supérieure à 70 %

kubectl autoscale deployment my-Deployments --min=2 --max=10 --cpu-percent=70  

Kubectl : Logging

• Utiliser kubectl pour diagnostiquer les applications et le cluster kubernetes :

kubectl cluster-info
kubectl get events --sort-by='.lastTimestamp'
kubectl describe node <NODE_NAME>
kubectl describe node <node-name> | grep Taints
kubectl  logs (-f) <POD_NAME>

Kubectl : Logs

• Voir les logs containers kubectl logs
• Il est possible de donner un nom de pod ou un type/nom par exemple si l'on donne un nom de déploiement ou de replica set, les logs correspondront au premier pod
• Par défaut les logs affichées sont celles du premier container dans le pod.

# exemple :
kubectl logs deploy/nginx

• Faire un CTRL-Cpour arrêter la sortie

Kubectl : Afficher les logs en temps réel

kubectl logs supporte les options suivantes : - -f/--follow pour suivre les affichage des logs en temps réel (comme pour tail -f) - --tail pour n'afficher que les n lignes à partir de la fin de la sortie - --since pour n'afficher que les logs à partir d'une certaine date - --timestampsaffichera le timestamp du message

# exemple :
kubectl logs deploy/pingpong --tail 100 --follow --since=5s
# Affichera toutes les logs depuis 5 secondes et commencera au 100eme messages et continuera l'affichage des nouveaux messages

Kubectl : Afficher les logs de plusieurs pods

• Lorsque on spécifie un nom de déploiement, seuls les logs d'un seul pod sont affichés

• Pour afficher les logs de plusieurs pod il faudra utiliser un selecteur (label)

kubectl logs -l app=my-app --tail 100 # -f 

Kubectl : un outil très pratique pour les logs :

stern

Kubectl : Maintenance

• Obtenir la liste des noeuds ainsi que les informations détaillées :

kubectl get nodes
kubectl describe nodes

Kubectl : Maintenance

• Marquer le noeud comme unschedulable (+ drainer les pods) et schedulable :

kubectl cordon <NODE_NAME>
kubectl drain <NDOE_NAME>
kubectl uncordon <NODE_NAME>

Kubectl : Contexts

• Dans le cas ou votre kubeconfig comporte plusieurs clusters

# lister les contextes
kubectl config get-contexts

# Se déplacer dans un contexte 
kubectl config use-context <nom-du-contexte>


# ou

alias kubectx='kubectl config use-context '

# ex: kubectx <nom-du-cluster>

Kubectl : Se déplacer dans un NS de manière permanente

Évite de toujours préciser le flag -n

kubectl get ns

kubectl config set-context --current --namespace <nom-du-namespace>

# ou

alias kubens='kubectl config set-context --current --namespace '

# ex: kubens kube-system 

Kubectl : Installer des plugins

krew est un manager de plugins pour kubectl

installation de krew (https://krew.sigs.k8s.io/docs/user-guide/setup/install/)

kubectl krew install example

kubectl example deploy

Liste des plugins : https://krew.sigs.k8s.io/plugins/ très utiles :

• neat : permet de d'avoir un ouput "propre" d'une resource kubernetes - très utile pour créer des manifestes à partir de resources existantes
• ctx : permet de changer de contexte facilement
• ns : permet de changet de namespace facilement
• node-shell : Créer un shell racine sur un nœud via kubectl, très pratique sur les CSP
• df-pv : Afficher l'utilisation du disque (comme la commande df) pour les volumes persistants
• popeye : Analyse vos clusters pour détecter d'éventuels problèmes de ressources

Scheduling manuel

Taints et Tolerations

Un nœud avec un taint empêche l'exécution sur lui-même des pods qui ne tolèrent pas ce taint

• Les taints et tolerations fonctionnent ensemble
• Les taints sont appliqués aux nœuds
• Les tolerations sont décrites aux niveau des pods
• On peut mettre plusieurs taints sur un nœuds (il faudra que le pod tolère tous ces taints)
• Les taints sont définis ainsi : key=value:Effect

Taints et Tolerations : Champ "Effect"

Ce champ peut avoir 3 valeurs : NoSchedule, PreferNoSchedule, NoExecute

• NoSchedule : Contrainte forte, seuls les pods supportant le taint pourront s'exécuter sur le nœud.
• PreferNoSchedule: Contrainte faible, le scheduler de kubernetes évitera de placer un pod qui ne tolère pas ce taint sur le nœud, mais pourra le faire si besoin
• NoExecute : Contrainte forte, les pods seront expulsés du nœud / ne pourront pas s'exécuter sur le nœuds

Taints et Tolerations : Operateur

• Par valeur par défaut est Equal (key=value:Effect)
• Mais peut avoir aussi comme valeur Exist (keyExist:Effect)

Taints et Tolerations : Utilisation des taints

En ligne de commande

• Ajouter un taint
  • kubectl taint nodes THENODE special=true:NoExecute
  • kubectl taint node worker-0 node-role.kubernetes.io/master="":NoSchedule
  • kubectl taint node worker-2 test:NoSchedule
• Supprimer un taint
  • kubectl taint nodes THENODE special=true:NoExecute-
  • kubectl taint node worker-0 node-role.kubernetes.io/master-
  • kubectl taint node worker-2 test:NoSchedule-
• Lister les tains d'un nœud
  • kubectl get nodes THENODE -o jsonpath="{.spec.taints}"
  • [{"effect":"NoSchedule","key":"node-role.kubernetes.io/master"}]

Taints et Tolerations : Utilisation des tolerations

• Les tolerations peuvent être décrites au niveau des pods ou au niveau des templates de pods dans les replicaset, daemonset, statefulset et deployment.

• Ces tolerations permettront aux pods de s'exécuter sur les nœuds qui ont le taint correspondant.

Taints et Tolerations : Exemples

• Quand il n'y a pas de valeur (value) dans le taint

apiVersion: v1
kind: Pod
metadata:
...
spec:
  tolerations:
    - key: node-role.kubernetes.io/master
      effect: NoSchedule

Taints et Tolerations : Exemples (suite)

• Quand il y a une valeur (value)

apiVersion: v1
kind: Pod
metadata:
...
spec:
  tolerations:
    - key:  special
      value: "true"
      effect: NoExecute
      Operator: Equal

Taints et Tolerations : Cas particulier

Une clé vide avec un opérateur Exist fera en sorte que le pod s'exécutera sur tous les nœuds quelque soit leurs taints

exemple :

tolerations:
- operator: "Exists"

nodeSelector

• Champs clé valeur au niveau des podSpecs
• Pour que le pod puisse s'exécuter il faut que le nœud ait l'ensemble des labels correspondants

nodeSelector exemple

Exemples

• Pose du label sur un nœud
  • kubectl label nodes <node-name> <label-key>=<label-value>
  • ex: kubectl label nodes worker-0 disktype=ssd
• Utilisation dans un pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

Affinité / Anti-affinité

Ce système permet de gérer très finement les règles de placement des pods en regard de la simplicité du nodeSelector

• Le langage permettant d'exprimer les affinités / anti-affinités est riche de possibilités
• Possibilité de d'écrire des préférences soft (pod déployé malgré tout) ou hard (pod déployé uniquement si les règles sont respectées)
• Contraintes dépendantes de labels présents dans d'autres pods

Node Affinity

• Égal conceptuellement au nodeSelector, mais avec la possibilité de faire du soft (should) ou hard (must)
• Soft : preferredDuringSchedulingIgnoredDuringExecution
• Hard : requiredDuringSchedulingIgnoredDuringExecution

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In # (NotIn, Exists, DoesNotExist, Gt, Lt)
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In # (NotIn, Exists, DoesNotExist, Gt, Lt)
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

Un autre exemple

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
             - ssd
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

Pod Affinity

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

Pod anti-Affinity

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0

Authentication & Autorisation

Authentication

Authentication (Qui êtes-vous ?):

• Vérifie l'identité de l'utilisateur

• Méthodes principales :

  • Certificats clients X.509
  • Tokens Bearer (JWT)
  • Service Accounts pour les pods
  • OpenID Connect / OAuth2
  • Fichiers de configuration statiques

Résultat : identité confirmée ou requête rejetée

RBAC (Autorisation)

Authorization (Que pouvez-vous faire ?):

• Vérifie les permissions de l'utilisateur authentifié
• Utilise principalement RBAC (Role-Based Access Control)

• Composants clés :

  • Roles : définissent les permissions dans un namespace
  • ClusterRoles : permissions à l'échelle du cluster
  • RoleBindings : lient les rôles aux utilisateurs dans un namespace
  • ClusterRoleBindings : lient les rôles aux utilisateurs au niveau cluster

3 entités sont utilisées :

• Utilisateurs représentés par les Users ou les ServiceAccounts
• Ressources représentées par les Deployments, Pods, Services, etc...
• les différentes opérations possibles : create, list, get, delete, watch, patch

RBAC

• L'authentification précède toujours l'autorisation
• Une requête doit passer les deux contrôles pour être acceptée
• Les deux mécanismes sont indépendants mais complémentaires
• RBAC est le standard de facto pour l'autorisation dans Kubernetes

Service Accounts

• Objet Kubernetes permettant d'identifier une application s'exécutant dans un pod
• Par défaut, un ServiceAccount par namespace
• Le ServiceAccount est formatté ainsi : system:serviceaccount:<namespace>:<service_account_name>

Service Accounts

apiVersion: v1
kind: ServiceAccount
metadata:
    name: default
    namespace: default

Role

• L'objet Role est un ensemble de règles permettant de définir quelle opération (ou verbe) peut être effectuée et sur quelle ressource
• Le Role ne s'applique qu'à un seul namespace et les ressources liées à ce namespace

Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding

• L'objet RoleBinding va allouer à un User, ServiceAccount ou un groupe les permissions dans l'objet Role associé
• Un objet RoleBinding doit référencer un Role dans le même namespace.
• L'objet roleRef spécifié dans le RoleBinding est celui qui crée le liaison

RoleBinding

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole

• L'objet ClusterRole est similaire au Role à la différence qu'il n'est pas limité à un seul namespace
• Il permet d'accéder à des ressources non limitées à un namespace comme les nodes

ClusterRole

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

 kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: salme-reads-all-pods
subjects:
- kind: User
  name: jsalmeron
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

RBAC

kubectl auth can-i get pods /
--namespace=default /
--as=spesnova@example.com

NetworkPolicies

NetworkPolicies

• La ressource NetworkPolicy est une spécification permettant de définir comment un ensemble de pods communiquent entre eux ou avec d'autres endpoints

• Le NetworkPolicy utilisent les labels pour sélectionner les pods sur lesquels s'appliquent les règles qui définissent le trafic alloué sur les pods sélectionnés

• Le NetworkPolicy est générique et fait partie de l'API Kubernetes. Il est nécessaire que le plugin réseau déployé supporte cette spécification

NetworkPolicies

• DENY tout le trafic sur une application
• LIMIT le trafic sur une application
• DENY les trafic entrant et sortant dans un namespace
• DENY tout le trafic venant d'autres namespaces
• exemples de Network Policies : https://github.com/ahmetb/kubernetes-network-policy-recipes

NetworkPolicies

• Exemple de NetworkPolicy permettant de bloquer le trafic entrant :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-deny-all
spec:
  podSelector:
    matchLabels:
      app: web
  ingress: []

NetworkPolicies : outils : Cilium Network Policy Editor

Cilium Network Policy Editor : https://editor.networkpolicy.io/?id=xJYCeLwGmAGxTqjm

NetworkPolicies : outils : Tufin Network Policy Viewer

Tufin Network Policy Viewer : https://orca.tufin.io/netpol/

NetworkPolicies : outils : Kubernetes NetworkPolicy viewer

Kubernetes NetworkPolicy viewer : https://artturik.github.io/network-policy-viewer/

Pod Security Admission

Alpha en 1.22, GA depuis la 1.25

Plus simple que les PSP.

• S'appuie sur les standards de sécurité des pods (Pod Security Standards - PSS).
• Définit trois politiques :
  • privileged (peut tout faire ; pour les composants système)
    • peut tout faire
  • restricted (pas d'utilisateur root ; presque aucune capacité)
    • La politique Restricted vise à appliquer les meilleures pratiques actuelles de renforcement des Pods, au détriment d'une certaine compatibilité.
    • Elle est destinée aux opérateurs et développeurs d'applications critiques pour la sécurité, ainsi qu'aux utilisateurs à faible niveau de confiance.
  • baseline (intermédiaire avec des valeurs par défaut raisonnables)
    • La politique Baseline vise à faciliter l'adoption pour les charges de travail conteneurisées courantes tout en prévenant les escalades de privilèges connues.
    • Cette politique est destinée aux opérateurs d'applications et aux développeurs d'applications non critiques.
• Labels sur les namespaces pour indiquer quelles politiques sont autorisées.
• Supporte également la définition de valeurs par défaut globales.
• Supporte les modes enforce, audit et warn.

Pod Security Admission : Namespace labels

Trois labels optionnels peuvent être ajoutés aux namespaces :

• pod-security.kubernetes.io/enforce
• pod-security.kubernetes.io/audit

• pod-security.kubernetes.io/warn

• enforce = empêche la création de pods
• warn = autorise la création mais inclut un avertissement dans la réponse de l'API (sera visible par exemple dans la sortie de kubectl)

• audit = autorise la création mais génère un événement d'audit de l'API (sera visible si l'audit de l'API a été activé et configuré)

Les valeurs possibles sont :

• baseline,
• restricted,
• privileged

(définir la valeur à privileged n'a pas vraiment d'effet)

Pod Security Admission : Exemple

apiVersion: v1
kind: Namespace
metadata:
  labels:
    kubernetes.io/metadata.name: formation-k8s
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  name: formation-k8s

Les trois lignes suivantes définissent les labels:

pod-security.kubernetes.io/enforce=baseline :

- Applique la politique de sécurité "baseline" en mode "enforce". 
- Cela empêchera la création de pods qui ne respectent pas les critères de sécurité de base.
 

pod-security.kubernetes.io/audit=restricted :

- Configure l'audit en mode "restricted". 
- Cela générera des événements d'audit pour les pods qui ne respectent pas les critères de sécurité restrictifs.
  

pod-security.kubernetes.io/warn=restricted :

- Active les avertissements en mode "restricted". 
- Cela produira des avertissements lors de la création de pods qui ne respectent pas les critères de sécurité restrictifs.

Pod Security Admission : Revenir en arriere

apiVersion: v1
kind: Namespace
metadata:
  labels:
    kubernetes.io/metadata.name: formation-k8s
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged
  name: formation-k8s

• Typiquemement les pod dans kube-system doivent pouvoir être en mode privileged.
• Si vous ne définissez pas de PSA les pod privilégiés sont autorisés.

Upgrade de l'OS

• Le retrait d'un noeud du cluster peut survenir suite à une panne ou pour des fins de maintenance comme des opérations de mise à jour, ou d'application de correctifs de sécurité.
• La commande kubectl drain permet de vider un noeud des pods qu'il héberge vers un autre noeud, puis de marquer le noeud "not schedulable". Ainsi au cours de l'opération de maintenance, aucun pod ne peut lui être affecté.

Upgrade de l'OS

• Avec kubectl uncordon, le noeud est remis dans le cluster et peut à nouveau héberger des pods.
• La commande kubectl cordon marque uniquement le noeud "not schedulable" tout en conservant les pods qu'il héberge. Il s'assure simplement que de nouveaux pods ne lui soient pas affectés.

Upgrade de l'OS

• Il est important de mettre à jour la version de kubernetes afin de bénéficier de nouvelles fonctinnalités.
• Ce process s'effectue par la mise à jour des composants du control plane
• Les composants du control plane peuvent avoir des versions différentes mais celle de l'API server doit toujours être suppérieure à celle des autre composants
• Le passage de version s'effectue de façon incrémentielle. On ne peut par exemple que passer de la version v1.19.x à la version v1.23.x
• Un upgrade de Kubeadm met à jour les composants du control plane sauf le kubelet. Il est nécessaire de le mettre à jour séparément pour un passage à niveau complet.

Upgrade de l'OS

• Voici les étapes à suivre pour une mise à niveau d'un cluster avec Kubeadm:
• La commande kubeadm upgrade plan fournit les informations sur la version actuelle de kubeadm installée, la version du cluster et la dernière version stable de Kubernetes disponible

 kubectl drain worker-0
 apt-get upgrade -y kubeadm=1.21.0-00
 apt-get upgrade -y kubelet=1.21.0-00
 apt-get upgrade node config --kubelet-version v1.21.0
 systemctl restart kubelet
 kubectl uncordon worker-0

ETCD sauvegarde et restauration

• Il est recommandé de faire des sauvegardes régulières de la base de données ETCD. Une restauration peut être nécessaire après un désastre ou une maintenance.
• etcdctl est un client en ligne de commande du service ETCD
• Avec une installation par défaut de Kubeadm, la base de données clé-valeur ETCD est déployée en tant que pod statique sur le Master node.
• Les commandes
  • etcdctl snapshot save -h = sauvegarder la base de données.
  • etcdctl snapshot restore -h = restaurer la base de données.

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 !