Configurar la visibilidad intranodo

Autopilot Standard

---

En esta guía se explica cómo configurar la visibilidad intranodo en un clúster de Google Kubernetes Engine (GKE).

La visibilidad intranodo configura la red de cada nodo del clúster para que la red de nube privada virtual (VPC) del clúster procese el tráfico enviado de un pod a otro, aunque los pods estén en el mismo nodo.

La visibilidad intranodo está inhabilitada de forma predeterminada en los clústeres estándar y habilitada de forma predeterminada en los clústeres de Autopilot.

Arquitectura

La visibilidad intranodo asegura que la red de VPC siempre procese los paquetes enviados entre pods, lo que garantiza que las reglas de cortafuegos, las rutas, los registros de flujo y las configuraciones de creación de réplicas de paquetes se apliquen a los paquetes.

Cuando un pod envía un paquete a otro pod del mismo nodo, el paquete sale del nodo y lo procesa la Google Cloud red. A continuación, el paquete se envía inmediatamente de vuelta al mismo nodo y se reenvía al pod de destino.

La visibilidad intranodo implementa el netd DaemonSet.

Ventajas

La visibilidad intranodo ofrece las siguientes ventajas:

• Consulta los registros de flujo de todo el tráfico entre pods, incluido el tráfico entre pods del mismo nodo.
• Crea reglas de cortafuegos que se apliquen a todo el tráfico entre pods, incluido el tráfico entre pods del mismo nodo.
• Usa Replicación de paquetes para clonar el tráfico, incluido el tráfico entre pods del mismo nodo, y reenvíalo para su análisis.

Requisitos y limitaciones

La visibilidad intranodo tiene los siguientes requisitos y limitaciones:

• Tu clúster debe tener la versión 1.15 de GKE o una posterior.
• La visibilidad intranodo no se admite en grupos de nodos de Windows Server.
• Para evitar problemas de conectividad al usar la marca ip-masq-agent con la visibilidad intranodo, tu lista nonMasqueradeCIDRs personalizada debe incluir los intervalos de direcciones IP de los nodos y los pods del clúster.

Reglas de cortafuegos

Si habilitas la visibilidad intranodo, la red VPC procesa todos los paquetes enviados entre pods, incluidos los que se envían entre pods del mismo nodo. Esto significa que las reglas de cortafuegos de VPC y las políticas de cortafuegos jerárquicas se aplican de forma coherente a la comunicación entre pods, independientemente de la ubicación de los pods.

Si configuras reglas de cortafuegos personalizadas para la comunicación dentro del clúster, evalúa detenidamente las necesidades de red del clúster para determinar el conjunto de reglas de permiso de salida y de entrada. Puedes usar pruebas de conectividad para asegurarte de que no se obstruya el tráfico legítimo. Por ejemplo, la comunicación entre pods es necesaria para que funcione la política de red.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Habilitar la visibilidad intranodo en un clúster nuevo

Puedes crear un clúster con la visibilidad intranodo habilitada mediante la CLI de gcloud o la Google Cloud consola.

gcloud

Para crear un clúster de un solo nodo con la visibilidad intranodo habilitada, usa la marca --enable-intra-node-visibility:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-intra-node-visibility

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del nuevo clúster.
• CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

Consola

Para crear un clúster de un solo nodo con la visibilidad intranodo habilitada, sigue estos pasos:

1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

   Ir a Google Kubernetes Engine

2. Haz clic en Crear.

3. Introduce el nombre del clúster.

4. En el cuadro de diálogo Configurar clúster, junto a GKE Standard, haz clic en Configurar.

5. Configura el clúster según sea necesario.

6. En el panel de navegación, ve a Clúster y haz clic en Redes.

7. Selecciona la casilla Habilitar visibilidad intranodo.

8. Haz clic en Crear.

Habilitar la visibilidad intranodo en un clúster

Puedes habilitar la visibilidad intranodo en un clúster con la CLI de gcloud o la Google Cloud consola.

Cuando habilitas la visibilidad intranodo en un clúster, GKE reinicia los componentes del plano de control y de los nodos de trabajador.

gcloud

Para habilitar la visibilidad intranodo en un clúster, usa la marca --enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

Sustituye CLUSTER_NAME por el nombre de tu clúster.

Consola

Para habilitar la visibilidad intranodo en un clúster, sigue estos pasos:

1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

3. En Redes, haz clic en Editar visibilidad intranodo.

4. Selecciona la casilla Habilitar visibilidad intranodo.

5. Haz clic en Guardar cambios.

Para aplicar este cambio, es necesario volver a crear los nodos, lo que puede provocar interrupciones en las cargas de trabajo en ejecución. Para obtener información sobre este cambio concreto, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos y respetando las políticas de mantenimiento. Para obtener más información sobre las actualizaciones de nodos, consulta Planificar interrupciones de actualizaciones de nodos.

Importante: GKE respeta las políticas de mantenimiento al recrear los nodos para este cambio mediante la estrategia de actualización de nodos y depende de la disponibilidad de recursos. Inhabilitar las actualizaciones automáticas de los nodos no impide este cambio. Para aplicar los cambios a los nodos manualmente, usa la CLI de gcloud para llamar al comando gcloud container clusters upgrade y pasa la marca --cluster-version con la misma versión de GKE que ya esté ejecutando el grupo de nodos.

