Uso del plugin CNI de red de pod nativo de VCN de OCI para redes de pod

Obtenga información sobre el plugin CNI de red de pod nativo de VCN de OCI para la comunicación de pod en nodos de trabajador en clusters creados con Kubernetes Engine (OKE).

El plugin CNI de red de pod nativo de VCN de OCI proporciona direcciones IP a los pods desde un bloque CIDR de una VCN. El plugin CNI de red de pod nativo de VCN de OCI permite que otros recursos de la misma subred (o una subred diferente) se comuniquen directamente con los pods de un cluster de Kubernetes. Las direcciones IP de pod se pueden enrutar directamente desde otras VCN conectadas (con intercambio de tráfico) a esa VCN y desde redes locales.

Dado que los pods son directamente enrutables, puede utilizar la funcionalidad de VCN 'nativa' para:

Controlar el acceso a los pods y desde ellos mediante reglas de seguridad definidas como parte de grupos de seguridad de red (recomendado) o listas de seguridad. Las reglas de seguridad se aplican a todos los pods de todos los nodos de trabajador conectados a la subred de pod especificada para un pool de nodos. Consulte Grupos de seguridad de red y Listas de seguridad.
Observe el tráfico hacia, desde y entre pods mediante logs de flujo de VCN para la resolución de problemas y la auditoría de conformidad. Consulte Logs de flujos de VCN.
Enrute las solicitudes entrantes a los pods según las políticas de enrutamiento especificadas por las reglas de enrutamiento y las tablas de rutas. Consulte Tablas de rutas de VCN.

Al utilizar el plugin CNI de red de pod nativos de VCN de OCI, los nodos de trabajador se conectan a dos subredes especificadas para el pool de nodos:

Subred de nodo de trabajador: la subred del nodo de trabajador soporta la comunicación entre los procesos que se ejecutan en el plano de control del cluster (como kube-apiserver, kube-controller-manager, kube-scheduler) y los procesos que se ejecutan en el nodo de trabajador (como kubelet, kube-proxy). La subred del nodo de trabajador puede ser privada o pública, y puede ser una subred regional (recomendado) o en distintas subredes específicas de un dominio de disponibilidad (una en cada dominio de disponibilidad de la región).
Subred de pod: la subred de pod admite la comunicación entre pods y el acceso directo a pods individuales mediante direcciones IP de pod privado. La subred de pod debe ser privada y debe ser una subred regional. La subred de pod permite a los pods comunicarse con otros pods en el mismo nodo de trabajador, con pods en otros nodos de trabajador, con servicios de OCI (a través de un gateway de servicio) e Internet (a través de un gateway de NAT). Especifique una única subred de pod para todos los pods que se ejecutan en nodos de trabajador en un pool de nodos. Puede especificar la misma subred de pod o subredes de pod diferentes para diferentes pools de nodos de un cluster. Puede especificar la misma subred de pod para pools de nodos en diferentes clusters.

La subred del nodo de trabajador y la subred de pod deben estar en la misma VCN. En algunas situaciones, la subred del nodo de trabajador y la subred de pod pueden ser la misma subred (consulte Número máximo de VNIC y pods admitidos por diferentes unidades). Si la subred de nodo de trabajador y la subred de pod son la misma subred, Oracle recomienda definir reglas de seguridad en grupos de seguridad de red (en lugar de en listas de seguridad) para enrutar el tráfico de red a nodos de trabajador y pods. La subred de nodo de trabajador y la subred de pod se suman a la subred de punto final de API de Kubernetes y a cualquier subred de equilibrador de carga definida para el cluster.

Al utilizar el plugin CNI de red de pod nativo de VCN de OCI, se asocian un mínimo de dos VNIC a cada nodo de trabajador. La primera VNIC está conectada a la subred del nodo de trabajador. La segunda VNIC está conectada a la subred de pod. Por defecto, se asignan 31 direcciones IP a la VNIC para que las utilicen los pods que se ejecutan en el nodo de trabajador. Para evitar quedarse sin direcciones IP, las direcciones IP se asignan previamente en la subred de pod antes de crear los pods en el cluster.

Si la unidad que seleccione para el pool de nodos soporta más de dos VNIC, las VNIC adicionales se pueden conectar a la subred de pod para proporcionar más direcciones IP que soporten más pods.

