Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Implémentation de référence de l'équilibrage de charge de couche 7 HAProxy

Google Distributed Cloud (GDC) avec isolation physique fournit un équilibreur de charge de couche 4 (L4) géré intégré, mais de nombreuses applications d'entreprise nécessitent des fonctionnalités avancées de couche 7 (L7), telles que le routage basé sur l'hôte, la gestion centralisée du protocole TLS et la répartition complexe du trafic. Historiquement, cela se fait à l'aide de l'API Ingress, qui est désormais considérée comme figée dans la communauté Kubernetes.

Cette architecture de référence fournit une solution d'équilibrage de charge de couche 7 autogérée. En déployant le contrôleur Open Source HAProxy populaire sur un cluster GDC standard, les clients peuvent acheminer de manière fluide le trafic L7 vers des environnements hybrides. Cette architecture utilise la terminaison TLS (HTTPRoute) pour acheminer le trafic en fonction de l'indication du nom du serveur (SNI) vers les pods conteneurisés intégrés et les applications hébergées sur des machines virtuelles externes.

Architecture

Schéma d'architecture pour l'équilibrage de charge de couche 7 HAProxy sur GDC avec air gap.

Voici les principaux composants de la solution :

Client : entité qui lance des requêtes HTTPS pour interagir avec les applications.
Cluster GDC standard : GDC fournit un moyen intégré de créer des clusters Kubernetes Vanilla. Dans cette solution, le cluster hébergera l'équilibreur de charge L7 et ses contrôleurs, ainsi que les charges de travail et le service sans adresse IP pour les VM externes.
Équilibreur de charge L4 GDC : équilibreur de charge L4 intégré servant de point d'entrée, qui distribue le trafic TCP/443 directement aux pods Kubernetes exécutant les contrôleurs.
Contrôleurs d'entrée : opérateurs HAProxy s'exécutant dans le cluster standard. Ils surveillent les ressources Ingress et mettent à jour de manière dynamique les proxys sous-jacents. Le contrôleur d'entrée HAProxy sera utilisé dans l'implémentation suivante.
Ingress : ressources Kubernetes standardisées définissant le port d'écoute physique (443) et les règles de routage de l'hôte basées sur SNI avec terminaison TLS.
Charge de travail conteneurisée (pods) : déploiement Kubernetes standard exposé en interne avec un Service Kubernetes standard.
Charge de travail basée sur une VM (externe) : charge de travail hébergée sur une VM externe sur le réseau du projet, exposée au proxy à l'aide d'un Service Kubernetes sans adresse IP et d'un point de terminaison personnalisé contenant l'adresse IP directe de la VM.
Registre Harbor : registre de conteneurs privé utilisé pour stocker et diffuser les images de proxy et d'application dans l'environnement isolé.

Dans le cluster standard, vous créez trois espaces de noms :

L'espace de noms load-balancer héberge le contrôleur d'entrée HAProxy et la charge de travail de l'équilibreur de charge HAProxy :
L'espace de noms hello-app héberge le Deployment, un Service et un Ingress pour la charge de travail du conteneur de démonstration :
L'espace de noms vm-app héberge un service sans adresse IP de cluster qui expose l'adresse IP de la VM externe, un EndpointSlice qui pointe vers l'adresse IP externe et un Ingress :

Avant de commencer

Avant de déployer cette solution, assurez-vous de remplir les conditions préalables suivantes :

Logiciels requis : helm, docker, kubectl

Connexion à la CLI et configuration locale : téléchargez gdcloud CLI depuis la console GDC et configurez votre environnement localement :

export USER_NAME="USER_NAME"
export PROJECT_ID="PROJECT_ID"
export ZONE="ZONE"
export ORG_NAME="ORG_NAME"
export GDC_URL="GDC_URL"

gdcloud components install gdcloud-k8s-auth-plugin

gdcloud config set core/organization_console_url \
  https://console.$ORG_NAME.$ZONE.$GDC_URL
gdcloud config set core/zone $ZONE
gdcloud config set core/project ${PROJECT_ID}

gdcloud auth login # use --login-config-cert option in case of TLS error

Configuration du projet : créez un projet dans votre environnement GDC sous air gap pour stocker les ressources :
```
gdcloud projects create $PROJECT_ID
```

Rôles IAM : attribuez à votre utilisateur les rôles Administrateur de cluster et Administrateur de cluster standard pour gérer les ressources Kubernetes, ainsi que le rôle Administrateur d'instance Harbor pour transférer des images :

# Grant standard cluster and cluster admin roles
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=standard-cluster-admin

