Theforge on Valérian Pyckaert https://valerian-pyckaert.dev/categories/theforge/ Recent content in Theforge on Valérian Pyckaert Valérian Pyckaert https://valerian-pyckaert.dev/images/default-cover.svg https://valerian-pyckaert.dev/images/default-cover.svg Hugo en Wed, 03 Jun 2026 19:00:00 +0200 TheForge #4 — Installation de Nginx Gateway Fabric & Cert manager pour exposer les services sur Kubernetes https://valerian-pyckaert.dev/posts/the-forge-gateway/ Wed, 03 Jun 2026 19:00:00 +0200 https://valerian-pyckaert.dev/posts/the-forge-gateway/ Apprenez à installer Nginx Gateway Fabric pour exposer vos services sur Kubernetes. Ce qu’on va faire

Nous allons installer Nginx Gateway Fabric pour exposer nos services Kubernetes sur internet, ainsi que Cert Manager pour gérer les certificats TLS.

Architecture cible

Je possède un nom de domaine chez Cloudflare, je vais donc utiliser Cloudflare comme DNS provider pour gérer les enregistrements DNS de mon domaine. Nginx Gateway Fabric sera configuré pour utiliser un LoadBalancer de type External, ce qui me permettra d’obtenir une adresse IP publique pour exposer mes services.