Puede especificar el número máximo de pods que desea ejecutar en un único nodo de trabajador en un pool de nodos, hasta un límite de 110. Kubernetes impone el límite de 110. Si desea más de 31 pods en un único nodo de trabajador, la unidad que especifique para el pool de nodos debe soportar tres o más VNIC (una VNIC para conectarse a la subred del nodo de trabajador y al menos dos VNIC para conectarse a la subred del pod). Consulte Maximum Number of VNICs and Pods Supported by Different Shapes.

Si desea conservar el espacio de direcciones de la subred de pod, reduzca el número máximo de pods que desea ejecutar en un único nodo de trabajador y, por lo tanto, reduzca el número de direcciones IP que están preasignadas en la subred de pod.

Tenga en cuenta lo siguiente al utilizar el plugin CNI de red de pod nativos de VCN de OCI:

Puede utilizar el plugin CNI de redes de pod nativo de VCN de OCI con pools de nodos virtuales y pools de nodos gestionados.
Puede utilizar el plugin CNI de red de pod nativo de VCN de OCI con nodos autogestionados, siempre que los nodos de plano de control del cluster ejecuten la versión 1.27.10 de Kubernetes (o posterior). Para obtener más información, consulte Working with Self-Managed Nodes.
Solo puede utilizar el plugin CNI de red de Pod nativo de VCN de OCI con clusters que ejecuten Kubernetes 1.22 o posterior (consulte Uso del plugin CNI de red de Pod nativo de VCN de OCI para redes de pod). Para obtener más información, consulte Redes de pod.
Si utiliza el plugin CNI de redes de pod nativo de VCN de OCI y desea especificar una imagen de OKE como imagen base para los nodos de trabajador, no seleccione una imagen de OKE publicada antes de junio de 2022.
Si utiliza el plugin CNI de red de pod nativo de VCN de OCI y desea enrutar el tráfico de una red local a un pod, tenga en cuenta que la dirección IP del pod no es persistente si se vuelve a crear el pod. Por ejemplo, un pod de Nginx puede tener inicialmente 10.0.0.5 como su dirección IP, pero si el pod se suprime y se vuelve a crear, el pod puede tener una dirección IP diferente (como 10.0.0.8).
Los productos de malla de servicio (como Istio y Linkerd) están soportados al utilizar el plugin CNI de red de pod nativo de VCN de OCI para redes de pod. Tenga en cuenta que, a excepción del complemento Istio, el soporte actualmente está limitado a Oracle Linux 7 (está planificado el soporte de Oracle Linux 8). El complemento Istio es compatible con Oracle Linux 7 y Oracle Linux 8. Los nodos de trabajador deben ejecutar Kubernetes 1.26 (o posterior).

Reglas de seguridad para nodos y pod de trabajador

Al utilizar el plugin CNI de redes de pod nativo de VCN de OCI para redes de pod, se necesitan determinadas reglas de seguridad para la subred de pod y la subred de nodo de trabajador. Consulte Reglas de seguridad para subredes de pod.

Número máximo de VNIC y pods admitidos por diferentes unidades

El número máximo de VNIC (y, por lo tanto, el número máximo de pods) para los nodos de trabajador en un pool de nodos depende de la unidad que seleccione para el pool de nodos.

Para averiguar el número máximo de VNIC para una unidad concreta, consulte Unidades de computación.

Para calcular el número máximo de pods en un pool de nodos de una unidad concreta, utilice la siguiente ecuación:

Maximum number of Pods per node = MIN( (Number of VNICs - 1) * 31 ), 110)

Política de IAM adicional para acceder a los recursos con direcciones IPv6

Para utilizar el plugin CNI de red de pod nativo de VCN de OCI en el que los recursos relacionados de un cluster (como el punto final de API de Kubernetes, el equilibrador de carga y los nodos de trabajador) tienen direcciones IPv6, incluya una sentencia de política similar a la siguiente en una política de IAM:

Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Política de IAM adicional cuando un cluster y sus recursos relacionados están en distintos compartimentos

Para utilizar el plugin CNI de redes de pod nativo de VCN de OCI en un escenario poco común en el que los recursos relacionados de un cluster (como pools de nodos, VCN y recursos de VCN) están en un compartimento diferente al propio cluster, debe incluir sentencias de política similares a las siguientes en una política de IAM:

Allow any-user to manage instances in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use private-ips in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use network-security-groups in tenancy where all { request.principal.type = 'cluster' }

Si considera que estas sentencias de política son demasiado permisivas, puede restringir los permisos para especificar explícitamente el compartimento al que pertenecen los recursos relacionados y/o para especificar explícitamente el cluster que tiene recursos relacionados en un compartimento diferente. Por ejemplo:

