Configurar la compatibilidad con varias redes para Pods

Estándar

En esta página, se muestra cómo habilitar varias interfaces en nodos y Pods en un clúster de Google Kubernetes Engine (GKE) mediante la compatibilidad de varias redes para Pods. La compatibilidad con varias redes solo está disponible para proyectos habilitados con GKE Enterprise.

Ya deberías estar familiarizado con los conceptos generales de herramientas de redes, la terminología y los conceptos específicos de esta función y los requisitos y limitaciones a fin de obtener compatibilidad con varias redes para Pods.

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

Requisitos y limitaciones

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

Requisitos

GKE versión 1.28 o posterior.
Habilita la edición Google Kubernetes Engine (GKE) Enterprise
La compatibilidad con varias redes para Pods usa las mismas especificaciones a nivel de VM que varias NIC para Compute Engine.
La compatibilidad de varias redes para Pods requiere GKE Dataplane V2.
La compatibilidad con varias redes de Pods solo está disponible para los nodos de Container-Optimized OS que ejecutan la versión m101 o posterior.

Limitaciones generales

La compatibilidad de varias redes para Pods no funciona con clústeres que están habilitados para Herramientas de redes de pila doble.
La VPC compartida solo es compatible con la versión 1.28 de GKE o las posteriores.
El CIDR de varios Pods no está disponible para clústeres con varias redes habilitadas.
Cualquier red de Pod en un solo clúster de GKE no puede tener rangos de CIDR superpuestos.
Cuando habilitas la compatibilidad de varias redes para Pods, no puedes agregar ni quitar interfaces de red de nodos ni redes de Pods después de crear un grupo de nodos. Para cambiar esta configuración, debes volver a crear el grupo de nodos.
De forma predeterminada, el acceso a Internet no está disponible en interfaces adicionales de redes de Pods dentro del Pod. Sin embargo, puedes habilitarlo de forma manual con Cloud NAT.
No puedes cambiar la puerta de enlace predeterminada dentro de un Pod con interfaces múltiples a través de la API. La puerta de enlace predeterminada debe estar conectada a la red de Pods predeterminada.
La red de Pods predeterminada siempre debe incluirse en los Pods, incluso si creas interfaces o redes de Pods adicionales.
No puedes configurar la función de varias redes cuando se configuró el Hubble administrado.
Para usar la VPC compartida, asegúrate de que tu clúster de GKE ejecute la versión 1.28.4 o posterior.
Para las implementaciones de VPC compartida, todas las interfaces de red (NIC) conectadas a los nodos deben pertenecer al mismo proyecto que el proyecto host.

Limitaciones del dispositivo y el kit de desarrollo del plano de datos (DPDK)

Una NIC de VM que se pasa a un Pod como una NIC de tipo Device no está disponible para otros Pods en el mismo nodo.
Los Pods que usan el modo DPDK deben ejecutarse en modo privilegiado para acceder a los dispositivos de VFIO.
En el modo DPDK, un dispositivo se trata como un recurso de nodo y solo se conecta al primer contenedor (no init) del Pod. Si deseas dividir varios dispositivos de DPDK entre contenedores en el mismo Pod, debes ejecutarlos en Pods diferentes.

Limitaciones de escalamiento

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

Puedes agregar hasta 7 redes de nodos adicionales a cada grupo de nodos de GKE. Este es el mismo límite de escalamiento para las VMs de Compute Engine.
Cada Pod debe tener menos de 7 redes adicionales.
Puedes configurar hasta 35 redes de Pods en las 8 redes de nodos dentro de un solo grupo de nodos. Puedes dividirlo 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 nodo con 30 redes de Pods El límite para los rangos secundarios por subred es de 30.
Puedes configurar hasta 50 redes de Pods por clúster.
Puedes configurar hasta 32 Pods de varias redes por nodo.
Puedes tener hasta 3,000 nodos con interfaces múltiples.
Puedes tener hasta 100,000 interfaces adicionales en todos los Pods.
Puedes configurar hasta un máximo de 1,000 nodos con redes de tipo Device.
Puedes configurar hasta 4 redes de tipo Device por nodo como máximo.

Precios

