Déployer des applications Windows sur Kubernetes géré

Last reviewed 2024-08-14 UTC

Ce document explique comment déployer l'architecture de référence décrite dans Gérer et mettre à l'échelle la mise en réseau pour les applications Windows exécutées sur Kubernetes géré.

Ces instructions sont destinées aux architectes cloud, aux administrateurs réseau et aux professionnels de l'informatique qui sont responsables de la conception et de la gestion des applications Windows exécutées sur des clusters Google Kubernetes Engine (GKE).

Architecture

Le schéma suivant illustre l'architecture de référence que vous utilisez lorsque vous déployez des applications Windows exécutées sur des clusters GKE gérés.

Les données transitent par un équilibreur de charge d'application interne et une passerelle Envoy.

Comme le montre le schéma précédent, une flèche représente le workflow de gestion de la mise en réseau pour les applications Windows exécutées sur GKE à l'aide de Cloud Service Mesh et des passerelles Envoy. Le cluster GKE régional inclut des pools de nœuds Windows et Linux. Cloud Service Mesh crée et gère les routes de trafic vers les pods Windows.

Objectifs

  • Créez et configurez un cluster GKE pour exécuter des applications Windows et des proxys Envoy.
  • Déployez et vérifiez les applications Windows.
  • Configurez Cloud Service Mesh comme plan de contrôle pour les passerelles Envoy.
  • Utilisez l'API Kubernetes Gateway pour provisionner l'équilibreur de charge d'application interne et exposer les passerelles Envoy.
  • Comprendre les opérations de déploiement continu que vous avez créées.

Coûts

Le déploiement de cette architecture utilise les composants facturables suivants deGoogle Cloud :

Une fois que vous avez terminé ce déploiement, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. Enable the Cloud Shell, and Cloud Service Mesh APIs.

    Enable the APIs

  4. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Si vous exécutez l'application dans un environnement de cloud privé virtuel (VPC) partagé, vous devez également suivre les instructions pour créer manuellement le sous-réseau et la règle de pare-feu réservés au proxy pour les vérifications de réactivité de Cloud Load Balancing.

    Créer un cluster GKE

    Suivez les étapes ci-dessous pour créer un cluster GKE. Vous utilisez le cluster GKE pour contenir et exécuter les applications Windows et les proxys Envoy dans ce déploiement.

    1. Dans Cloud Shell, exécutez la commande Google Cloud CLI suivante pour créer un cluster GKE régional avec un nœud dans chacune des trois régions :

      gcloud container clusters create my-cluster
    --enable-ip-alias \
    --num-nodes=1 \
    --release-channel stable \
    --enable-dataplane-v2 \
    --region us-central1 \
    --scopes=cloud-platform \
    --gateway-api=standard

    2. Ajoutez le pool de nœuds Windows au cluster GKE :

      gcloud container node-pools create win-pool \
    --cluster=my-cluster \
    --image-type=windows_ltsc_containerd \
    --no-enable-autoupgrade \
    --region=us-central1 \
    --num-nodes=1 \
    --machine-type=n1-standard-2 \
    --windows-os-version=ltsc2019

      Cette opération peut prendre environ 20 minutes.

    3. Stockez l'ID de votre projet Google Cloud dans une variable d'environnement :

      export PROJECT_ID=$(gcloud config get project)

    4. Connectez-vous au cluster GKE :

      gcloud container clusters get-credentials my-cluster --region us-central1

    5. Affichez la liste de tous les nœuds du cluster GKE :

      kubectl get nodes

      Le résultat doit afficher trois nœuds Linux et trois nœuds Windows.

      Une fois le cluster GKE prêt, vous pouvez déployer deux applications de test basées sur Windows.

    Déployer deux applications de test

    Dans cette section, vous allez déployer deux applications de test basées sur Windows. Les deux applications de test affichent le nom d'hôte sur lequel l'application s'exécute. Vous allez également créer un service Kubernetes pour exposer l'application via des groupes de points de terminaison du réseau (NEG) autonomes.

    Lorsque vous déployez une application basée sur Windows et un service Kubernetes sur un cluster régional, un NEG est créé pour chaque zone dans laquelle l'application s'exécute. Ce guide de déploiement explique ensuite comment configurer ces NEG en tant que backends pour les services Cloud Service Mesh.

    1. Dans Cloud Shell, appliquez le fichier YAML suivant avec kubectl pour déployer la première application de test. Cette commande déploie trois instances de l'application de test, une dans chaque zone régionale.

      apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver-1
  name: win-webserver-1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: win-webserver-1
  template:
    metadata:
      labels:
        app: win-webserver-1
      name: win-webserver-1
    spec:
     containers:
      - name: windowswebserver
        image: k8s.gcr.io/e2e-test-images/agnhost:2.36
        command: ["/agnhost"]
        args: ["netexec", "--http-port", "80"]
     topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: win-webserver-1
     nodeSelector:
      kubernetes.io/os: windows

    2. Appliquez le service Kubernetes correspondant et exposez-le avec un NEG :

      apiVersion: v1