Voici un schéma pour une meilleur compréhension :

  graph TD
    A[Internet] --> B[Cloudflare DNS + Proxy]
    B --> C[Enregistrement DNS pointant vers l'IP du LoadBalancer GCP]
    C --> D[LoadBalancer GCP]
    D --> E[Nginx Gateway Fabric sur Kubernetes]
    E --> F[HTTPRoute -> Services Kubernetes]
    F --> G[Cert Manager pour TLS]

Étapes

1. Installation de la CRD gateway API

Les ingress controller ne sont plus supportés, il faut désormais ce tourner vers les gateway API. Il existe plusieurs implémentations, j’ai choisi d’installer Nginx Gateway Fabric qui est une solution robuste et bien supportée.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml

ou via ArgoCD (la sync-wave à 0 permet de s’assurer que les CRDs sont installées avant les autres ressources) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gateway-api-crds
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: default
  source:
    repoURL: https://github.com/nginx/nginx-gateway-fabric.git
    targetRevision: v2.6.3
    path: config/crd/gateway-api/standard
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - ServerSideApply=true

2. Installation de Nginx Gateway Fabric

Je vais aller assez vite sur l’installation de Nginx Gateway Fabric, si vous avez suivi les articles précédents cela ne devrait pas poser de problème.

On ajoute dans notre repo de CD la configuration suivante :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gateway-fabric
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  project: default
  source:
    repoURL: ghcr.io/nginx/charts
    chart: nginx-gateway-fabric
    targetRevision: 2.6.3
    helm:
      releaseName: nginx-gateway-fabric
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx-gateway
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Après quelques secondes les ressources sont créées et nous avons notre gateway qui tourne.

kubectl get pods -n nginx-gateway
NAME                                    READY   STATUS    RESTARTS   AGE
nginx-gateway-fabric-77c559bb4f-c7zlb   1/1     Running   0          93s

3. Installation de Cert Manager

Le principe est le même, voici la configuration à appliquer :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: default
  source:
    repoURL: https://charts.jetstack.io
    chart: cert-manager
    targetRevision: v1.20.2
    helm:
      releaseName: cert-manager
      values: |
        crds:
          enabled: true
          keep: true
  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Après quelques secondes les ressources sont créées et nous avons notre cert manager qui tourne.

kubectl get pods -n cert-manager
NAME                                       READY   STATUS              RESTARTS   AGE
cert-manager-65dd558d9c-qzjw9              1/1     Running             0          5m6s
cert-manager-cainjector-77bd875bf4-6bcpn   1/1     Running             0          5m5s
cert-manager-startupapicheck-fhsng         0/1     ContainerCreating   0          2m29s
cert-manager-webhook-69666f4d4c-7wccg      1/1     Running             0          5m6s

4. Configuration Cloudflare

Récupération de l’IP du LoadBalancer GCP

Maintenant que ma gateway est en place, je vais configurer Cloudflare pour pointer mon domaine vers l’IP publique de mon LoadBalancer GCP. Je vais créer un enregistrement A dans Cloudflare qui pointe vers l’IP du LoadBalancer, et je vais activer le proxy de Cloudflare pour bénéficier de la protection DDoS et du CDN.

Pour cela il faut récupérer l’IP du LoadBalancer GCP qui a été créé pour exposer Nginx Gateway Fabric. Vous pouvez le faire avec la commande suivante :

kubectl get svc -n nginx-gateway
# Noter l'EXTERNAL-IP → à mettre dans Cloudflare DNS (enregistrement A)

Création d’un token API Cloudflare

Pour automatiser la configuration de Cloudflare, je vais créer un token API avec les permissions nécessaires pour gérer les enregistrements DNS. Dans Cloudflare → My Profile → API Tokens → Create Token :

Template : Edit zone DNS Permissions : Zone / DNS / Edit Zone : mon domaine (ici valerian-pyckaert.dev)

kubectl create secret generic cloudflare-api-token \
  --namespace cert-manager \
  --from-literal=api-token=<TOKEN_CF>

5. Configuration de Cert Manager pour Cloudflare

Il s’agit maintenant d’ajouter une ressource ClusterIssuer pour utiliser le token API Cloudflare et gérer les certificats TLS automatiquement.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: ton@email.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-key
    solvers:
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

Une fois cette configuration appliquée, Cert Manager pourra automatiquement obtenir et renouveler les certificats TLS pour les domaines gérés via Cloudflare. Pour vérifier le bon fonctionnement :

kubectl get clusterissuer -A
NAME               READY   AGE
letsencrypt-prod   True    17h
kubectl get certificate -A
default     wildcard-cert   True    wildcard-cert   54m

6. Configuration d’une HTTPRoute pour exposer un service

Maintenant que tout est en place, nous allons créer une ressource HTTPRoute pour exposer un service Kubernetes via Nginx Gateway Fabric et positionner le certificat généré par Cert Manager.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: default
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    hostname: "*.mondomaine.com"
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: main-gateway
  hostnames:
  - "app.mondomaine.com"
  rules:
  - backendRefs:
    - name: my-service
      port: 80
---

Résultat

Si vous avez suivi chaque étapes vous devriez avoir un résultat similaire à celui-ci :

❯ kubectl get gateway -A
NAMESPACE   NAME           CLASS   ADDRESS         PROGRAMMED   AGE
default     main-gateway   nginx   34.156.85.195   True         29m
❯ kubectl get httproute -A
NAMESPACE   NAME        HOSTNAMES                         AGE
default     nginx-app   ["nginx.valerian-pyckaert.dev"]   29m
❯ kubectl get certificate -A
NAMESPACE   NAME            READY   SECRET          AGE
default     wildcard-cert   True    wildcard-cert   21m

Votre service devrait être accessible via l’URL https://nginx.mondomaine.com et le certificat TLS devrait être valide, en l’occurence pour moi c’était https://nginx.valerian-pyckaert.dev avec un certificat pour valerian-pyckaert.dev généré par Let’s Encrypt.

Welcome nginx

Pour ce faire j’ai enregistré un enregistrement A dans Cloudflare qui pointe vers l’IP du LoadBalancer GCP : Cloudflare record

Obstacles rencontrés

La gateway ne peut pas accéder au namespace demo et au service nginx

J’avais installé ma ressource HTTPRoute dans le namespace default alors que mon service nginx était dans le namespace demo. Par défaut, la gateway n’a pas accès aux ressources d’autres namespaces, il faut donc lui accorder les permissions nécessaires.

Soit via un ReferenceGrant :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-to-demo
  namespace: demo
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: default
  to:
  - group: ""
    kind: Service

Soit installé la ressource HTTPRoute dans le même namespace que le service nginx (ici demo).

Pods en pending

Par péché de rapidité j’ai volontairement omis de spécifier les ressources CPU et memory de mes workloads, ce qui a pour conséquence que les pods sont restés en pending car le scheduler ne pouvait pas les placer sur un nœud. Il faut donc veiller à toujours spécifier les ressources de vos workloads pour éviter ce genre de problème.

Pour la suite

Dans le prochain et dernier article de cette série The Forge je vous parlerai de SOPS et de comment gérer vos secrets de manière sécurisée dans Kubernetes. Nous verrons comment chiffrer vos secrets avec SOPS et les stocker dans Git pour une gestion centralisée et sécurisée de vos secrets.

]]> TheForge #3 — Monitoring Kubernetes avec Prometheus, Grafana et Loki https://valerian-pyckaert.dev/posts/the-forge-monitoring/ Sun, 31 May 2026 09:35:18 +0200 https://valerian-pyckaert.dev/posts/the-forge-monitoring/ Installation d&#39;une stack de monitoring complète sur Kubernetes avec Prometheus, Grafana et Loki.