Las funciones del Optimizador de funciones de red (NFO), incluida la compatibilidad con varias redes y alto rendimiento para Pods, solo se admiten en clústeres alojados en proyectos habilitados con GKE Enterprise. Para comprender los cargos que se aplican por habilitar la edición Google Kubernetes Engine (GKE) Enterprise, consulta Precios de GKE Enterprise.

Implementa Pods de varias redes

Para implementar Pods de varias redes, haz lo siguiente:

Prepara una VPC adicional , subred (red de nodos) y rangos secundarios (red de Pods).
Crea un clúster de GKE habilitado para varias redes con el comando de Google Cloud CLI.
Crea un grupo de nodos nuevo de GKE conectado a las redes adicionales de nodos y de Pods mediante el comando de Google Cloud CLI.
Crea una red de Pods y haz referencia a la VPC, la subred y los rangos secundarios correctos en objetos de varias redes mediante la API de Kubernetes.
En la configuración de la carga de trabajo, haz referencia al objeto de Kubernetes de red preparado con la API de Kubernetes.

Antes de comenzar

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

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Habilita GKE Enterprise.
Revisa los requisitos y las limitaciones.

Prepara una VPC adicional

Google Cloud crea una red de Pods predeterminada durante la creación del clúster asociada con el grupo de nodos de GKE que se usó 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 capacidades de varias redes dentro del grupo de nodos, debes preparar las VPC existentes o nuevas que admitan redes de tipo Layer 3 y Device.

Para preparar una VPC adicional, considera los siguientes requisitos:

Red de tipo Layer 3 y Netdevice:
- Crea un rango secundario si usas redes del tipo Layer 3.
- Asegúrate de que el tamaño de CIDR para el rango secundario sea lo suficientemente grande como para satisfacer la cantidad de nodos en el grupo de nodos y la cantidad de Pods por nodo que deseas tener.
- Al igual que las redes de Pods predeterminadas, las otras redes de Pods usan el aprovisionamiento excesivo de direcciones IP. El rango de direcciones IP secundario debe tener el doble de direcciones IP por nodo que la cantidad de Pods por nodo.
Requisitos de red de tipo Device: Crea una subred normal en una VPC. No necesitas una subred secundaria.

Para habilitar las capacidades de varias redes en el grupo de nodos, debes preparar las VPC a las que deseas establecer conexiones adicionales. Puedes usar una VPC existente o crear una VPC nueva específicamente para el grupo de nodos.

Crea una red de VPC que admita el dispositivo de tipo `Layer 3`

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

Asegúrate de que el tamaño de CIDR para el rango secundario sea lo suficientemente grande como para satisfacer la cantidad de nodos en el grupo de nodos y la cantidad de Pods por nodo que deseas tener.
Al igual que las redes de Pods predeterminadas, las otras redes de Pods usan el aprovisionamiento excesivo de direcciones IP. El rango de direcciones IP secundario debe tener el doble de direcciones IP por nodo que la cantidad 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>

Reemplaza lo siguiente:

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

Console

En Google Cloud Console, ve a la página Redes de VPC.
Haz clic en Crear red de VPC.
En el campo Nombre, ingresa el nombre de la red. Por ejemplo, l3-vpc
En el menú desplegable Unidad de transmisión máxima (MTU), elige el valor de MTU adecuado.

Nota: Antes de establecer la MTU en un valor superior a1460, revisa la sección Unidad de transmisión máxima.
En la sección Modo de creación de subred, elige Personalizado.
Haz clic en AGREGAR SUBRED.
En la sección Subred nueva, especifica los siguientes parámetros de configuración para una subred:
1. Proporciona un Nombre. Por ejemplo, l3-subnet
2. Selecciona una Región.
3. Ingresa un Rango de direcciones IP. Este es el rango IPv4 principal de la subred.
  
  Si seleccionas un rango que no es una dirección RFC 1918, confirma que el rango no entre en conflicto con una configuración existente. Para obtener más información, consulta Rangos de subredes IPv4.
4. Para definir un rango secundario para la subred, haz clic en Crear rango de IP secundario.
  
  Si seleccionas un rango que no es una dirección RFC 1918, confirma que el rango no entre en conflicto con una configuración existente. Para obtener más información, consulta Rangos de subredes IPv4.