kind: Service
metadata:
  name: win-webserver-1
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}'
spec:
  type: ClusterIP
  selector:
    app: win-webserver-1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

    3. Vérifiez le déploiement :

      kubectl get pods

      Le résultat indique que l'application comporte trois pods Windows en cours d'exécution.

      NAME                               READY   STATUS    RESTARTS   AGE
win-webserver-1-7bb4c57f6d-hnpgd   1/1     Running   0          5m58s
win-webserver-1-7bb4c57f6d-rgqsb   1/1     Running   0          5m58s
win-webserver-1-7bb4c57f6d-xp7ww   1/1     Running   0          5m58s

    4. Vérifiez que le service Kubernetes a été créé :

      $ kubectl get svc

      Le résultat se présente comme suit :

      NAME              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes        ClusterIP   10.64.0.1            443/TCP   58m
win-webserver-1   ClusterIP   10.64.6.20           80/TCP    3m35s

    5. Exécutez la commande describe pour kubectl afin de vérifier que les NEG correspondants ont été créés pour le service Kubernetes dans chacune des zones dans lesquelles l'application s'exécute :

      $ kubectl describe service win-webserver-1

      Le résultat se présente comme suit :

      Name:              win-webserver-1
Namespace:         default
Labels:            
Annotations:       cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}}
                   cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}
Selector:          app=win-webserver-1
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.64.6.20
IPs:               10.64.6.20
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         10.60.3.5:80,10.60.4.5:80,10.60.5.5:80
Session Affinity:  None
Events:
  Type    Reason  Age    From            Message
  ----    ------  ----   ----            -------
  Normal  Create  4m25s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a".
  Normal  Create  4m18s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b".
  Normal  Create  4m11s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c".
  Normal  Attach  4m9s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a")
  Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c")
  Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b")

      Le résultat de la commande précédente indique qu'un NEG a été créé pour chaque zone.

    6. Facultatif : Utilisez la gcloud CLI pour vérifier que les NEG ont été créés :

      gcloud compute network-endpoint-groups list

      Voici le résultat :

      NAME                                                        LOCATION            ENDPOINT_TYPE     SIZE
win-webserver-1                                us-central1-a  GCE_VM_IP_PORT  1
win-webserver-1                                us-central1-b  GCE_VM_IP_PORT  1
win-webserver-1                                us-central1-c  GCE_VM_IP_PORT  1

    7. Pour déployer la deuxième application de test, appliquez le fichier YAML suivant :

      apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver-2
  name: win-webserver-2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: win-webserver-2
  template:
    metadata:
      labels:
        app: win-webserver-2
      name: win-webserver-2
    spec:
     containers:
      - name: windowswebserver
        image: k8s.gcr.io/e2e-test-images/agnhost:2.36
        command: ["/agnhost"]
        args: ["netexec", "--http-port", "80"]
     topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: win-webserver-2
     nodeSelector:
      kubernetes.io/os: windows

    8. Créez le service Kubernetes correspondant :

      apiVersion: v1