# Grant Harbor instance admin role
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=harbor-instance-admin

Créer un cluster standard

Cette section vous guide tout au long du processus de configuration d'un cluster Kubernetes standard dans votre environnement GDC sous air gap. Un cluster standard fournit une base flexible et robuste pour déployer diverses charges de travail, y compris le contrôleur d'entrée HAProxy et vos applications personnalisées. Les étapes suivantes vous permettront de vous assurer que votre cluster est correctement configuré et accessible pour les déploiements ultérieurs.

Identifiez les types d'images de machine virtuelle disponibles en exécutant la commande suivante :
```
gdcloud compute machine-types list
```
Sélectionnez un type de machine approprié pour les nœuds de calcul de votre cluster. Pour ce tutoriel, nous vous recommandons d'utiliser un type de machine avec au moins quatre processeurs virtuels.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Obtenez le fichier kubeconfig du serveur d'API de gestion et définissez un alias :

export CLUSTER_NAME="CLUSTER_NAME"

KUBECONFIG=kubeconfig-admin.yaml gdcloud clusters \
  get-credentials ${ORG_NAME}-admin

alias km="kubectl --kubeconfig kubeconfig-admin.yaml"

Créez un cluster standard avec deux nœuds de calcul :

km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
  namespace: ${PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${CLUSTER_NAME}-node-pool
EOF

Pour en savoir plus sur les options disponibles, consultez la documentation.

La création d'un cluster standard peut prendre jusqu'à 60 minutes. Pour vérifier l'état, utilisez la commande suivante :

km get clusters/${CLUSTER_NAME} \
  -n ${PROJECT_ID} \
  --watch

Une fois le cluster prêt, le résultat doit indiquer l'état "Running" (En cours d'exécution), comme suit :

NAME         STATE     K8S VERSION
my-cluster   Running   1.30.12-gke.300

Une fois le cluster prêt, récupérez ses identifiants :

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${CLUSTER_NAME} \
  --standard \
  --project ${PROJECT_ID} \
  --zone ${ZONE}

Créez un alias pour que les commandes kubectl soient plus concises dans le reste de ce guide. Cet alias sera utilisé pour interagir avec le cluster standard :
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Créez des espaces de noms pour le contrôleur, l'application conteneurisée de démonstration "hello-app" et l'application de démonstration basée sur une VM :
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Créer et intégrer un registre Harbor

Harbor est un registre d'images de conteneurs avec compatibilité intégrée dans GDC sous air gap. Cette section vous explique comment intégrer un registre Harbor à votre cluster standard, y compris comment configurer les identifiants et les secrets pour permettre l'extraction et l'envoi sécurisés d'images.

Créez une instance Harbor dans votre projet.
Créez un projet Harbor dans votre instance Harbor.

Définissez les variables d'environnement :

export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME"
export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL"
export HARBOR_PROJECT="HARBOR_PROJECT"
export IMAGE_PULL_SECRET_NAME="harbor-secret"

Connectez-vous à l'instance Harbor à l'aide d'un compte de robot :
```
docker --config=./docker login ${HARBOR_INSTANCE_URL}
```

Créez les secrets dans le cluster standard :

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n load-balancer

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n hello-app

Déployer une application conteneurisée de démonstration

Cette section explique comment déployer une application conteneurisée de démonstration (hello-app) dans votre cluster Kubernetes GDC sous air gap. Vous allez créer les ressources de déploiement et de service Kubernetes nécessaires pour exécuter hello-app et l'exposer en interne dans le cluster, afin de le préparer à l'accès à l'aide de l'équilibreur de charge L7.

Importez un exemple d'image pour l'application conteneurisée de démonstration dans Harbor :

docker pull gcr.io/google-samples/hello-app:1.0 \
  --platform linux/amd64
docker tag gcr.io/google-samples/hello-app:1.0 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0

Déployez le fichier manifeste suivant dans le cluster standard :

cat << EOF > hello-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: hello-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-server
        image: ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: ${IMAGE_PULL_SECRET_NAME}
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app
  namespace: hello-app
spec:
  type: ClusterIP
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

kk apply -f hello-app.yaml

Vérifiez ensuite que le déploiement et le service sont présents.

kk get svc,deploy -n hello-app

Déployer une application de démonstration dans une VM

Cette section décrit le déploiement d'une application de démonstration sur une machine virtuelle (VM) en dehors de votre cluster Kubernetes. En configurant un serveur HTTP sur une VM, vous simulerez une application externe que l'équilibreur de charge peut exposer, ce qui démontrera sa capacité à gérer le trafic vers des ressources à l'intérieur et à l'extérieur du cluster.

Commencez par créer une VM pour l'application de démonstration :

Ouvrez la console GDC dans votre navigateur Web.
Sélectionnez le même projet que celui dans lequel vous avez créé votre cluster Kubernetes standard.
Ouvrez le menu, puis cliquez sur Machines virtuelles.
Cliquez sur Créer une instance.
Nommez la VM vm-workload. Une image à deux processeurs virtuels suffit pour l'exemple.
Pour l'image disque de démarrage, sélectionnez une distribution Ubuntu 22.04, qui est fournie avec Python préinstallé.
Cliquez sur Créer.
Attendez quelques minutes jusqu'à ce que la VM soit prête.
Établissez une connexion SSH avec la VM :
1. Dans la console GDC, cliquez sur la VM.
2. Cliquez sur Se connecter avec SSH.

Une fois connecté à la console SSH, exécutez la commande suivante :

mkdir ~/simple-server
cd ~/simple-server
echo 'Welcome to my VM!' > index.html
python3 -m http.server --bind 0.0.0.0 8080 &

Pour acheminer le trafic vers une VM, créez un service sans adresse IP de cluster (sans sélecteurs). Elle sera mappée manuellement à l'adresse IP interne de la VM à l'aide d'une ressource EndpointSlice.

kk apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: vm-app-svc
  namespace: vm-app
spec:
  ports:
  - protocol: TCP
    port: 443
    targetPort: 443
EOF

Obtenez l'adresse IP de la VM vm-workload en exécutant la commande suivante :

gdcloud compute instances list --project ${PROJECT_ID} \
  | grep workload-vm | awk '{print $3}'

Le résultat sera l'adresse IP de la VM, qui sera nécessaire pour configurer la ressource EndpointSlice.

Créez la ressource EndpointSlice qui se connectera au service sans sélecteur VM-app et adressera l'adresse IP de la VM vers laquelle le trafic doit être acheminé.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: vm-app-endpoints
  namespace: vm-app
  labels:
    kubernetes.io/service-name: vm-app-svc
addressType: IPv4
ports:
  - port: 8080
endpoints:
  - addresses:
    - "VM_IP"
    conditions:
      ready: true

Créer des certificats autosignés

Cette section vous guide tout au long du processus de création de certificats TLS et de secrets Kubernetes pour sécuriser la communication de vos applications basées sur des conteneurs et des VM. Ce guide utilise des certificats autosignés pour plus de commodité, mais dans les environnements de production, vous devez utiliser des certificats de qualité production, comme décrit dans Facultatif : Utiliser des certificats prêts pour la production. Choisissez des exemples de noms de domaine arbitraires pour ces applications. En établissant des connexions sécurisées, vous garantissez l'intégrité et la confidentialité des données pour les clients qui accèdent à votre application via le contrôleur d'entrée HAProxy.

Pour l'application conteneurisée, nous créons un certificat autosigné et l'enregistrons en tant que secret dans l'espace de noms de l'équilibreur de charge. Il sera utilisé pour TLS lors de la demande de k8s-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-containerized.key \
  -out tls-containerized.crt \
  -subj "/CN=k8s-app.example.com" \
  -days 365

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

Pour l'application de VM, un certificat autosigné similaire est émis et enregistré. Il sera utilisé pour le protocole TLS lors de la demande de vm-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-vm.key \
  -out tls-vm.crt \
  -subj "/CN=vm-app.example.com" \
  -days 365

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Déployer HAProxy

Installer le contrôleur d'entrée HAProxy et l'équilibreur de charge L4

export HAPROXY_VERSION=3.1.14

# pull the HAProxy Ingress Controller image and push it to Harbor
docker pull haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  --platform linux/amd64
docker tag haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}

# Get Helm repo
helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

# Install the Ingress Controller with helm
helm upgrade --install haproxy-kubernetes-ingress \
  haproxytech/kubernetes-ingress \
  --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml \
  --namespace load-balancer \
  --set controller.image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress \
  --set controller.image.tag=${HAPROXY_VERSION} \
  --set controller.existingImagePullSecret=${IMAGE_PULL_SECRET_NAME} \
  --set controller.service.type=LoadBalancer \
  --set-json \
  controller.service.annotations='{"networking.gke.io/load-balancer-type": "internal"}'

