Configurar pods de Google Kubernetes Engine con inserción automática de Envoy

Información general

En una malla de servicios, el código de tu aplicación no necesita conocer tu configuración de red. En su lugar, tus aplicaciones se comunican a través de un plano de datos, que está configurado por un plano de control que gestiona la red de servicios. En esta guía, Cloud Service Mesh es tu plano de control y los proxies sidecar de Envoy son tu plano de datos.

El inyector de sidecar de Envoy gestionado por Google añade proxies de sidecar de Envoy a tus pods de Google Kubernetes Engine. Cuando el inyector de sidecar de Envoy añade un proxy, también lo configura para que gestione el tráfico de la aplicación y se conecte a Cloud Service Mesh para obtener la configuración.

En esta guía se explica cómo configurar Cloud Service Mesh con Google Kubernetes Engine. Estos pasos proporcionan la base que puedes ampliar a casos prácticos avanzados, como una malla de servicios que se extienda a varios clústeres de Google Kubernetes Engine y, posiblemente, a máquinas virtuales de Compute Engine. También puedes seguir estas instrucciones si vas a configurar Cloud Service Mesh con una VPC compartida.

El proceso de configuración implica lo siguiente:

1. Crear un clúster de GKE para tus cargas de trabajo.
2. Instalar el inyector de sidecar de Envoy y habilitar la inyección.
3. Desplegar un cliente de ejemplo y verificar la inyección.
4. Desplegar un servicio de Kubernetes para realizar pruebas.
5. Configurar Cloud Service Mesh con componentes de Cloud Load Balancing para enrutar el tráfico al servicio de prueba.
6. Verificar la configuración enviando una solicitud del cliente de ejemplo al servicio de prueba.

Requisitos previos

Antes de seguir las instrucciones de esta guía, completa las tareas previas que se describen en Preparar la configuración de las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.

Para obtener información sobre la versión de Envoy compatible, consulta las notas de la versión de Cloud Service Mesh.

Requisitos previos adicionales con VPC compartida

Si vas a configurar Cloud Service Mesh en un entorno de VPC compartida, asegúrate de que se cumplan los siguientes requisitos.

• Tienes los permisos y roles correctos para la VPC compartida.
• Ha configurado los proyectos y la facturación correctos.
• Has habilitado la facturación en los proyectos.
• Has habilitado las APIs de Cloud Service Mesh y GKE en cada proyecto, incluido el proyecto host.
• Has configurado las cuentas de servicio correctas para cada proyecto.
• Has creado una red de VPC y subredes.
• Has habilitado VPC compartida.

Para obtener más información, consulta VPC compartida.

Configurar roles de gestión de identidades y accesos

En este ejemplo de configuración de roles de gestión de identidades y accesos, se presupone que el proyecto host de la VPC compartida tiene dos subredes y que hay dos proyectos de servicio en la VPC compartida.

1. En Cloud Shell, crea una carpeta de trabajo (WORKDIR)) en la que crearás los archivos asociados a esta sección:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. Configura los permisos de gestión de identidades y accesos en el proyecto del host para que los proyectos de servicio puedan usar los recursos de la VPC compartida.

   En este paso, configura los permisos de gestión de identidades y accesos para que el proyecto de servicio 1 pueda acceder a subnet-1 y el proyecto de servicio 2 pueda acceder a subnet-2. Asigna el rol de gestión de identidades y accesos Usuario de red de Compute (roles/compute.networkUser) a la cuenta de servicio predeterminada de Compute de Compute Engine y a la cuenta de servicio de la API Google Cloud en cada proyecto de servicio de cada subred.

   1. En el proyecto de servicio 1, configura los permisos de gestión de identidades y accesos para subnet-1:

      export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')
      
      cat > subnet-1-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_1_API_SA}
        - serviceAccount:${SVC_PROJECT_1_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_1_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-1 \
      subnet-1-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_1}
      

   2. En el proyecto de servicio 2, configura los permisos de gestión de identidades y accesos de subnet-2:

      export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')
      
      cat > subnet-2-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_2_API_SA}
        - serviceAccount:${SVC_PROJECT_2_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_2_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-2 \
      subnet-2-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_2}
      

3. En cada proyecto de servicio, debes conceder el rol de IAM de usuario de agente de servicio de host de Kubernetes Engine (roles/container.hostServiceAgentUser) a la cuenta de servicio de GKE en el proyecto host:

   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   
   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   

   Este rol permite que la cuenta de servicio de GKE del proyecto de servicio use la cuenta de servicio de GKE del proyecto host para configurar los recursos de red compartidos.