5. Acceso privado a Google: Puedes habilitar el acceso privado a Google para la subred cuando la creas o la edites más adelante.
6. Registros de flujo: Puedes habilitar los registros de flujo de VPC para la subred cuando la creas o si la editas más adelante.
7. Haz clic en Listo.
Nota: Para agregar más subredes, haz clic en Agregar subred. También puedes agregar más subredes a la red después de haberla creado.
En la sección Reglas de firewall, en Reglas de firewall de IPv4, selecciona cero o más reglas de firewall predefinidas.

Las reglas abordan casos de uso comunes para la conectividad con instancias. Puedes crear tus propias reglas de firewall después de crear la red. Cada nombre de regla predefinida comienza con el nombre de la red de VPC que creas.
En Reglas de firewall IPv4, para editar la regla de firewall de entrada predefinida llamada allow-custom, haz clic en EDITAR.

Puedes editar subredes, agregar rangos IPv4 adicionales y especificar protocolos y puertos.

La regla de firewall allow-custom no se actualiza automáticamente si agregas subredes adicionales más adelante. Si necesitas reglas de firewall para las subredes nuevas, debes actualizar la configuración del firewall a fin de agregar las reglas.
En la sección Modo de enrutamiento dinámico, para la red de VPC. Para obtener más información, consulta Modo de enrutamiento dinámico. Puedes cambiar el modo de enrutamiento dinámico más adelante.
Haz clic en Crear.

Crea 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>

Reemplaza lo siguiente:

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

Console

En Google Cloud Console, ve a la página Redes de VPC.
Haz clic en Crear red de VPC.
En el campo Nombre, ingresa el nombre de la red. Por ejemplo, netdevice-vpc o dpdk-vpc.
En el menú desplegable Unidad de transmisión máxima (MTU), elige el valor de MTU adecuado.

Nota: Antes de establecer la MTU en un valor superior a1460, revisa la sección Unidad de transmisión máxima.
En la sección Modo de creación de subred, elige Personalizado.
En la sección Subred nueva, especifica los siguientes parámetros de configuración para una subred:
1. Proporciona un Nombre. Por ejemplo, netdevice-subnet o dpdk-vpc.
2. Selecciona una Región.
3. Ingresa un Rango de direcciones IP. Este es el rango IPv4 principal de la subred.
  
  Si seleccionas un rango que no es una dirección RFC 1918, confirma que el rango no entre en conflicto con una configuración existente. Para obtener más información, consulta Rangos de subredes IPv4.
4. Acceso privado a Google: Elige si quieres habilitar el Acceso privado a Google para la subred cuando la creas o si la editas más tarde.
5. Registros de flujo: Puedes habilitar los registros de flujo de VPC para la subred cuando la creas o si la editas más adelante.
6. Haz clic en Listo.
  
  Nota: Para agregar más subredes, haz clic en Agregar subred. También puedes agregar más subredes a la red después de haberla creado.
En la sección Reglas de firewall, en Reglas de firewall de IPv4, selecciona cero o más reglas de firewall predefinidas.

Las reglas abordan casos de uso comunes para la conectividad con instancias. Puedes crear tus propias reglas de firewall después de crear la red. Cada nombre de regla predefinida comienza con el nombre de la red de VPC que creas.
En Reglas de firewall IPv4, para editar la regla de firewall de entrada predefinida llamada allow-custom, haz clic en EDITAR.

Puedes editar subredes, agregar rangos IPv4 adicionales y especificar protocolos y puertos.

La regla de firewall allow-custom no se actualiza automáticamente si agregas subredes adicionales más adelante. Si necesitas reglas de firewall para las subredes nuevas, debes actualizar la configuración del firewall a fin de agregar las reglas.
En la sección Modo de enrutamiento dinámico, para la red de VPC. Para obtener más información, consulta Modo de enrutamiento dinámico. Puedes cambiar el modo de enrutamiento dinámico más adelante.
Haz clic en Crear.

Crea un clúster de GKE con capacidades de varias redes

gcloud

Crea un clúster de GKE con capacidades de varias redes:

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

Reemplaza lo siguiente:

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 (CRD) de varias redes en el servidor de la API para este clúster e implementa un administrador de controlador de red que contiene la conciliación y la administración del ciclo de vida para los objetos de varias redes.
--enable-dataplane-v2: habilita GKE Dataplane V2. Esta marca es obligatoria para habilitar varias redes.

Console

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