Le contrôleur d'entrée HAProxy obtient une adresse IP virtuelle unique pour l'accès client à l'aide d'un service de type LoadBalancer. Ce service configure un équilibreur de charge de couche 4 entièrement géré. Pour simplifier ce guide, un équilibreur de charge interne est créé en définissant l'annotation load-balancer-type sur internal. Si vous omettez cette annotation, un équilibreur de charge externe sera créé. Le déploiement Kubernetes extrait de manière sécurisée les images de Harbor à l'aide du secret fourni (${IMAGE_PULL_SECRET_NAME}), qui contient les identifiants du compte de robot Harbor.

Valider l'installation du contrôleur d'entrée HAProxy

Vérifiez que les pods du contrôleur d'entrée HAProxy sont en cours d'exécution et prêts :

kk get pods -n load-balancer

Le résultat doit se présenter sous la forme suivante :

NAME                                          READY   STATUS      RESTARTS   AGE
haproxy-kubernetes-ingress-78dc9c8676-f8fcb   1/1     Running     0          35s
haproxy-kubernetes-ingress-78dc9c8676-lfnr2   1/1     Running     0          65s
haproxy-kubernetes-ingress-crdjob-3-tgj2h     0/1     Completed   0          65s

Vérifiez que le service du contrôleur d'entrée HAProxy est créé et configuré :

kk get services -n load-balancer

La sortie ressemble à ceci :

NAME                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                  AGE
haproxy-kubernetes-ingress   LoadBalancer   10.252.27.46   10.252.4.17   80:32023/TCP,443:31103/TCP,443:31103/UDP,1024:30146/TCP,6060:30718/TCP   10m

Définir des ressources Ingress pour les applications de démonstration

Créez la ressource Ingress qui connectera HAProxy au service d'application conteneurisée.

cat << EOF > hello-app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-app-ingress
  namespace: hello-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "k8s-app.example.com"
    secretName: tls-containerized
  rules:
  - host: "k8s-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-app
            port:
              number: 80
EOF

kk apply -f hello-app-ingress.yaml

Créez la ressource Ingress qui se connectera au service sans sélecteur VM-app et qui adressera l'adresse IP de la VM vers laquelle le trafic doit être acheminé.

cat << EOF > vm-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vm-app-ingress
  namespace: vm-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "vm-app.example.com"
    secretName: tls-vm
  rules:
  - host: "vm-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vm-app-svc
            port:
              number: 443
EOF

kk apply -f vm-ingress.yaml

Récupérer l'adresse IP de l'équilibreur de charge

Exécutez la commande pour obtenir l'adresse IP de l'équilibreur de charge.

kk get services/haproxy-kubernetes-ingress \
  -n load-balancer \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Vous en aurez besoin pour vérifier l'accès aux applications. Dans le cadre de la présente procédure, elle sera appelée LOAD_BALANCER_IP.

Créer une VM cliente

Pour créer une VM cliente, procédez comme suit :

Ouvrez la console GDC dans votre navigateur Web.
Ouvrez le menu et cliquez sur Machines virtuelles.
Cliquez sur Créer une instance.
Créez une VM nommée client, sélectionnez un petit type de machine, puis sélectionnez Rocky Linux ou Ubuntu, qui sont fournis avec curl préinstallé.
Cliquez sur Créer.
Attendez quelques minutes jusqu'à ce que la VM soit prête.
Une fois la VM prête, établissez une connexion SSH avec elle :
1. Dans la console GDC, cliquez sur la VM.
2. Cliquez sur Se connecter avec SSH.

Vérifier l'accès et le routage

Pour tester le routage, exécutez des commandes curl à partir de votre VM cliente. Vous pouvez vous connecter aux deux applications à l'aide de leurs noms d'hôte définis avec l'adresse IP de l'équilibreur de charge.

En transmettant le flag --resolve dans curl, vous pouvez forcer la résolution des noms de domaine vers l'adresse IP de votre équilibreur de charge L4 GDC sous air gap. Notez que nous transmettons l'option -k pour faire confiance aux certificats autosignés.

Testez l'application Kubernetes conteneurisée :

curl -k --resolve k8s-app.example.com:443:$LOAD_BALANCER_IP https://k8s-app.example.com -v

Testez l'application de VM externe :

curl -k --resolve vm-app.example.com:443:$LOAD_BALANCER_IP https://vm-app.example.com -v

S'il est configuré correctement, le contrôleur d&#Ingress agira de manière transparente en tant que terminaison TLS et transmettra le trafic à la destination.

Facultatif : Utiliser des certificats prêts pour la production