Pré-requis

  • Un cluster GKE up and running
  • Connaissance de base de Kubernetes et GitOps
  • ArgoCD installé et configuré

Étapes

1. Qu’est ce qu’on va installer ?

Outil Description
Prometheus Système de surveillance open-source qui collecte et stocke des métriques sous forme de séries temporelles en interrogeant périodiquement des endpoints HTTP.
Kube State Metrics Service Kubernetes qui expose l’état des objets du cluster (pods, deployments, nodes…) sous forme de métriques consommables par Prometheus.
Grafana Plateforme de visualisation qui permet de créer des dashboards interactifs à partir de sources de données comme Prometheus.
Alertmanager Composant de l’écosystème Prometheus qui gère le routage, le regroupement et l’envoi des alertes vers des canaux de notification (Slack, e-mail, PagerDuty…).
Loki Système d’agrégation de logs inspiré de Prometheus, conçu pour indexer uniquement les métadonnées des logs afin de réduire les coûts de stockage.
Alloy Agent de collecte de données de Grafana Labs, successeur de Grafana Agent, capable de collecter métriques, logs et traces pour les acheminer vers différents backends.

1. Installation de la kube-prometheus-stack (Prometheus + Grafana + Alertmanager)

Si vous avez suivi l’article précédent, rien de plus simple : il suffit d’ajouter une nouvelle application dans apps/ dans notre repo de CD.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kube-prometheus-stack
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 86.0.1
    helm:
      releaseName: kube-prometheus-stack
      valueFiles: []
      values: |
        grafana:
          enabled: true
          adminPassword: admin
          service:
            type: ClusterIP
        prometheus:
          prometheusSpec:
            retention: 7d
            resources:
              requests:
                cpu: 200m
                memory: 512Mi
              limits:
                memory: 2Gi
            storageSpec: {}
        alertmanager:
          enabled: true
        kubeStateMetrics:
          enabled: true
        nodeExporter:
          enabled: true
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

On push ce fichier kube-prometheus-stack.yaml et Argo se charge de déployer la stack de monitoring dans notre cluster.

Après quelques minutes d’attente, vous devriez voir les pods de Prometheus, Grafana et Alertmanager en cours d’exécution dans le namespace monitoring :

kubectl get pods -n monitoring
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          2m30s
kube-prometheus-stack-admission-create-ljf79                0/1     Pending   0          41s
kube-prometheus-stack-grafana-6ddb85bf55-j5shg              3/3     Running   0          2m35s
kube-prometheus-stack-kube-state-metrics-5fc57bf8f9-vhfhq   1/1     Running   0          2m35s
kube-prometheus-stack-operator-585c4957f7-2r772             1/1     Running   0          2m35s
prometheus-kube-prometheus-stack-prometheus-0               2/2     Running   0          2m30s
---

Grafana est désormais accessible via un port-forwarding :

kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

Rendez-vous sur http://localhost:3000 et connectez-vous avec les identifiants admin/admin.

Cliquez ensuite sur “Dashboards” pour voir la liste des dashboards disponibles par défaut avec la chart : Dashboards Grafana

3. Collecte des Logs avec Loki

Là encore il suffit de créer une nouvelle application ArgoCD qui pointe vers le chart Helm de Loki pour déployer un stack de collecte de logs dans notre cluster.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: loki
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://grafana.github.io/helm-charts
    chart: loki
    targetRevision: 7.0.0
    helm:
      releaseName: loki
      values: |
        deploymentMode: SingleBinary
        loki:
          auth_enabled: false
          commonConfig:
            replication_factor: 1
          storage:
            type: filesystem
          schemaConfig:
            configs:
              - from: "2024-01-01"
                store: tsdb
                object_store: filesystem
                schema: v13
                index:
                  prefix: index_
                  period: 24h
        singleBinary:
          replicas: 1
          persistence:
            size: 10Gi
        read:
          replicas: 0
        write:
          replicas: 0
        backend:
          replicas: 0
        gateway:
          enabled: true
        chunksCache:
          enabled: false
        resultsCache:
          enabled: false
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Enfin il faut indiquer à Grafana où trouver Loki pour pouvoir visualiser les logs dans notre dashboard.