4. En cada proyecto de servicio, concede a la cuenta de servicio predeterminada de Compute Engine el rol de gestión de identidades y accesos Lector de red de Compute (roles/compute.networkViewer) en el proyecto host.

   gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
       --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
       --role roles/compute.networkViewer
   
   gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
       --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
       --role roles/compute.networkViewer
   

   Cuando el proxy sidecar de Envoy se conecta al servicio xDS (API de Traffic Director), el proxy usa la cuenta de servicio del host de la máquina virtual (VM) de Compute Engine o de la instancia de nodo de GKE. La cuenta de servicio debe tener el permiso de gestión de identidades y accesos a nivel de proyecto compute.globalForwardingRules.get. El rol Lector de Compute Network es suficiente para este paso.

Configurar la información del proyecto

Si aún no has creado un proyecto ni instalado Google Cloud CLI, sigue estas instrucciones. Google Cloud Si aún no has instalado kubectl, sigue estas instrucciones.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should correspond to the channel for your GKE cluster. If your GKE cluster
# does not have a specified channel, please use unspecified in this field.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

Si usas las nuevas APIs de enrutamiento de servicios, para recursos de malla, sigue estas instrucciones para definir MESH_NAME, MESH_PROJECT_NUMBER y TARGET:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

Para el recurso de pasarela, sigue estas instrucciones para definir SCOPE_NAME, SCOPE_PROJECT_NUMBER y TARGET:

# The gateway scope name of the traffic director load balancing API.
export SCOPE_NAME=YOUR_SCOPE_NAME
# The project that holds the gateway resources.
export SCOPE_PROJECT_NUMBER=YOUR_GATEWAY_PROJECT_NUMBER_HERE

export TARGET=projects/${SCOPE_PROJECT_NUMBER}/locations/global/gatewayScopes/${SCOPE_NAME}

En la mayoría de los casos, CLUSTER_PROJECT_ID y MESH_PROJECT_NUMBER hacen referencia al mismo proyecto. Sin embargo, si configuras otro proyecto, como cuando usas una VPC compartida, CLUSTER_PROJECT_ID hace referencia al ID del proyecto que contiene tu clúster de GKE y MESH_PROJECT_NUMBER hace referencia al número del proyecto que contiene los recursos. Asegúrate de que has configurado los permisos adecuados para permitir que el Envoy insertado recupere las configuraciones del

Habilitar la API Mesh Config

Habilita la siguiente API para empezar a usar el inyector de sidecar gestionado por Google.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

Crear un clúster de GKE para tus cargas de trabajo

Los clústeres de GKE deben cumplir los siguientes requisitos para admitir Cloud Service Mesh:

• Se debe habilitar la compatibilidad con grupos de puntos finales de red. Para obtener más información y ejemplos, consulta Grupos de puntos finales de red independientes.
• La cuenta de servicio de tus nodos o pods de GKE debe tener permiso para acceder a la API Traffic Director. Para obtener más información sobre los permisos necesarios, consulta Habilitar la cuenta de servicio para acceder a la API Traffic Director.

Crear el clúster de GKE

Crea un clúster de GKE en la zona que prefieras. Por ejemplo: us-central1-a.

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Dirigir kubectl al clúster recién creado

Cambia el contexto actual de kubectl al clúster que acabas de crear con el siguiente comando:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Aplica las configuraciones de Mutating Webhook

En las siguientes secciones se explica cómo aplicar el objeto MutatingWebhookConfiguration al clúster. Cuando se crea un pod, se invoca el controlador de admisión del clúster. El controlador de admisión se comunica con el inyector de sidecar gestionado para añadir el contenedor de Envoy al pod.

Aplica las siguientes configuraciones de webhook de mutación a tu clúster.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

Habilitar la inyección de sidecar

El siguiente comando habilita la inyección para el espacio de nombres default. El inyector de contenedor secundario inserta contenedores secundarios en los pods creados en este espacio de nombres:

kubectl label namespace default td-injection=enabled

Para comprobar que el espacio de nombres default está habilitado correctamente, ejecuta el siguiente comando:

kubectl get namespace -L td-injection

Debería devolver lo siguiente:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Si estás configurando la seguridad de los servicios de Cloud Service Mesh con Envoy, vuelve a la sección Configurar un servicio de prueba de esa guía de configuración.

Desplegar un cliente de ejemplo y verificar la inyección

