Sélection d'une interface réseau de conteneur

Cloud privé virtuel

Examinez les informations suivantes pour sélectionner une interface réseau de conteneur (CNI).

Dans Red Hat OpenShift on IBM Cloud version 4.20 et suivantes, Calico est le CNI par défaut, mais les clusters VPC qui utilisent des nœuds de travail RHCOS ont la possibilité de sélectionner Open Virtual Network (OVN) comme CNI de leur cluster.

Calico Défaut: Calico est une plateforme unique pour la mise en réseau, la sécurité du réseau et l'observabilité pour toute distribution Kubernetes dans le nuage, sur site ou à la périphérie. Que vous débutiez avec Kubernetes ou que vous opériez à grande échelle, les éditions open source, entreprise et cloud de Calico vous offrent le réseau, la sécurité et l'observabilité dont vous avez besoin. Pour plus d'informations, voir la documentation de Calico.
OVN- Kubernetes (OVN) 4.20 et versions ultérieures Nœuds de travail RHCOS uniquement: OVN- Kubernetes est basé sur Open Virtual Network (OVN) et fournit une implémentation de réseau basée sur la superposition. Un cluster qui utilise le plugin OVN- Kubernetes exécute également Open vSwitch (OVS) sur chaque nœud. OVN configure OVS sur chaque nœud pour mettre en œuvre la configuration réseau déclarée. Pour plus d'informations, voir la documentation Red Hat

Comparaison entre Calico et OVN

Consultez le tableau suivant pour comparer les caractéristiques et les fonctionnalités de Calico et d'OVN.

Lorsque vous utilisez OVN, vous devez vous assurer que vos sous-réseaux VPC ne chevauchent pas les sous-réseaux supplémentaires spécifiés dans le tableau suivant. S'il y a un chevauchement de sous-réseaux, la mise en réseau de pod à pod échouera.

Layer2 De plus, les réseaux définis par l'utilisateur (UDN) d' layer3 ne sont pas pris en charge avec les charges de travail utilisant le protocole DHCP, telles que les machines virtuelles d' OpenShift Virtualization.

