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.

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

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.

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 :

Ce qui vient ensuite

La prochaine brique de notre plateforme Kubernetes : le monitoring.

Sources

• ArgoCD Documentation
• Terraform Helm Provider
• Blog Stéphane Robert
• Mon Repo Infra
• Mon Repo CD

Stack : GCP · GKE · Terraform · Helm · ArgoCD · SOPS · Kube-Prom-Stack · Nginx Gateway Fabric · cert-manager

Pourquoi ce projet ?

Je me lance en freelance DevOps / Platform Engineer / Cloud Engineer. Pour montrer ce que je sais faire (et documenter ce que j’apprends en chemin), je démarre un projet fil rouge public : construire une plateforme Kubernetes complète sur GCP, from scratch, avec les outils que j’estime indispensables en 2026.

Chaque article de la série documente une étape, les obstacles rencontrés et comment je les ai résolus. Format court, orienté pratique.

Je vais tenter de garder une approche pragmatique orientée “best practices” (mais pas dogmatique) pour que ce soit utile à d’autres personnes qui veulent se lancer dans la même aventure.

Ce qu’on va construire

Un cluster GKE avec la stack suivante, déployée en GitOps :

Je me focalise sur ce qui me semble essentiel pour adresser la majorité des besoins. A termes j’envisage d’ajouter d’autres composants destinés à des usages plus complexes : KEDA, Karpenter, Dapr, …

Les étapes prévues

1. Création du cluster GKE via Terraform
2. Bootstrap Helm & ArgoCD via Terraform
3. Déploiement de kube-prometheus-stack via ArgoCD
4. Déploiement de Nginx Gateway Fabric / Gateway API via ArgoCD
5. Déploiement de cert-manager + Let’s Encrypt via ArgoCD
6. Mise en place de SOPS pour la gestion des secrets

J’ajouterai probablement d’autres étapes au fur et à mesure* (ex: gestion des node pools, autoscaling, etc.) selon les besoins et les obstacles rencontrés*

Principes de base

• Tout dans Git — aucune modification manuelle sur le cluster après le bootstrap
• Least privilege — les SA GCP auront le minimum requis
• Les secrets ne sont jamais en clair dans le repo
• KISS — Keep It Simple Stupid. Pas de sur-optimisation, pas de microservices inutiles, pas de complexité superflue

Prochaine étape

→ Création du cluster GKE avec Terraform (à venir)