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 redes de pod nativo de VCN de OCI para la comunicación de pod en nodos de trabajador en clusters creados mediante Container Engine for Kubernetes (OKE).

El plugin CNI de red de pod nativos de VCN de OCI proporciona direcciones IP a los pods desde un bloque CIDR de una VCN. El plugin CNI de red de pod nativos 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 permiten el direccionamiento directo de otras redes virtuales en la nube conectadas (conectadas) a esa VCN, desde redes locales e Internet.

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 soporta la comunicación entre pods y el acceso directo a pods individuales mediante direcciones IP de pod privadas. La subred de pod puede ser privada o pública, 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 (mediante un gateway de servicio) e Internet (mediante 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 clusters diferentes.

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.
• Solo puede utilizar el plugin CNI de red de pod nativos de VCN de OCI con clusters que ejecuten Kubernetes 1.22 o una versión posterior (consulte Uso del plugin CNI de red de pod nativos de VCN de OCI para redes de pod). Para obtener más información, consulte Red de pods.
• 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.
• Los productos de malla de servicios (como Oracle Cloud Infrastructure Service Mesh, 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 está limitado actualmente a Oracle Linux 7 (se ha planificado el soporte de Oracle Linux 8). El complemento Istio está soportado con Oracle Linux 7 y Oracle Linux 8. Los nodos de trabajador deben ejecutar Kubernetes 1.26 (o una versión posterior).

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

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' }

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>' }

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