Configurar la compatibilidad con varias redes para pods

Autopilot Standard

En esta página se explica cómo habilitar varias interfaces en nodos y pods de un clúster de Google Kubernetes Engine (GKE) mediante la compatibilidad con varias redes para pods.

Antes de leer esta página, asegúrate de que conoces los conceptos generales de redes, la terminología y los conceptos específicos de esta función, así como los requisitos y las limitaciones del servicio de asistencia para varias redes de los pods.

Para obtener más información, consulta Información sobre la compatibilidad con varias redes para pods.

Requisitos y limitaciones

La compatibilidad con varias redes para pods tiene los siguientes requisitos y limitaciones:

Requisitos

• GKE Standard 1.28 o una versión posterior.
• GKE Autopilot versión 1.29.5-gke.1091000 y posteriores o versión 1.30.1-gke.1280000 y posteriores.
• La compatibilidad con varias redes para pods usa las mismas especificaciones a nivel de VM que la compatibilidad con varias NICs en Compute Engine.
• Para usar varias redes en los pods, se necesita GKE Dataplane V2.
• La compatibilidad con varias redes para pods está disponible en Container-Optimized OS. La asistencia para Ubuntu está disponible en los nodos que ejecutan la versión 1.32.3-gke.1785000 de GKE o una posterior.

Limitaciones generales

• La compatibilidad con varias redes para pods no funciona en clústeres en los que se haya habilitado la red de pila dual.
• La VPC compartida solo se admite en GKE 1.28 o versiones posteriores.
• CIDR de varios pods solo se admite en GKE 1.29 o versiones posteriores, y solo para la red de pods predeterminada.
• Las redes de pods de un mismo clúster de GKE no pueden tener intervalos CIDR superpuestos.
• Cuando habilitas la compatibilidad con varias redes para pods, no puedes añadir ni quitar interfaces de red de nodos ni redes de pods después de crear un grupo de nodos. Para cambiar estos ajustes, debes volver a crear el grupo de nodos.
• De forma predeterminada, no se puede acceder a Internet desde las interfaces adicionales de las redes de pods dentro del pod. Sin embargo, puedes habilitarlo manualmente con Cloud NAT.
• No puedes cambiar la pasarela predeterminada de un pod con varias interfaces a través de la API. La pasarela predeterminada debe estar conectada a la red de pods predeterminada.
• La red de pods predeterminada siempre debe incluirse en los pods, aunque crees redes o interfaces de pods adicionales.
• No puedes configurar la función de varias redes cuando se ha configurado Managed Hubble.
• Para usar una VPC compartida, asegúrate de que tu clúster de GKE tenga la versión 1.28.4 o una posterior.
• En las implementaciones de VPC compartida, todas las interfaces de red (NICs) conectadas a los nodos deben pertenecer al mismo proyecto que el proyecto host.
• El nombre de los objetos de red de tipo de dispositivo no puede tener más de 41 caracteres. Se compone la ruta completa de cada socket de dominio UNIX, incluido el nombre de red correspondiente. Linux tiene una limitación en la longitud de las rutas de sockets (menos de 107 bytes). Teniendo en cuenta el directorio, el prefijo del nombre de archivo y la extensión .sock, el nombre de la red puede tener un máximo de 41 caracteres.
• No puedes mutar objetos Network y GKENetworkParamSet. Para actualizar estos objetos, elimínelos y vuelva a crearlos.

Limitaciones del kit de desarrollo de planos de datos y dispositivos (DPDK)

• Una NIC de VM transferida a un pod como una NIC de tipo Device no está disponible para otros pods del mismo nodo.
• Los pods que usan el modo DPDK deben ejecutarse en modo con privilegios para acceder a los dispositivos VFIO.
• El modo Autopilot no admite DPDK.
• En el modo DPDK, un dispositivo se trata como un recurso de nodo y solo se adjunta al primer contenedor (no init) del pod. Si quieres dividir varios dispositivos DPDK entre contenedores del mismo pod, debes ejecutar esos contenedores en pods independientes.
• En los nodos de Ubuntu, las redes DPDK-VFIO solo se admiten en GKE 1.33.1-gke.1959000 y versiones posteriores.

Limitaciones de escalado

GKE proporciona una arquitectura de red flexible que te permite escalar tu clúster. Puedes añadir redes de nodos y redes de pods adicionales a tu clúster. Puedes escalar tu clúster de la siguiente manera:

• Puedes añadir hasta 8 redes de nodos adicionales a cada grupo de nodos de GKE. Este es el mismo límite de escalado para las máquinas virtuales de Compute Engine.
• Cada pod debe tener menos de 8 redes adicionales asociadas.
• Puedes configurar hasta 35 Pod-networks en las 8 node-networks de un solo grupo de nodos. Puedes desglosarlo en diferentes combinaciones, como las siguientes:
  • 7 redes de nodos con 5 redes de pods cada una
  • 5 redes de nodos con 7 redes de pods cada una
  • 1 red de nodos con 30 redes de pods. El límite de intervalos secundarios por subred es de 30.
• Puedes configurar hasta 50 redes de pods por clúster.
• Puedes configurar hasta un máximo de 32 pods de varias redes por nodo.
• Puedes tener hasta 5000 nodos con varias interfaces.
• Puedes tener hasta 100.000 interfaces adicionales en todos los Pods.