Pour cela, on ajoute une datasource Loki dans Grafana en utilisant un ConfigMap Kubernetes :

spec:
  source:
    helm:
      values: |
        grafana:
          additionalDataSources:
            - name: Loki
              type: loki
              access: proxy
              url: http://loki-gateway.monitoring.svc.cluster.local
              jsonData:
                maxLines: 1000

Et voilà le résultat :

Logs loki

4. Collecte des logs de notre application

Pour l’heure, les logs de notre application nginx ne sont pas collectés par Loki. Nous allons déployer Alloy en tant que DaemonSet dans notre cluster pour collecter les logs de tous les pods et les envoyer à Loki, il s’agit ici encore d’ajouter une nouvelle application ArgoCD dans notre repo de CD :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: alloy
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://grafana.github.io/helm-charts
    chart: alloy
    targetRevision: 1.16.1
    helm:
      releaseName: alloy
      values: |
        alloy:
          configMap:
            content: |
              discovery.kubernetes "pods" {
                role = "pod"
              }

              discovery.relabel "pods" {
                targets = discovery.kubernetes.pods.targets

                rule {
                  source_labels = ["__meta_kubernetes_namespace"]
                  target_label  = "namespace"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_name"]
                  target_label  = "pod"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_container_name"]
                  target_label  = "container"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_label_app"]
                  target_label  = "app"
                }
              }

              loki.source.kubernetes "pods" {
                targets    = discovery.relabel.pods.output
                forward_to = [loki.write.default.receiver]
              }

              loki.write "default" {
                endpoint {
                  url = "http://loki-gateway.monitoring.svc.cluster.local/loki/api/v1/push"
                }
              }
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

La configuration utilise la syntaxe River d’Alloy pour :

  • Découvrir tous les pods Kubernetes
  • Extraire les labels namespace, pod, container et app
  • Envoyer les logs vers votre Loki gateway
  • Alloy sera déployé comme DaemonSet et collectera les logs de votre nginx. Dans Grafana, vous pourrez les consulter avec :

{namespace=“demo”, app=“nginx”}

De retour sur Grafana, la liste des filtres disponibles est désormais bien plus fournie : Filtres Loki

Logs Loki

Résultat

Dans cet article nous avons vu comment installer une stack de monitoring complète sur Kubernetes avec Prometheus, Grafana et Loki, le tout déployé en GitOps via ArgoCD. Nous avons également vu comment collecter les logs de nos pods sur notre cluster avec Alloy et les visualiser dans Grafana.

Si vous avez suivi toutes les étapes de cet article vous devriez avoir les workloads suivantes :

kubectl get pods -n monitoring
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          21m
alloy-jb2nf                                                 2/2     Running   0          5m22s
kube-prometheus-stack-grafana-bf74d765f-4hzlt               3/3     Running   0          23m
kube-prometheus-stack-kube-state-metrics-6b747b7c5f-hjjwd   1/1     Running   0          23m
kube-prometheus-stack-operator-59c5d9f8c-q6phj              1/1     Running   0          23m
kube-prometheus-stack-prometheus-node-exporter-zhmfp        1/1     Running   0          23m
loki-0                                                      2/2     Running   0          32m
loki-canary-55ccd5d799-wkc7t                                1/1     Running   0          32m
loki-gateway-6df7c96bc9-l92d2                               1/1     Running   0          32m
prometheus-kube-prometheus-stack-prometheus-0               2/2     Running   0          21m

kubectl get pods -n demo
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7489fb554f-hffjv   1/1     Running   0          33m

L’essentiel des travaux est disponible sur mon repo GitHub

Ce qui vient ensuite

Nous verrons comment exposer notre application à travers la Gateway API dans le prochain article de la série, stay tuned !

Sources :

]]> TheForge #2 — Installation d'ArgoCD pour le déploiement continu sur Kubernetes https://valerian-pyckaert.dev/posts/the-forge-cd/ Thu, 28 May 2026 19:00:00 +0200 https://valerian-pyckaert.dev/posts/the-forge-cd/ Installation d&#39;ArgoCD pour le déploiement continu sur Kubernetes. Ce qu’on fait

