Dans un précédent blog, nous avons pu voir l’aspect théorique de Kubernetes, ses différents composants et ses objets. Tout cela peut paraitre confus et complexe, mais étudions à présent un exemple simple concernant le déploiement d’une application sur un cluster Kubernetes.
Préparation de l’environnement Kubernetes:
Nous créons, dans un premier temps, notre cluster Kubernetes (K8S) sur la Google Cloud Plateform (GCP). Par défaut, les machines utilisées par Google sont des n1-standard-1. Il est possible de choisir les VMs que l’on souhaite avec la commande --machine-type=<machine_type> au moment de la création du cluster. En quelques secondes, on dispose d’un K8S déjà managé. Vous pouvez bien entendu procéder à l’installation vous même, mais cela prendre plus de temps.
gcloud container clusters create <CLUSTER_NAME> --num-nodes=<NUM_NODES --machine-type=<MACHINE_TYPE>>
Un des avantages du système est la possibilité de gérer notre cluster directement dans la UI de GCP.
Un unique cluster avec un noeud et un core est utilisé à titre d’exemple. Dans la pratique, on appliquera plusieurs noeuds (3+) avec au minimum 2 à 4 cores. En effet, K8S/GCP exploitent de base un certain nombre de containers “systèmes”…
Déploiement
Dans Kubernetes, l’état du cluster est toujours le reflet des fichiers de configuration. Lorsqu’on envoie un nouveau fichier, le cluster va faire évoluer sa configuration en allouant des ressources, pour converger vers l’état désiré. Le fichier de déploiement permet de lancer notre application avec divers paramètres que nous allons détailler. my-deployment.yaml:
apiVersion: apps/v1beta1 # version api de kubernetes
kind: Deployment # Type de fichier: Pod / Déploiement ...
metadata:
name: watchdog-deployment # nom du deploiement
labels: # clés/valeurs qui définissent notre pod deploiement
app: watchdog
spec: # spécificités du deploiement
replicas: 3 # nombre de répliques de notre pod
selector: # définition des pods à manager par le déploiement -> par rapport aux valeurs des labels
matchLabels:
app: watcher
template: # definition du pod
metadata:
labels: # clés/valeurs qui définissent notre pod
app: watcher
spec: # spec du pod
containers: # containers tournant dans le pod
- name: watcher # nom du conteneur
image: gcr.io/affini-tech-00/watchdog:v1 # image du conteneur
resources:
requests: # ressources demandées
cpu: "0.100"
limits: # limite du CPU allouée attribuée au conteneur
cpu: "0.500"
- name: consumer-gcs
image: gcr.io/affini-tech-00/consumer-gcs:v1
resources:
requests:
cpu: "0.100"
limits:
cpu: "0.500"
- name: consumer-bq
image: gcr.io/affini-tech-00/consumer-bq:v1
resources:
requests:
cpu: "0.100"
limits:
cpu: "0.500"
L’application décrite dans ce déploiement comporte 3 containers qui fonctionnement ensemble pour apporter un service. Pour cette raison, ils sont intégrés dans le même pod (groupe de containers qui partagent un réseau et un espace de stockage). Ce choix de granularité du pod pourrait être le sujet d’un blog à lui tout seul…
Le lancement de l’application est aussi simple que l’envoie au cluster du fichier de configuration :
kubectl create -f ./my-deployment.yaml
La commande kubectl get deployments nous permet enfin de nous assurer du bon déploiement de notre application.
Votre première application tourne désormais dans Kubernetes ! Dans de prochains blogs, nous regarderons comment exposer des services, utiliser des types de déploiements plus spécifiques pour répondre à des besoins particulier, etc…