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

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

Dans la version Red Hat OpenShift on IBM Cloud 4.20 et les versions ultérieures, Calico est le CNI par défaut, mais les clusters 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.
Open Virutal Network (OVN) 4.20 et versions ultérieures Nœuds de travail RHCOS uniquement: Open Virtual Network (OVN) est une solution Open vSwitch-based de mise en réseau définie par logiciel (SDN) pour fournir des services réseau aux instances. OVN offre une prise en charge neutre de l'ensemble de l'API de mise en réseau OpenStack. Avec OVN, vous pouvez programmer la connexion de groupes d'instances invitées à des réseaux privés L2 et L3. 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.

Si vous prévoyez d'utiliser OVN, vous devez vous assurer que les sous-réseaux de votre VPC n'empiètent pas sur 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 et layer3 user defined networks (UDN) ne sont pas pris en charge avec les charges de travail qui utilisent DHCP, telles que les VM de virtualisation Openshift.

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	Ceci est mis en œuvre par calico-ipam CNI et non par les conteneurs dans le cluster. Les IP et les sous-réseaux de pods utilisés et libres sont stockés en tant que ressources personnalisées dans le cluster. 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 d'un /26 sont utilisées, Calico attribue un deuxième sous-réseau /26 au nœud. Vous pouvez utiliser le site `calicoctl ipam check` pour voir les sous-réseaux attribués à chaque nœud. Le CNI `calico-ipam` attribue une IP à chaque nouveau pod.	L'IPAM du pod est géré à la fois par le pod `ovnkube-control-plane` (conteneur `ovnkube-cluster-manager` ) dans le plan de contrôle et par les pods `ovnkube-node` dans le cluster client (conteneur `ovnkube-controller` ). Le conteneur `ovnkube-cluster-manager` dans le plan de contrôle surveille les nouveaux nœuds et alloue un sous-réseau de pod /24 (256 IP) à chaque nouveau nœud du cluster. Seul un sous-réseau de pods /24 est ajouté, sans possibilité d'en ajouter un second. Il attribue également une IP de sous-réseau de jonction à chaque nouveau nœud. Le conteneur `ovnkube-controller` sur chaque nœud du cluster surveille toutes les ressources k8s et attribue une IP de pod à chaque nouveau pod.
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 via Geneve. De nombreuses interfaces ont été créées, telles que : `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex`
Règles réseau Kubernetes	Implémenté par `calico-node` en ajoutant des règles iptables. Enregistre les interruptions et/ou les autorisations de la politique de réseau. 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é 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. \N- -n Les journaux sont envoyés au fichier `/var/log/ovn/acl-audit-log.log` dans le pod `ovnkube-node`. Il existe des options de configuration permettant d'envoyer ces journaux vers d'autres cibles. Les journaux indiquent la stratégie qui a autorisé le trafic, mais pas celle qui l'a refusé, car les stratégies n'autorisent que les autorisations. 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 sur 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). `openshift-kube-proxy` espace de noms. `openshift-kube-proxy` (chaque nœud). `tigera-operator`. `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 entre pods se fait directement pour les pods sur les nœuds dans le même sous-réseau et protocole/port que le pod utilise et utilise IPinIP sans port pour le trafic encapsulé.	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 se fait via le tunnel Geneve sur UDP port 6081. - Pour plus d'informations, voir Configuration de votre pare-feu.