Selección de una interfaz de red para contenedores

Nube privada virtual

Consulta la siguiente información para seleccionar una interfaz de red de contenedores (CNI).

En la versión 4.20 de IBM Cloud Kubernetes Service y posteriores, Calico es la CNI predeterminada, pero los clústeres VPC que utilizan nodos de trabajo RHCOS tienen la opción de seleccionar Open Virtual Network (OVN) como CNI de su clúster.

Calico Por defecto: Calico es una plataforma única para redes, seguridad de redes y observabilidad para cualquier distribución de Kubernetes, ya sea en la nube, en las instalaciones o en el perímetro. Tanto si acabas de empezar a utilizar Kubernetes como si ya operas a gran escala, las ediciones de código abierto, empresarial y en la nube de Calico te proporcionan la conectividad, la seguridad y la observabilidad que necesitas. Para obtener más información, consulta la documentación de Calico.
OVN-Kubernetes (OVN) 4.20 y versiones posterioresSolo nodos de trabajo de RHCOS: OVN- Kubernetes se basa en Open Virtual Network (OVN) y ofrece una implementación de red basada en superposición. Un clúster que utiliza el complemento OVN- Kubernetes también ejecuta Open vSwitch (OVS) en cada nodo. OVN configura OVS en cada nodo para implementar la configuración de red declarada. Para obtener más información, consulta la documentación de Red Hat

Comparación entre Calico y OVN

Consulta la siguiente tabla para comparar las características y funcionalidades de Calico y OVN.

Al utilizar OVN, debe asegurarse de que sus subredes VPC no se solapen con las subredes adicionales especificadas en la siguiente tabla. Si se produce un solapamiento de subredes, la conexión de red entre pods fallará.

Layer2 Además, las redes definidas por el usuario (UDN) de layer3 no son compatibles con cargas de trabajo que utilicen DHCP, como las máquinas virtuales de OpenShift Virtualization.

Calico y tabla comparativa con OVN
Componente	Calico	OVN- Kubernetes
Encapsulación	IP en el protocolo IP (no UDP ni TCP ) Encapsula únicamente el tráfico de pod a pod procedente de pods que se ejecutan en nodos que se encuentran en subredes diferentes.	Geneve: Protocolo UDP en el puerto 6081 Encapsula todo el tráfico entre pods
Red de clúster predeterminada / MTU del pod	1480 bytes (encabezado IPinIP de 20 bytes) por defecto. Esto se puede modificar.	1400 bytes (encabezado Geneve de 100 bytes) por defecto. Esto se puede modificar. Daemonset debe crear un fichero NetworkManager en lugar de limitarse a ejecutarlo `ip link set dev ens3 mtu`. También debes reiniciar los nuevos nodos de trabajo.
Pod IPAM	Calico Inicialmente, asigna a cada nuevo nodo una subred /26 (64 direcciones IP; normalmente, al menos una se utiliza como dirección IP de l tunl0, y el resto están disponibles para los pods). Si se agotan todas las direcciones IP de los pods de una subred /26, Calico asigna una segunda subred /26 al nodo, y más si es necesario. Puedes utilizar el `calicoctl ipam check` para ver las subredes asignadas a cada nodo.	OVN asigna inicialmente una subred de pod /24 (256 direcciones IP) a cada nuevo nodo del clúster. No existe la opción de añadir más subredes de pod. Además, asigna una dirección IP de subred de unión a cada nuevo nodo, que OVN utiliza internamente
Enrutamiento de pod a pod	Utiliza rutas de Linux. Utiliza BGP para distribuir rutas. `tunl0` Interfaz en cada nodo para la encapsulación.	Open vSwitch (OVS) se ejecuta en cada nodo y enruta el tráfico entre pods. OVN configura los flujos de OVS para definir el enrutamiento entre pods. En cada nodo se crean muchas otras interfaces, tales como: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, y `br-ex`, que son utilizadas por OVN y OVS
Políticas de red de Kubernetes	Se implementa `calico-node` añadiendo reglas de iptables. Es posible registrar el tráfico bloqueado por las políticas de red, pero resulta complicado. Requiere políticas de Calico adicionales que utilicen una acción de Log, así como cierta reflexión y planificación sobre dónde y cuándo aplicar estas acciones de Log. Los registros se almacenan en `syslog` el nodo de trabajo, lo que puede dificultar su recuperación. Los registros no incluyen qué política permitió o bloqueó el tráfico.	Implementado por OVS mediante ACL en puertos lógicos (no mediante iptables). Registrar los rechazos de la política de red y/o el tráfico permitido resulta mucho más sencillo utilizando anotaciones. Anota los espacios de nombres en los que deseas registrar la actividad de la política y si quieres registrar las autorizaciones, las denegaciones o ambas. Los registros se envían a un archivo `/var/log/ovn/acl-audit-log.log` en el pod `ovnkube-node`. Existen opciones de configuración para enviar estos registros a otros destinos de registro. Los registros incluyen qué política permitió el tráfico, pero no qué tráfico lo denegó, ya que las políticas son únicamente de permiso. Debe haber al menos una política activa para que se registren los tráficos permitidos.
Políticas de red del host	Calico GlobalNetworkPolicies	Ninguna
Subredes adicionales	Ninguna	Subred de unión: `100.64.0.0/16` (valor predeterminado de OpenShift ). Subred de enmascaramiento: `169.254.64.0/18`. Esto difiere del valor predeterminado de OpenShift, que es `169.254.0.0/17`. Esta diferencia tiene como objetivo evitar conflictos con las direcciones IP `169.254.2.0/24` que se utilizan para el registro local de HAProxy. Subred de tránsito:`100.88.0.0/16` (valor predeterminado de OpenShift ).
APIserver vigila	registra `calico-typha` las observaciones de recursos y actúa como proxy de los pods `calico-node` para notificar los cambios. se conecta `calico-node` a uno de los `calico-typha` pods y se registra para recibir notificaciones de cambios en los recursos.	El contenedor `ovnkube-cluster-manager` del plano de control supervisa la aparición de nuevos nodos. El `ovnkube-controller` contenedor de cada nodo del clúster supervisa los recursos y los traduce a entradas lógicas de OVN en la base de datos nbdb.
CNI	Los binarios y `calico` CNI `calico-ipam` se copian en cada nodo mediante el initContainer`install-cni` en el pod `calico-node`.	El contenedor `ovnkube-controller` del `ovnkube-node` pod ejecuta el binario CNI para las llamadas de adición y eliminación.
Recursos creados	espacio `calico-apiserver` de nombres - ( `calico-apiserver` despliegue, 2 pods) `calico-system` espacio de nombres - `calico-node` (cada nodo) `calico-typha` (despliegue, de 2 a 10 pods). `calico-kube-controllers` (1 nodo). `openshift-kube-proxy` espacio de nombres. `openshift-kube-proxy` (cada nodo). `tigera-operator` espacio de nombres. `tigera-operator` (despliegue, 1 pod). El binario CNI `calico`, el binario CNI `calico-ipam` y otros binarios CNI diversos se copian en cada nodo mediante initContainer `install-cni` en `calico-node`.	`openshift-ovn-kubernetes` namespace, `ovnkube-node` en cada nodo con 8 contenedores, `ovnkube-controller` supervisa los recursos, asigna direcciones IP a los pods y traduce los recursos a entradas lógicas de OVN en `nbdb`. También gestiona la adición y eliminación de CNI. `nbdb` almacena entradas lógicas. `northd` convierte las entradas lógicas de `nbdb` en flujos lógicos en `sbdb`. `sbdb` almacena flujos lógicos. `ovn-controller` convierte los flujos lógicos en `sbdb` y programa el conmutador OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protege las métricas de los nodos para que solo los usuarios autorizados puedan recopilarlas. `kube-rbac-proxy-ovn-metrics` protege las métricas de OVN para que solo los usuarios autorizados puedan recopilarlas.
Conexiones entre pods	El `calico-node` pod se conecta inicialmente al servidor de API de Kubernetes a través de un haproxy local en el pod proxy, que escucha en TCP172.20.0.1:2040, para obtener la lista de pods `calico-typha`. El `calico-node` pod se conecta a uno de los pods `calico-typha` en TCP, puerto 5473, para estar a la escucha de actualizaciones de los recursos del clúster. El `calico-node` pod ejecuta el demonio bird BGP, que se conecta en una malla completa con todos los demás demonios `calico-node` bird BGP en TCP, puerto 179. El tráfico de pod a pod se produce directamente entre los pods de nodos de la misma subred. El tráfico de pod a pod entre pods de nodos de diferentes subredes se encapsula mediante el protocolo IPinIP (o VxLAN para clústeres Satellite ).	El contenedor `ovnkube-controller` de cada nodo se conecta al kube apiserver a través de un haproxy local en un pod proxy que escucha en TCP para `172.20.0.1:2040` la supervisión de recursos. Todo el tráfico de pod a pod se encapsula mediante Geneve y se envía a través de UDP en el puerto 6081. Para obtener más información, consulta Configuración del cortafuegos.