Allow any-user to manage instances in compartment <compartment-ocid-of-nodepool> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use private-ips in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use network-security-groups in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

donde:

<compartment-ocid-of-nodepool> es el OCID del compartimento al que pertenecen los pools de nodos y las instancias informáticas.
<compartment-ocid-of-network-resources> es el OCID del compartimento al que pertenecen la VCN y las subredes.

Actualización del plugin de CNI de red de pod nativo de VCN de OCI

Al especificar la red de pods nativa de VCN como tipo de red de cluster, el cluster y sus pools de nodos ejecutan inicialmente la última versión del plugin CNI de red de pod nativo de VCN de OCI.

Las actualizaciones del plugin CNI de red del pod nativo de la VCN de OCI se publican periódicamente.

En las versiones del plugin CNI de red de pod nativo de VCN de OCI anteriores a la versión 2.3.0 (agosto de 2025), puede especificar que desea que Oracle despliegue las actualizaciones en el cluster automáticamente. También puede especificar que desea seleccionar la versión que desea desplegar. Si decides elegir una versión (y esta es anterior a la versión 2.3.0), asumirás la responsabilidad de mantener actualizado el complemento. El plugin CNI de red de pod nativo de VCN de OCI utiliza la estrategia de actualización RollingUpdate, por lo que los pods de plugin CNI existentes se terminan automáticamente y se crean nuevos pods que ejecutan la nueva versión del plugin CNI (para obtener más información sobre la estrategia de actualización RollingUpdate, consulte DaemonSet Update Strategy en la documentación de Kubernetes). Las actualizaciones se aplican cuando los nodos de trabajador se reinician.

In OCI VCN-Native Pod Networking CNI plugin version 2.3.0 (August 2025) and later versions, CNI plugin updates are never deployed on the cluster automatically. El plugin CNI de red de pod nativo de VCN de OCI utiliza la estrategia de actualización OnDelete, por lo que el plugin CNI solo se puede actualizar suprimiendo explícitamente los pods de plugin CNI (para obtener más información sobre la estrategia de actualización OnDelete, consulte Estrategia de actualización DaemonSet en la documentación de Kubernetes). Este enfoque evita reinicios inesperados de los pods del plugin CNI durante las actualizaciones del cluster. La versión 2.3.0 también introduce una política de admisión de validación que restringe la eliminación de los pods del plugin CNI. Para actualizar el plugin CNI a una versión más reciente al utilizar la versión 2.3.0 o posterior, adopte una de las siguientes técnicas:

(recomendado) Aprovisionar nuevos nodos en el cluster: al aprovisionar nuevos nodos en el cluster, reciben automáticamente los pods de plugin CNI que ejecutan la última versión del plugin CNI. Opcionalmente, puede drenar y eliminar nodos con pods de plugin CNI que ejecutan versiones anteriores.
Actualizar nodos existentes en el cluster: puede actualizar la versión del plugin CNI en los nodos existentes suprimiendo los pods del plugin CNI existentes. Debe eliminar la política de admisión de validación que restringe la supresión de pod de plugin CNI, suprimir los pods de plugin CNI existentes y, a continuación, restaurar la política. DaemonsetController vuelve a crear los pods del plugin CNI y ejecuta la última versión del plugin CNI. Siga estos pasos:
1. Identifique los pods del plugin CNI de los nodos existentes que desea actualizar introduciendo:
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Suprima la política de admisión de validación para permitirle eliminar los pods del plugin CNI de la siguiente manera:
  1. Guarde la política de admisión de validación y el enlace de política de admisión de validación como vap-policy.yaml y vap-binding.yaml para que pueda restaurarlos más tarde, introduciendo los siguientes comandos:
```
kubectl get validatingadmissionpolicy npn-pod-deletion-deny-policy -o yaml > vap-policy.yaml
```
```
kubectl get validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding -o yaml > vap-binding.yaml
```
  2. Elimine la política de admisión de validación y el enlace de política de admisión de validación introduciendo los siguientes comandos:
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. Suprima los pods del plugin CNI que identificó anteriormente introduciendo el siguiente comando para cada pod:
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. Restaure la política de admisión de validación y el enlace de política que ha suprimido anteriormente, mediante los archivos vap-policy.yaml y vap-binding.yaml que ha creado anteriormente, introduciendo los siguientes comandos:
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

Para determinar si las actualizaciones se han desplegado y están esperando a que se apliquen, inspeccione los logs de Daemonset vcn-native-ip-cni introduciendo:

kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"

Interprete la respuesta al comando de la siguiente manera: