# Présentation de GKE

Google Kubernetes Engine (GKE) est un environnement géré grâce auquel vous pouvez déployer, gérer et faire évoluer vos applications en conteneurs à l'aide de l'infrastructure Google. Il comprend plusieurs machines (en particulier, les instances Compute Engine) regroupées pour former un cluster.

## Orchestration de cluster avec GKE

Les clusters GKE sont basés sur le système de gestion de clusters open source Kubernetes. Les mécanismes de Kubernetes vous permettent d'interagir avec votre cluster. Grâce aux commandes et aux ressources proposées, vous pouvez déployer et gérer vos applications, effectuer des tâches d'administration, définir des stratégies et surveiller l'état de vos charges de travail déployées.

Kubernetes et les services Google les plus couramment utilisés reposent sur les mêmes principes de conception et présentent les mêmes avantages tels que la gestion automatique, la surveillance et la vérification de la vivacité pour les conteneurs d'applications, le scaling automatique et les mises à jour progressives. Lorsque vous faites fonctionner vos applications dans un cluster, vous utilisez des technologies qui sont le fruit de plus de 10 années d'expérience que Google a consacrées à l'exécution de charges de travail de production dans des conteneurs.

## Kubernetes sur Google Cloud

Quand vous exécutez un cluster GKE, vous bénéficiez également des avantages qu'offrent les fonctionnalités avancées de gestion de clusters proposées par Google Cloud, y compris :

* l'équilibrage de charge de Google Cloud pour les instances Compute Engine
* les pools de nœuds pour désigner des sous-ensembles de nœuds au sein d'un cluster pour plus de flexibilité
* le scaling automatique du nombre d'instances de nœuds de votre cluster
* les mises à niveau automatiques du logiciel des nœuds de votre cluster
* la réparation automatique des nœuds pour gérer l'état et la disponibilité des nœuds
* la journalisation et la surveillance avec la suite Google Cloud Operations pour plus de visibilité dans votre cluster

> **_SOURCE:_** https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview?hl=fr

### Node pools

Un pool de nœuds est un groupe de nœuds au sein d'un cluster qui possèdent tous la même configuration. Les pools de nœuds utilisent une spécification NodeConfig. Chaque nœud du pool possède un libellé de nœud Kubernetes, cloud.google.com/gke-nodepool, qui a pour valeur le nom du pool.

Lorsque vous créez un cluster, le nombre et le type de nœuds que vous spécifiez sont utilisés pour créer le premier pool de nœuds du cluster. Ensuite, vous pouvez ajouter à votre cluster d'autres pools de nœuds personnalisés de tailles et de types différents. Tous les nœuds d'un pool donné sont identiques les uns aux autres.

Par exemple, vous pouvez créer un pool de nœuds dans votre cluster avec des disques SSD locaux, une configuration minimale pour la plate-forme du processeur et des Spot VM, une image de nœud spécifique, différents types de machines ou une interface de réseau virtuel plus efficace.

Les pools de nœuds personnalisés sont utiles lorsque vous devez planifier des pods nécessitant plus de ressources que d'autres, par exemple plus de mémoire ou plus d'espace disque local. Si vous avez besoin de davantage de contrôle sur l'emplacement des pods, vous pouvez utiliser des rejets de nœuds.

Vous pouvez créer, mettre à niveau et supprimer des pools de nœuds individuellement sans affecter l'ensemble du cluster. Vous ne pouvez pas configurer un seul nœud dans un pool de nœuds : toute modification de la configuration affecte tous les nœuds du pool de nœuds.

Vous pouvez redimensionner des pools de nœuds dans un cluster en ajoutant ou en supprimant des nœuds.

Par défaut, tous les nouveaux pools de nœuds exécutent la même version de Kubernetes que le plan de contrôle. Les pools de nœuds existants peuvent être mis à jour manuellement ou automatiquement. Vous pouvez également exécuter des versions différentes de nœuds Kubernetes dans chaque pool de nœuds de votre cluster, mettre à jour chaque pool de manière indépendante, et cibler différents pools de nœuds pour des déploiements spécifiques.

> **_SOURCE:_** https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools?hl=fr

### Autoscaling

Lorsque la demande est élevée, l'autoscaler de cluster ajoute des nœuds au pool de nœuds. Lorsque la demande est faible, l'autoscaler de cluster redimensionne les pools à la taille minimale que vous avez définie. Cela permet d'augmenter la disponibilité de vos charges de travail lorsque vous en avez besoin, tout en contrôlant les coûts. Pour savoir comment configurer l'autoscaler de cluster, consultez la page Procéder à l'autoscaling d'un cluster.

Avec les clusters Autopilot, vous n'avez pas à vous soucier du provisionnement des nœuds, ni de la gestion des pools de nœuds, car les nœuds sont soumis à un provisionnement automatique et les pools de nœuds font l'objet d'un scaling automatique afin de répondre aux exigences de vos charges de travail.

#### Aperçu
L'autoscaler de cluster de GKE redimensionne automatiquement le nombre de nœuds dans un pool de nœuds donné, en fonction des exigences de vos charges de travail. Vous n'avez pas besoin d'ajouter ou de supprimer manuellement des nœuds, ni de surprovisionner vos pools de nœuds. À la place, il suffit de spécifier une taille minimale et maximale pour le pool de nœuds, et le reste est automatique.

Si des ressources sont supprimées ou déplacées lors de l'autoscaling de votre cluster, vos charges de travail peuvent être temporairement interrompues. Par exemple, si votre charge de travail comprend un contrôleur avec une seule instance dupliquée, le pod de cette instance dupliquée peut être reprogrammé sur un nœud différent si son nœud actuel est supprimé. Avant d'activer l'autoscaler de cluster, concevez vos charges de travail de manière à tolérer des perturbations potentielles ou assurez-vous que les pods critiques ne sont pas interrompus.

#### Comment fonctionne l'autoscaler de cluster
L'autoscaler de cluster fonctionne par pool de nœuds. Lorsque vous configurez un pool de nœuds avec l'autoscaler de cluster, vous spécifiez une taille minimale et maximale pour le pool de nœuds.

L'autoscaler de cluster augmente ou diminue automatiquement la taille du pool de nœuds en ajoutant ou en supprimant des instances de machine virtuelle (VM) dans le groupe d'instances géré Compute Engine sous-jacent pour le pool de nœuds. L'autoscaler de cluster prend ces décisions de scaling en fonction des demandes de ressources (plutôt qu'en fonction de l'utilisation réelle des ressources) des pods exécutés sur les nœuds de ce pool. Il vérifie régulièrement l'état des pods et des nœuds, et prend les mesures suivantes :

Si les pods ne peuvent pas être programmés, car il n'y a pas assez de nœuds dans le pool de nœuds, l'autoscaler de cluster en ajoute, jusqu'à atteindre la taille maximale du pool de nœuds.
Si les nœuds sont sous-utilisés et que tous les pods peuvent être programmés, même avec moins de nœuds dans le pool, l'autoscaler de cluster supprime des nœuds, jusqu'à atteindre la taille minimale du pool de nœuds. Si des pods d'un nœud ne peuvent pas être déplacés vers d'autres nœuds du cluster, l'autoscaler de cluster ne tente pas de réduire la capacité de ce nœud. Si les pods peuvent être déplacés vers d'autres nœuds, mais que le nœud ne peut pas être drainé correctement après un délai d'inactivité (actuellement de 10 minutes), le nœud est automatiquement arrêté. Le délai de grâce n'est pas configurable pour les clusters GKE. Pour en savoir plus sur le fonctionnement du scaling à la baisse, consultez la documentation sur l'autoscaler de cluster.
Si vos pods ont demandé trop peu de ressources (ou n'ont pas changé les valeurs par défaut qui pourraient être insuffisantes) et si vos nœuds connaissent des manques, l'autoscaler de cluster ne corrigera pas la situation. Vous pouvez vous assurer que l'autoscaler de cluster fonctionne aussi précisément que possible en effectuant des demandes de ressources explicites pour toutes vos charges de travail.

> **_SOURCE:_** https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler?hl=fr

### Gestion du loadBalancer

Afin de rendre disponible un service a l'extérieur de nore cluster GKE, nous avons choisis de nous appuyer sur le loadbalancer Google. Ce dernier sera créé automatiquement à la création de l'ingress controller.

ci dessous le fichier `helmfile` permettant ça création:

repositories:
  - name: ingress-nginx
    url: https://kubernetes.github.io/ingress-nginx


releases:
  - name: ingress-nginx
    namespace: ingress-nginx
    chart: ingress-nginx/ingress-nginx
    version: 4.1.4
    values:
    - controller:
        service:
          type: LoadBalancer
          loadBalancerIP: XX.XX.XX.XX
        metrics:
          enabled: true
          serviceMonitor:
            enabled: true
            additionalLabels:
              release: monitoring

Une fois le controller installé vous devais voir ce dernier dans l'IHM Google:


# Le monitoring dans Google

Google permet de monitoré votre cluster directement dans l'IHM `google cloud`. vous pouvez y acceder en suivant ce lien : [Google Monitoring](https://console.cloud.google.com/monitoring)

il est interessant de créer vos dashboard personalisé afin de bien maitriser les informations remontées.

## Dans la pratique

Google met a votre disposition la possibilité de remonté vos données de type `time series` et de vous les formatés sous formes graphique dans la section `Monitoring`.
Dans votre cluster GKE vous retrouverez les pods suivants permettant la remonté de ces informations:

kube-system     gke-metrics-agent-4wp57                                           1/1     Running
kube-system     gke-metrics-agent-cblxd                                           1/1     Running
kube-system     gke-metrics-agent-crtzl                                           1/1     Running
kube-system     gke-metrics-agent-r8rhf                                           1/1     Running

Ces pods sont déployés avec un `DaemonSet` donc vous retrouverez un pod pas worker node.
Vous retrouverez également le pod `metric-server` pour l'agrégation des données avant de les remonter dans le cluster central Google. Ce dernier est déployé avec un `ReplicaSet`:

kube-system     metrics-server-v0.4.5-fb4c49dd6-gkjfp                             2/2     Running

Une fois cela installé nous pouvons visualisé l'état de notre cluster.


La documentation pour le monitoring de vorte cluster GKE est [ici](https://cloud.google.com/stackdriver/docs/solutions/gke/observing?hl=fr)

# Le logging dans Google

Cloud Logging est un service entièrement géré qui vous permet de stocker, de rechercher, d'analyser et de surveiller les données et les événements de journalisation de Google Cloud, puis de déclencher des alertes le cas échéant. Vous pouvez collecter des données de journalisation à partir de plus de 150 composants d'application

Afin de pouvoir centraliser vos logs sur le cluster centraliser de Google, vous devez ajouter des droits à votre service account du cluster GKE :

gcloud projects add-iam-policy-binding d-irs-woi-dev-321 \
--member "serviceAccount:[e-mail]" \
--role roles/logging.logWriter

gcloud projects add-iam-policy-binding d-irs-woi-dev-321 \
--member "serviceAccount:[e-mail]" \
--role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding d-irs-woi-dev-321 \
--member "serviceAccount:[e-mail]" \
--role roles/monitoring.viewer

gcloud projects add-iam-policy-binding d-irs-woi-dev-321 \
--member "serviceAccount:[e-mail]" \
--role roles/stackdriver.resourceMetadata.writer

Une fois cela effectué, vous retrouverez des pods `fluentbit` dans votre cluster, ces derniers seront déployé avec un `DaemonSet` afin d'être présent sur toutes les workers :

kube-system     fluentbit-gke-cvvr6                                               2/2     Running
kube-system     fluentbit-gke-g8889                                               2/2     Running
kube-system     fluentbit-gke-tk6gw                                               2/2     Running
kube-system     fluentbit-gke-v2cpr                                               2/2     Running

Maintenant vous pouvez vous rendre sur [Google Logging](https://console.cloud.google.com/logs) afin de pouvoir explorer / rechercher / filtrer vos logs des service et applicatifs.

Vous pouvez vous servir des [Sample queries](https://cloud.google.com/logging/docs/view/query-library#using-queries) pour vous aider a filtrer dans tous les logs disponibles.

Quelque exemples:

* logs de Kube-proxy : `resource.type="k8s_node" AND
log_id("kube-proxy")`
* logs du runtime : `resource.type="k8s_node" AND
log_id("container-runtime")`
* logs d'un namespace : `resource.type = ("k8s_container" OR "k8s_pod")
resource.labels.namespace_name = (
"wois")`
* logs système: `resource.type = ("k8s_container" OR "k8s_pod")
resource.labels.namespace_name = (
"cnrm-system" OR
"config-management-system" OR
"gatekeeper-system" OR
"gke-connect" OR
"gke-system" OR
"istio-system" OR
"knative-serving" OR
"monitoring-system" OR
"kube-system")`
* logs d'un pod : `resource.type="k8s_pod" AND
resource.labels.pod_name="$POD_NAME" AND
log_id("events")`

Ci dessous le retour dans l'IHM:


* IHM
* Premier pas (k8s / LB)
* Monitoring
* **LOGS**
* **SECU** ( GKE + cert manager)
* k9s (gestion cluster) / Lens

# Intro Terraform avec CI --> Fabrice
* wois-iac
* Terraform avec Gitlab
* init cluster GKE
* installation base K8s
* init gitlab runner
* Sonar

# Refacto code
* CI -> Kevin
* Kaniko
* Helm
* OC to Kubernetes
* vars Maven
# To do / remarques
* Gestion des pods (k8s)
* Gestion des images de conteneurs infra
* Utilisation du plugin kubectl ns (krew)
* Clean de code
* test