kind: Service
metadata:
  name: win-webserver-2
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}'
spec:
  type: ClusterIP
  selector:
    app: win-webserver-2
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

    9. Vérifiez le déploiement de l'application :

      kubectl get pods

      Vérifiez la sortie et assurez-vous que trois pods sont en cours d'exécution.

    10. Vérifiez que le service Kubernetes et les trois NEG ont été créés :

      kubectl describe service win-webserver-2

    Configurer Cloud Service Mesh

    Dans cette section, Cloud Service Mesh est configuré comme plan de contrôle pour les passerelles Envoy.

    Vous mappez les passerelles Envoy à la configuration de routage Cloud Service Mesh appropriée en spécifiant le paramètre scope_name. Le paramètre scope_name vous permet de configurer différentes règles de routage pour les différentes passerelles Envoy.

    1. Dans Cloud Shell, créez une règle de pare-feu qui autorise le trafic entrant provenant des services Google qui vérifient la réactivité des applications :

      gcloud compute firewall-rules create allow-health-checks \
  --network=default \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp \
  --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"

    2. Vérifiez la réactivité de la première application :

      gcloud compute health-checks create http win-app-1-health-check \
  --enable-logging \
  --request-path="/healthz" \
  --use-serving-port

    3. Vérifiez la réactivité de la deuxième application :

      gcloud compute health-checks create http win-app-2-health-check \
  --enable-logging \
  --request-path="/healthz" \
  --use-serving-port

    4. Créez un service de backend Cloud Service Mesh pour la première application :

      gcloud compute backend-services create win-app-1-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED \
 --port-name=http \
 --health-checks win-app-1-health-check

    5. Créez un service de backend Cloud Service Mesh pour la deuxième application :

      gcloud compute backend-services create win-app-2-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED \
 --port-name=http \
 --health-checks win-app-2-health-check

    6. Ajoutez les NEG que vous avez créés précédemment. Ces NEG sont associés à la première application que vous avez créée en tant que backend du service de backend Cloud Service Mesh. Cet exemple de code ajoute un NEG pour chaque zone du cluster régional que vous avez créé.

      BACKEND_SERVICE=win-app-1-service
APP1_NEG_NAME=win-webserver-1
MAX_RATE_PER_ENDPOINT=10

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-b \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-a \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-c \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

    7. Ajoutez d'autres NEG. Ces NEG sont associés à la deuxième application que vous avez créée en tant que backend du service de backend Cloud Service Mesh. Cet exemple de code ajoute un NEG pour chaque zone du cluster régional que vous avez créé.

      BACKEND_SERVICE=win-app-2-service
APP2_NEG_NAME=win-webserver-2

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-b \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-a \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-c \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

    Configurer des ressources Cloud Service Mesh supplémentaires

    Maintenant que vous avez configuré les services Cloud Service Mesh, vous devez configurer deux ressources supplémentaires pour terminer la configuration de Cloud Service Mesh.

    Tout d'abord, les étapes suivantes expliquent comment configurer une ressource Gateway. Une ressource Gateway est une ressource virtuelle utilisée pour générer des règles de routage Cloud Service Mesh. Les règles de routage Cloud Service Mesh sont utilisées pour configurer les proxys Envoy en tant que passerelles.

    Les étapes suivantes montrent comment configurer une ressource HTTPRoute pour chacun des services de backend. La ressource HTTPRoute mappe les requêtes HTTP au service de backend approprié.

    1. Dans Cloud Shell, créez un fichier YAML nommé gateway.yaml qui définit la ressource Gateway :

      cat <<EOF> gateway.yaml
name: gateway80
scope: gateway-proxy
ports:
- 8080
type: OPEN_MESH
EOF

    2. Créez la ressource Gateway en appelant le fichier gateway.yaml :

      gcloud network-services gateways import gateway80 \
  --source=gateway.yaml \
  --location=global

      Le nom Gateway sera projects/$PROJECT_ID/locations/global/gateways/gateway80.

      Vous utiliserez ce nom Gateway lorsque vous créerez HTTPRoutes pour chaque service de backend.

    Créez le HTTPRoutes pour chaque service de backend :

    1. Dans Cloud Shell, stockez votre ID de projet Google Cloud dans une variable d'environnement :

      export PROJECT_ID=$(gcloud config get project)

    2. Créez le fichier YAML HTTPRoute pour la première application :

      cat <<EOF> win-app-1-route.yaml
name: win-app-1-http-route
hostnames:
- win-app-1
gateways:
- projects/$PROJECT_ID/locations/global/gateways/gateway80
rules:
- action:
   destinations:
   - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service"
EOF

    3. Créez la ressource HTTPRoute pour la première application :

      gcloud network-services http-routes import win-app-1-http-route \
  --source=win-app-1-route.yaml \
  --location=global

    4. Créez le fichier YAML HTTPRoute pour la deuxième application :

      cat <<EOF> win-app-2-route.yaml
name: win-app-2-http-route
hostnames:
- win-app-2
gateways:
- projects/$PROJECT_ID/locations/global/gateways/gateway80
rules:
- action:
   destinations:
 - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service"
EOF

    5. Créez la ressource HTTPRoute pour la deuxième application :

      gcloud network-services http-routes import win-app-2-http-route \
  --source=win-app-2-route.yaml \
  --location=global

    Déployer et exposer les passerelles Envoy

    Après avoir créé les deux applications de test basées sur Windows et Cloud Service Mesh, vous déployez les passerelles Envoy en créant un fichier YAML de déploiement. Le fichier YAML de déploiement effectue les tâches suivantes :

    • Amorce les passerelles Envoy.
    • Configure les passerelles Envoy pour qu'elles utilisent Cloud Service Mesh comme plan de contrôle.
    • Configure les passerelles Envoy pour qu'elles utilisent HTTPRoutes pour la passerelle nommée Gateway80.

    Déployez deux passerelles Envoy répliquées. Cette approche permet de rendre les passerelles tolérantes aux pannes et de fournir une redondance. Pour mettre à l'échelle automatiquement les passerelles Envoy en fonction de la charge, vous pouvez éventuellement configurer un autoscaler horizontal de pods. Si vous décidez de configurer un autoscaler horizontal de pods, vous devez suivre les instructions de la section Configurer l'autoscaling horizontal de pods.

    1. Dans Cloud Shell, créez un fichier YAML :

      apiVersion: apps/v1
kind: Deployment
    metadata:
  creationTimestamp: null
  labels:
    app: td-envoy-gateway
  name: td-envoy-gateway
spec:
  replicas: 2
  selector:
    matchLabels:
      app: td-envoy-gateway
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: td-envoy-gateway
    spec:
      containers:
      - name: envoy
        image: envoyproxy/envoy:v1.21.6
        imagePullPolicy: Always
        resources:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 100m
            memory: 128Mi
        env:
        - name: ENVOY_UID
          value: "1337"
        volumeMounts:
          - mountPath: /etc/envoy
            name: envoy-bootstrap
      initContainers:
      - name: td-bootstrap-writer
        image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator
        imagePullPolicy: Always
        args:
          - --project_number='my_project_number'
          - --scope_name='gateway-proxy'
          - --envoy_port=8080
          - --bootstrap_file_output_path=/var/lib/data/envoy.yaml
          - --traffic_director_url=trafficdirector.googleapis.com:443
          - --expose_stats_port=15005
        volumeMounts:
          - mountPath: /var/lib/data
            name: envoy-bootstrap
      volumes:
        - name: envoy-bootstrap
          emptyDir: {}

      • Remplacez my_project_number par votre numéro de projet.

        • Vous pouvez trouver le numéro de votre projet en exécutant la commande suivante :
        gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

      Le port 15005 est utilisé pour exposer le point de terminaison Envoy Admin nommé /stats. Il est également utilisé aux fins suivantes :

      • En tant que point de terminaison de réactivité de l'équilibreur de charge d'application interne.
      • Pour utiliser les métriques Google Cloud Managed Service pour Prometheus à partir d'Envoy.

      Lorsque les deux pods Envoy Gateway sont en cours d'exécution, créez un service de type ClusterIP pour les exposer. Vous devez également créer un fichier YAML nommé BackendConfig. BackendConfig définit un contrôle de réactivité non standard. Cette vérification permet de vérifier la réactivité des passerelles Envoy.

    2. Pour créer la configuration du backend avec un contrôle de réactivité non standard, créez un fichier YAML nommé envoy-backendconfig :

      apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: envoy-backendconfig