Desplegar pods de varias redes

Para implementar pods de varias redes, haz lo siguiente:

1. Prepara una VPC adicional, una subred (red de nodos) y rangos secundarios (red de pods).
2. Crea un clúster de GKE con varias redes con el comando de la CLI de Google Cloud.
3. Crea un grupo de nodos de GKE que esté conectado a la red de nodos y a la red de pods adicionales mediante el comando de la CLI de Google Cloud.
4. Crea una red de pods y haz referencia a la VPC, la subred y los intervalos secundarios correctos en objetos de varias redes mediante la API de Kubernetes.
5. En la configuración de tu carga de trabajo, hace referencia al objeto de Kubernetes Network preparado mediante la API de Kubernetes.

Antes de empezar

Antes de empezar, asegúrate de que has 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.

• Consulta los requisitos y las limitaciones.

Preparar una VPC adicional

Google Cloud crea una red de pods predeterminada durante la creación del clúster asociada al grupo de nodos de GKE utilizado durante la creación inicial del clúster de GKE. La red de pods predeterminada está disponible en todos los nodos y pods del clúster. Para facilitar las funciones de varias redes en el pool de nodos, debes preparar las VPCs que ya tengas o crear otras nuevas que admitan redes de tipo Layer 3 y Device.

Para preparar una VPC adicional, ten en cuenta los siguientes requisitos:

• Redes de tipo Layer 3 y Netdevice:

  • Crea un intervalo secundario si usas redes de tipo Layer 3.
  • Asegúrate de que el tamaño de CIDR del intervalo secundario sea lo suficientemente grande como para satisfacer el número de nodos del grupo de nodos y el número de pods por nodo que quieras tener.
  • Al igual que la red de pods predeterminada, las demás redes de pods usan el aprovisionamiento excesivo de direcciones IP. El intervalo de direcciones IP secundario debe tener el doble de direcciones IP por nodo que el número de pods por nodo.

• Requisitos de la red de tipo Device: crea una subred normal en una VPC. No necesitas una subred secundaria.

Para habilitar las funciones de varias redes en el pool de nodos, debes preparar las VPCs a las que quieras establecer conexiones adicionales. Puedes usar una VPC que ya tengas o crear una específicamente para el grupo de nodos.

Nota: Una vez creado el pool de nodos, no puedes añadir una VPC para conectarte al pool de nodos.

Crear una red VPC que admita dispositivos de tipo Layer 3

Para crear una red de VPC que admita dispositivos de tipo Layer 3, haz lo siguiente:

• Asegúrate de que el tamaño de CIDR del intervalo secundario sea lo suficientemente grande como para satisfacer el número de nodos del grupo de nodos y el número de pods por nodo que quieras tener.

• Al igual que la red de pods predeterminada, las demás redes de pods usan el aprovisionamiento excesivo de direcciones IP. El intervalo de direcciones IP secundarias debe tener el doble de direcciones IP por nodo que el número de pods por nodo.

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Haz los cambios siguientes:

• SUBNET_NAME: el nombre de la subred.
• PROJECT_ID: el ID del proyecto que contiene la red VPC en la que se crea la subred.
• SUBNET_RANGE: el intervalo de direcciones IPv4 principal de la nueva subred, en notación CIDR.
• NETWORK_NAME: el nombre de la red VPC que contiene la nueva subred.
• REGION: la región en la que se crea la nueva subred. Google Cloud
• SECONDARY_RANGE_NAME: el nombre del intervalo secundario.
• SECONDARY_IP_RANGE el intervalo de direcciones IPv4 secundario en notación CIDR.

Consola

1. En la Google Cloud consola, ve a la página Redes de VPC.

2. Haz clic en Crear red VPC.

3. En el campo Nombre, introduce el nombre de la red. Por ejemplo, l3-vpc.

4. En el menú desplegable Unidad máxima de transmisión (MTU), elija el valor de MTU adecuado.

   Nota: Antes de definir la MTU en un valor superior a 1460, consulta la unidad máxima de transmisión
   .

5. En la sección Modo de creación de subred, elige Personalizado.

6. Haz clic en AÑADIR SUBNET.

7. En la sección Nueva subred, especifica los siguientes parámetros de configuración de una subred:

   1. Asígnele un nombre. Por ejemplo, l3-subnet.

   2. Selecciona una región.

   3. Introduce un intervalo de direcciones IP. Este es el intervalo IPv4 principal de la subred.

      Si seleccionas un intervalo que no es una dirección RFC 1918, confirma que no entra en conflicto con una configuración ya establecida. Para obtener más información, consulta Intervalos de subred IPv4.

   4. Para definir un intervalo secundario para la subred, haz clic en Crear intervalo de direcciones IP secundario.

      Si seleccionas un intervalo que no es una dirección RFC 1918, confirma que no entra en conflicto con una configuración ya establecida. Para obtener más información, consulta Intervalos de subred IPv4.

   5. Acceso privado de Google: puedes habilitar el acceso privado de Google en la subred al crearla o más adelante editándola.

   6. Registros de flujo: puedes habilitar los registros de flujo de VPC de la subred al crearla o más adelante editándola.

   7. Haz clic en Listo.

   Nota: Para añadir más subredes, haz clic en Añadir subred. También puedes añadir más subredes a la red después de crearla.