Ir a Google Kubernetes Engine
Haz clic en Crear.
Configura tu clúster estándar. Para obtener más información, consulta Crea un clúster zonal o Crea un clúster regional. Mientras creas el clúster, selecciona la red y la subred de nodo adecuadas.
En el panel de navegación, en Clúster, haz clic en Herramientas de redes.
Selecciona la casilla de verificación Habilitar Dataplane V2.
Selecciona Habilitar redes múltiples.
Haz clic en Crear.

Habilitar varias herramientas de redes para un clúster agrega las CustomResourceDefinitions (CRD) necesarias al servidor de la API para ese clúster. También implementa un administrador de controlador de red, que es responsable de conciliar y administrar los objetos de varias redes. No puedes modificar la configuración del clúster después de crearla.

Crea un grupo de nodos de GKE conectado a VPC adicionales

Crea un grupo de nodos que incluya nodos conectados a la red de nodos (VPC y subred) y la red de Pods (rango secundario) creada en Crea una red de Pods.

Para crear el grupo de nodos nuevo y asociarlo con las redes adicionales en el clúster de GKE, haz lo siguiente:

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

Reemplaza lo siguiente:

POOL_NAME por el nombre del grupo de nodos nuevo.
CLUSTER_NAME por el nombre del clúster existente al que agregarás el grupo de nodos.
NETWORK_NAME por el nombre de la red a la que se conectarán los nodos del grupo de nodos.
SUBNET_NAME por el nombre de la subred dentro de la red que se usará para los nodos.
POD_IP_RANGE es el rango de direcciones IP del Pod dentro de la subred.
NUMBER_OF_PODS es la cantidad máxima de Pods por nodo.

Este comando contiene las siguientes marcas:

--additional-node-network: Define los detalles de la interfaz de red, la red y la subred adicionales. Esto se usa para especificar las redes de nodos a fin de conectarse a los nodos del grupo de nodos. Especifica este parámetro cuando desees conectarte a otra VPC. Si no especificas este parámetro, se usa la VPC predeterminada asociada con el clúster. Para las redes de tipo Layer 3, especifica la marca additional-pod-network que define la red de Pod, que se expone dentro del clúster de GKE como el objeto Network. Cuando usas la marca --additional-node-network, debes proporcionar una red y una subred como parámetros obligatorios. Asegúrate de separar los valores de red y subred con una coma y evita usar espacios.
--additional-pod-network especifica los detalles del rango secundario que se usará para la red del Pod. Este parámetro no es obligatorio si usas una red de tipo Device. En este argumento, se especifican los siguientes valores 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 la especificas, la red de Pod adicional se asocia a la subred predeterminada proporcionada durante la creación del clúster.
- --max-pods-per-node: El max-pods-per-node debe especificarse y debe ser una potencia de 2. El valor mínimo es 4. El max-pods-per-node no debe ser mayor que el valor de max-pods-per-node en el grupo de nodos.

Console

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

Ir a Google Kubernetes Engine
En el panel de navegación, haz clic en Clústeres.
En la sección Clústeres de Kubernetes, haz clic en el clúster que creaste.
En la parte superior de la página, para crear el grupo de nodos, haz clic en Agregar grupo de nodos.
En la sección Detalles del grupo de nodos, completa lo siguiente:
1. Ingresa un Nombre para el grupo de nodos.
2. Ingresa la Cantidad de nodos que se crearán en el grupo.
En el panel de navegación, en Grupos de nodos, 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, los tipos de imagen de nodo basados en Docker no son compatibles. En la versión 1.23 de GKE, tampoco puedes crear grupos de nodos nuevos con tipos de imágenes 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 Acerca de la baja de la imagen de nodo de Docker.
Cuando creas una VM, debes seleccionar un tipo de máquina de una familia de máquinas que determina los recursos disponibles para esa VM. Por ejemplo, un tipo de máquina como e2-standard-4 contiene 4 CPU virtuales, por lo que puede admitir hasta 4 VPC. Puedes elegir entre varias familias de máquinas, y cada una se organiza en series de máquinas y tipos predefinidos o personalizados de máquinas dentro de cada serie. Cada tipo de máquina se factura de manera diferente. Para obtener más información, consulta la hoja de precios de tipos de máquinas.
En el panel de navegación, selecciona Herramientas de redes.
En la sección Redes de nodos, especifica la cantidad máxima de Pods por nodo. En la sección Redes de nodos, se muestra la red de VPC que se usa para crear el clúster. Es necesario designar redes de nodos adicionales que se correlacionen con las redes de VPC y los tipos de dispositivos establecidos antes.
Crea la asociación del grupo de nodos:
1. Para el dispositivo de tipo Layer 3:
  1. En la sección Redes de nodos, haz clic en AGREGAR UNA RED DE NODO.
  2. En la lista desplegable de redes, selecciona la VPC que admite el dispositivo de tipo de capa 3.
  3. Selecciona la subred creada para la VPC Layer 3.
  4. En la sección Rangos de direcciones IP del Pod del alias, haz clic en Agregar rango de direcciones IP del Pod.
  5. Selecciona la Subred secundaria y, luego, indica la cantidad máxima de Pods por nodo.
  6. Seleccione Listo.
