Exposer les services Geocore

Contour et son proxy Envoy exposent l’API Geocore et Centui en HTTP(S). Envoy traduit les appels gRPC-Web de Centui en requêtes gRPC pour l’API. MQTT et NTP ne passent pas par Contour : conservez leur configuration NodePort décrite dans le guide k0s. Consultez Exposition des services pour tous les choix d’exposition.

1. Installer Contour et Envoy

Contour est nécessaire pour le chemin d’accès Geocore documenté. Le chart geocore-ingress-contour crée uniquement les routes Geocore ; il n’installe ni Contour ni Envoy. Conservez les services API Geocore et Centui dans leur type ClusterIP par défaut.

Créer les identifiants Harbor pour télécharger les images

Les images Contour et Envoy sont hébergées dans Centiloc Harbor. Créez l’espace de noms contour, puis créez dans celui-ci un secret de registre Docker :

kubectl create namespace contour

kubectl create secret docker-registry harbor-regcred \
  --namespace contour \
  --docker-server=harbor.centiloc.com \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

Le secret est limité à l’espace de noms : il doit être créé avant l’installation de Contour et est distinct des identifiants utilisés par Helm pour télécharger les charts.

LoadBalancer

Utilisez cette option lorsque la plateforme Kubernetes, ou MetalLB, fournit une adresse LoadBalancer :

helm install contour oci://harbor.centiloc.com/bitnamicharts/contour \
  --namespace contour \
  --version 21.1.4 \
  --set contour.certgen.certificateLifetime=2190 \
  --set 'global.imagePullSecrets[0]=harbor-regcred'

NodePort

Utilisez cette option pour une installation sur un nœud unique, en HTTP non chiffré. Envoy est exposé sur le NodePort 30180 :

helm install contour oci://harbor.centiloc.com/bitnamicharts/contour \
  --namespace contour \
  --version 21.1.4 \
  --set contour.certgen.certificateLifetime=2190 \
  --set 'global.imagePullSecrets[0]=harbor-regcred' \
  --set envoy.service.type="NodePort" \
  --set envoy.service.nodePorts.http="30180"

Proxy gRPC-Web alternatif

Un proxy alternatif, tel que grpcwebproxy, peut être utilisé à la place de Contour et de geocore-ingress-contour. Son installation et sa configuration ne sont pas couvertes ici.

2. Choisir HTTP non chiffré ou TLS

Envoy peut publier l’API et Centui en HTTP non chiffré ou avec terminaison TLS. Le choix doit correspondre aux valeurs core.geo.tlsEnabled et core.centui.tlsEnabled définies dans le guide k0s.

Transport Ingress	`core.geo.tlsEnabled` et `core.centui.tlsEnabled`	`tlsEnabled` du chart de routage
HTTP non chiffré	`false`	`false`
TLS	`true`	`true`

Ne poursuivez avec les sections TLS suivantes que si vous utilisez HTTPS. En HTTP non chiffré, passez directement à la section 5, « Créer les routes Geocore ».

3. Configurer TLS

Les étapes suivantes décrivent une option TLS autogérée pour un cluster à nœud unique. Si votre infrastructure fournit déjà des certificats et un contrôleur Ingress, utilisez son processus de gestion des certificats.

Installer cert-manager

Installez cert-manager pour gérer les certificats dans le cluster :

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true

Créer une PKI Geocore

Créez un fichier geocore-pki.yaml. Cet exemple crée une autorité de certification racine autosignée et un émetteur intermédiaire pour les certificats Geocore :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
  namespace: cert-manager
spec:
  selfSigned: {}

---

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: root-ca
  namespace: cert-manager
spec:
  isCA: true
  dnsNames:
    - X.X.X.X
  subject:
    organizations:
      - YourOrganization
    countries:
      - FR
  commonName: Root CA Issuer
  secretName: root-ca-secret
  duration: 864000h
  renewBefore: 700000h
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io

---

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: root-ca-issuer
  namespace: cert-manager
spec:
  ca:
    secretName: root-ca-secret

---

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: geocore-cert
  namespace: cert-manager
spec:
  isCA: true
  subject:
    organizations:
      - Your Organization Name
    countries:
      - Your Country Name
  commonName: Geocore Intermediate Issuer
  secretName: geocore-cert-secret
  duration: 438000h
  renewBefore: 420000h
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: root-ca-issuer
    kind: ClusterIssuer
    group: cert-manager.io

---

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: geocore-issuer
  namespace: cert-manager
spec:
  ca:
    secretName: geocore-cert-secret

Adresse IP k0s

Remplacez X.X.X.X par l’adresse IP du cluster k0s à nœud unique avant d’appliquer le manifeste.

Appliquez la PKI :

kubectl apply -f geocore-pki.yaml

Faire confiance à l’autorité de certification

Lorsque vous utilisez des certificats autosignés, ajoutez le certificat d’autorité de certification généré au magasin de certificats de confiance de chaque client accédant à l’API ou à Centui.

4. Fournir une adresse LoadBalancer

Dans un cluster à nœud unique, MetalLB peut attribuer une adresse IP externe à un service LoadBalancer. Ignorez cette section si votre plateforme Kubernetes fournit déjà des équilibreurs de charge.

Installez MetalLB :

helm repo add metallb https://metallb.github.io/metallb
helm repo update
helm install my-metallb metallb/metallb \
  --namespace metallb \
  --create-namespace \
  --version 0.13.11

Créez un fichier metallb-ipaddresspool.yaml et remplacez X.X.X.X par l’adresse attribuée à l’hôte k0s :

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: geocore-pool
  namespace: metallb
spec:
  addresses:
    - X.X.X.X/32

Appliquez le pool d’adresses :

kubectl apply -f metallb-ipaddresspool.yaml

5. Créer les routes Geocore

Une fois Contour prêt, créez un fichier ingress-values.yaml. Choisissez l’onglet correspondant à la méthode d’exposition Envoy sélectionnée dans le chart Geocore.

HTTP non chiffré

certmanager:
  enabled: false

tlsEnabled: false

api:
  domain: api.local.centiloc.com

centui:
  domain: centui.local.centiloc.com

TLS

certmanager:
  enabled: true
  issuer:
    name: geocore-issuer

tlsEnabled: true

api:
  domain: api.local.centiloc.com

centui:
  domain: centui.local.centiloc.com

Installez le chart de routage :

helm install geocore-ingress-contour \
  oci://harbor.centiloc.com/centiloc/geocore-ingress-contour \
  --namespace geocore \
  -f ingress-values.yaml

Cohérence des noms d’hôte

Les valeurs api.domain et centui.domain doivent correspondre aux noms d’hôte associés dans la configuration du chart Geocore. Avec un NodePort Envoy, ajoutez le port Envoy à core.centui.apiURL, par exemple api.k0s.example.test:30180 ; ne l’ajoutez pas à api.domain.

6. Publier les enregistrements DNS

Faites pointer les enregistrements DNS publics vers l’adresse externe d’Envoy :

<ingress-controller-IP> api.local.centiloc.com
<ingress-controller-IP> centui.local.centiloc.com

Pour une preuve de concept locale, vous pouvez ajouter les mêmes entrées au fichier hosts de la machine cliente. En production, créez les enregistrements DNS correspondants dans votre zone DNS.

7. Vérifier l’accès

Une fois les enregistrements résolus vers Envoy, ouvrez Centui à l’URL configurée et vérifiez que les requêtes API aboutissent. Si l’un des services n’est pas disponible, vérifiez d’abord qu’Envoy expose son adresse externe, puis contrôlez le chart de routage Geocore et les valeurs de FQDN.