8. En la sección Reglas de cortafuegos, vaya a Reglas de cortafuegos IPv4 y seleccione cero o más reglas de cortafuegos predefinidas.

   Las reglas abordan casos prácticos habituales de conectividad a instancias. Puedes crear tus propias reglas de cortafuegos después de crear la red. Cada nombre de regla predefinida empieza por el nombre de la red de VPC que estás creando.

9. En Reglas de cortafuegos IPv4, para editar la regla de cortafuegos de entrada predefinida llamada allow-custom, haz clic en EDITAR.

   Puede editar subredes, añadir intervalos de IPv4 y especificar protocolos y puertos.

   La regla de cortafuegos allow-custom no se actualiza automáticamente si añades subredes más adelante. Si necesitas reglas de cortafuegos para las nuevas subredes, debes actualizar la configuración del cortafuegos para añadir las reglas.

10. En la sección Modo de enrutamiento dinámico de la red de VPC. Para obtener más información, consulta el artículo sobre el modo de enrutamiento dinámico. Puedes cambiar el modo de enrutamiento dinámico más adelante.

11. Haz clic en Crear.

Crear una red de VPC que admita dispositivos de tipo Netdevice o DPDK

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Haz los cambios siguientes:

• SUBNET_NAME: el nombre de la subred.
• PROJECT_ID: el ID del proyecto que contiene la red VPC en la que se crea la subred.
• SUBNET_RANGE: el intervalo de direcciones IPv4 principal de la nueva subred, en notación CIDR.
• NETWORK_NAME: el nombre de la red VPC que contiene la nueva subred.
• REGION: la región en la que se crea la nueva subred. Google Cloud
• SECONDARY_RANGE_NAME: el nombre del intervalo secundario.
• SECONDARY_IP_RANGE el intervalo de direcciones IPv4 secundario en notación CIDR.

Consola

1. En la Google Cloud consola, ve a la página Redes de VPC.

2. Haz clic en Crear red VPC.

3. En el campo Nombre, introduce el nombre de la red. Por ejemplo, netdevice-vpc o dpdk-vpc.

4. En el menú desplegable Unidad máxima de transmisión (MTU), elija el valor de MTU adecuado.

   Nota: Antes de definir la MTU en un valor superior a 1460, consulta la sección Unidad máxima de transmisión.

5. En la sección Modo de creación de subred, elige Personalizado.

6. En la sección Nueva subred, especifica los siguientes parámetros de configuración de una subred:

   1. Asígnele un nombre. Por ejemplo, netdevice-subnet o dpdk-vpc.

   2. Selecciona una región.

   3. Introduce un intervalo de direcciones IP. Este es el intervalo IPv4 principal de la subred.

      Si seleccionas un intervalo que no es una dirección RFC 1918, confirma que no entra en conflicto con una configuración ya establecida. Para obtener más información, consulta Intervalos de subred IPv4.

   4. Acceso privado de Google: elige si quieres habilitar el Acceso privado de Google en la subred al crearla o más adelante editándola.

   5. Registros de flujo: puedes habilitar los registros de flujo de VPC de la subred al crearla o más adelante editándola.

   6. Haz clic en Listo.

      Nota: Para añadir más subredes, haz clic en Añadir subred. También puedes añadir más subredes a la red después de crearla.

7. En la sección Reglas de cortafuegos, vaya a Reglas de cortafuegos IPv4 y seleccione cero o más reglas de cortafuegos predefinidas.

   Las reglas abordan casos prácticos habituales de conectividad a instancias. Puedes crear tus propias reglas de cortafuegos después de crear la red. Cada nombre de regla predefinida empieza por el nombre de la red de VPC que estás creando.

8. En Reglas de cortafuegos IPv4, para editar la regla de cortafuegos de entrada predefinida llamada allow-custom, haz clic en EDITAR.

   Puede editar subredes, añadir intervalos de IPv4 y especificar protocolos y puertos.

   La regla de cortafuegos allow-custom no se actualiza automáticamente si añades subredes más adelante. Si necesitas reglas de cortafuegos para las nuevas subredes, debes actualizar la configuración del cortafuegos para añadir las reglas.

9. En la sección Modo de enrutamiento dinámico de la red de VPC. Para obtener más información, consulta el artículo sobre el modo de enrutamiento dinámico. Puedes cambiar el modo de enrutamiento dinámico más adelante.

10. Haz clic en Crear.

Crear un clúster de GKE con funciones de varias redes

Al habilitar la función de multirred en un clúster, se añaden las CustomResourceDefinitions (CRDs) necesarias al servidor de la API de ese clúster. También implementa un gestor de controladores de red, que se encarga de conciliar y gestionar objetos de varias redes. No puedes modificar la configuración del clúster después de crearlo.

Crear un clúster de Autopilot de GKE con funciones de varias redes

Crea un clúster de Autopilot de GKE con funciones de varias redes:

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-multi-networking

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• CLUSTER_VERSION: la versión del clúster.