spec:
  healthCheck:
    checkIntervalSec: 5
    timeoutSec: 5
    healthyThreshold: 2
    unhealthyThreshold: 3
    type: HTTP
    requestPath: /stats
    port: 15005

      La vérification de la réactivité utilisera le point de terminaison /stats sur le port 15005 pour vérifier en continu la réactivité des passerelles Envoy.

    3. Créez le service de passerelles Envoy :

      apiVersion: v1
kind: Service
metadata:
  name: td-envoy-gateway
  annotations:
    cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}'
spec:
  type: ClusterIP
  selector:
    app: td-envoy-gateway
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
  - name: stats
    protocol: TCP
    port: 15005
    targetPort: 15005

    4. Affichez le service de passerelles Envoy que vous avez créé :

      kubectl get svc td-envoy-gateway

    Créer la ressource Kubernetes Gateway

    La création de la ressource Kubernetes Gateway provisionne l'équilibreur de charge d'application interne pour exposer les passerelles Envoy.

    Avant de créer cette ressource, vous devez créer deux exemples de certificats auto-signés, puis les importer dans le cluster GKE en tant que secrets Kubernetes. Les certificats permettent l'architecture de passerelle suivante :

    • Chaque application est diffusée via HTTPS.
    • Chaque application utilise un certificat dédié.

    Lorsque vous utilisez des certificats autogérés, l'équilibreur de charge d'application interne peut utiliser jusqu'à la limite maximale de certificats pour exposer des applications avec différents noms de domaine complets.

    Pour créer les certificats, utilisez openssl.

    1. Dans Cloud Shell, générez un fichier de configuration pour le premier certificat :

      cat <<EOF >CONFIG_FILE
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = win-webserver-1.example.com
[sans_list]
DNS.1                     = win-webserver-1.example.com
EOF

    2. Générez une clé privée pour le premier certificat :

      openssl genrsa -out sample_private_key 2048

    3. Générez une demande de certificat :

      openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE

    4. Signez et générez le premier certificat :

      openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt     -extfile CONFIG_FILE -extensions extension_requirements -days 90

    5. Générez un fichier de configuration pour le deuxième certificat :

      cat <<EOF >CONFIG_FILE2
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = win-webserver-2.example.com
[sans_list]
DNS.1                     = win-webserver-2.example.com
EOF

    6. Générez une clé privée pour le deuxième certificat :

      openssl genrsa -out sample_private_key2 2048

    7. Générez une demande de certificat :

      openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2

    8. Signez et générez le deuxième certificat :

      openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt     -extfile CONFIG_FILE2 -extensions extension_requirements -days 90

    Importer des certificats en tant que secrets Kubernetes

    Dans cette section, vous allez effectuer les tâches suivantes :

    • Importez les certificats autosignés dans le cluster GKE en tant que secrets Kubernetes.
    • Créez une adresse IP statique pour un VPC interne.
    • Créez la ressource de l'API Kubernetes Gateway.
    • Vérifiez que les certificats fonctionnent.

    1. Dans Cloud Shell, importez le premier certificat en tant que secret Kubernetes :

      kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key

    2. Importez le deuxième certificat en tant que secret Kubernetes :

      kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2

    3. Pour activer l'équilibreur de charge d'application interne, créez une adresse IP statique sur le VPC interne :

      gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default

    4. Créez le fichier YAML de la ressource Kubernetes Gateway API :

      kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-https
