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

Cloud privé virtuel

Consultez les informations suivantes pour choisir une interface réseau de conteneur (CNI).

Dans la version 4.20 d' IBM Cloud Kubernetes Service et les versions ultérieures, 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 Par défaut: Calico Il s'agit d'une plateforme unique dédiée à la mise en réseau, à la sécurité réseau et à l'observabilité pour toute distribution d' Kubernetes, que ce soit dans le cloud, sur site ou en périphérie. Que vous débutiez avec l' Kubernetes ou que vous exploitiez une infrastructure à grande échelle, les éditions open source, entreprise et cloud d' Calico vous offrent les fonctionnalités de mise en réseau, de sécurité et d'observabilité dont vous avez besoin. Pour plus d’informations, consultez la documentation d’ Calico.
OVN-Kubernetes (OVN) 4.20 et versions ultérieuresNœuds de travail RHCOS uniquement: OVN- Kubernetes, qui repose sur Open Virtual Network (OVN), offre une implémentation réseau de type overlay. Un cluster utilisant le plugin OVN- Kubernetes exécute également Open vSwitch (OVS) sur chaque nœud. OVN configure OVS sur chaque nœud afin de mettre en œuvre la configuration réseau déclarée. Pour plus d'informations, consultez la documentation relative à l' Red Hat.

Comparaison entre l' Calico et l'OVN

