Selección de una interfaz de red de contenedor

Nube privada virtual

Revise la siguiente información para seleccionar una interfaz de red de contenedor (CNI).

En Red Hat OpenShift on IBM Cloud versión 4.20 y posteriores, Calico es el CNI por defecto, pero los clusters VPC que utilizan nodos trabajadores RHCOS tienen la opción de seleccionar Open Virtual Network (OVN) como su CNI de cluster.

Calico Por defecto: Calico es una plataforma única para redes, seguridad de redes y capacidad de observación para cualquier distribución de Kubernetes en la nube, en las instalaciones o en el perímetro. Tanto si acaba de empezar a utilizar Kubernetes como si trabaja a gran escala, las ediciones de código abierto, para empresas y en la nube de Calico le ofrecen la red, la seguridad y la capacidad de observación que necesita. Para más información, consulte la documentación de Calico.
OVN- Kubernetes (OVN) 4.20 y posteriores Sólo nodos trabajadores 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 plugin 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 más información, consulte la documentación de Red Hat

Comparación entre Calico y OVN

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

Cuando utilice OVN, debe asegurarse de que las subredes de su VPC no se solapan con las subredes adicionales especificadas en la siguiente tabla. Si hay un solapamiento de subredes, fallará la interconexión de pod a pod.

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 OVN
Componente	Calico	OVN- Kubernetes
Encapsulación	IP en Protocolo IP (no UDP o TCP ) Encapsula sólo el tráfico de pod a pod desde pods que se ejecutan en nodos que están en subredes diferentes.	Geneve: UDP Protocolo en el puerto 6081 Encapsula todo el tráfico de pod a pod
Red de Cluster / Pod MTU por defecto	1480 bytes (20 bytes IPinIP header) por defecto. Esto se puede cambiar.	1400 bytes (cabecera Geneve de 100 bytes) por defecto. Esto se puede cambiar. Daemonset necesita crear el archivo NetworkManager en lugar de simplemente ejecutar `ip link set dev ens3 mtu`. También debe reiniciar los nuevos nodos trabajadores.
IPAM para pods	Calico asigna inicialmente a cada nuevo nodo una subred /26 (64 IPs, al menos una se utiliza normalmente como tunl0 IP, el resto están disponibles para pods). Si se utilizan todas las IPs del pod en un /26, entonces Calico asigna una segunda subred /26 al nodo, y más si/cuando sea necesario. Puede utilizar `calicoctl ipam check` para ver las subredes asignadas a cada nodo.	OVN asigna inicialmente una subred de pod /24 (256 IPs) a cada nuevo nodo del cluster. No hay opción de añadir más subredes de pods. También asigna una IP de subred de unión a cada nuevo nodo, que es utilizada internamente por OVN
Enrutamiento pod a pod	Utiliza rutas 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 de pod a pod. OVN configura los flujos de OVS para definir el enrutamiento de pod a pod. En cada nodo se crean muchas otras interfaces como: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` y son utilizadas por OVN y OVS
Políticas de red de Kubernetes	Implementado por `calico-node` añadiendo reglas iptables. El registro de tráfico bloqueado por políticas de red es posible, pero complicado. Requiere políticas adicionales de Calico que utilicen una acción "Log" y cierta reflexión y planificación sobre dónde/cuándo colocar estas acciones Log. Registros en `syslog` en el nodo trabajador, que pueden ser difíciles de recuperar. Los registros no incluyen qué política permitió o bloqueó el tráfico.	Implementado por OVS usando ACLs en puertos lógicos (no iptables). Registrar caídas de políticas de red y/o tráfico permitido es mucho más fácil usando anotaciones. Anote el espacio(s) de nombres donde quiere registrar la actividad de la política, y si quiere registrar permisos, denegaciones, o ambos. Los registros se envían al 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 ha permitido el tráfico, pero no qué tráfico lo ha denegado, ya que las políticas son sólo de permiso. Debe existir al menos una política para que se registre el tráfico permitido.
Políticas de red del host	Calico GlobalNetworkPolicies	Ninguna
Subredes adicionales	Ninguna	Unir subred: `100.64.0.0/16` ( OpenShift por defecto). Máscara de subred: `169.254.64.0/18`. Esto difiere del valor por defecto de OpenShift, `169.254.0.0/17`. Esta diferencia es para evitar conflictos con las IPs de `169.254.2.0/24` que se utilizan para el registro local haproxy. Subred de tránsito:`100.88.0.0/16` ( OpenShift por defecto).
Vigilancia del servidor API	`calico-typha` registra los vigilantes de recursos y actúa como proxy ante los pods `calico-node` para notificar los cambios. `calico-node` se conecta a uno de los pods de `calico-typha` y se registra para recibir notificaciones de cambios en los recursos.	El contenedor `ovnkube-cluster-manager` en el plano de control busca nuevos nodos. El contenedor `ovnkube-controller` en cada nodo del clúster vigila los recursos y los traduce en entradas lógicas OVN en la nbdb.
CNI	Los binarios CNI `calico` y `calico-ipam` son copiados a cada nodo por `install-cni` initContainer en el pod `calico-node`.	El contenedor `ovnkube-controller` del pod `ovnkube-node` ejecuta el binario CNI para las llamadas de adición y eliminación.
Recursos creados	`calico-apiserver` namespace `calico-apiserver` (despliegue, 2 pods) `calico-system` namespace `calico-node` (cada nodo) `calico-typha` (despliegue, de 2 - 10 pods). `calico-kube-controllers` (1 nodo). Espacio de nombres `openshift-kube-proxy`. `openshift-kube-proxy` (cada nodo). Espacio de nombres `tigera-operator`. `tigera-operator` (despliegue, 1 pod). El binario CNI `calico`, el binario CNI `calico-ipam` y otros binarios CNI son copiados a cada nodo por `install-cni` initContainer en `calico-node`.	`openshift-ovn-kubernetes` namespace, `ovnkube-node` en cada nodo con 8 contenedores, `ovnkube-controller` vigila los recursos, asigna las IPs de los pods y traduce los recursos en entradas lógicas OVN en `nbdb`. También se encarga de añadir y eliminar 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 flujos lógicos en `sbdb` y programa el conmutador OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protege las métricas de nodo para que sólo los usuarios autorizados puedan rasparlas. `kube-rbac-proxy-ovn-metrics` protege las métricas OVN para que sólo los usuarios autorizados puedan descifrarlas.
Conexiones entre cápsulas	El pod `calico-node` se conecta inicialmente al apiserver kube a través de haproxy local en proxy pod escuchando en TCP 172.20.0.1:2040 para obtener la lista de pods `calico-typha`. El pod `calico-node` se conecta a uno de los pods `calico-typha` en TCP puerto 5473 para escuchar las actualizaciones de recursos del cluster. El pod `calico-node` ejecuta un demonio BGP de pájaro que se conecta en una malla completa a todos los demás demonios BGP de pájaro `calico-node` en el puerto 179 de TCP. El tráfico de pod a pod se produce directamente para los pods en nodos de la misma subred. El tráfico de pod a pod entre pods en nodos en diferentes subredes se encapsula utilizando IPinIP encapsulation (o VxLAN para Satellite clusters).	El contenedor `ovnkube-controller` en cada nodo se conecta a kube apiserver a través de haproxy local en proxy pod escuchando en TCP `172.20.0.1:2040` para vigilancia de recursos. Todo el tráfico de pod a pod se encapsula utilizando Geneve y se envía a través de UDP puerto 681. Para más información, consulte Configuración de su cortafuegos.