Installation d’ArgoCD pour le déploiement continu sur Kubernetes via Terraform et Helm.

Pré-requis

  • Cluster GKE up and running
  • Connaissance de base de Kubernetes et GitOps
  • Outils : terraform, gcloud, kubectl, helm…

Étapes

1. Installation d’ArgoCD

Pour cette partie j’ai choisi d’installer ArgoCD via Terraform en utilisant le provider Helm. Cela nous permettra de gérer l’installation d’ArgoCD de manière déclarative et reproductible. Argo sera ensuite en charge de déployer les workloads sur notre cluster Kubernetes.

Ajout des providers nécessaires dans notre configuration Terraform :

provider "kubernetes" {
  host                   = "https://${google_container_cluster.primary.endpoint}"
  token                  = data.google_client_config.default.access_token
  cluster_ca_certificate = base64decode(google_container_cluster.primary.master_auth.0.cluster_ca_certificate)
}

provider "helm" {
  kubernetes = {
    host                   = "https://${google_container_cluster.primary.endpoint}"
    token                  = data.google_client_config.default.access_token
    cluster_ca_certificate = base64decode(google_container_cluster.primary.master_auth.0.cluster_ca_certificate)
  }
}

Ne pas oublier terraform init pour installer les providers. Ensuite, nous allons ajouter une ressource Helm pour installer ArgoCD :

resource "helm_release" "argocd" {
  name             = "argocd"
  repository       = "https://argoproj.github.io/argo-helm"
  chart            = "argo-cd"
  version          = "9.5.15"
  namespace        = "argocd"
  create_namespace = true

  set = [
    {
      name  = "dex.enabled"
      value = "false"
    },
    {
      name  = "notifications.enabled"
      value = "false"
    },
    {
      name  = "applicationSet.enabled"
      value = "false"
    },
    {
      name  = "server.extraArgs[0]"
      value = "--insecure"
    }
  ]

  depends_on = [google_container_node_pool.primary_nodes]
}

Ici nous installons ArgoCD dans le namespace argocd en désactivant certaines fonctionnalités que nous n’utiliserons pas pour le moment (Dex, notifications, ApplicationSet) et en configurant le serveur ArgoCD pour qu’il fonctionne en mode non sécurisé (insecure) pour simplifier les choses dans un environnement de développement.

2. Création de la Root Application ArgoCD (App of Apps Pattern)

Le pattern “App of Apps” est une approche recommandée pour organiser les applications dans ArgoCD. Il consiste à créer une application principale (root application) qui référence d’autres applications (child applications).

Cela permet de structurer les déploiements de manière hiérarchique et de faciliter la gestion des dépendances entre les applications.

resource "kubernetes_manifest" "argocd_app" {
  manifest = {
    apiVersion = "argoproj.io/v1alpha1"
    kind       = "Application"
    metadata = {
      name      = "root-app"
      namespace = "argocd"
    }
    spec = {
      project = "default"
      source = {
        repoURL        = "https://github.com/Bernedotcom2312/theforge-cd.git" #Changez pour le votre
        targetRevision = "main"
        path           = "apps"
      }
      destination = {
        server    = "https://kubernetes.default.svc"
        namespace = "default"
      }
      syncPolicy = {
        automated = {
          prune    = true
          selfHeal = true
        }
      }
    }
  }

  depends_on = [helm_release.argocd]
}

Cette configuration crée une application ArgoCD nommée root-app qui pointe vers un dépôt Git contenant les définitions des applications à déployer. Le champ syncPolicy est configuré pour permettre le déploiement automatique et de réparer les ressources qui ne sont pas conformes à la configuration (selfHeal).

3. Application de la configuration Terraform

Maintenant que nous avons ajouté la configuration pour installer ArgoCD et créer la root application, nous pouvons appliquer notre configuration Terraform :

terraform apply

Cette commande va provisionner ArgoCD sur notre cluster GKE et créer la root application qui référencera les applications à déployer depuis notre dépôt Git.

Résultat

ArgoCD est maintenant installé sur notre cluster GKE et prêt à être utilisé pour le déploiement continu de nos applications.

Vous pouvez vérifier que les pods ArgoCD sont en cours d’exécution avec la commande suivante :