Cette section explique comment utiliser le service d'autorité de certification GDC air-gapped pour créer une autorité de certification racine privée, émettre des certificats signés pour vos charges de travail et mettre à jour de manière sécurisée votre cluster standard GDC air-gapped et vos VM clientes.

Cette section explique comment utiliser le service d'autorité de certification de GDC sous air gap pour créer une autorité de certification racine privée et émettre des certificats valides pour vos applications. En installant cette autorité de certification racine sur votre VM cliente, vous pouvez vérifier que la terminaison TLS fonctionne de manière fluide avec des certificats de confiance, sans avoir à contourner les avertissements SSL (par exemple, en utilisant curl -k).

Accorder les autorisations nécessaires et obtenir des identifiants

Pour gérer CA Service et émettre des certificats, votre utilisateur doit disposer des rôles IAM appropriés dans le projet.

Attribuez les rôles certificate-authority-service-admin et certificate-requester :

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-authority-service-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-requester

Obtenez les identifiants du serveur de l'API de gestion :
```
gdcloud clusters get-credentials ${ORG_NAME}-admin
```

Créer l'autorité de certification racine

Vous allez créer une autorité de certification dans le serveur de l'API de gestion au sein de l'espace de noms de votre projet.

Appliquez la ressource CertificateAuthority :

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  namespace: ${PROJECT_ID}
spec:
  caProfile:
    commonName: "My Root CA"
    duration: 87600h # 10 years
    keyAlgorithm: RSA_2048
    maxChainLength: 1
  caType: ROOT
  keyLocation: HSM
  rotationPolicy:
    cronTime: 0 0 1 1 *
EOF

km -n ${PROJECT_ID} get \
certificateauthority.pki.security.gdc.goog/my-root-ca -ojson \
| jq -r '
.status.conditions[] | select( .type as $id | "Ready" | index($id)) .status'

Émettre et déployer des certificats

Une fois l'autorité de certification prête, vous demanderez des certificats pour l'application conteneurisée et l'application basée sur une VM. Ces requêtes sont effectuées sur le serveur de l'API de gestion, et les clés obtenues doivent être déplacées vers votre cluster standard.

Créez des requêtes pour les deux domaines :

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-containerized-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "k8s-app.example.com"
      dnsNames:
      - "k8s-app.example.com"
  signedCertificateSecret: tls-containerized-signed
---
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-vm-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "vm-app.example.com"
      dnsNames:
      - "vm-app.example.com"
  signedCertificateSecret: tls-vm-signed
EOF

Attendez quelques instants que les certificats soient émis. Vous pouvez vérifier qu'ils sont prêts lorsque la condition "Ready" est définie sur "True" :

km get certificaterequests -n ${PROJECT_ID}

Mettre à jour le cluster standard

Si vous avez suivi les sections précédentes de ce guide, vous disposez de secrets autosignés dans votre cluster standard. Vous devez les supprimer avant de créer les nouvelles versions signées :

kk delete secret tls-containerized -n load-balancer
kk delete secret tls-vm -n load-balancer

kk delete secret tls-containerized -n hello-app
kk delete secret tls-vm -n vm-app

À présent, extrayez les certificats signés du serveur d'API Management et créez les secrets dans le cluster standard.

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-containerized.key

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-vm.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-vm.key

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Les nouveaux secrets seront obtenus automatiquement et actualisés par les équilibreurs de charge.

Configurer la confiance du client

Pour vérifier la configuration, vous devez indiquer à votre VM cliente de faire confiance à votre nouvelle autorité de certification racine.

Extrayez le certificat CA racine dans un fichier :

km get secret -n ${PROJECT_ID} my-root-ca-secret \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > my-root-ca.crt

Transférez le certificat vers votre VM cliente. (Vous pouvez copier le contenu de my-root-ca.crt et le coller dans un fichier sur la VM cliente.)

Sur la VM cliente, mettez à jour le magasin de confiance.

Si la VM client est Ubuntu :

sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo chmod 644 /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates

Si la VM client est Rocky Linux :

sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Vérifier l'accès

Vous pouvez désormais accéder à vos applications à l'aide de curl sans l'option -k. La connexion sera entièrement fiable.

Testez l'application k8s conteneurisée :

curl -v --resolve k8s-app.example.com:443:LOAD_BALANDER_IP https://k8s-app.example.com

Testez l'application de VM :

curl -v --resolve vm.example.com:443:LOAD_BALANDER_IP https://vm-app.example.com

Si l'opération réussit, le résultat de l'application s'affiche immédiatement, sans avertissement concernant le certificat SSL.