Kubernetes sur Google Cloud Platform

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"... Kubernetes

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. Kubernetes

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...