kubectl get pods -n argocd
NAME                                                READY   STATUS    RESTARTS      AGE
argocd-application-controller-0                     1/1     Running   0             94s
argocd-applicationset-controller-6c6b88d4bc-krjc5   1/1     Running   0             95s
argocd-dex-server-79fc985b7b-rbz6w                  1/1     Running   2 (77s ago)   96s
argocd-notifications-controller-6c44f9dbbf-v4777    1/1     Running   0             96s
argocd-redis-7979d55d5b-ft6rc                       1/1     Running   0             96s
argocd-repo-server-584c965f87-tzvsg                 1/1     Running   0             95s
argocd-server-5f7d4885d5-vkccj                      1/1     Running   0             95s

Accès au dashboard ArgoCD :

kubectl port-forward svc/argocd-server -n argocd 8080:80

Rendez vous sur http://localhost:8080. Vous devriez avoir un warning de sécurité concernant le mode “insecure” que nous avons configuré pour le serveur ArgoCD, mais c’est acceptable pour un environnement de développement, nous verrons comment sécuriser cela dans une prochaine étape.

Pour se connecter, utilisez les identifiants suivants :

  • Username : admin
  • Password : le mot de passe est généré automatiquement et stocké dans le secrets argocd-initial-admin-secret dans le namespace argocd. Vous pouvez le récupérer avec la commande suivante :
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Notre application d’exemple (Nginx) devrait également être déployée et visible dans l’interface d’ArgoCD.

kubectl get pods -n demo
NAME                    READY   STATUS    RESTARTS   AGE
nginx-78b9f9966-bh7vb   1/1     Running   0          110s

Un dernier port-forward pour accéder à l’application Nginx :

kubectl port-forward svc/nginx -n demo 8081:80

Et voilà le résultat en accèdant au port 8081 de votre localhost :

Welcome page nginx

Ce qui vient ensuite

La prochaine brique de notre plateforme Kubernetes : le monitoring.

Sources

]]> TheForge #1 — Création d'un cluster Kubernetes sur GCP avec Terraform https://valerian-pyckaert.dev/posts/the-forge-cluster/ Wed, 27 May 2026 13:00:00 +0200 https://valerian-pyckaert.dev/posts/the-forge-cluster/ Dans ce premier article de la série TheForge, nous allons créer un cluster Kubernetes sur Google Cloud Platform (GCP) en utilisant Terraform. Nous verrons les étapes nécessaires pour configurer notre environnement, provisionner le cluster et valider son bon fonctionnement. Pré-requis
  • Un compte GCP avec les permissions nécessaires pour créer des ressources.
    • API Kubernetes Engine activée
    • Billing account configuré
  • Terraform installé sur votre machine
  • Quelques connaissances sur Git

Étapes

1. Creation du repository Git

Ici pas question de réinventer la roue, j’utilise un template fournit par Hashicorp(Terraform) pour le bootstrap de mon cluster.

git clone https://github.com/hashicorp-education/learn-terraform-provision-gke-cluster
mv learn-terraform-provision-gke-cluster theforge-infra
cd theforge-infra
git remote set-url origin git@github.com:mon-repo.git

Nous ferons le tour d’horizon des ressources juste après.

2. Configuration GCLOUD

brew install --cask google-cloud-sdk
gcloud init
gcloud auth application-default login

3. Architecture du repo

Fichier Rôle
vpc.tf Déclare le VPC et un subnet pour isoler le cluster, ainsi que les variables project_id / region et le provider Google.
gke.tf Crée le cluster GKE (version 1.27.x, default node pool supprimé) et un node pool séparé de 2 nœuds n1-standard-1.
versions.tf Fixe le provider Google à la version 7.33.0 et Terraform >= 0.14.
outputs.tf Expose la région, le project ID, le nom et l’endpoint du cluster.
terraform.tfvars Variables d’entrée (project_id à remplacer, région us-central1).
kubernetes-dashboard-admin.rbac.yaml Manifest RBAC Kubernetes pour un accès admin au dashboard (à appliquer post-déploiement).

4. Fine tuning de la configuration Terraform

Ajout du Project ID et de la région

Quelques modifications à apporter à la configuration de base, notamment le project_id et la region dans le fichier terraform.tfvars :

project_id = "MON_PROJECT_ID"
region     = "europe-west1"

Puis on valide que Terraform est correctement configuré et peut communiquer avec GCP :

terraform init

Terraform has been successfully initialized!

Mise à jour de la version de Terraform et des providers

