Ai-je besoin d'un Orchestrateur ?

1 conteneur

Plusieurs conteneurs

Cluster de serveurs et distribution des resources

Mise à l'échelle

'self healing'

'Rolling deployment'

Load balancer

Kubernetes en particulier

• Abstraction de tous ces concepts
• Extensibilité
• Adoption massive

Une API pour les gouverner tous

Et pour le développeur ?

• Culture DevOps
• You build it, you run it

→ Kubernetes peut devenir un prérequis pour tout développeur (cf. Docker...)

Timeline

Genèse : Google

• 2003 : Borg
• 2013 : Omega
• 2014 : Kubernetes, héritier OSS de Borg
• 07/2015
  • Kubernetes 1.0
  • Naissance de la CNCF (Google + The Linux Foundation)

Adoption

• 06/2015 : RedHat OpenShift v3
• 08/2015 : Release de Google Container Engine
• 09/2016 : Etude de cas Pokemon GO! sur GCP
• 08/2017 : Github sur Kubernetes (API)
• 05-06/2018
  • Rancher v2 (Cattle → Kubernetes)
  • Amazon EKS
  • Microsoft Azure AKS

Architecture

Anatomie d'un Cluster

• Master node
  • etcd : stockage clé/valeur
  • API server
  • Controller manager : état des objets
  • Scheduler : choix des noeuds pour l'exécution
• Worker nodes (minions)
  • kubelet : exécution des pods sur les workers
  • kube-proxy : règles réseau
  • Container runtime : exécution des conteneurs

Exécution des conteneurs

CRI : Container Runtime Interface

• Docker
• Containerd
• CRI-O
• ... ?

Dév : J'aimerais que mon application soit déployée en 2 instances.

Le controller manager est alerté, il crée et persiste les définitions de pods pour l'application.

Le scheduler voit que des pods sont en attente. Il cherche un worker pour chacun et persiste l'information.

Chaque kubelet concerné est alerté et exécute son container runtime pour déployer le(s) pod(s).

Du coup, on se monte un petit cluster ?

Solutions

Services managés cloud :

• GKE, AKS, EKS, Digital Ocean, OVH, ...
• RedHat OpenShift
• Rancher

Concepts de base

Pod

• Ressource de base d'un déploiement
• Abrite 1 ou plusieurs containers
• Éphémère

Labels et selectors

• Label : étiquette sur une ressource. Exemples :
  • app : application name
  • environment : dev/prod/...
  • component : back/front/db...
• Label selector : identification d'un ensemble de ressources

Deployment

Service

• Expose l'accès réseau à un groupe de pods (sorte de load balancer)
• DNS interne
  • [service name].[namespace].svc.cluster.local
• Peut servir une IP externe
• Non éphémère

Service

Service

Ingress

• Expose des accès externes vers des services du cluster
• Définition de règles de routage host/path
• Nécessite un Ingress controller dans le cluster
  • Traefik
  • Nginx
  • HAProxy...

Ingress

Développement

Kubectl

Utilitaires du terminal

• kube-ps1
• kubectx
• kubens

Templating des manifestes

• Helm
• Kustomize

Log / Debug

• Voir les logs : kubectl logs
• Voir mieux les logs : Stern
• Lancer un pod dans le cluster :
  • kubectl run -it --rm alpine --image=alpine sh
• Accès en local aux services du cluster : kubefwd

Focus sur Kubectl

Mode Impératif commande

$ kubectl run nginx --image nginx
						

$ kubectl create deployment nginx --image=nginx
						

kubectl scale|annotate|edit|patch ...

Limitations

• Options limitées : plusieurs commandes parfois nécessaires
• Pas de versioning de la configuration
• Pas de templating des ressources

Mode Impératif fichier

$ kubectl create -f config.yaml
						

$ kubectl replace -f config.yaml
						

Limitations

• Ecrase toute modification extérieure
• On doit connaître l'existence ou non de la ressource (create vs replace)
• Marche mal sur les répertoires selon la doc

Mode Déclaratif

$ kubectl apply -f config.yaml
						

$ kubectl apply -Rf my_config_folder/
						

• Gère création / mise à jour / suppression
• Merge les modifications sans les écraser
• Permet de développer une approche GitOps

On décrit l'état désiré ; Kube fait le reste !

Démo