Consultez le tableau ci-dessous pour comparer les caractéristiques et les fonctionnalités d' 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 indiqués dans le tableau suivant. En cas de chevauchement de sous-réseaux, la communication entre pods é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 avec OVN
Composant	Calico	OVN - Kubernetes
Encapsulation	IP dans le protocole IP (et non UDP ou TCP ) Encapsule uniquement le trafic entre pods provenant de pods s'exécutant sur des nœuds situés dans des sous-réseaux différents.	Genève : protocole UDP sur le port 6081 Encapsule l'ensemble du trafic entre pods
Réseau de cluster par défaut / MTU des pods	1 480 octets (en-tête IPinIP de 20 octets) par défaut. Ce texte peut être modifié.	1 400 octets (en-tête Geneve de 100 octets) par défaut. Ce texte peut être modifié. Daemonset doit créer un fichier NetworkManager au lieu de se contenter de s'exécuter `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 adresses IP, dont au moins une est généralement utilisée comme adresse IP d' tunl0, les autres étant disponibles pour les pods). Si toutes les adresses IP des pods d'un sous-réseau /26 sont utilisées, Calico attribue un deuxième sous-réseau /26 au nœud, et d'autres si nécessaire. Vous pouvez utiliser la commande pour `calicoctl ipam check` afficher les sous-réseaux attribués à chaque nœud.	OVN attribue initialement un sous-réseau de pods /24 (256 adresses IP) à chaque nouveau nœud de cluster. Il n'est pas possible d'ajouter d'autres sous-réseaux de pod. Il attribue également une adresse IP de sous-réseau de jonction à chaque nouveau nœud, qui est utilisée en interne par OVN
Routage de pod à pod	Utilise des routes Linux. Utilise le protocole BGP pour distribuer les routes. Une interface `tunl0` sur chaque nœud pour l'encapsulation.	Open vSwitch (OVS) s'exécute sur chaque nœud et achemine le trafic entre les pods. OVN configure les flux OVS pour définir le routage entre les pods. De nombreuses autres interfaces sont créées sur chaque nœud, telles que : `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, et `br-ex` sont utilisées par OVN et OVS
Règles réseau Kubernetes	Mise en œuvre par `calico-node` l'ajout de règles iptables. L'enregistrement des trafics bloqués par les politiques réseau est possible, mais complexe. Cela nécessite des politiques d' Calico supplémentaires utilisant une action Log, ainsi qu'une réflexion et une planification quant à l'emplacement et au moment d'application de ces actions Log. Les journaux sont enregistrés sur `syslog` le nœud de travail, ce qui peut compliquer leur récupération. Les journaux n'indiquent pas quelle politique a autorisé ou bloqué le trafic.	Mise en œuvre par OVS à l’aide d’ACL sur des ports logiques (et non par iptables). La journalisation des rejets liés à la politique réseau et/ou du trafic autorisé est nettement simplifiée grâce à l’utilisation d’annotations. Annotez le ou les espaces de noms pour lesquels vous souhaitez journaliser l’activité liée à la politique, et précisez si vous souhaitez journaliser les autorisations, les refus ou les deux. Les journaux sont envoyés vers un 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 destinations de journalisation. Les journaux indiquent quelle politique a autorisé le trafic, mais pas quelle politique l’a refusé, car les politiques sont exclusivement de type autorisation. Au moins une politique doit être en place pour que le trafic autorisé soit journalisé.
Politiques relatives au réseau hôte	Calico GlobalNetworkPolicies	Aucun
Sous-réseaux supplémentaires	Aucun	Sous-réseau d'appartenance: `100.64.0.0/16` (par défaut : OpenShift ). Sous-réseau de masquerade: `169.254.64.0/18`. Cela diffère du style par défaut d’ OpenShift, qui est `169.254.0.0/17`. Cette différence vise à éviter tout conflit avec les adresses IP `169.254.2.0/24` utilisées pour le registre local haproxy. Sous-réseau de transit:`100.88.0.0/16` (par défaut OpenShift ).
APIserver surveille	enregistre `calico-typha` les surveillances de ressources et sert de proxy aux `calico-node` pods pour signaler les changements. se connecte `calico-node` à l'un des pods `calico-typha` et s'enregistre pour recevoir les notifications de changements de ressources.	Le conteneur `ovnkube-cluster-manager` du plan de contrôle surveille l'apparition de nouveaux nœuds. Le `ovnkube-controller` conteneur de chaque nœud du cluster surveille les ressources et les convertit en entrées logiques OVN dans la base de données nbdb.
CNI	Les binaires et `calico` CNI `calico-ipam` sont copiés sur chaque nœud par le initContainer`install-cni` sur le pod `calico-node`.	Le conteneur `ovnkube-controller` du `ovnkube-node` pod exécute le binaire CNI pour les appels d'ajout et de suppression.
Ressources créées	espace `calico-apiserver` 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` 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 initContainer`install-cni` lors de `calico-node`.	namespace `openshift-ovn-kubernetes`, `ovnkube-node` sur chaque nœud comportant 8 conteneurs, `ovnkube-controller` surveille les ressources, attribue des adresses IP aux pods et convertit les ressources en entrées logiques OVN dans `nbdb`. Gère également l'ajout et la suppression de CNI. stocke `nbdb` les entrées logiques. `northd` convertit les entrées logiques de `nbdb` en flux logiques dans `sbdb`. `sbdb` stocke les flux logiques. convertit `ovn-controller` 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 extraire. `kube-rbac-proxy-ovn-metrics` protège les métriques OVN afin que seuls les utilisateurs autorisés puissent les extraire.
Connexions entre les pods	Le pod `calico-node` se connecte initialement au serveur API Kubernetes via un proxy haproxy local dans un pod proxy écoutant sur TCP172.20.0.1:2040 pour obtenir la liste des pods `calico-typha`. Le pod `calico-node` se connecte à l’un des `calico-typha` pods sur TCP au port 5473 pour écouter les mises à jour des ressources du cluster. Le `calico-node` pod exécute le démon Bird BGP qui se connecte en maillage complet à tous les autres démons `calico-node` Bird BGP sur TCP au port 179. Le trafic de pod à pod s'effectue directement entre les pods situés sur des nœuds du même sous-réseau. Le trafic de pod à pod entre des pods situés sur des nœuds de sous-réseaux différents est encapsulé à l’aide de l’encapsulation IPinIP (ou VxLAN pour les clusters Satellite ).	Le conteneur `ovnkube-controller` de chaque nœud se connecte au kube apiserver via un haproxy local dans un pod proxy écoutant sur TCP pour `172.20.0.1:2040` la surveillance des ressources. Tout le trafic entre pods est encapsulé à l'aide de Geneve et transmis via UDP sur le port 6081. Pour plus d'informations, consultez la section Configuration de votre pare-feu.