Configurare Google Kubernetes Engine e i servizi gRPC proxyless
Questa guida descrive come configurare Google Kubernetes Engine, le applicazioni gRPC e i componenti di bilanciamento del carico richiesti da Traffic Director.
Prima di seguire le istruzioni riportate in questa guida, consulta Preparare la configurazione di Traffic Director con servizi gRPC senza proxy.
Panoramica
La configurazione di Traffic Director con GKE e servizi gRPC proxyless prevede quanto segue:
- Preparazione del cluster GKE.
- Deployment di un'applicazione server gRPC come servizio Kubernetes. Annota la specifica del deployment di GKE per creare automaticamente un gruppo di endpoint di rete (NEG) per il servizio.
- Configurazione di Traffic Director utilizzando il NEG e altri componenti di bilanciamento del carico di Google Cloud.
- Verificare che il deployment funzioni correttamente utilizzando un'applicazione client gRPC proxyless per inviare il traffico all'applicazione server gRPC.
Configurazione dei cluster GKE per Traffic Director
Questa sezione fornisce istruzioni per consentire ai cluster GKE di funzionare con Traffic Director.
Requisiti dei cluster GKE
I cluster GKE devono soddisfare i seguenti requisiti:
- Devi attivare il supporto per i gruppi di endpoint di rete. Per ulteriori informazioni ed esempi, consulta Gruppi di endpoint di rete autonomi. La funzionalità NEG autonoma è disponibile in disponibilità generale per Traffic Director.
- L'account di servizio delle istanze dei nodi cluster deve avere l'autorizzazione per accedere all'API Traffic Director. Per scoprire di più sulle autorizzazioni richieste, consulta Abilitare l'account di servizio per accedere all'API Traffic Director.
- I container devono avere accesso all'API Traffic Director, protetta dall'autenticazione OAuth. Per ulteriori informazioni, consulta la pagina relativa alla configurazione dell'host.
Creazione del cluster GKE
L'esempio seguente mostra come creare un cluster GKE denominato grpc-td-cluster
in us-central1-a zone
.
Console
Per creare un cluster utilizzando la console Google Cloud, esegui questi passaggi:
Vai al menu Kubernetes Engine nella console Google Cloud.
Fai clic su Crea cluster.
Scegli il modello Cluster standard o scegli un modello appropriato per il carico di lavoro.
Personalizza il modello, se necessario. I seguenti campi sono obbligatori:
- Nome: inserisci
grpc-td-cluster
. - Tipo di località:
Zonal
. - Zona:
us-central1-a
. - Pool di nodi:
- Nome: inserisci
Nel menu a sinistra, fai clic su default-pool.
Cambia il Nome in
grpc-td-cluster
.In Dimensioni, inserisci il numero di nodi da creare. Devi disporre della quota di risorse disponibile per i nodi e le relative risorse (ad esempio le route firewall).
Nel menu a sinistra, fai clic su Nodi.
In Configurazione macchina, in Famiglia di macchine, fai clic su Ottimizzato da Compute.
Seleziona un tipo di macchina. Per informazioni sui prezzi dei tipi di macchine, consulta la pagina dei prezzi di Compute Engine.
In Networking, aggiungi il tag di rete
allow-health-checks
.Nel menu a sinistra, fai clic su Sicurezza dei nodi.
In Ambiti di accesso, seleziona Consenti accesso completo a tutte le API Cloud.
Fai clic su Crea.
Dopo aver creato un cluster nella console Google Cloud, devi configurare kubectl
per interagire con il cluster. Per scoprire di più, consulta Generazione di una voce kubeconfig
.
gcloud
Crea il cluster.
gcloud container clusters create grpc-td-cluster \ --zone us-central1-a \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --tags=allow-health-checks \ --enable-ip-alias
Ottenere i privilegi necessari per il cluster GKE
Passa al cluster appena creato eseguendo il comando seguente. Questo
indirizza kubectl
al cluster corretto.
gcloud
gcloud container clusters get-credentials grpc-td-cluster \ --zone us-central1-a
Configurazione dei servizi GKE
Questa sezione descrive come preparare le specifiche di deployment GKE per l'utilizzo con Traffic Director. Questo consiste nel configurare un servizio di esempio GKE helloworld
con annotazioni NEG.
Il servizio di esempio helloworld
è un'applicazione server gRPC che restituisce un semplice messaggio in risposta alla richiesta di un client gRPC. Non c'è niente di speciale nel servizio helloworld
. Non è un servizio gRPC senza proxy e può rispondere alle richieste da qualsiasi client gRPC.
La parte "proxyless" entra in gioco solo quando un'applicazione client gRPC si connette
a Traffic Director, viene a conoscenza del servizio helloworld
e può quindi inviare il traffico ai pod associati a helloworld
, senza dover fare affidamento
su indirizzi IP o risoluzione dei nomi basata su DNS.
Configurazione dei servizi GKE con NEG
Il primo passaggio della configurazione dei servizi GKE da utilizzare con Traffic Director consiste nell'esporre il servizio tramite un NEG. Per essere esposta tramite i NEG, ogni specifica deve avere la seguente annotazione, corrispondente alla porta che vuoi esporre.
... metadata: annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}'
Questa annotazione crea un NEG autonomo quando esegui il deployment del servizio per la prima volta. Questo NEG contiene endpoint che sono gli indirizzi IP e le porte del pod. Per ulteriori informazioni ed esempi, consulta Gruppi di endpoint di rete autonomi.
Nell'esempio seguente viene eseguito il deployment di un servizio Kubernetes helloworld
esposto sulla porta 8080
. Questa è la porta sulla quale il servizio è visibile nel cluster. Il servizio gRPC nel pod è in ascolto su targetPort
50051
. Questa è la porta sul pod a cui viene inviata la richiesta. In genere, port
e targetPort
sono impostati sullo stesso valore per comodità, ma questo esempio utilizza valori diversi per indicare il valore corretto da utilizzare nell'annotazione NEG.
cat << EOF > grpc-td-helloworld.yaml apiVersion: v1 kind: Service metadata: name: helloworld annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}' spec: ports: - port: 8080 name: helloworld protocol: TCP targetPort: 50051 selector: run: app1 type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: labels: run: app1 name: app1 spec: selector: matchLabels: run: app1 replicas: 2 template: metadata: labels: run: app1 spec: containers: - image: grpc/java-example-hostname:1.50.2 name: app1 ports: - protocol: TCP containerPort: 50051 EOF
kubectl apply -f grpc-td-helloworld.yaml
Verifica che il nuovo servizio helloworld
sia stato creato:
kubectl get svc
L'output di kubectl get svc
dovrebbe essere simile al seguente:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE helloworld ClusterIP 10.71.9.71 <none> 8080/TCP 41m [..skip..]
Verifica che il pod dell'applicazione sia in esecuzione:
kubectl get pods
L'output di kubectl get pods
dovrebbe essere simile al seguente:
NAME READY STATUS RESTARTS AGE app1-6db459dcb9-zvfg2 1/1 Running 0 6m app1-6db459dcb9-hlvhj 1/1 Running 0 6m [..skip..]
Verifica che il nome NEG sia corretto.
Console
Per visualizzare un elenco di gruppi di endpoint di rete, vai alla pagina Gruppi di endpoint di rete nella console Google Cloud. Vedrai un NEG denominato example-grpc-server
.
Vai alla pagina Gruppi di endpoint di rete
gcloud
# List the NEGs gcloud compute network-endpoint-groups list \ --filter "name=example-grpc-server" --format "value(name)" # Optionally examine the NEG gcloud compute network-endpoint-groups describe example-grpc-server \ --zone us-central1-a # Optionally examine the endpoint(s) contained gcloud compute network-endpoint-groups list-network-endpoints example-grpc-server \ --zone us-central1-a
Configurazione di Traffic Director con i componenti di bilanciamento del carico
Questa sezione descrive come configurare i componenti di bilanciamento del carico di Google Cloud per i servizi. Questi componenti contengono informazioni di configurazione che consentono ai client gRPC proxy di comunicare con i tuoi servizi GKE.
L'esempio di configurazione di Traffic Director che segue formula queste ipotesi:
- I NEG e tutte le altre risorse vengono creati nella rete predefinita in modalità automatica nella zona
us-central1-a
. - Quando utilizzi Google Cloud CLI, il nome NEG per il cluster è
example-grpc-server
.
Creazione del controllo di integrità, della regola firewall e del servizio di backend in corso...
In questa sezione, creerai un controllo di integrità e la regola firewall per il controllo di integrità. Il controllo di integrità deve utilizzare il protocollo del controllo di integrità gRPC. La regola firewall consente ai probe del controllo di integrità di connettersi alle VM nel deployment. L'istruzione --use-serving-port
viene utilizzata dai controlli di integrità per ottenere la porta di ascolto configurata per ogni endpoint.
La regola firewall consente le connessioni di controllo di integrità in entrata alle istanze nella rete.
In questa sezione, creerai un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED
e protocollo GRPC
, quindi associ il controllo di integrità al servizio di backend.
Per saperne di più, consulta Creazione di controlli di integrità.
gcloud
Crea il controllo di integrità.
gcloud compute health-checks create grpc grpc-gke-helloworld-hc \ --use-serving-port
Creare la regola firewall.
gcloud compute firewall-rules create grpc-gke-allow-health-checks \ --network default --action allow --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags allow-health-checks \ --rules tcp:50051
Creare il servizio di backend.
gcloud compute backend-services create grpc-gke-helloworld-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --protocol=GRPC \ --health-checks grpc-gke-helloworld-hc
Aggiungi i NEG di backend al servizio di backend.
gcloud compute backend-services add-backend grpc-gke-helloworld-service \ --global \ --network-endpoint-group example-grpc-server \ --network-endpoint-group-zone us-central1-a \ --balancing-mode RATE \ --max-rate-per-endpoint 5
Creazione della mappa di regole di routing
In questa sezione, creerai una mappa URL, un matcher percorso e una regola host per instradare il traffico per il tuo servizio in base al nome host e a un percorso. L'esempio seguente utilizza helloworld-gke
come nome del servizio. Il client gRPC utilizza questo nome di servizio nell'URI di destinazione quando si connette al servizio helloworld
.
Puoi anche creare il proxy gRPC target e la regola di forwarding.
Per saperne di più, vedi Mappe delle regole di routing.
L'esempio seguente utilizza il nome del servizio helloworld-gke
e la porta 8000
.
Ciò significa che il client gRPC deve utilizzare xds:///helloworld-gke:8000
per connettersi a questo servizio ed è necessario configurare una regola host helloworld-gke:8000
nella mappa URL. Tieni presente che la porta del servizio 8080
mostrata nelle specifiche del servizio Kubernetes
sopra non è utilizzata da Traffic Director perché helloworld-gke:8000
è stato
risolto direttamente negli endpoint NEG in ascolto su targetPort
50051
.
In genere, la porta nella regola host della mappa URL e le specifiche del servizio Kubernetes port
e targetPort
sono tutte impostate sullo stesso valore per comodità, ma in questo esempio vengono usati valori diversi per mostrare che port
nella specifica del servizio non viene utilizzato da Traffic Director.
gcloud
Crea la mappa URL.
gcloud compute url-maps create grpc-gke-url-map \ --default-service grpc-gke-helloworld-service
Crea il matcher percorso.
gcloud compute url-maps add-path-matcher grpc-gke-url-map \ --default-service grpc-gke-helloworld-service \ --path-matcher-name grpc-gke-path-matcher \ --new-hosts helloworld-gke:8000
Crea il proxy gRPC di destinazione.
gcloud compute target-grpc-proxies create grpc-gke-proxy \ --url-map grpc-gke-url-map \ --validate-for-proxyless
Crea la regola di forwarding.
gcloud compute forwarding-rules create grpc-gke-forwarding-rule \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --address=0.0.0.0 \ --target-grpc-proxy=grpc-gke-proxy \ --ports 8000 \ --network default
Traffic Director è ora configurato per bilanciare il carico del traffico tra gli endpoint nel NEG per i servizi specificati nella mappa URL.
Verifica della configurazione
Al termine della procedura di configurazione, verifica di poter raggiungere il server gRPC helloworld
utilizzando un client gRPC proxy. Questo client si connette
a Traffic Director, ottiene le informazioni sul servizio helloworld
(configurato con Traffic Director utilizzando il servizio di backend
grpc-gke-helloworld-service
) e utilizza queste informazioni per inviare il traffico ai backend
del servizio.
Puoi anche controllare la sezione Traffic Director nella console Google Cloud per informazioni sul servizio configurato helloworld-gke
e verificare se i backend sono segnalati come integri.
Verifica con un client gRPC proxyless
Negli esempi riportati di seguito, utilizzi i client gRPC in diversi linguaggi o lo strumento grpcurl
per verificare che Traffic Director stia instradando correttamente il traffico nel mesh. Crea un pod client, quindi apri una shell ed esegui i comandi di verifica dalla shell.
Configurazione della variabile di ambiente e del file di bootstrap
L'applicazione client richiede un file di configurazione bootstrap. Modifica la tua specifica di deployment dell'applicazione Kubernetes aggiungendo un elemento initContainer
che genera il file bootstrap e un volume per il trasferimento. Aggiorna il container esistente per trovare il file.
Aggiungi initContainer
alla specifica di deployment dell'applicazione:
initContainers: - args: - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.11.0 imagePullPolicy: IfNotPresent name: grpc-td-init resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ volumes: - name: grpc-td-conf emptyDir: medium: Memory
Aggiorna la sezione env
del container dell'applicazione in modo che includa quanto segue:
env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/
Ecco un esempio completo di una specifica Kubernetes client:
cat << EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: labels: run: client name: sleeper spec: selector: matchLabels: run: client template: metadata: labels: run: client spec: containers: - image: openjdk:8-jdk imagePullPolicy: IfNotPresent name: sleeper command: - sleep - 365d env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" resources: limits: cpu: "2" memory: 2000Mi requests: cpu: 300m memory: 1500Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - args: - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.11.0 imagePullPolicy: IfNotPresent name: grpc-td-init resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Quando il deployment indicato sopra è pronto, apri una shell per il pod client.
kubectl exec -it $(kubectl get pods -o custom-columns=:.metadata.name \ --selector=run=client) -- /bin/bash
Per verificare la configurazione, esegui gli esempi appropriati nella shell dei pod.
Java
Per verificare il servizio con un client Java gRPC:
Scarica l'ultima versione di gRPC Java, con la patch più recente e crea l'applicazione client
xds-hello-world
.curl -L https://github.com/grpc/grpc-java/archive/v1.37.0.tar.gz | tar -xz cd grpc-java-1.37.0/examples/example-xds ../gradlew --no-daemon installDist
Esegui il client con
"world"
come nome e"xds:///helloworld-gke:8000"
come URI di servizio e porta../build/install/example-xds/bin/xds-hello-world-client "world" \ xds:///helloworld-gke:8000
Go
Per verificare il servizio con un client gRPC Go:
Scarica l'ultima versione di gRPC Go, con la patch più recente, e crea l'applicazione client
xds-hello-world
.apt-get update -y apt-get install -y golang git curl -L https://github.com/grpc/grpc-go/archive/v1.37.0.tar.gz | tar -xz cd grpc-go-1.37.0/examples/features/xds/client go get google.golang.org/grpc@v1.37.0 go build .
Esegui il client con
"world"
come nome e"xds:///helloworld-gke:8000"
come URI di servizio e porta../client "world" xds:///helloworld-gke:8000
C++
Per verificare il servizio con un client gRPC C++:
Scarica l'ultima versione di gRPC C++, con la patch più recente e crea l'esempio di client
helloworld
.apt-get update -y apt-get install -y build-essential cmake git git clone --recurse-submodules -b v1.37.1 https://github.com/grpc/grpc cd grpc mkdir -p cmake/build pushd cmake/build cmake ../.. make make install popd mkdir -p third_party/abseil-cpp/cmake/build pushd third_party/abseil-cpp/cmake/build cmake ../.. make make install popd cd examples/cpp/helloworld mkdir -p cmake/build cd cmake/build/ cmake ../.. make
Esegui il client con "xds:///helloworld-gke:8000" come URI e porta di servizio.
./greeter_client --target=xds:///helloworld-gke:8000
grpcurl
Lo strumento grpcurl
può anche agire come client gRPC proxyless. In questo caso, grpcurl
utilizza le informazioni relative alla variabile di ambiente e al bootstrap per connettersi a Traffic Director. Poi viene a conoscenza del servizio helloworld
, che è stato configurato con Traffic Director tramite il servizio di backend grpc-gke-helloworld-service
.
Per verificare la configurazione utilizzando lo strumento grpcurl
:
Scarica e installa lo strumento
grpcurl
.curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.8.1/grpcurl_1.8.1_linux_x86_64.tar.gz | tar -xz
Esegui lo strumento
grpcurl
con "xds:///helloworld-gke:8000" come URI di servizio ehelloworld.Greeter/SayHello
come nome e metodo di servizio da richiamare. I parametri del metodoSayHello
vengono passati utilizzando l'opzione-d
../grpcurl --plaintext \ -d '{"name": "world"}' \ xds:///helloworld-gke:8000 helloworld.Greeter/SayHello
Python
Per verificare il servizio con un client Python gRPC, esegui questo comando. Utilizza l'ultima versione di gRPC con la patch più recente.
apt-get update -y apt-get install python3-pip -y pip3 install virtualenv curl -L https://github.com/grpc/grpc/archive/v1.37.1.tar.gz | tar -xz cd grpc-1.37.1/examples/python/xds virtualenv venv -p python3 source venv/bin/activate pip install -r requirements.txt python client.py xds:///helloworld-gke:8000
Ruby
Per verificare il servizio con un client Ruby gRPC, esegui il comando seguente. Utilizza l'ultima versione di gRPC con la patch più recente.
apt-get update -y apt-get install -y ruby-full gem install grpc curl -L https://github.com/grpc/grpc/archive/v1.37.1.tar.gz | tar -xz cd grpc-1.37.1/examples/ruby ruby greeter_client.rb john xds:///helloworld-gke:8000
PHP
Per verificare il servizio con un client PHP gRPC, esegui questo comando. Utilizza l'ultima versione di gRPC con la patch più recente.
apt-get update -y apt-get install -y php7.3 php7.3-dev php-pear phpunit python-all zlib1g-dev git pecl install grpc curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer curl -L https://github.com/grpc/grpc/archive/v1.37.1.tar.gz | tar -xz cd grpc-1.37.1 export CC=/usr/bin/gcc ./tools/bazel build @com_google_protobuf//:protoc ./tools/bazel build src/compiler:grpc_php_plugin cd examples/php composer install ../../bazel-bin/external/com_google_protobuf/protoc --proto_path=../protos \ --php_out=. --grpc_out=. \ --plugin=protoc-gen-grpc=../../bazel-bin/src/compiler/grpc_php_plugin \ ../protos/helloworld.proto php -d extension=grpc.so greeter_client.php john xds:///helloworld-gke:8000
Node.js
Per verificare il servizio con un client Node.js gRPC, esegui il comando seguente. Utilizza l'ultima versione di gRPC con la patch più recente.
apt-get update -y apt-get install -y nodejs npm curl -L https://github.com/grpc/grpc/archive/v1.34.0.tar.gz | tar -xz cd grpc-1.34.0/examples/node/xds npm install node ./greeter_client.js --target=xds:///helloworld-gke:8000
Dovresti vedere un output simile al seguente, dove INSTANCE_HOST_NAME
è il nome host dell'istanza VM:
Greetings: Hello world, from INSTANCE_HOST_NAME
In questo modo verifichi che il client gRPC proxyless si sia connesso correttamente a Traffic Director e abbia appreso i backend per il servizio helloworld-gke
utilizzando il resolver del nome xds. Il client ha inviato una richiesta a uno dei backend del servizio senza dover conoscere l'indirizzo IP o eseguire la risoluzione DNS.
Passaggi successivi
- Scopri di più sulla sicurezza del servizio Traffic Director.
- Scopri di più sulla Gestione avanzata del traffico.
- Scopri come configurare l'osservabilità.
- Scopri come risolvere i problemi di deployment di Traffic Director senza proxy.