2. Para los dispositivos de tipo Netdevice y DPDK:
  1. En la sección Redes de nodos, haz clic en AGREGAR UNA RED DE NODO.
  2. En la lista desplegable de red, selecciona la VPC que admite dispositivos de tipo Netdevice o DPDK.
  3. Selecciona la subred creada para la VPC Netdevice o DPDK.
  4. Seleccione Listo.
Haz clic en Crear.

Notas:

Si se especifican varias redes de Pods adicionales dentro de la misma red de nodos, deben estar en la misma subred.
No puedes hacer referencia al mismo rango secundario de una subred varias veces.

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

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --zone 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 adicionales de redes de nodos y de Pods, 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 Pods

Define las redes de los Pods a las que accederán los Pods mediante la definición de objetos de Kubernetes y su vinculación a los recursos correspondientes de Compute Engine, como VPC, subredes y rangos secundarios.

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

Configura la red de VPC `Layer 3`

YAML

Para la VPC Layer 3, crea objetos Network y GKENetworkParamSet:

Guarda el siguiente manifiesto de muestra 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.
Aplica el manifiesto al clúster:
```
kubectl apply -f blue-network.yaml
```
Guarda el siguiente manifiesto como dataplane.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 dataplane, establece el nombre de la VPC como dataplane, el nombre de la subred como subnet-dp y un rango de direcciones IPv4 secundario para Pods llamado sec-range-blue.
Aplica el manifiesto al clúster:
```
kubectl apply -f dataplane.yaml
```

Console

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

Ir a Google Kubernetes Engine
En el panel de navegación, haz clic en Optimizador de funciones de red.
Haz clic en Habilitar GKE Enterprise.

Nota: No verás esta opción si GKE Enterprise ya está habilitado.
En la parte superior de la página, haz clic en Crear para crear la red del Pod.
En la sección Antes de comenzar, verifica los detalles.
Haz clic en SIGUIENTE: UBICACIÓN DE RED DEL POD.
En la sección Ubicación de la red del Pod, en el menú desplegable Clúster, selecciona el clúster de GKE que tiene habilitadas las redes múltiples y GKE Dataplane V2.
Haz clic en SIGUIENTE: REFERENCIA DE LA RED DE VPC.
En la sección Referencia de la red de VPC, en el menú desplegable Referencia de la red de VPC, selecciona la red de VPC que se usa para los Pods de varias NIC Layer 3.
Haz clic en SIGUIENTE: TIPO DE RED DEL POD.
En la sección Tipo de red del Pod, selecciona L3 y, luego, ingresa el nombre de la red del Pod.
Haz clic en SIGUIENTE: RANGO SECUNDARIO DE LA RED DEL POD.
En la sección Rango secundario de la red del Pod, ingresa el Rango secundario.
Haz clic en SIGUIENTE: RUTAS DE LA RED DE PODS.
En la sección Rutas de la red de Pods, para definir Rutas personalizadas, selecciona AGREGAR RUTA.
Haz clic en CREAR RED DE PODS.

Configura la red de DPDK

YAML

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

Guarda el siguiente manifiesto de muestra 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"
```
En este manifiesto, se define un recurso Network llamado dpdk-network con un tipo de Device. El recurso Network hace referencia a un objeto GKENetworkParamSet llamado dpdk para su configuración.
Aplica el manifiesto al clúster:
```
kubectl apply -f dpdk-network.yaml
```
Para 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"
```
En este manifiesto, se define el objeto GKENetworkParamSet llamado dpdk, se establece el nombre de la VPC como dpdk, el nombre de la subred como subnet-dpdk y el nombre del deviceMode DPDK-VFIO.
Aplica el manifiesto al clúster:
```
kubectl apply -f dpdk-network.yaml
```