Inhabilitar la visibilidad intranodo

Puedes inhabilitar la visibilidad intranodo en un clúster mediante la CLI de gcloud o la Google Cloud consola.

Cuando inhabilitas la visibilidad entre nodos en un clúster, GKE reinicia los componentes del plano de control y de los nodos de trabajo.

gcloud

Para inhabilitar la visibilidad intranodo, usa la marca --no-enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

Sustituye CLUSTER_NAME por el nombre de tu clúster.

Consola

Para inhabilitar la visibilidad intranodo, sigue estos pasos:

1. Ve a la página Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

3. En Redes, haz clic en Editar visibilidad intranodo.

4. Desmarca la casilla Habilitar visibilidad intranodo.

5. Haz clic en Guardar cambios.

Para aplicar este cambio, es necesario volver a crear los nodos, lo que puede provocar interrupciones en las cargas de trabajo en ejecución. Para obtener información sobre este cambio concreto, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos y respetando las políticas de mantenimiento. Para obtener más información sobre las actualizaciones de nodos, consulta Planificar interrupciones de actualizaciones de nodos.

Importante: GKE respeta las políticas de mantenimiento al recrear los nodos para este cambio mediante la estrategia de actualización de nodos y depende de la disponibilidad de recursos. Inhabilitar las actualizaciones automáticas de los nodos no impide este cambio. Para aplicar los cambios a los nodos manualmente, usa la CLI de gcloud para llamar al comando gcloud container clusters upgrade y pasa la marca --cluster-version con la misma versión de GKE que ya esté ejecutando el grupo de nodos.

Ejercicio: verificar la visibilidad intranodo

En este ejercicio se muestran los pasos necesarios para habilitar la visibilidad intranodo y confirmar que funciona en tu clúster.

En este ejercicio, seguirás estos pasos:

1. Habilita los registros de flujo de la subred predeterminada en la región us-central1.
2. Crea un clúster de un solo nodo con la visibilidad intranodo habilitada en la zona us-central1-a.
3. Crea dos pods en tu clúster.
4. Envía una solicitud HTTP de un pod a otro.
5. Consulta la entrada del registro de flujo de la solicitud de pod a pod.

Habilitar registros de flujo

1. Habilita los registros de flujo de la subred predeterminada:

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. Verifica que la subred predeterminada tenga habilitados los registros de flujo:

   gcloud compute networks subnets describe default \
       --region=us-central1
   

   El resultado muestra que los registros de flujo están habilitados, como se indica a continuación:

   ...
   enableFlowLogs: true
   ...
   

Crear un clúster

1. Crea un clúster de un solo nodo con la visibilidad intranodo habilitada:

   gcloud container clusters create flow-log-test \
       --location=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

2. Obtén las credenciales de tu clúster:

   gcloud container clusters get-credentials flow-log-test \
       --location=us-central1-a
   

Crea dos Pods

1. Crea un Pod.

   Guarda el siguiente manifiesto en un archivo llamado pod-1.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

2. Aplica el manifiesto a tu clúster:

   kubectl apply -f pod-1.yaml
   

3. Crea un segundo pod.

   Guarda el siguiente manifiesto en un archivo llamado pod-2.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

4. Aplica el manifiesto a tu clúster:

   kubectl apply -f pod-2.yaml
   

5. Ver los pods:

   kubectl get pod pod-1 pod-2 --output wide
   

   El resultado muestra las direcciones IP de tus pods, de forma similar a lo siguiente:

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   Anota las direcciones IP de pod-1 y pod-2.

Enviar una solicitud

1. Obtén un shell del contenedor en pod-1:

   kubectl exec -it pod-1 -- sh
   

2. En tu shell, envía una solicitud a pod-2:

   curl -s POD_2_IP_ADDRESS:8080
   

   Sustituye POD_2_IP_ADDRESS por la dirección IP de pod-2.

   El resultado muestra la respuesta del contenedor que se ejecuta en pod-2.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. Escribe exit para salir de la shell y volver al entorno de línea de comandos principal.

Ver entradas de registro de flujo

Para ver una entrada de registro de flujo, usa el siguiente comando:

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

Haz los cambios siguientes:

• PROJECT_ID: tu ID de proyecto.
• POD_1_IP_ADDRESS: la dirección IP de pod-1.
• POD_2_IP_ADDRESS: la dirección IP de pod-2.

El resultado muestra una entrada de registro de flujo de una solicitud de pod-1 a pod-2. En este ejemplo, pod-1 tiene la dirección IP 10.56.0.13 y pod-2 tiene la dirección IP 10.56.0.14.

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

Limpieza

Para evitar que se te apliquen cargos no deseados en tu cuenta, sigue estos pasos para eliminar los recursos que has creado:

1. Elimina el clúster:

   gcloud container clusters delete -q flow-log-test
   

2. Inhabilita los registros de flujo de la subred predeterminada:

   gcloud compute networks subnets update default --no-enable-flow-logs
   

Siguientes pasos

• Consulta cómo controlar la comunicación entre los pods y los servicios de tu clúster creando una política de red de clúster.
• Consulta las ventajas de los clústeres nativos de VPC.