Skip to content

Kubernetes

Architecture

Kubernetes dispose d'une architecture modulable. Permet la création de distributions Kubernetes. On peut rapprocher Kubernetes d'un OS pour containers.

  • CRI: Container Runtime Interface
  • CNI: Container Network Interface
  • CSI: Container Storage Interface

Kubernetes est un système API-centric avec des resources telles que les deployments, pod, nodes etc. Le client CLI, les nodes dialoguent avec le serveur d'API (situé sur le master).

La persistance est gérée par un moteur clé-valeur (etcd).

On peut query n'importe quelle instance de resource en utilisant un système de labels et selectors.

Warnings

Kubernetes is hard!

Jess Frazelle: Business Executive Guide to Kubernetes

  • Kubernetes ne doit pas être utilisé pour la data et les applications stateful (StatefulSet, Kubernetes n'offre pas de solution de réplication de data)
  • Attention à la sécurité du dashboard et de l'API du master control plane !
  • Upgrader Kubernetes est périlleux. Il faut avoir plus d'un cluster en production.
  • Kubernetes est difficile à apprendre et à exploiter
  • Kubernetes managé facilite la tâche mais de nombreux concepts à maitriser pour le day to day

Distributions

Kubernetes peut être vu comme un OS open source pour containers. Il existe donc plusieurs distributions Kubernetes sur le marché:

Liste des distributions (CNCF maintained)

Distributions certifiées:

La CNCF valide les différentes distributions via un programme de certification:

  • API Kubernetes correctement supportée ? (CRI-O, etc)
  • Support des quelles versions de kube

Versions de Kubernetes:

  • upstream: la version originale de kubernetes/kubernetes - permet d'avoir les dernières fonctionnalités et mises à jour
  • packaged: (ex: OpenShift ou Rancher) - souvent avec de la valeur ajoutée

Schémas

Concepts

Kubernetes engine:

Installation de Kubernetes: GKE, EKS... Une fois l'engine crée, il faut encore créer le ou les clusters qui seront à l'intérieur

Cluster

  • on doit spécifier le nombre de nodes du cluster kubernetes

Master

1 master gouverne plusieurs workers/nodes

Contient l'API Server + le Replication Controller + le Scheduler, et relié à etcd.

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é

Controller: appelle le scheduler pour obtenir des resources en fonction de sa conf (voir Controllers)

Etcd: KV store qui stocke la configuration du cluster et son current state.

Node

Appelé worker ou minion (ancien borg name)

VM ou machine physique. Un node accueille plusieurs pods

chaque node run aussi:

  • Kubelet: agent Kubernetes
  • kube-proxy: route le trafic vers le bon container et implémente la CNI choisie par la distrib Kubenrnetes
  • container runtime: Docker la plupart du temps
  • sidecars: exemple fluentd peut être installé sur tous les pods pour remonter les logs

Pod

Groupement logique de containers et volumes (process inter-dépendants, resources partagées etc). On peut le voir comme la représentation interne des containers dans Kubernetes.

commande commentaire
kubectl run mypodinstance --image=myimage:mytag crée un pod (deployment)
kubectl get pods liste rapide des pods et leur statut
kubectl logs -f mypod logs du pod
  • possède 1 seule adresse IP qui change au restart
  • de base, accessible uniquement depuis l'intérieur du cluster
  • tous les container sur un même pod se connaissent au niveau network et storage
  • contient plusieurs containers et volumes
  • pod template = conf pour créer des réplicas de pod
  • HPA: Horizontal Pod Autoscaling, policy pour faire du scaling auto
  • Manifest: fichier de configuration du pod

Labels: permet de grouper des pods et des les sélectionner pour faire des opérations dessus (ex: app=myapp tier=backend)

Probes

Article source: Most common mistakes K8S

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!)

Service

Resource accessible de l'extérieur du cluster. Un service = une IP (+ DNS endpoint optionnel) fixe par service.

Via les services, gestion de service discovery: routage du trafic vers les bons pods (qui changent tout le temps d'IP), peu importe où ils soient.

L'action de créer un service en partant d'un deployment / pod = exposition

1
2
kubectl expose deployment nginx --port 80 --type LoadBalancer
kubectl get services

Types de services:

  • LoadBalancer
  • ClusterIP
  • NodeIP

Controllers

Les controllers sont les objets qui configurent les pods. Chaque controller contient:

  • un kind: deployment, replicaSet etc.
  • une spec: permet de spécifier quels containers faire tourner et/ou quels resources sélectionner via une query (labels + selectors)

Deployment

kubectl run nginx --image=nginx:1.0.0 crée un deployment

ReplicaSet

Permet de spécifier une conf de scaling.

StatefulSet

Le fameux controller qui permet de gérer des applications stateful.

Les pods créées avec StatefulSet auront un nommage stable et prévisible (exemple database-01, database-02)

Volumes

PV

Déclaration du volume total disponible sur le cluster, de type Storage Class. Exemple: le cluster a 50Mo de NFS storage et un S3 dispo.

Le cycle de vie du PV est donc indépendant du cycle de vie des nodes.

Un cluster administrator doit veiller à offrir plusieurs types de storage class.

PVC

Allocation d'un PV pour faire un volume sur un pod. Exemple: le pod demande un PVC

Storage classes

Type de storage à allouer sur le cluster

  • hostPath: prend un répertoire ou un fichier sur le host et en fait un PV. Uniquement à utiliser sur du Minikube (single node cluster)

todo

  • operators
  • manifests
  • helm / charts

Tools

Kubectl

Outil officiel CLI pour interagir avec l'API Master

Action Commande
cert / CA / client key cat ~/.kube/config
adresse du cluster kubectl cluster-info

Minikube

Single node cluster pour dev environment. Utiliser le driver virtualbox de préférence (et pas none!): permet d'utiliser le cluster en non-sudoer, driver le plus stable.

Helm

Outil officiel de gestion de package

  • Package: une application qui contient des charts et des templates
  • Chart: chart.yml, équivalent d'un docker-compose
  • Template: autres fichiers de config

Debugging patterns

port-forwarding: on redescend au niveau du pod et sans avoir besoin d'un service, on port forward ce dont on a besoin.

1
2
// port local:pod port
kubectl port-forward mypod 10080:80

exec command / shell access: le classique équivalent du docker run --rm -it mycontainer /bin/sh, mais en Kubernetes

1
kubectl exec mypod --stdin --tty -c mycontainer /bin/sh

Auto-formation

Concepts

Utiliser un cluster

Installer un cluster