spec:
  gatewayClassName: gke-l7-rilb
  addresses:
    - type: NamedAddress
      value: sample-ingress-ip
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: sample-cert
      - name: sample-cert-2

      Par défaut, une passerelle Kubernetes ne comporte aucun itinéraire par défaut. La passerelle renvoie une erreur "Page introuvable (404)" lorsque des requêtes lui sont envoyées.

    5. Configurez un fichier YAML route par défaut pour la passerelle Kubernetes qui transmet toutes les requêtes entrantes aux passerelles Envoy :

        kind: HTTPRoute
  apiVersion: gateway.networking.k8s.io/v1beta1
  metadata:
    name: envoy-default-backend
  spec:
    parentRefs:
    - kind: Gateway
      name: internal-https
    rules:
    - backendRefs:
      - name: td-envoy-gateway
        port: 8080

      Vérifiez l'intégralité du flux en envoyant des requêtes HTTP aux deux applications. Pour vérifier que les passerelles Envoy acheminent le trafic vers les bons pods d'application, inspectez l'en-tête HTTP Host.

    6. Recherchez et stockez l'adresse IP de la passerelle Kubernetes dans une variable d'environnement :

      export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)

    7. Envoyez une requête à la première application :

      curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName

    8. Envoyez une requête à la deuxième application :

      curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName

    9. Vérifiez que le nom d'hôte renvoyé par la requête correspond aux pods exécutant win-app-1 et win-app-2 :

      kubectl get pods

      Le résultat doit afficher win-app-1 et win-app-2.

    Surveiller les passerelles Envoy

    Surveillez vos passerelles Envoy avec Google Cloud Managed Service pour Prometheus.

    Google Cloud Managed Service pour Prometheus doit être activé par défaut sur le cluster que vous avez créé précédemment.

    1. Dans Cloud Shell, créez une ressource PodMonitoring en appliquant le fichier YAML suivant :

      apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-envoy
spec:
  selector:
    matchLabels:
      app: td-envoy-gateway
  endpoints:
  - port: 15005
    interval: 30s
    path: /stats/prometheus

      Après avoir appliqué le fichier YAML, le système commence à collecter les métriques Google Cloud Managed Service pour Prometheus dans un tableau de bord.

    2. Pour créer le tableau de bord des métriques Google Cloud Managed Service pour Prometheus, suivez ces instructions :

      1. Connectez-vous à la console Google Cloud .
      2. Ouvrez le menu .
      3. Cliquez sur Opérations > Surveillance > Tableaux de bord.

    3. Pour importer le tableau de bord, procédez comme suit :

      1. Sur l'écran "Tableaux de bord", cliquez sur Bibliothèque d'exemples.
      2. Saisissez "envoy" dans la zone de filtre.
      3. Cliquez sur Présentation de Istio Envoy-Prometheus.
      4. Cochez la case.
      5. Cliquez sur Importer, puis sur Confirmer pour importer le tableau de bord.

    4. Pour afficher le tableau de bord, procédez comme suit :

      1. Cliquez sur Liste des tableaux de bord.
      2. Sélectionnez Intégrations.
      3. Cliquez sur Présentation de Istio Envoy-Prometheus pour afficher le tableau de bord.

    Vous pouvez désormais consulter les métriques les plus importantes de vos passerelles Envoy. Vous pouvez également configurer des alertes en fonction de vos critères. Avant de nettoyer, envoyez quelques requêtes de test supplémentaires aux applications et voyez comment le tableau de bord se met à jour avec les dernières métriques.

    Effectuer un nettoyage

    Pour éviter que les ressources utilisées dans le cadre de ce déploiement soient facturées sur votre compte Google Cloud , supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

    Supprimer le projet

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    Étapes suivantes

    Contributeurs

    Auteur : Eitan Eibschutz | Consultant solutions techniques pour le personnel

    Autres contributeurs :