Le template utilise une version de Terraform et du provider Google qui sont un peu anciennes, il est recommandé de les mettre à jour pour bénéficier des dernières fonctionnalités et corrections de bugs. Dans versions.tf, on peut mettre à jour la version de Terraform et du provider Google :

terraform {
  required_version = ">= 1.15"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 7.33.0"
    }
  }
}

Sources :

Mise à jour de la version de GKE

Par défaut, le template utilise aussi une version de GKE qui n’est plus supportée (1.27.x). Il faut donc mettre à jour la version du cluster dans gke.tf pour une version plus récente, par exemple 1.36.x :

resource "google_container_cluster" "primary" {
  name     = "theforge-cluster"
  location = var.region

  # Autres configurations...

  # Mise à jour de la version du cluster
  min_master_version = "1.36"
}

Ensuite, on peut relancer terraform plan pour vérifier que la configuration est valide avec la nouvelle version.

Sources :

Séparation des ressources dans des fichiers

Pour une meilleure organisation, j’ai choisi de remanier quelque peu la structure du repo en séparant les ressources dans des fichiers dédiés (variables.tf, providers.tf). J’envisage en effet de réutiliser ce repository à l’avenir pour d’autres projets, à ce titre je souhaite le rendre plus modulaire et facilement maintenable.

Résultat

Une fois satisfait de votre configuration il ne reste qu’à lancer la commande terraform apply pour provisionner le cluster sur GCP. Après quelques minutes d’attente, le cluster devrait être opérationnel et vous devriez voir les outputs suivants :

Connexion au cluster

Google Cloud SDK (gcloud) est nécessaire pour récupérer les credentials du cluster et pouvoir interagir avec lui via kubectl.

gcloud container clusters get-credentials "moncluster" --region europe-west1 --project "monprojet"
#> kubeconfig entry generated for moncluster.

Verification du status des pods

Une fois le cluster déployé vous devriez voir les pods du cluster en cours d’exécution :

kubectl get pods -A
NAMESPACE         NAME                                                             READY   STATUS    RESTARTS   AGE
gke-managed-cim   kube-state-metrics-0                                             2/2     Running   0          35m
gmp-system        collector-jc4t8                                                  2/2     Running   0          30m
gmp-system        collector-jdjzw                                                  2/2     Running   0          30m

Repo disponible sur GitHub

L’ensemble de la configuration Terraform utilisée pour ce projet est disponible sur GitHub : theforge-infra.

Erreurs rencontrées

Pas de billing account configuré

ERROR: (gcloud.services.enable) FAILED_PRECONDITION: Billing account for project ‘X’ is not found

Renseignez un billing account valide pour votre projet et c’est réglé.

API Kubernetes désactivée

Error: Error retrieving available container cluster versions: googleapi: Error 403: Kubernetes Engine API has not been used in project deft-accord-496812-k9 before or it is disabled.

Elle était assez explicite : l’API Kubernetes Engine n’était pas activée sur le projet GCP. Je l’ai activée via la console GCP, puis relancé terraform plan pour valider que tout est bon. Vous pouvez aussi l’activer avec la CLI :

gcloud services enable container.googleapis.com

Problème de provisioning du cluster

Google Compute Engine: Not all instances running in IGM after 35m11.660099086s. Expected 1, running 0, transitioning 1. Current errors: [GCE_STOCKOUT]: Instance ‘gke-deft-accord-496812-k-default-pool-19ca1c15-p6ls’ creation failed: The zone ‘projects/deft-accord-496812-k9/zones/europe-west1-c’ does not have enough resources available to fulfill the request. Try a different zone, or try again later.

Résolution : changer la zone de déploiement du cluster dans gke.tfs pour une zone moins sollicitée, par exemple europe-west1-b ou europe-west1-d.

resource "google_container_cluster" "primary" {
  name     = "${var.project_id}-gke"
  location = var.region
  node_locations = ["europe-west1-b", "europe-west1-d"]
  # Autres configurations...
}

Plugin GKE introuvable

couldn’t get current server API group list: Get “https://35.233.30.210/api?timeout=32s”: getting credentials: exec: executable gke-gcloud-auth-plugin.exe not found

Solution : installer le plugin d’authentification GKE pour kubectl, qui est nécessaire pour se connecter au cluster GKE.

gcloud components install gke-gcloud-auth-plugin
]]>