Console

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

Ir a Google Kubernetes Engine
En el panel de navegación, haz clic en Optimizador de funciones de red.
En la parte superior de la página, haz clic en Crear para crear la red del Pod.
En la sección Antes de comenzar, verifica los detalles.
Haz clic en SIGUIENTE: UBICACIÓN DE RED DEL POD.
En la sección Ubicación de la red del Pod, en el menú desplegable Clúster, selecciona el clúster de GKE que tiene habilitadas las redes múltiples y GKE Dataplane V2.
Haz clic en SIGUIENTE: REFERENCIA DE LA RED DE VPC.
En la sección Referencia de la red de VPC, en el menú desplegable Referencia de la red de VPC, selecciona la red de VPC que se usa para los Pods de varias NIC dpdk.
Haz clic en SIGUIENTE: TIPO DE RED DEL POD.
En la sección Tipo de red del Pod, selecciona DPDK-VFIO (dispositivo) y, luego, ingresa el nombre de la red del Pod.
Haz clic en SIGUIENTE: RANGO SECUNDARIO DE LA RED DEL POD. La sección del rango secundario de la red del Pod no estará disponible.
Haz clic en SIGUIENTE: RUTAS DE LA RED DE PODS. En la sección de rutas de la red de Pods, selecciona AGREGAR RUTA para definir rutas personalizadas.
Haz clic en CREAR RED DE PODS.

Configura la red netdevice

Para la VPC netdevice, crea objetos Network y GKENetworkParamSet.

YAML

Guarda el siguiente manifiesto de muestra 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"
```
En este manifiesto, se define un recurso Network llamado netdevice-network con un tipo de Device. Hace referencia al objeto GKENetworkParamSet llamado netdevice.

Aplica el manifiesto al clúster:

kubectl apply -f netdevice-network.yaml

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
```
En este manifiesto, se define un recurso GKENetworkParamSet llamado netdevice, se establece el nombre de la VPC como netdevice, el nombre de la subred como subnet-netdevice y se especifica el modo de dispositivo como NetDevice.
Aplica el manifiesto al clúster:
```
kubectl apply -f netdevice.yaml
```

Console

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

Ir a Google Kubernetes Engine
En el panel de navegación, haz clic en Optimizador de funciones de red.
En la parte superior de la página, haz clic en Crear para crear la red del Pod.
En la sección Antes de comenzar, verifica los detalles.
Haz clic en SIGUIENTE: UBICACIÓN DE RED DEL POD.
En la sección Ubicación de la red del Pod, en el menú desplegable Clúster, selecciona el clúster de GKE que tiene habilitadas las redes múltiples y GKE Dataplane V2.
Haz clic en SIGUIENTE: REFERENCIA DE LA RED DE VPC.
En la sección Referencia de la red de VPC, en el menú desplegable Referencia de la red de VPC, selecciona la red de VPC que se usa para los Pods de varias NIC netdevice.
Haz clic en SIGUIENTE: TIPO DE RED DEL POD.
En la sección Tipo de red del Pod, selecciona NetDevice (dispositivo) y, luego, ingresa el nombre de la red del Pod.
Haz clic en SIGUIENTE: RANGO SECUNDARIO DE LA RED DEL POD. La sección del rango secundario de la red del Pod no estará disponible.
Haz clic en SIGUIENTE: RUTAS DE LA RED DE PODS. En la sección Rutas de la red de Pods, para definir rutas personalizadas, selecciona AGREGAR RUTA.
Haz clic en CREAR RED DE PODS.

Configura rutas de red

La configuración de la 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 dentro del Pod.

YAML

Guarda el siguiente 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"

En este manifiesto, se 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.

Aplica el manifiesto al clúster:
```
kubectl apply -f red-network.yaml
```

Console

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

Ir a Google Kubernetes Engine
Haz clic en Crear.
En el panel de navegación, haz clic en Optimizador de funciones de red.
En la sección Clústeres de Kubernetes, haz clic en el clúster que creaste.
En la parte superior de la página, haz clic en Crear para crear la red del Pod.
En la sección Rutas de la red de Pods, define Rutas personalizadas.
Haz clic en CREAR RED DE PODS.

