Esegui il deployment di applicazioni Windows su Kubernetes gestito

Last reviewed 2024-08-14 UTC

Questo documento descrive come eseguire il deployment dell'architettura di riferimento in Gestire e scalare il networking per le applicazioni Windows eseguite su Kubernetes gestito.

Queste istruzioni sono destinate ad architetti cloud, amministratori di rete e professionisti IT responsabili della progettazione e della gestione di applicazioni Windows eseguite su cluster Google Kubernetes Engine (GKE).

Architettura

Il seguente diagramma mostra l'architettura di riferimento che utilizzi quando esegui il deployment di applicazioni Windows eseguite su cluster GKE gestiti.

I dati scorrono attraverso un bilanciatore del carico delle applicazioni interno e un gateway Envoy.

Come mostrato nel diagramma precedente, una freccia rappresenta il flusso di lavoro per la gestione del networking per le applicazioni Windows eseguite su GKE utilizzando Cloud Service Mesh e i gateway Envoy. Il cluster GKE regionale include pool di nodi Windows e Linux. Cloud Service Mesh crea e gestisce le route del traffico verso i pod Windows.

Obiettivi

  • Crea e configura un cluster GKE per eseguire applicazioni Windows e proxy Envoy.
  • Esegui il deployment e verifica le applicazioni Windows.
  • Configura Cloud Service Mesh come control plane per i gateway Envoy.
  • Utilizza l'API Kubernetes Gateway per eseguire il provisioning del bilanciatore del carico delle applicazioni interno ed esporre i gateway Envoy.
  • Comprendi le operazioni di deployment continuo che hai creato.

Costi

Il deployment di questa architettura utilizza i seguenti componenti fatturabili di Google Cloud:

