Questo documento descrive come eseguire il deployment dell'architettura di riferimento in Gestire e scalare la rete per le applicazioni Windows in esecuzione su Kubernetes gestito.
Queste istruzioni sono rivolte 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 utilizzata per eseguire il deployment di applicazioni Windows in esecuzione su cluster GKE gestiti.
Come mostrato nel diagramma precedente, una freccia rappresenta il flusso di lavoro per la gestione della rete per le applicazioni Windows in esecuzione 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 i percorsi di traffico per 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 piano di controllo 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 di questo deployment, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.
Prima di iniziare
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Cloud Shell, and Cloud Service Mesh APIs.
-
In the Google Cloud console, activate Cloud Shell.
Se esegui l'operazione in un ambiente Virtual Private Cloud (VPC) condiviso, devi anche seguire le istruzioni per creare manualmente la subnet e la regola firewall solo per proxy per i controlli di reattività di Cloud Load Balancing.
Crea un cluster GKE
Per creare un cluster GKE, segui questi passaggi. Utilizza il cluster GKE per contenere ed eseguire le applicazioni Windows e i proxy Envoy in questo deployment.
In Cloud Shell, esegui il seguente 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
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.
Memorizza l'ID progetto Google Cloud in una variabile di ambiente:
export PROJECT_ID=$(gcloud config get project)
Connettiti al cluster GKE:
gcloud container clusters get-credentials my-cluster --region us-central1
Elenca tutti i nodi del 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. Inoltre, crei 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 seguito, questa guida all'implementazione illustra come configurare queste NEG come backend per i servizi Cloud Service Mesh.
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
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
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
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 Esegui il comando
describe
perkubectl
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.
(Facoltativo) Utilizza gcloud CLI per verificare che le NEG siano state create:
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
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
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
Verifica il deployment dell'applicazione:
kubectl get pods
Controlla l'output e verifica che siano presenti tre pod in esecuzione.
Verifica che il servizio Kubernetes e tre NEG siano stati creati:
kubectl describe service win-webserver-2
Configura Cloud Service Mesh
In questa sezione, Cloud Service Mesh è configurato come piano di controllo per i gateway Envoy.
Puoi mappare 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.
In Cloud Shell, crea una regola firewall che consenta il traffico in entrata proveniente 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"
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
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
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
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
Aggiungi i gruppi di esclusioni 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
Aggiungi altri NEG. Questi NEG sono associati alla seconda applicazione che hai creato come backend per il 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
Configurare risorse Cloud Service Mesh aggiuntive
Ora che hai configurato i servizi Cloud Service Mesh, devi configurare altre due risorse 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 le regole di routing di Cloud Service Mesh. Le regole di routing di Cloud Service Mesh vengono utilizzate per configurare i proxy Envoy come gateway.
Di seguito vengono descritti i passaggi per configurare una risorsa HTTPRoute
per ciascuno dei servizi di backend. La risorsa HTTPRoute
mappa le richieste HTTP al servizio di backend pertinente.
In Cloud Shell, crea un file YAML denominato
gateway.yaml
che definisce la risorsaGateway
:cat <<EOF> gateway.yaml name: gateway80 scope: gateway-proxy ports: - 8080 type: OPEN_MESH EOF
Crea la risorsa
Gateway
richiamando il filegateway.yaml
:gcloud network-services gateways import gateway80 \ --source=gateway.yaml \ --location=global
Il nome di
Gateway
saràprojects/$PROJECT_ID/locations/global/gateways/gateway80
.Utilizza questo nome
Gateway
quando creiHTTPRoutes
per ogni servizio di backend.
Crea HTTPRoutes
per ogni servizio di backend:
In Cloud Shell, archivia l'ID progetto Google Cloud in una variabile di ambiente:
export PROJECT_ID=$(gcloud config get project)
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
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
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
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 esegue le seguenti attività:
- Esegue il bootstrap dei gateway Envoy.
- Configura i gateway Envoy in modo che utilizzino Cloud Service Mesh come piano di controllo.
- Configura i gateway Envoy in modo che utilizzino
HTTPRoutes
per il gateway denominatoGateway80
.
Esegui il deployment di due gateway Envoy di replica. Questo approccio contribuisce a rendere i gateway tolleranti ai guasti e fornisce ridondanza. Per scalare automaticamente i gateway Envoy in base al carico, puoi eventualmente configurare un Horizontal Pod Autoscaler. Se decidi di configurare un Horizontal Pod Autoscaler, devi seguire le istruzioni riportate in Configurazione della scalabilità automatica del pod orizzontale.
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.
- Per trovare il numero del progetto, esegui il seguente comando:
gcloud projects describe $(gcloud config get project) --format="value(projectNumber)"
La porta
15005
viene utilizzata per esporre l'endpoint Envoy Admin denominato/stats
. Viene inoltre utilizzata per le seguenti finalità:- Come endpoint di reattività dal bilanciatore del carico delle applicazioni interno.
- Come un 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 denominatoBackendConfig
.BackendConfig
definisce un controllo di adattabilità non standard. Questo controllo viene utilizzato per verificare la reattività dei gateway Envoy.Per creare la configurazione del backend con un controllo della 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 porta15005
per controllare continuamente la reattività dei gateway Envoy.Crea il servizio di 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
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 dell'Application Load Balancer 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 attivano la seguente architettura del gateway:
- Ogni applicazione viene pubblicata tramite HTTPS.
- Ogni applicazione utilizza un certificato dedicato.
Quando utilizzi i certificati gestiti autonomamente, 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
.
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
Genera una chiave privata per il primo certificato:
openssl genrsa -out sample_private_key 2048
Genera una richiesta di certificato:
openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE
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
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
Genera una chiave privata per il secondo certificato:
openssl genrsa -out sample_private_key2 2048
Genera una richiesta di certificato:
openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2
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
Importa i certificati come secret Kubernetes
In questa sezione, esegui le seguenti attività:
- Importa i certificati autofirmati nel cluster GKE come secret Kubernetes.
- Crea un indirizzo IP statico per una VPC interna.
- Crea la risorsa dell'API Kubernetes Gateway.
- Verifica che i certificati funzionino.
In Cloud Shell, importa il primo certificato come segreto Kubernetes:
kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key
Importa il secondo certificato come secret Kubernetes:
kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2
Per attivare il bilanciatore del carico delle applicazioni interno, crea un indirizzo IP statico nella VPC interna:
gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default
Crea il file YAML della risorsa dell'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 Pagina non trovata (404) quando vengono inviate richieste.
Configura un file YAML
route
predefinito per il gateway Kubernetes che inoltra tutte le richieste in arrivo 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 di applicazioni corretti, controlla l'intestazione Host HTTP.
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)
Invia una richiesta alla prima applicazione:
curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName
Invia una richiesta alla seconda applicazione:
curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName
Verifica che il nome host restituito dalla richiesta corrisponda ai pod che eseguono
win-app-1
ewin-app-2
:kubectl get pods
L'output dovrebbe mostrare
win-app-1
ewin-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 nel cluster creato in precedenza.
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.
Per creare la dashboard delle metriche di Google Cloud Managed Service per Prometheus, segui queste istruzioni:
- Accedi alla console Google Cloud.
- Apri il menu .
- Fai clic su Operazioni > Monitoraggio > Dashboard.
Per importare la dashboard:
- Nella schermata Dashboard, fai clic su Sample Library (Raccolta di esempi).
- Inserisci envoy nella casella del filtro.
- Fai clic su Panoramica di Prometheus per Istio Envoy.
- Seleziona la casella di controllo.
- Fai clic su Importa e poi su Conferma per importare la dashboard.
Per visualizzare la dashboard:
- Fai clic su Elenco dashboard.
- Seleziona Integrations (Integrazioni).
- 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 gli avvisi in base ai tuoi criteri. Prima di eseguire la pulizia, invia altre richieste di test alle applicazioni e controlla 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
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Scopri di più sui prodotti Google Cloud utilizzati in questa guida all'implementazione:
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.
Collaboratori
Autore: Eitan Eibschutz | Technical Solutions Consultant dello staff
Altri collaboratori:
- John Laham | Solution Architect
- Kaslin Fields | Developer Advocate
- Maridi (Raju) Makaraju | Technical Lead per l'idoneità all'assistenza
- Valavan Rajakumar | Key Enterprise Architect
- Victor Moreno | Product Manager, Cloud Networking