Haz referencia a la `Network` preparada

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

Conecta el Pod a redes específicas

Para conectar Pods a las redes especificadas, debes incluir los nombres de los objetos Network como anotaciones dentro de la configuración del Pod. Asegúrate de incluir default Network y las redes adicionales seleccionadas en las anotaciones para establecer las conexiones.

Guarda el siguiente manifiesto de muestra 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":"l3-network"}
      ]
spec:
  containers:
  - name: sample-l3-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

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

Aplica el manifiesto al clúster:
```
kubectl apply -f sample-l3-pod.yaml
```

Conecta el Pod con varias redes

Guarda el siguiente manifiesto de muestra 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":"l3-network"},
        {"interfaceName":"eth2","network":"netdevice-network"}
      ]
spec:
  containers:
  - name: sample-l3-netdevice-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

En este manifiesto, se crea un Pod llamado sample-l3-netdevice-pod con tres interfaces de red, eth0, eth1 y eth2, asociadas con las redes default, l3-network y netdevice, respectivamente.

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.

Cuando creas un Pod con una especificación de varias redes, los componentes del plano de datos generan de forma automática la configuración de interfaces del Pod y los guardan en las CR de NetworkInterface. Crea un CR NetworkInterface para cada Network no predeterminada especificada en la especificación del Pod.

Por ejemplo, en el siguiente manifiesto, se muestran detalles de un manifiesto NetworkInterface:

apiVersion: v1
items:
-   apiVersion: networking.gke.io/v1
  kind: NetworkInterface
  metadata:
    labels:
      podName: samplepod
    name: "samplepod-c0b60cbe"
    namespace: default
  spec:
    networkName: "blue-network"
  status:
    gateway4: 172.16.1.1
    ipAddresses:
    -   172.16.1.2/32
    macAddress: 82:89:96:0b:92:54
    podName: samplepod

En este manifiesto, se incluyen el nombre de la red, la dirección de la puerta de enlace, las direcciones IP asignadas, la dirección MAC y el nombre del Pod.

Configuración de muestra 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 el grupo de nodos.
Verifica que los grupos de nodos se creen con --additional-node-network o --additional-pod-network solo si las redes múltiples están habilitadas en el clúster.
Asegúrate de que la misma subred no se especifique dos veces como argumento --additional-node-network para un grupo de nodos.
Verifica que no se especifique el mismo rango secundario como el argumento --additional-pod-network en un grupo de nodos.
Sigue los límites de escala especificados para los objetos de red y considera la cantidad máxima de nodos, Pods y direcciones IP permitidos.
Verifica que solo haya un objeto GKENetworkParamSet que haga referencia a una subred y un rango secundario en particular.
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 una red Device, no esté en uso en el mismo nodo con otra red con un rango secundario. Solo puedes validar esto en el entorno de ejecución.
Verifica que los diversos rangos secundarios asignados a los grupos de nodos no tengan direcciones IP superpuestas.

Soluciona problemas de parámetros de redes múltiples en GKE

Cuando creas un clúster y un grupo de nodos, Google Cloud implementa ciertas verificaciones para garantizar que solo se permitan parámetros de varias redes válidos. Esto garantiza que la red esté configurada de manera correcta para el clúster.

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

kubectl describe pods samplepod

El resultado es similar a este:

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   Scheduled               26m   default-scheduler  Successfully assigned default/samplepod to node-n1-04
  Warning  FailedCreatePodSandBox  26m   kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "e16c58a443ab70d671159509e36894b57493300ea21b6c24c14bdc412b0fdbe6": Unable to create endpoint: [PUT /endpoint/{id}][400] putEndpointIdInvalid  failed getting interface and network CR for pod "default/samplepod": failed creating interface CR default/samplepod-c0b60cbe: admission webhook "vnetworkinterface.networking.gke.io" denied the request: NetworkInterface.networking.gke.io "samplepod-c0b60cbe" is invalid: Spec.NetworkName: Internal error: failed to get the referenced network "sample-network": Network.networking.gke.io "sample-network" not found
...

Los siguientes son motivos generales por los que falla la creación de Pods:

No se pudo programar el Pod debido a que no se cumplen los requisitos de recursos de varias redes
No se pudieron identificar las redes especificadas
No se pudo configurar ni crear el objeto de interfaz de red para un Pod

Para inspeccionar si Google Cloud creó los objetos NetworkInterface en el servidor de la API, ejecuta el siguiente comando:

kubectl get networkinterfaces.networking.gke.io -l podName=samplepod

Soluciona problemas de creación de redes de Kubernetes

Después de crear una red de forma correcta, los nodos que deben tener acceso a la red configurada se anotan con una anotación de estado de la red.

Para observar las anotaciones, ejecuta el siguiente comando:

kubectl describe node NODE_NAME

Reemplaza NODE_NAME por el nombre del conjunto de datos.

El resultado es similar a este:

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

El resultado enumera cada red disponible en el nodo. Si el estado de la red no se ve en el nodo, haz lo siguiente:

Verifica si el nodo puede acceder a la red

Si la red no aparece en la anotación de estado de la red del nodo, haz lo siguiente:

Verifica que el nodo sea parte de un grupo configurado para las redes múltiples.
Verifica las interfaces del nodo a fin de ver si tiene una interfaz para la red que estás configurando.
Si a un nodo le falta el estado de la red y tiene solo una interfaz de red, debes crear un grupo de nodos con varias redes habilitadas.
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, verifica los recursos Network y GKENetworkParamSet (GNP).

Verifica los recursos `Network` y `GKENetworkParamSet`

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

Para inspeccionar el campo de condiciones, ejecuta el siguiente comando:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Reemplaza GNP_NAME por el nombre del recurso GKENetworkParamSet.

Cuando la condición Ready es igual a verdadera, 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 falso, 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 encuentras un mensaje similar, asegúrate de que tu GNP esté configurado correctamente. Si ya lo es, asegúrate de que la configuración de red de Google Cloud sea correcta. Después de actualizar la configuración de red de Google Cloud, es posible que debas volver a crear el recurso de GNP para activar de forma manual una resincronización. Esto es para evitar un sondeo infinito de la API de Google Cloud.

Una vez que el GNP esté listo, verifica el recurso Network.

kubectl get networks NETWORK_NAME -o yaml

Reemplaza NETWORK_NAME por el nombre del recurso Network.

El resultado de una configuración válida es similar al 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 de forma correcta. reason: NetworkReady no implica que el recurso de red esté disponible en un nodo específico o que se esté usando de forma activa.
Si hay un error o una configuración incorrecta, el campo reason en la condición especifica el motivo exacto del problema. En esos casos, ajusta la configuración según corresponda.
GKE propaga el campo ParamsReady si el campo parametersRef se configura en un recurso GKENetworkParamSet que existe en el clúster. Si especificaste un parámetro de tipo GKENetworkParamSet de Ref y la condición no aparece, asegúrate de que el nombre, el tipo y el grupo coincidan con el recurso GNP que existe dentro de tu clúster.

Configurar la compatibilidad con varias redes para Pods

Requisitos y limitaciones

Requisitos

Limitaciones generales

Limitaciones del dispositivo y el kit de desarrollo del plano de datos (DPDK)

Limitaciones de escalamiento

Precios

Implementa Pods de varias redes

Antes de comenzar

Prepara una VPC adicional

Crea una red de VPC que admita el dispositivo de tipo Layer 3

gcloud

Console

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

gcloud

Console

Crea un clúster de GKE con capacidades de varias redes

gcloud

Console

Crea un grupo de nodos de GKE conectado a VPC adicionales

gcloud

Console

Crear red de Pods

Configura la red de VPC Layer 3

YAML

Console

Configura la red de DPDK

YAML

Console

Configura la red netdevice

YAML

Console

Configura rutas de red

YAML

Console

Haz referencia a la Network preparada

Conecta el Pod a redes específicas

Conecta el Pod con varias redes

Verificación

Soluciona problemas de parámetros de redes múltiples en GKE

Soluciona problemas de creación de redes de Kubernetes

Verifica si el nodo puede acceder a la red

Verifica los recursos Network y GKENetworkParamSet

¿Qué sigue?

Crea una red de VPC que admita el dispositivo de tipo `Layer 3`

Crea una red de VPC que admita dispositivos de tipo `Netdevice` o `DPDK`

Configura la red de VPC `Layer 3`

Haz referencia a la `Network` preparada

Verifica los recursos `Network` y `GKENetworkParamSet`