Calico et tableau comparatif OVN
Composant	Calico	OVN- Kubernetes
Encapsulation	IP dans IP Protocol (pas UDP ou TCP ) Encapsule uniquement le trafic de pod à pod entre des pods fonctionnant sur des nœuds situés dans des sous-réseaux différents.	Geneve : UDP Protocole sur le port 6081 Encapsule tout le trafic de pod à pod
Réseau de cluster par défaut / MTU de pod	1480 octets (20 octets d'en-tête IPinIP ) par défaut. Cela peut être modifié.	1400 octets (100 octets d'en-tête Geneve) par défaut. Cela peut être modifié. Daemonset doit créer le fichier NetworkManager au lieu d'exécuter simplement `ip link set dev ens3 mtu`. Vous devez également redémarrer les nouveaux nœuds de travail.
Pod IPAM	Calico attribue initialement à chaque nouveau nœud un sous-réseau /26 (64 IP, dont au moins une est généralement utilisée comme IP tunl0, le reste étant disponible pour les pods). Si toutes les IP de pods d'un /26 sont utilisées, alors Calico attribue un deuxième sous-réseau /26 au nœud, et d'autres si nécessaire. Vous pouvez utiliser le site `calicoctl ipam check` pour voir les sous-réseaux attribués à chaque nœud.	OVN alloue initialement un sous-réseau de pods /24 (256 IP) à chaque nouveau nœud de cluster. Il n'est pas possible d'ajouter d'autres sous-réseaux de pods. Il attribue également à chaque nouveau nœud une IP de sous-réseau de jonction, qui est utilisée en interne par OVN
Routage de pod à pod	Utilise les routes linux. Utilise BGP pour distribuer les routes. `tunl0` l'interface BGP est utilisée sur chaque nœud pour l'encapsulation.	Open vSwitch (OVS) fonctionne sur chaque nœud et achemine le trafic de pod à pod. OVN configure les flux OVS pour définir le routage de pod à pod. De nombreuses autres interfaces sont créées sur chaque nœud, telles que : `ovs-system` `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` et sont utilisées par OVN et OVS
Règles réseau Kubernetes	Implémenté par `calico-node` en ajoutant des règles iptables. La journalisation des trafics bloqués par les politiques de réseau est possible, mais compliquée. Cela nécessite des politiques supplémentaires Calico qui utilisent une action "Log" et une certaine réflexion et planification sur où/quand placer ces actions Log. Les journaux sont envoyés à `syslog` sur le nœud de travail, ce qui peut être difficile à récupérer. Les journaux n'indiquent pas quelle politique a autorisé ou bloqué le trafic.	Mise en œuvre par OVS à l'aide d'ACL sur les ports logiques (pas iptables). Il est beaucoup plus facile d'enregistrer les suppressions de règles de réseau et/ou le trafic autorisé en utilisant des annotations. Annotez le(s) espace(s) de noms où vous voulez enregistrer l'activité de la politique, et si vous voulez enregistrer les autorisations, les refus, ou les deux. Les journaux sont envoyés au fichier `/var/log/ovn/acl-audit-log.log` dans le pod `ovnkube-node`. Des options de configuration permettent d'envoyer ces journaux vers d'autres cibles. Les journaux indiquent la politique qui a autorisé le trafic, mais pas celle qui l'a refusé, car les politiques n'autorisent que le trafic. Il doit y avoir au moins une politique en place pour que le trafic autorisé soit enregistré.
Politiques du réseau hôte	Calico GlobalNetworkPolicies	Aucun
Sous-réseaux supplémentaires	Aucun	Join Subnet: `100.64.0.0/16` ( OpenShift par défaut). Sous-réseau de mascarade: `169.254.64.0/18`. Cela diffère de la valeur par défaut de OpenShift, à savoir `169.254.0.0/17`. Cette différence permet d'éviter les conflits avec les IP de `169.254.2.0/24` qui sont utilisées pour le registre local haproxy. Sous-réseau de transit:`100.88.0.0/16` ( OpenShift par défaut).
Veille de l'APIserver	`calico-typha` enregistre les surveillances de ressources et agit en tant que mandataire auprès des modules `calico-node` pour les informer des changements. `calico-node` se connecte à l'un des pods `calico-typha` et s'enregistre pour être informé des changements de ressources.	Le conteneur `ovnkube-cluster-manager` dans le plan de contrôle surveille les nouveaux nœuds. Le conteneur `ovnkube-controller` sur chaque nœud du cluster surveille les ressources et les traduit en entrées logiques OVN dans la nbdb.
CNI	Les binaires CNI `calico` et `calico-ipam` sont copiés sur chaque nœud par `install-cni` initContainer sur le pod `calico-node`.	Le conteneur `ovnkube-controller` du pod `ovnkube-node` exécute le binaire CNI pour les appels d'ajout et de suppression.
Ressources créées	`calico-apiserver` espace de noms `calico-apiserver` (déploiement, 2 pods) `calico-system` espace de noms `calico-node` (chaque nœud) `calico-typha` (déploiement, de 2 à 10 pods). `calico-kube-controllers` (1 nœud). Espace de noms `openshift-kube-proxy`. `openshift-kube-proxy` (chaque nœud). `tigera-operator` espace de noms. `tigera-operator` (déploiement, 1 pod). Le binaire CNI `calico`, le binaire CNI `calico-ipam` et divers autres binaires CNI sont copiés sur chaque nœud par `install-cni` initContainer sur `calico-node`.	`openshift-ovn-kubernetes` l'espace de noms, `ovnkube-node` sur chaque nœud avec 8 conteneurs, `ovnkube-controller` surveille les ressources, alloue les IP des pods et traduit les ressources en entrées logiques OVN dans `nbdb`. Gère également l'ajout et la suppression de CNI. `nbdb` stocke les entrées logiques. `northd` convertit les entrées logiques de `nbdb` en flux logiques dans `sbdb`. `sbdb` stocke les flux logiques. `ovn-controller` convertit les flux logiques dans `sbdb` et programme le commutateur OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protège les métriques des nœuds afin que seuls les utilisateurs autorisés puissent les récupérer. `kube-rbac-proxy-ovn-metrics` protège les métriques OVN afin que seuls les utilisateurs autorisés puissent les récupérer.
Connexions entre les nacelles	Le pod `calico-node` se connecte d'abord à l'apiserver kube via l'haproxy local dans le pod proxy écoutant sur TCP 172.20.0.1:2040 pour obtenir la liste des pods `calico-typha`. Le module `calico-node` se connecte à l'un des modules `calico-typha` sur le port 5473 de TCP pour écouter les mises à jour des ressources du cluster. Le pod `calico-node` exécute le démon bird BGP qui se connecte en maillage complet à tous les autres démons bird BGP de `calico-node` sur le port 179 de TCP. Le trafic de pod à pod se fait directement pour les pods sur les nœuds du même sous-réseau. Le trafic de pod à pod entre les pods sur des nœuds dans des sous-réseaux différents est encapsulé en utilisant l'encapsulation IPinIP (ou VxLAN pour les clusters Satellite ).	Le conteneur `ovnkube-controller` sur chaque nœud se connecte à kube apiserver via un haproxy local dans un pod proxy écoutant sur TCP `172.20.0.1:2040` pour les veilles de ressources. Tout le trafic entre pods est encapsulé à l'aide de Geneve et envoyé via le port 6081 de UDP. Pour plus d'informations, voir Configuration de votre pare-feu.