En esta sección se muestra cómo desplegar un pod de ejemplo que ejecuta Busybox, que proporciona una interfaz sencilla para acceder a un servicio de prueba. En una implementación real, desplegarías tu propia aplicación cliente.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

El pod Busybox consta de dos contenedores. El primer contenedor es el cliente basado en la imagen de Busybox y el segundo contenedor es el proxy de Envoy insertado por el inyector de sidecar. Para obtener más información sobre el pod, ejecuta el siguiente comando:

kubectl describe pods -l run=client

Debería devolver lo siguiente:

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Proxy de Cloud Service Mesh

El inyector de sidecar gestionado usará la imagen del proxy de Cloud Service Mesh como proxy. El proxy de Cloud Service Mesh es un contenedor sidecar responsable de iniciar un proxy de Envoy para las instancias habilitadas para la malla. La imagen del proxy usa la imagen de Envoy de OSS junto con un agente de proxy responsable de iniciar Envoy, proporcionar la configuración de arranque y comprobar el estado de Envoy. Las versiones de la imagen del proxy de Cloud Service Mesh se corresponden con la versión de Envoy de OSS. Puedes hacer un seguimiento de las imágenes de proxy disponibles aquí: https://gcr.io/gke-release/asm/csm-mesh-proxy

El proxy de malla de Cloud Service Mesh que se inserta varía en función del canal que haya elegido el usuario para el clúster de GKE. La versión de Envoy se actualiza periódicamente en función de las versiones de OSS Envoy actuales y se prueba con la versión específica de GKE para asegurar la compatibilidad.

Versión del proxy de Cloud Service Mesh

En la siguiente tabla se muestra la asignación actual del canal del clúster de GKE a la versión del proxy de Cloud Service Mesh:

Actualización del proxy de Cloud Service Mesh

Te recomendamos que actualices a la versión más reciente. Aunque la malla de servicios funciona correctamente cuando el plano de control y los proxies tienen versiones diferentes, te recomendamos que actualices los proxies para que se configuren con la nueva versión de Cloud Service Mesh.

El inyector de sidecar gestionado se encarga de la versión de Envoy, que siempre inyecta la versión más reciente de Envoy cualificada por Google. Si la versión del proxy de Cloud Service Mesh es más reciente que la versión del proxy, reinicia los proxies de tus servicios.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Desplegar un servicio de Kubernetes para realizar pruebas

En las secciones siguientes se proporcionan instrucciones para configurar un servicio de prueba que usarás más adelante en esta guía para verificar la configuración de extremo a extremo.

Configurar servicios de GKE con NEGs

Los servicios de GKE deben exponerse a través de grupos de puntos finales de red (NEGs) para que puedas configurarlos como backends de un servicio de backend de Cloud Service Mesh. Añade la anotación NEG a la especificación de tu servicio de Kubernetes y elige un nombre (sustituyendo NEG-NAME en el ejemplo de abajo) para que puedas encontrarlo fácilmente más adelante. Necesitarás el nombre cuando adjuntes el NEG a tu servicio de backend de Cloud Service Mesh. Para obtener más información sobre cómo anotar NEGs, consulta Asignar nombres a NEGs.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Esta anotación crea un NEG independiente que contiene los endpoints correspondientes a las direcciones IP y los puertos de los pods del servicio. Para obtener más información y ejemplos, consulta Grupos de puntos de conexión de red independientes.

El siguiente servicio de ejemplo incluye la anotación NEG. El servicio sirve el nombre de host a través de HTTP en el puerto 80. Usa el siguiente comando para obtener el servicio e implementarlo en tu clúster de GKE.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Comprueba que se haya creado el nuevo servicio y que el pod de la aplicación se esté ejecutando:

kubectl get svc

La salida debería ser similar a la siguiente:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

Verifica que el pod de la aplicación asociado a este servicio se esté ejecutando:

kubectl get pods

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Guardar el nombre de la NEG

Busca el NEG creado en el ejemplo anterior y anota su nombre para la configuración de Cloud Service Mesh en la siguiente sección.

gcloud compute network-endpoint-groups list

Devuelve lo siguiente:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Guarda el nombre del NEG en la variable NEG_NAME:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Configurar Cloud Service Mesh con componentes de Cloud Load Balancing

En esta sección se configura Cloud Service Mesh mediante recursos de balanceo de carga de Compute Engine. De esta forma, el proxy sidecar del cliente de ejemplo puede recibir la configuración de Cloud Service Mesh. El proxy sidecar gestiona las solicitudes salientes del cliente de ejemplo y las dirige al servicio de prueba.

Debes configurar los siguientes componentes:

• Una comprobación del estado. Para obtener más información sobre las comprobaciones del estado, consulta los artículos Conceptos de comprobación del estado y Crear comprobaciones del estado.
• Un servicio de backend. Para obtener más información sobre los servicios backend, consulta Servicios backend.
• Un mapa de reglas de enrutamiento. Esto incluye la creación de una regla de reenvío, un proxy HTTP de destino y un mapa de URLs. Para obtener más información, consulta los artículos Usar reglas de reenvío en Cloud Service Mesh, Usar proxies de destino en Cloud Service Mesh y Usar mapas de URLs.

Crear la comprobación del estado y la regla de cortafuegos

Sigue estas instrucciones para crear una comprobación del estado y la regla de cortafuegos que se necesita para las sondas de comprobación del estado. Para obtener más información, consulta Reglas de cortafuegos para comprobaciones del estado.

Crear el servicio de backend

Crea un servicio de backend global con un esquema de balanceo de carga INTERNAL_SELF_MANAGED. En la consolaGoogle Cloud , el esquema de balanceo de carga se define de forma implícita. Añade la comprobación del estado al servicio de backend.

Crear el mapa de reglas de enrutamiento

El mapa de reglas de enrutamiento define cómo enruta Cloud Service Mesh el tráfico en tu malla. Como parte del mapa de reglas de enrutamiento, debes configurar una dirección IP virtual (VIP) y un conjunto de reglas de gestión del tráfico asociadas, como el enrutamiento basado en el host. Cuando una aplicación envía una solicitud a la VIP, el proxy sidecar de Envoy adjunto hace lo siguiente:

1. Intercepta la solicitud.
2. La evalúa según las reglas de gestión del tráfico del mapa de URLs.
3. Selecciona un servicio de backend en función del nombre de host de la solicitud.
4. Elige un backend o un endpoint asociado al servicio de backend seleccionado.
5. Envía tráfico a ese backend o endpoint.

En este punto, Cloud Service Mesh configura tus proxies sidecar para enrutar las solicitudes que especifican el nombre de host service-test a los backends de td-gke-service. En este caso, esos backends son puntos finales del grupo de puntos finales de red asociado al servicio de prueba de Kubernetes que has implementado anteriormente.

Verificar la configuración

En esta sección se muestra cómo verificar que el tráfico enviado desde el cliente Busybox de ejemplo se enruta a tu servicio de Kubernetes service-test. Para enviar una solicitud de prueba, puedes acceder a un shell en uno de los contenedores y ejecutar el siguiente comando de verificación. Un service-test Pod debería devolver el nombre de host del pod de servicio.

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Así se verifica la configuración:

• El cliente de ejemplo ha enviado una solicitud que especificaba el nombre de host service-test.
• El cliente de ejemplo tiene un proxy adicional de Envoy que ha inyectado el inyector adicional de Envoy.
• El proxy sidecar ha interceptado la solicitud.
• Con el mapa de URLs, Envoy ha asociado el nombre de host service-test al servicio td-gke-service de Cloud Service Mesh.
• Envoy ha elegido un endpoint del grupo de endpoints de red asociado a td-gke-service.
• Envoy ha enviado la solicitud a un pod asociado al servicio de Kubernetes service-test.

Cómo migrar a Managed Sidecar Injector

En este tutorial se explica cómo migrar una aplicación del inyector de sidecar de Cloud Service Mesh antiguo en GKE (con un inyector de sidecar en el clúster) a uno que utilice un inyector de sidecar gestionado.

Inhabilitar la inyección de sidecar en el clúster

Los siguientes comandos inhabilitan el inyector sidecar en clúster antiguo para el espacio de nombres predeterminado.

kubectl label namespace default istio-injection-

Limpiar el inyector de sidecar en el clúster

Descarga y extrae el inyector de sidecar de Envoy antiguo.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Eliminar recursos de inyectores de sidecar en el clúster

kubectl delete -f specs/

Siguientes pasos

• Información sobre la gestión avanzada del tráfico
• Consulta información sobre la seguridad de los servicios de Cloud Service Mesh.
• Consulta cómo configurar la observabilidad con Envoy.
• Consulta cómo solucionar problemas de implementaciones de Cloud Service Mesh.
• Consulta las opciones de configuración de pods de Google Kubernetes Engine con inserción automática de Envoy.