La marca --enable-multi-networking habilita las definiciones de recursos personalizados (CRDs) de varias redes en el servidor de la API de este clúster e implementa un network-controller-manager que contiene la reconciliación y la gestión del ciclo de vida de los objetos de varias redes.

Crear un clúster estándar de GKE con funciones de varias redes

gcloud

Crea un clúster estándar de GKE con funciones de varias redes:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• CLUSTER_VERSION: la versión del clúster.

Este comando incluye las siguientes marcas:

• --enable-multi-networking: habilita las definiciones de recursos personalizados (CRDs) de redes múltiples en el servidor de la API de este clúster e implementa un network-controller-manager que contiene la reconciliación y la gestión del ciclo de vida de los objetos de redes múltiples.
• --enable-dataplane-v2: habilita GKE Dataplane V2. Esta marca es obligatoria para habilitar varias redes.

Consola

1. En la Google Cloud consola, ve a la página Crear un clúster de Kubernetes.

   Ir a Crear un clúster de Kubernetes

2. Configura tu clúster estándar. Para obtener más información, consulta Crear un clúster zonal o Crear un clúster regional. Al crear el clúster, selecciona la red y la subred de nodos adecuadas.
3. En el panel de navegación, ve a Clúster y haz clic en Redes.
4. Marca la casilla Habilitar Dataplane V2.
5. Selecciona Habilitar la opción de usar varias redes.
6. Haz clic en Crear.

Crear un grupo de nodos de GKE Standard conectado a VPCs adicionales

Crea un grupo de nodos que incluya nodos conectados a la red de nodos (VPC y subred) y a la red de pods (intervalo secundario) creadas en Crear red de pods.

Para crear el nuevo grupo de nodos y asociarlo a las redes adicionales del clúster de GKE, sigue estos pasos:

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Haz los cambios siguientes:

• POOL_NAME con el nombre del nuevo grupo de nodos.
• CLUSTER_NAME con el nombre del clúster al que vas a añadir el grupo de nodos.
• NETWORK_NAME con el nombre de la red a la que se van a adjuntar los nodos del grupo de nodos.
• SUBNET_NAME con el nombre de la subred de la red que se va a usar para los nodos.
• POD_IP_RANGE el intervalo de direcciones IP de pods de la subred.
• Número máximo de pods por nodo: NUMBER_OF_PODS.

Este comando contiene las siguientes marcas:

• --additional-node-network: define los detalles de la interfaz de red, la red y la subred adicionales. Se usa para especificar las redes de nodos para conectarse a los nodos del grupo de nodos. Especifica este parámetro cuando quieras conectarte a otra VPC. Si no especifica este parámetro, se usará la VPC predeterminada asociada al clúster. En las redes de tipo Layer 3, especifica la marca additional-pod-network que define la red de pods, que se expone en el clúster de GKE como objeto Network. Cuando se usa la marca --additional-node-network, se deben proporcionar una red y una subred como parámetros obligatorios. Asegúrate de separar los valores de red y subred con una coma y de no usar espacios.
• --additional-pod-network: especifica los detalles del intervalo secundario que se va a usar en la red de pods. Este parámetro no es obligatorio si usa una red de tipo Device. Este argumento especifica los siguientes valores de clave: subnetwork, pod-ipv4-range y max-pods-per-node. Cuando uses --additional-pod-network, debes proporcionar los valores pod-ipv4-range y max-pods-per-node, separados por comas y sin espacios.
  • subnetwork: vincula la red de nodos con la red de pods. La subred es opcional. Si no lo especifica, la red de pods adicional se asociará a la subred predeterminada proporcionada durante la creación del clúster.
  • --max-pods-per-node: se debe especificar max-pods-per-node y debe ser una potencia de 2. El valor mínimo es 4. El valor de max-pods-per-node no debe ser superior al valor de max-pods-per-node del grupo de nodos.

Consola

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

   Ir a Google Kubernetes Engine

2. En el panel de navegación, haga clic en Clusters.

3. En la sección Clústeres de Kubernetes, haz clic en el clúster que has creado.

4. En la parte superior de la página, haz clic en Añadir grupo de nodos para crear el grupo de nodos.

5. En la sección Detalles del grupo de nodos, haz lo siguiente:

   1. Introduce un nombre para el grupo de nodos.
   2. Introduce el Número de nodos que quieras crear en el grupo de nodos.

6. En el panel de navegación, ve a Grupos de nodos y haz clic en Nodos.

   1. En la lista desplegable Tipo de imagen, selecciona la imagen de nodo Container-Optimized OS con containerd (cos_containerd).

      Advertencia: En la versión 1.24 de GKE y posteriores, no se admiten los tipos de imágenes de nodo basados en Docker. En la versión 1.23 de GKE, tampoco puedes crear grupos de nodos con tipos de imagen de nodo de Docker. Debes migrar a un tipo de imagen de nodo de containerd. Para obtener más información sobre este cambio, consulta el artículo Acerca de la discontinuación de la imagen de nodo de Docker.

7. Cuando creas una máquina virtual, seleccionas un tipo de máquina de una familia de máquinas que determina los recursos disponibles para esa máquina virtual. Por ejemplo, un tipo de máquina como e2-standard-4 contiene 4 vCPUs, por lo que puede admitir hasta 4 VPCs en total. Puedes elegir entre varias familias de máquinas, y cada familia se organiza en series de máquinas y tipos de máquinas predefinidos o personalizados dentro de cada serie. Cada tipo de máquina se factura de forma diferente. Para obtener más información, consulta la hoja de precios de los tipos de máquinas.

8. En el panel de navegación, selecciona Redes.

9. En la sección Red de nodos, especifica el número máximo de pods por nodo. En la sección Redes de nodos se muestra la red de VPC utilizada para crear el clúster. Es necesario designar redes de nodos adicionales que se correspondan con las redes de VPC y los tipos de dispositivo establecidos anteriormente.

10. Crea una asociación de grupo de nodos:

    1. Para dispositivos de tipo Layer 3:
       1. En la sección Redes de nodos, haz clic en AÑADIR UNA RED DE NODOS.
       2. En la lista desplegable de redes, selecciona la VPC que admite dispositivos de tipo Capa 3.
       3. Selecciona la subred creada para la VPC Layer 3.
       4. En la sección Intervalos de direcciones IP de alias de pods, haz clic en Añadir intervalo de direcciones IP de pods.
       5. Selecciona la Subred secundaria e indica el Número máximo de pods por nodo.
       6. Selecciona Hecho.
    2. Para dispositivos de tipo Netdevice y DPDK:
       1. En la sección Redes de nodos, haz clic en AÑADIR UNA RED DE NODOS.
       2. En la lista desplegable de redes, selecciona la VPC que admita dispositivos de tipo Netdevice o DPDK.
       3. Selecciona la subred creada para la VPC Netdevice o DPDK.
       4. Selecciona Hecho.

11. Haz clic en Crear.

Notas:

• Si se especifican varias redes de pods adicionales en la misma red de nodos, deben estar en la misma subred.
• No puedes hacer referencia a la misma subred secundaria varias veces.

Ejemplo En el siguiente ejemplo se crea un grupo de nodos llamado pool-multi-net que adjunta dos redes adicionales a los nodos: datapalane (red de tipo Layer 3) y highperformance (red de tipo netdevice). En este ejemplo se da por hecho que ya has creado un clúster de GKE llamado cluster-1:

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --location us-central1-c \
  --additional-node-network network=dataplane,subnetwork=subnet-dp \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Para especificar interfaces de red de nodos y de pods adicionales, define los parámetros --additional-node-network y --additional-pod-network varias veces, como se muestra en el siguiente ejemplo:

--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4

Para especificar redes de pods adicionales directamente en la interfaz de VPC principal del grupo de nodos, como se muestra en el siguiente ejemplo:

--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8

Crear red de Pod

Define las redes de pods a las que accederán los pods definiendo objetos de Kubernetes y vinculándolos a los recursos de Compute Engine correspondientes, como VPCs, subredes y rangos secundarios.

Para crear una red de pods, debes definir los objetos CRD de Network en el clúster.

Configurar una red de VPC de Layer 3

YAML

En la Layer 3 VPC, cree los objetos Network y GKENetworkParamSet:

1. Guarda el siguiente archivo de manifiesto de ejemplo como blue-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: blue-network
   spec:
     type: "L3"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "l3-vpc"
   

   El manifiesto define un recurso Network llamado blue-network del tipo Layer 3. El objeto Network hace referencia al objeto GKENetworkParamSet llamado l3-vpc, que asocia una red con recursos de Compute Engine.

2. Aplica el manifiesto al clúster:

   kubectl apply -f blue-network.yaml
   

3. Guarda el siguiente manifiesto como l3-vpc.yaml :

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: "l3-vpc"
   spec:
     vpc: "l3-vpc"
     vpcSubnet: "subnet-dp"
     podIPv4Ranges:
       rangeNames:
       - "sec-range-blue"
   

   Este manifiesto define el objeto GKENetworkParamSet llamado l3-vpc. Para ello, se asigna el nombre de la VPC como l3-vpc, el nombre de la subred como subnet-dp y el intervalo de direcciones IPv4 secundario de los pods como sec-range-blue.

4. Aplica el manifiesto al clúster:

   kubectl apply -f l3-vpc.yaml
   

Consola

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

   Ir a Google Kubernetes Engine

2. En el panel de navegación, haga clic en Network Function Optimizer.

3. En la parte superior de la página, haz clic en Crear para crear tu red Pod.

4. En la sección Antes de empezar, comprueba los detalles.

5. Haz clic en SIGUIENTE: UBICACIÓN DE LA RED DE PODS.

6. En la sección Ubicación de la red de pods, en el menú desplegable Clúster, selecciona el clúster de GKE que tenga habilitadas las opciones de multirred y GKE Dataplane V2.

7. Haz clic en SIGUIENTE: REFERENCIA DE RED DE VPC.

8. En la sección Referencia de red de VPC, selecciona la red de VPC que se va a usar para los pods Layer 3 multinic en el desplegable Referencia de red de VPC.

9. Haz clic en SIGUIENTE: TIPO DE RED DE PODS.

10. En la sección Tipo de red de pod, selecciona L3 e introduce el nombre de la red de pod.

11. Haz clic en SIGUIENTE: RANGO SECUNDARIO DE RED DE PODS.

12. En la sección Intervalo secundario de la red de pods, introduce el Intervalo secundario.

13. Haz clic en SIGUIENTE: RUTAS DE RED DE PODS.

14. En la sección Rutas de red de pods, para definir Rutas personalizadas, selecciona AÑADIR RUTA.

15. Haz clic en CREAR RED DE PODS.

Configurar la red DPDK

YAML

En el caso de la VPC de DPDK, crea objetos Network y GKENetworkParamSet.

1. Guarda el siguiente archivo de manifiesto de ejemplo como dpdk-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: dpdk-network
   spec:
     type: "Device"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "dpdk"
   

   Este manifiesto define un recurso Network llamado dpdk-network de tipo Device. El recurso Network hace referencia a un objeto GKENetworkParamSet llamado dpdk para su configuración.

2. Aplica el manifiesto al clúster:

   kubectl apply -f dpdk-network.yaml
   

3. En el objeto GKENetworkParamSet, guarda el siguiente manifiesto como dpdk.yaml:

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: "dpdk"
   spec:
     vpc: "dpdk"
     vpcSubnet: "subnet-dpdk"
     deviceMode: "DPDK-VFIO"
   

   Este manifiesto define el objeto GKENetworkParamSet llamado dpdk, establece el nombre de VPC como dpdk, el nombre de subred como subnet-dpdk y el nombre de deviceMode como DPDK-VFIO.

4. Aplica el manifiesto al clúster:

   kubectl apply -f dpdk-network.yaml
   

Consola

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

   Ir a Google Kubernetes Engine

2. En el panel de navegación, haga clic en Network Function Optimizer.

3. En la parte superior de la página, haz clic en Crear para crear tu red Pod.

4. En la sección Antes de empezar, comprueba los detalles.

5. Haz clic en SIGUIENTE: UBICACIÓN DE LA RED DE PODS.

6. En la sección Ubicación de la red de pods, en el menú desplegable Clúster, selecciona el clúster de GKE que tenga habilitadas las opciones de multirred y GKE Dataplane V2.

7. Haz clic en SIGUIENTE: REFERENCIA DE RED DE VPC.

8. En la sección Referencia de red de VPC, en el desplegable Referencia de red de VPC, selecciona la red de VPC que se usa para los pods multinic de dpdk.

9. Haz clic en SIGUIENTE: TIPO DE RED DE PODS.

10. En la sección Tipo de red de pod, selecciona DPDK-VFIO (Dispositivo) e introduce el nombre de la red de pod.

11. Haz clic en SIGUIENTE: RANGO SECUNDARIO DE RED DE PODS. La sección de intervalo secundario de la red de pods no estará disponible

12. Haz clic en SIGUIENTE: RUTAS DE RED DE PODS. En la sección Rutas de red de pods, seleccione AÑADIR RUTA para definir rutas personalizadas.

13. Haz clic en CREAR RED DE PODS.

Nota: En la red DPDK, la NIC está vinculada al controlador VFIO, que no se mostrará como un dispositivo de red normal del kernel en ip link.

Configurar la red de dispositivos de red

En la VPC netdevice, crea objetos Network y GKENetworkParamSet.

YAML

1. Guarda el siguiente archivo de manifiesto de ejemplo como netdevice-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
       name: netdevice-network
   spec:
       type: "Device"
       parametersRef:
         group: networking.gke.io
         kind: GKENetworkParamSet
         name: "netdevice"
   

   Este manifiesto define un recurso Network llamado netdevice-network con el tipo Device. Hace referencia al objeto GKENetworkParamSet llamado netdevice.

2. Aplica el manifiesto al clúster:

   kubectl apply -f netdevice-network.yaml
   

3. Guarda el siguiente manifiesto como netdevice.yaml :

   apiVersion: networking.gke.io/v1
   kind: GKENetworkParamSet
   metadata:
     name: netdevice
   spec:
     vpc: netdevice
     vpcSubnet: subnet-netdevice
     deviceMode: NetDevice
   

   Este manifiesto define un recurso GKENetworkParamSet llamado netdevice, establece el nombre de la VPC como netdevice, el nombre de la subred como subnet-netdevice y especifica el modo del dispositivo como NetDevice.

4. Aplica el manifiesto al clúster:

   kubectl apply -f netdevice.yaml
   

Consola

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

   Ir a Google Kubernetes Engine

2. En el panel de navegación, haga clic en Network Function Optimizer.

3. En la parte superior de la página, haz clic en Crear para crear tu red Pod.

4. En la sección Antes de empezar, comprueba los detalles.

5. Haz clic en SIGUIENTE: UBICACIÓN DE LA RED DE PODS.

6. En la sección Ubicación de la red de pods, en el menú desplegable Clúster, selecciona el clúster de GKE que tenga habilitadas las opciones de multirred y GKE Dataplane V2.

7. Haz clic en SIGUIENTE: REFERENCIA DE RED DE VPC.

8. En la sección Referencia de red de VPC, en el menú desplegable Referencia de red de VPC, selecciona la red de VPC que se usa para los pods multinic de netdevice.

9. Haz clic en SIGUIENTE: TIPO DE RED DE PODS.

10. En la sección Tipo de red de pod, selecciona NetDevice (Dispositivo) e introduce el nombre de la red de pod.

11. Haz clic en SIGUIENTE: RANGO SECUNDARIO DE RED DE PODS. La sección de intervalo secundario de la red de pods no estará disponible

12. Haz clic en SIGUIENTE: RUTAS DE RED DE PODS. En la sección Rutas de red de pods, para definir rutas personalizadas, selecciona AÑADIR RUTA.

13. Haz clic en CREAR RED DE PODS.

Configurar rutas de red

Configurar una ruta de red te permite definir rutas personalizadas para una red específica, que se configuran en los pods para dirigir el tráfico a la interfaz correspondiente del pod.

YAML

1. Guarda el siguiente archivo de manifiesto como red-network.yaml:

   apiVersion: networking.gke.io/v1
   kind: Network
   metadata:
     name: red-network
   spec:
     type: "L3"
     parametersRef:
       group: networking.gke.io
       kind: GKENetworkParamSet
       name: "management"
     routes:
     -   to: "10.0.2.0/28"
   

   Este manifiesto define un recurso de red llamado red-network con un tipo de Layer 3 y una ruta personalizada "10.0.2.0/28" a través de esa interfaz de red.

2. Aplica el manifiesto al clúster:

   kubectl apply -f red-network.yaml
   

Consola

1. Ve a la página Network Function Optimizer de la Google Cloud consola.

   Ir a Network Function Optimizer

2. Haz clic en Crear.

3. Selecciona un clúster que tenga habilitada la función de multirred.

4. Configura las preferencias de red.

5. Haz clic en Crear red Pod.

Consulta el Networkpreparado

En la configuración de tu carga de trabajo, haz referencia al objeto de Network Kubernetes preparado mediante la API de Kubernetes.

Conectar un Pod a redes específicas

Para conectar pods a las redes especificadas, debe incluir los nombres de los objetos Network como anotaciones en la configuración del pod. Asegúrate de incluir tanto default Network como las redes adicionales seleccionadas en las anotaciones para establecer las conexiones.

1. Guarda el siguiente archivo de manifiesto de ejemplo como sample-l3-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"}
         ]
   spec:
     containers:
     - name: sample-l3-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   Este manifiesto crea un pod llamado sample-l3-pod con dos interfaces de red, eth0 y eth1, asociadas a las redes default y blue-network, respectivamente.

2. Aplica el manifiesto al clúster:

   kubectl apply -f sample-l3-pod.yaml
   

Conectar un Pod a varias redes

1. Guarda el siguiente archivo de manifiesto de ejemplo como sample-l3-netdevice-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-netdevice-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"},
           {"interfaceName":"eth2","network":"netdevice-network"}
         ]
   spec:
     containers:
     - name: sample-l3-netdevice-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   Este manifiesto crea un pod llamado sample-l3-netdevice-pod con tres interfaces de red, eth0, eth1 y eth2, asociadas a las redes default, blue-network y netdevice, respectivamente.

2. Aplica el manifiesto al clúster:

   kubectl apply -f sample-l3-netdevice-pod.yaml
   

Puedes usar la misma anotación en cualquier ReplicaSet (Deployment o DaemonSet) en la sección de anotaciones de la plantilla.

Configuración de ejemplo de un pod con varias interfaces:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
    link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
      valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
    link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.1.2/32 scope global eth1
      valid_lft forever preferred_lft forever

Verificación

• Asegúrate de crear clústeres con --enable-multi-networking solo si --enable-dataplane-v2 está habilitado.
• Verifica que todos los grupos de nodos del clúster ejecuten imágenes de Container-Optimized OS en el momento de la creación del clúster y del grupo de nodos.
• Verifica que los grupos de nodos se creen con --additional-node-network o --additional-pod-network solo si la función de multiconexión está habilitada en el clúster.
• Asegúrate de que no se especifica dos veces la misma subred como argumento --additional-node-network de un grupo de nodos.
• Verifica que el mismo intervalo secundario no se haya especificado como argumento --additional-pod-network de un pool de nodos.
• Sigue los límites de escalado especificados para los objetos de red, teniendo en cuenta el número máximo de nodos, pods y direcciones IP permitidos.
• Verifica que solo haya un objeto GKENetworkParamSet que haga referencia a una subred y a un intervalo secundario concretos.
• Verifica que cada objeto de red haga referencia a un objeto GKENetworkParamSet diferente.
• Verifica que el objeto de red, si se crea con una subred específica con la red Device, no se esté usando en el mismo nodo con otra red con un intervalo secundario. Solo puedes validar esto en el tiempo de ejecución.
• Verifica que los distintos intervalos secundarios asignados a los grupos de nodos no tengan direcciones IP superpuestas.

Solucionar problemas con los parámetros de multirred en GKE

Cuando creas un clúster y un grupo de nodos,se Google Cloud implementan determinadas comprobaciones para asegurarse de que solo se permiten parámetros de multirred válidos. De esta forma, te aseguras de que la red esté configurada correctamente para el clúster.

Nota: Cuando solucione problemas con redes de tipo Device, asegúrese de que high-perf-device-plugin y anetd estén instalados en los nodos. Además, comprueba que la etiqueta de nodo google.cloud.com/run-high-perf-daemons: "true" esté presente en los nodos. Esta etiqueta controla específicamente el high-perf-device-plugin.

A partir de la versión 1.32 de GKE, el campo high-perf-config-daemon solo es obligatorio cuando hay una red DPDK-VFIO en el nodo. Para comprobar el high-perf-config-daemon, verifica que esté presente la etiqueta del nodo cloud.google.com/run-high-perf-config-daemons: "true". La ausencia de los complementos o las etiquetas de nodo necesarios para el tipo de red específico puede indicar que la configuración está incompleta o es incorrecta.

Si no puedes crear cargas de trabajo de varias redes, puedes consultar el estado del pod y los eventos para obtener más información:

kubectl describe pods samplepod

El resultado debería ser similar al siguiente:

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   NotTriggerScaleUp  9s               cluster-autoscaler  pod didn't trigger scale-up:
  Warning  FailedScheduling   8s (x2 over 9s)  default-scheduler   0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod

A continuación, se indican los motivos generales por los que no se puede crear un pod:

• No se ha podido programar el pod porque no se cumplen los requisitos de recursos de la multiconexión de red
• No se han podido identificar las redes especificadas

Solucionar problemas de creación de redes de Kubernetes

Una vez que hayas creado una red correctamente, los nodos que deban tener acceso a la red configurada se anotarán con una anotación de estado de la red.

Para ver las anotaciones, ejecuta el siguiente comando:

kubectl describe node NODE_NAME

Sustituye NODE_NAME por el nombre del nodo.

El resultado debería ser similar al siguiente:

networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]

El resultado muestra cada red disponible en el nodo. Si el estado de la red esperado no se muestra en el nodo, haga lo siguiente:

Comprueba si el nodo puede acceder a la red

Si la red no aparece en la anotación de estado de la red del nodo:

1. Verifica que el nodo forme parte de un pool configurado para la función de multirred.
2. Comprueba las interfaces del nodo para ver si tiene una interfaz para la red que estás configurando.
3. Si a un nodo le falta el estado de la red y solo tiene una interfaz de red, debes crear un pool de nodos con la función de multirred habilitada.
4. Si tu nodo contiene la interfaz de la red que estás configurando, pero no se ve en la anotación de estado de la red, comprueba los recursos Network y GKENetworkParamSet (GNP).

Consulta los recursos Network y GKENetworkParamSet.

El estado de los recursos Network y GKENetworkParamSet (GNP) incluye un campo de condiciones para informar de los errores de configuración. Le recomendamos que compruebe primero el GNP, ya que no depende de otro recurso para ser válido.

Para inspeccionar el campo conditions, ejecuta el siguiente comando:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Sustituye GNP_NAME por el nombre del recurso GKENetworkParamSet.

Cuando la condición Ready es igual a true, la configuración es válida y el resultado es similar al siguiente:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-dp
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:38:04Z"
    message: ""
    reason: GNPReady
    status: "True"
    type: Ready
  networkName: dp-network
  podCIDRs:
    cidrBlocks:
    -   172.16.1.0/24

Cuando la condición Ready es igual a false, el resultado muestra el motivo y es similar al siguiente:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-nonexist
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:37:57Z"
    message: 'subnet: subnet-nonexist not found in VPC: dataplane'
    reason: SubnetNotFound
    status: "False"
    type: Ready
  networkName: ""

Si aparece un mensaje similar, compruebe que el GNP se haya configurado correctamente. Si ya lo está, asegúrate de que la Google Cloud configuración de red sea correcta. Después de actualizar la configuración de la red, puede que tengas que volver a crear el recurso de GNP para activar manualmente una resincronización. Google Cloud De esta forma, se evita el sondeo infinito de la Google Cloud API.

Cuando el GNP esté listo, consulta el recurso Network.

kubectl get networks NETWORK_NAME -o yaml

Sustituye NETWORK_NAME por el nombre del recurso Network.

La salida de una configuración válida es similar a la siguiente:

apiVersion: networking.gke.io/v1
kind: Network
...
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: dp-gnp
  type: L3
status:
  conditions:
  -   lastTransitionTime: "2023-06-07T19:31:42Z"
    message: ""
    reason: GNPParamsReady
    status: "True"
    type: ParamsReady
  -   lastTransitionTime: "2023-06-07T19:31:51Z"
    message: ""
    reason: NetworkReady
    status: "True"
    type: Ready

• reason: NetworkReady indica que el recurso de red está configurado correctamente. reason: NetworkReady no implica que el recurso de red esté necesariamente disponible en un nodo específico o que se esté usando de forma activa.
• Si hay un error o un problema de configuración, el campo reason de la condición especifica el motivo exacto del problema. En estos casos, ajuste la configuración en consecuencia.
• GKE rellena el campo ParamsReady si el campo parametersRef se ha definido en un recurso GKENetworkParamSet que existe en el clúster. Si has especificado un GKENetworkParamSet type parametersRef y no aparece la condición, asegúrate de que el nombre, el tipo y el grupo coincidan con el recurso GNP que hay en tu clúster.

Siguientes pasos

• Consulta cómo crear clústeres nativos de VPC.
• Codelabs
• Vídeo de demostración