Al termine del deployment, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

  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

    Se l'esecuzione avviene in un ambiente Virtual Private Cloud (VPC) condiviso, devi anche seguire le istruzioni per creare manualmente la subnet solo proxy e la regola firewall per i controlli di risposta di Cloud Load Balancing.

    Crea un cluster GKE

    Per creare un cluster GKE: Utilizzi il cluster GKE per contenere ed eseguire le applicazioni Windows e i proxy Envoy in questo deployment.

    1. In Cloud Shell, esegui questo comando Google Cloud CLI per creare un cluster GKE regionale con un nodo in ciascuna delle tre regioni:

      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. Aggiungi il pool di nodi Windows al 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

      Il completamento di questa operazione potrebbe richiedere circa 20 minuti.

    3. Memorizza l'ID progetto Google Cloud in una variabile di ambiente:

      export PROJECT_ID=$(gcloud config get project)

    4. Connettiti al cluster GKE:

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

    5. Elenca tutti i nodi nel cluster GKE:

      kubectl get nodes

      L'output dovrebbe mostrare tre nodi Linux e tre nodi Windows.

      Quando il cluster GKE è pronto, puoi eseguire il deployment di due applicazioni di test basate su Windows.

    Esegui il deployment di due applicazioni di test

    In questa sezione, esegui il deployment di due applicazioni di test basate su Windows. Entrambe le applicazioni di test stampano il nome host su cui viene eseguita l'applicazione. Crea anche un servizio Kubernetes per esporre l'applicazione tramite gruppi di endpoint di rete (NEG) autonomi.

    Quando esegui il deployment di un'applicazione basata su Windows e di un servizio Kubernetes su un cluster regionale, viene creato un NEG per ogni zona in cui viene eseguita l'applicazione. In un secondo momento, questa guida al deployment spiega come configurare questi NEG come backend per i servizi Cloud Service Mesh.

    1. In Cloud Shell, applica il seguente file YAML con kubectl per eseguire il deployment della prima applicazione di test. Questo comando esegue il deployment di tre istanze dell'applicazione di test, una in ogni zona regionale.

      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. Applica il servizio Kubernetes corrispondente ed esponilo con 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. Verifica il deployment:

      kubectl get pods

      L'output mostra che l'applicazione ha tre pod Windows in esecuzione.

      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. Verifica che il servizio Kubernetes sia stato creato:

      $ kubectl get svc

      L'output è simile al seguente:

      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. Esegui il comando describe per kubectl per verificare che siano stati creati NEG corrispondenti per il servizio Kubernetes in ciascuna delle zone in cui viene eseguita l'applicazione:

      $ kubectl describe service win-webserver-1

      L'output è simile al seguente:

      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")

      L'output del comando precedente mostra che è stato creato un NEG per ogni zona.

    6. (Facoltativo) Utilizza gcloud CLI per verificare che i NEG siano stati creati:

      gcloud compute network-endpoint-groups list

      L'output è il seguente:

      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. Per eseguire il deployment della seconda applicazione di test, applica il seguente file YAML:

      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. Crea il servizio Kubernetes corrispondente:

      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. Verifica il deployment dell'applicazione:

      kubectl get pods

      Controlla l'output e verifica che siano presenti tre pod in esecuzione.

    10. Verifica che siano stati creati il servizio Kubernetes e tre NEG:

      kubectl describe service win-webserver-2

    Configura Cloud Service Mesh

    In questa sezione, Cloud Service Mesh è configurato come control plane per i gateway Envoy.

    Mappa i gateway Envoy alla configurazione di routing Cloud Service Mesh pertinente specificando il parametro scope_name. Il parametro scope_name consente di configurare regole di routing diverse per i diversi gateway Envoy.

    1. In Cloud Shell, crea una regola firewall che consenta il traffico in entrata dai servizi Google che controllano la reattività dell'applicazione:

      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. Controlla la reattività della prima applicazione:

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

    3. Controlla la reattività della seconda applicazione:

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

    4. Crea un servizio di backend Cloud Service Mesh per la prima applicazione:

      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. Crea un servizio di backend Cloud Service Mesh per la seconda applicazione:

      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. Aggiungi i NEG che hai creato in precedenza. Questi NEG sono associati alla prima applicazione che hai creato come backend per il servizio di backend Cloud Service Mesh. Questo esempio di codice aggiunge un NEG per ogni zona del cluster regionale che hai creato.

      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. Aggiungi ulteriori NEG. Questi NEG sono associati alla seconda applicazione che hai creato come backend del servizio di backend Cloud Service Mesh. Questo esempio di codice aggiunge un NEG per ogni zona nel cluster regionale che hai creato.

      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

    Configura risorse Cloud Service Mesh aggiuntive

    Ora che hai configurato i servizi Cloud Service Mesh, devi configurare due risorse aggiuntive per completare la configurazione di Cloud Service Mesh.

    Innanzitutto, questi passaggi mostrano come configurare una risorsa Gateway. Una risorsa Gateway è una risorsa virtuale utilizzata per generare regole di routing di Cloud Service Mesh. Le regole di routing di Cloud Service Mesh vengono utilizzate per configurare i proxy Envoy come gateway.

    I passaggi successivi mostrano come configurare una risorsa HTTPRoute per ciascuno dei servizi di backend. La risorsa HTTPRoute mappa le richieste HTTP al servizio di backend pertinente.

    1. In Cloud Shell, crea un file YAML denominato gateway.yaml che definisce la risorsa Gateway:

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

    2. Crea la risorsa Gateway richiamando il file gateway.yaml:

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

      Il nome di Gateway sarà projects/$PROJECT_ID/locations/global/gateways/gateway80.

      Utilizzi questo nome Gateway quando crei HTTPRoutes per ogni servizio di backend.

    Crea il HTTPRoutes per ogni servizio di backend:

    1. In Cloud Shell, memorizza l'ID progetto in una variabile di ambiente: Google Cloud 

      export PROJECT_ID=$(gcloud config get project)

    2. Crea il file YAML HTTPRoute per la prima applicazione:

      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. Crea la risorsa HTTPRoute per la prima applicazione:

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

    4. Crea il file YAML HTTPRoute per la seconda applicazione:

      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. Crea la risorsa HTTPRoute per la seconda applicazione:

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

    Esegui il deployment ed esponi i gateway Envoy

    Dopo aver creato le due applicazioni di test basate su Windows e Cloud Service Mesh, esegui il deployment dei gateway Envoy creando un file YAML di deployment. Il file YAML di deployment svolge le seguenti attività:

    • Esegue il bootstrap dei gateway Envoy.
    • Configura i gateway Envoy per utilizzare Cloud Service Mesh come control plane.
    • Configura i gateway Envoy in modo che utilizzino HTTPRoutes per il gateway denominato Gateway80.

    Esegui il deployment di due gateway Envoy di replica. Questo approccio contribuisce a rendere i gateway tolleranti agli errori e fornisce ridondanza. Per scalare automaticamente i gateway Envoy in base al carico, puoi configurare facoltativamente un gestore della scalabilità automatica orizzontale dei pod. Se decidi di configurare un Horizontal Pod Autoscaler, devi seguire le istruzioni riportate in Configurazione della scalabilità automatica del pod orizzontale.

    1. In Cloud Shell, crea un file 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: {}

      • Sostituisci my_project_number con il numero del tuo progetto.

        • Puoi trovare il numero di progetto eseguendo questo comando:
        gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

      La porta 15005 viene utilizzata per esporre l'endpoint di amministrazione di Envoy denominato /stats. Viene utilizzato anche per i seguenti scopi:

      • Come endpoint di risposta dal bilanciatore del carico delle applicazioni interno.
      • Come modo per utilizzare le metriche di Google Cloud Managed Service per Prometheus da Envoy.

      Quando i due pod Envoy Gateway sono in esecuzione, crea un servizio di tipo ClusterIP per esporli. Devi anche creare un file YAML denominato BackendConfig. BackendConfig definisce un controllo di adattabilità non standard. Questo controllo viene utilizzato per verificare la reattività dei gateway Envoy.

    2. Per creare la configurazione del backend con un controllo di reattività non standard, crea un file YAML denominato 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

      Il controllo della reattività utilizzerà l'endpoint /stats sulla porta 15005 per controllare continuamente la reattività dei gateway Envoy.

    3. Crea il servizio dei gateway 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. Visualizza il servizio di gateway Envoy che hai creato:

      kubectl get svc td-envoy-gateway

    Crea la risorsa Kubernetes Gateway

    La creazione della risorsa Kubernetes Gateway esegue il provisioning del bilanciatore del carico delle applicazioni interno per esporre i gateway Envoy.

    Prima di creare questa risorsa, devi creare due certificati autofirmati di esempio e poi importarli nel cluster GKE come secret Kubernetes. I certificati consentono la seguente architettura del gateway:

    • Ogni applicazione viene pubblicata tramite HTTPS.
    • Ogni applicazione utilizza un certificato dedicato.

    Quando utilizzi certificati autogestiti, il bilanciatore del carico delle applicazioni interno può utilizzare fino al limite massimo di certificati per esporre applicazioni con nomi di dominio completi diversi.

    Per creare i certificati, utilizza openssl.

    1. In Cloud Shell, genera un file di configurazione per il primo certificato:

      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. Genera una chiave privata per il primo certificato:

      openssl genrsa -out sample_private_key 2048

    3. Genera una richiesta di certificato:

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

    4. Firma e genera il primo certificato:

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

    5. Genera un file di configurazione per il secondo certificato:

      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. Genera una chiave privata per il secondo certificato:

      openssl genrsa -out sample_private_key2 2048

    7. Genera una richiesta di certificato:

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

    8. Firma e genera il secondo certificato:

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

    Importare i certificati come secret Kubernetes

    In questa sezione, svolgerai le seguenti attività:

    • Importa i certificati autofirmati nel cluster GKE come secret Kubernetes.
    • Crea un indirizzo IP statico per un VPC interno.
    • Crea la risorsa API Kubernetes Gateway.
    • Verifica che i certificati funzionino.

    1. In Cloud Shell, importa il primo certificato come secret Kubernetes:

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

    2. Importa il secondo certificato come secret Kubernetes:

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

    3. Per attivare il bilanciatore del carico delle applicazioni interno, crea un indirizzo IP statico sul VPC interno:

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

    4. Crea il file YAML della risorsa API Kubernetes Gateway:

      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

      Per impostazione predefinita, un gateway Kubernetes non ha route predefinite. Il gateway restituisce un errore di pagina non trovata (404) quando vengono inviate richieste.

    5. Configura un file YAML route predefinito per il gateway Kubernetes che trasferisce tutte le richieste in entrata ai gateway 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

      Verifica il flusso completo inviando richieste HTTP a entrambe le applicazioni. Per verificare che i gateway Envoy indirizzino il traffico ai pod dell'applicazione corretti, ispeziona l'intestazione host HTTP.

    6. Trova e memorizza l'indirizzo IP del gateway Kubernetes in una variabile di ambiente:

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

    7. Invia una richiesta alla prima applicazione:

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

    8. Invia una richiesta alla seconda applicazione:

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

    9. Verifica che il nome host restituito dalla richiesta corrisponda ai pod che eseguono win-app-1 e win-app-2:

      kubectl get pods

      L'output dovrebbe mostrare win-app-1 e win-app-2.

    Monitorare i gateway Envoy

    Monitora i gateway Envoy con Google Cloud Managed Service per Prometheus.

    Google Cloud Managed Service per Prometheus dovrebbe essere abilitato per impostazione predefinita sul cluster che hai creato in precedenza.

    1. In Cloud Shell, crea una risorsa PodMonitoring applicando il seguente file YAML:

      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

      Dopo aver applicato il file YAML, il sistema inizia a raccogliere le metriche di Google Cloud Managed Service per Prometheus in una dashboard.

    2. Per creare il dashboard delle metriche di Google Cloud Managed Service per Prometheus, segui queste istruzioni:

      1. Accedi alla Google Cloud console.
      2. Apri il menu .
      3. Fai clic su Operazioni > Monitoraggio > Dashboard.

    3. Per importare la dashboard, segui queste istruzioni:

      1. Nella schermata Dashboard, fai clic su Libreria di esempi.
      2. Inserisci envoy nella casella del filtro.
      3. Fai clic su Panoramica di Istio Envoy Prometheus.
      4. Seleziona la casella di controllo.
      5. Fai clic su Importa e poi su Conferma per importare la dashboard.

    4. Per visualizzare la dashboard:

      1. Fai clic su Elenco dashboard.
      2. Seleziona Integrazioni.
      3. Fai clic su Panoramica di Istio Envoy Prometheus per visualizzare la dashboard.

    Ora puoi visualizzare le metriche più importanti dei tuoi gateway Envoy. Puoi anche configurare avvisi in base ai tuoi criteri. Prima di eseguire la pulizia, invia altre richieste di test alle applicazioni e verifica come la dashboard si aggiorna con le metriche più recenti.

    Esegui la pulizia

    Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo deployment, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

    Elimina il progetto

    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.

    Passaggi successivi

    Collaboratori

    Autore: Eitan Eibschutz | Staff Technical Solutions Consultant

    Altri collaboratori: