24.2. Architecture OVN-Kubernetes
24.2.1. Introduction à l'architecture OVN-Kubernetes
Le schéma suivant présente l'architecture OVN-Kubernetes.
Figure 24.1. Architecture OVK-Kubernetes
Les éléments clés sont les suivants :
- Cloud Management System (CMS) - Un client spécifique à la plateforme pour OVN qui fournit un plugin spécifique au CMS pour l'intégration d'OVN. Le plugin traduit le concept de configuration logique du réseau du système de gestion en nuage, stocké dans la base de données de configuration du CMS dans un format spécifique au CMS, en une représentation intermédiaire comprise par OVN.
-
OVN Northbound database (
nbdb) - Stocke la configuration logique du réseau transmise par le plugin CMS. -
OVN Southbound database (
sbdb) - Stocke l'état de la configuration physique et logique du réseau pour le système OpenVswitch (OVS) sur chaque nœud, y compris les tables qui les lient. -
ovn-northd - Il s'agit du client intermédiaire entre
nbdbetsbdb. Il traduit la configuration logique du réseau en termes de concepts de réseau conventionnels, tirés denbdb, en flux de chemins de données logiques danssbdben dessous de lui. Le nom du conteneur estnorthdet il fonctionne dans les podsovnkube-master. -
ovn-controller - Il s'agit de l'agent OVN qui interagit avec OVS et les hyperviseurs pour toute information ou mise à jour nécessaire à
sbdb. Leovn-controllerlit les flux logiques depuis lesbdb, les traduit en fluxOpenFlowet les envoie au démon OVS du nœud. Le nom du conteneur estovn-controlleret il s'exécute dans les podsovnkube-node.
La base de données OVN northbound possède la configuration logique du réseau qui lui a été transmise par le système de gestion des nuages (CMS). La base de données OVN northbound contient l'état actuel souhaité du réseau, présenté comme une collection de ports logiques, de commutateurs logiques, de routeurs logiques, etc. Le ovn-northd (conteneurnorthd ) se connecte à la base de données OVN northbound et à la base de données OVN southbound. Il traduit la configuration logique du réseau en termes de concepts de réseau conventionnels, tirés de la base de données OVN northbound, en flux de chemins de données logiques dans la base de données OVN southbound.
La base de données southbound d'OVN contient des représentations physiques et logiques du réseau et des tables de liaison qui les relient. Chaque nœud du cluster est représenté dans la base de données southbound, et vous pouvez voir les ports qui y sont connectés. Elle contient également tous les flux logiques, qui sont partagés avec le processus ovn-controller qui s'exécute sur chaque nœud et que ovn-controller transforme en règles OpenFlow pour programmer Open vSwitch.
Les nœuds du plan de contrôle Kubernetes contiennent chacun un pod ovnkube-master qui héberge des conteneurs pour les bases de données OVN northbound et southbound. Toutes les bases de données OVN en direction du nord forment un cluster Raft et toutes les bases de données en direction du sud forment un cluster Raft distinct. À tout moment, un seul ovnkube-master est le leader et les autres pods ovnkube-master sont des suiveurs.
24.2.2. Liste de toutes les ressources du projet OVN-Kubernetes
Il est important de trouver les ressources et les conteneurs qui fonctionnent dans le projet OVN-Kubernetes pour vous aider à comprendre la mise en œuvre du réseau OVN-Kubernetes.
Conditions préalables
-
Accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
L'OpenShift CLI (
oc) est installé.
Procédure
Exécutez la commande suivante pour obtenir toutes les ressources, les points de terminaison et
ConfigMapsdans le projet OVN-Kubernetes :$ oc get all,ep,cm -n openshift-ovn-kubernetes
Exemple de sortie
NAME READY STATUS RESTARTS AGE pod/ovnkube-master-9g7zt 6/6 Running 1 (48m ago) 57m pod/ovnkube-master-lqs4v 6/6 Running 0 57m pod/ovnkube-master-vxhtq 6/6 Running 0 57m pod/ovnkube-node-9k9kc 5/5 Running 0 57m pod/ovnkube-node-jg52r 5/5 Running 0 51m pod/ovnkube-node-k8wf7 5/5 Running 0 57m pod/ovnkube-node-tlwk6 5/5 Running 0 47m pod/ovnkube-node-xsvnk 5/5 Running 0 57m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/ovn-kubernetes-master ClusterIP None <none> 9102/TCP 57m service/ovn-kubernetes-node ClusterIP None <none> 9103/TCP,9105/TCP 57m service/ovnkube-db ClusterIP None <none> 9641/TCP,9642/TCP 57m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/ovnkube-master 3 3 3 3 3 beta.kubernetes.io/os=linux,node-role.kubernetes.io/master= 57m daemonset.apps/ovnkube-node 5 5 5 5 5 beta.kubernetes.io/os=linux 57m NAME ENDPOINTS AGE endpoints/ovn-kubernetes-master 10.0.132.11:9102,10.0.151.18:9102,10.0.192.45:9102 57m endpoints/ovn-kubernetes-node 10.0.132.11:9105,10.0.143.72:9105,10.0.151.18:9105 + 7 more... 57m endpoints/ovnkube-db 10.0.132.11:9642,10.0.151.18:9642,10.0.192.45:9642 + 3 more... 57m NAME DATA AGE configmap/control-plane-status 1 55m configmap/kube-root-ca.crt 1 57m configmap/openshift-service-ca.crt 1 57m configmap/ovn-ca 1 57m configmap/ovn-kubernetes-master 0 55m configmap/ovnkube-config 1 57m configmap/signer-ca 1 57m
Trois sites
ovnkube-masterssont exécutés sur les nœuds du plan de contrôle, et deux ensembles de démons sont utilisés pour déployer les modulesovnkube-masteretovnkube-node. Il y a un podovnkube-nodepour chaque nœud du cluster. Dans cet exemple, il y en a 5, et comme il y a unovnkube-nodepar nœud dans le cluster, il y a cinq nœuds dans le cluster. Le podovnkube-configConfigMapcontient les configurations OpenShift Container Platform OVN-Kubernetes démarrées par online-master etovnkube-node. Le siteovn-kubernetes-masterConfigMapcontient les informations sur le maître en ligne actuel.Listez tous les conteneurs dans les pods
ovnkube-masteren exécutant la commande suivante :$ oc get pods ovnkube-master-9g7zt \ -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesRésultats attendus
northd nbdb kube-rbac-proxy sbdb ovnkube-master ovn-dbchecker
Le pod
ovnkube-masterest composé de plusieurs conteneurs. Il est responsable de l'hébergement de la base de données nord (conteneurnbdb), de la base de données sud (conteneursbdb), de la surveillance des événements du cluster pour les pods, egressIP, namespaces, services, endpoints, egress firewall et network policy et de leur écriture dans la base de données nord (podovnkube-master), ainsi que de la gestion de l'allocation des sous-réseaux des pods aux nœuds.Listez tous les conteneurs dans les pods
ovnkube-nodeen exécutant la commande suivante :$ oc get pods ovnkube-node-jg52r \ -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesRésultats attendus
ovn-controller ovn-acl-logging kube-rbac-proxy kube-rbac-proxy-ovn-metrics ovnkube-node
Le pod
ovnkube-nodea un conteneur (ovn-controller) qui réside sur chaque nœud d'OpenShift Container Platform. Le siteovn-controllerde chaque nœud connecte la base de données OVN northbound à la base de données OVN southbound pour connaître la configuration OVN. Leovn-controllerse connecte au sud auovs-vswitchden tant que contrôleur OpenFlow, pour contrôler le trafic réseau, et auovsdb-serverlocal pour lui permettre de surveiller et de contrôler la configuration de l'Open vSwitch.
24.2.3. Liste du contenu de la base de données OVN-Kubernetes northbound
Pour comprendre les règles de flux logique, il faut examiner la base de données de la connexion nord et comprendre quels objets s'y trouvent pour voir comment ils sont traduits en règles de flux logique. L'information à jour est présente sur l'OVN Raft leader et cette procédure décrit comment trouver le Raft leader et ensuite l'interroger pour lister le contenu de la base de données de la liaison nord de l'OVN.
Conditions préalables
-
Accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
L'OpenShift CLI (
oc) est installé.
Procédure
Trouver le chef de file du radeau OVN pour la base de données en direction du nord.
NoteLe chef de file du radeau stocke les informations les plus récentes.
Dressez la liste des pods en exécutant la commande suivante :
$ oc get po -n openshift-ovn-kubernetes
Exemple de sortie
NAME READY STATUS RESTARTS AGE ovnkube-master-7j97q 6/6 Running 2 (148m ago) 149m ovnkube-master-gt4ms 6/6 Running 1 (140m ago) 147m ovnkube-master-mk6p6 6/6 Running 0 148m ovnkube-node-8qvtr 5/5 Running 0 149m ovnkube-node-fqdc9 5/5 Running 0 149m ovnkube-node-tlfwv 5/5 Running 0 149m ovnkube-node-wlwkn 5/5 Running 0 142m
Choisissez au hasard l'un des pods maîtres et exécutez la commande suivante :
$ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \ -- /usr/bin/ovn-appctl -t /var/run/ovn/ovnnb_db.ctl \ --timeout=3 cluster/status OVN_Northbound
Exemple de sortie
Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker 1c57 Name: OVN_Northbound Cluster ID: c48a (c48aa5c0-a704-4c77-a066-24fe99d9b338) Server ID: 1c57 (1c57b6fc-2849-49b7-8679-fbf18bafe339) Address: ssl:10.0.147.219:9643 Status: cluster member Role: follower 1 Term: 5 Leader: 2b4f 2 Vote: unknown Election timer: 10000 Log: [2, 3018] Entries not yet committed: 0 Entries not yet applied: 0 Connections: ->0000 ->0000 <-8844 <-2b4f Disconnections: 0 Servers: 1c57 (1c57 at ssl:10.0.147.219:9643) (self) 8844 (8844 at ssl:10.0.163.212:9643) last msg 8928047 ms ago 2b4f (2b4f at ssl:10.0.242.240:9643) last msg 620 ms ago 3
Recherchez le pod
ovnkube-masterfonctionnant sur l'adresse IP10.0.242.240à l'aide de la commande suivante :$ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.242.240 | grep -v ovnkube-node
Exemple de sortie
ovnkube-master-gt4ms 6/6 Running 1 (143m ago) 150m 10.0.242.240 ip-10-0-242-240.ec2.internal <none> <none>
Le pod
ovnkube-master-gt4msfonctionne sur l'adresse IP 10.0.242.240.
Exécutez la commande suivante pour afficher tous les objets de la base de données northbound :
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \ -c northd -- ovn-nbctl show
Le résultat est trop long pour être énuméré ici. La liste comprend les règles NAT, les commutateurs logiques, les équilibreurs de charge, etc.
Exécutez la commande suivante pour afficher les options disponibles avec la commande
ovn-nbctl:$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \ -c northd ovn-nbctl --help
Vous pouvez vous concentrer sur des composants spécifiques en utilisant certaines des commandes suivantes :
Exécutez la commande suivante pour afficher la liste des routeurs logiques :
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \ -c northd -- ovn-nbctl lr-list
Exemple de sortie
f971f1f3-5112-402f-9d1e-48f1d091ff04 (GR_ip-10-0-145-205.ec2.internal) 69c992d8-a4cf-429e-81a3-5361209ffe44 (GR_ip-10-0-147-219.ec2.internal) 7d164271-af9e-4283-b84a-48f2a44851cd (GR_ip-10-0-163-212.ec2.internal) 111052e3-c395-408b-97b2-8dd0a20a29a5 (GR_ip-10-0-165-9.ec2.internal) ed50ce33-df5d-48e8-8862-2df6a59169a0 (GR_ip-10-0-209-170.ec2.internal) f44e2a96-8d1e-4a4d-abae-ed8728ac6851 (GR_ip-10-0-242-240.ec2.internal) ef3d0057-e557-4b1a-b3c6-fcc3463790b0 (ovn_cluster_router)
NoteCette sortie montre qu'il y a un routeur sur chaque nœud et un
ovn_cluster_router.Exécutez la commande suivante pour afficher la liste des commutateurs logiques :
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \ -c northd -- ovn-nbctl ls-list
Exemple de sortie
82808c5c-b3bc-414a-bb59-8fec4b07eb14 (ext_ip-10-0-145-205.ec2.internal) 3d22444f-0272-4c51-afc6-de9e03db3291 (ext_ip-10-0-147-219.ec2.internal) bf73b9df-59ab-4c58-a456-ce8205b34ac5 (ext_ip-10-0-163-212.ec2.internal) bee1e8d0-ec87-45eb-b98b-63f9ec213e5e (ext_ip-10-0-165-9.ec2.internal) 812f08f2-6476-4abf-9a78-635f8516f95e (ext_ip-10-0-209-170.ec2.internal) f65e710b-32f9-482b-8eab-8d96a44799c1 (ext_ip-10-0-242-240.ec2.internal) 84dad700-afb8-4129-86f9-923a1ddeace9 (ip-10-0-145-205.ec2.internal) 1b7b448b-e36c-4ca3-9f38-4a2cf6814bfd (ip-10-0-147-219.ec2.internal) d92d1f56-2606-4f23-8b6a-4396a78951de (ip-10-0-163-212.ec2.internal) 6864a6b2-de15-4de3-92d8-f95014b6f28f (ip-10-0-165-9.ec2.internal) c26bf618-4d7e-4afd-804f-1a2cbc96ec6d (ip-10-0-209-170.ec2.internal) ab9a4526-44ed-4f82-ae1c-e20da04947d9 (ip-10-0-242-240.ec2.internal) a8588aba-21da-4276-ba0f-9d68e88911f0 (join)
NoteCette sortie montre qu'il y a un commutateur ext pour chaque nœud, des commutateurs avec le nom du nœud lui-même et un commutateur join.
Exécutez la commande suivante pour afficher la liste des équilibreurs de charge :
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \ -c northd -- ovn-nbctl lb-list
Exemple de sortie
UUID LB PROTO VIP IPs f0fb50f9-4968-4b55-908c-616bae4db0a2 Service_default/ tcp 172.30.0.1:443 10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443 0dc42012-4f5b-432e-ae01-2cc4bfe81b00 Service_default/ tcp 172.30.0.1:443 10.0.147.219:6443,169.254.169.2:6443,10.0.242.240:6443 f7fff5d5-5eff-4a40-98b1-3a4ba8f7f69c Service_default/ tcp 172.30.0.1:443 169.254.169.2:6443,10.0.163.212:6443,10.0.242.240:6443 12fe57a0-50a4-4a1b-ac10-5f288badee07 Service_default/ tcp 172.30.0.1:443 10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443 3f137fbf-0b78-4875-ba44-fbf89f254cf7 Service_openshif tcp 172.30.23.153:443 10.130.0.14:8443 174199fe-0562-4141-b410-12094db922a7 Service_openshif tcp 172.30.69.51:50051 10.130.0.84:50051 5ee2d4bd-c9e2-4d16-a6df-f54cd17c9ac3 Service_openshif tcp 172.30.143.87:9001 10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,10.0.242.240:9001 a056ae3d-83f8-45bc-9c80-ef89bce7b162 Service_openshif tcp 172.30.164.74:443 10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443 bac51f3d-9a6f-4f5e-ac02-28fd343a332a Service_openshif tcp 172.30.0.10:53 10.131.0.6:5353 tcp 172.30.0.10:9154 10.131.0.6:9154 48105bbc-51d7-4178-b975-417433f9c20a Service_openshif tcp 172.30.26.159:2379 10.0.147.219:2379,169.254.169.2:2379,10.0.242.240:2379 tcp 172.30.26.159:9979 10.0.147.219:9979,169.254.169.2:9979,10.0.242.240:9979 7de2b8fc-342a-415f-ac13-1a493f4e39c0 Service_openshif tcp 172.30.53.219:443 10.128.0.7:8443 tcp 172.30.53.219:9192 10.128.0.7:9192 2cef36bc-d720-4afb-8d95-9350eff1d27a Service_openshif tcp 172.30.81.66:443 10.128.0.23:8443 365cb6fb-e15e-45a4-a55b-21868b3cf513 Service_openshif tcp 172.30.96.51:50051 10.130.0.19:50051 41691cbb-ec55-4cdb-8431-afce679c5e8d Service_openshif tcp 172.30.98.218:9099 169.254.169.2:9099 82df10ba-8143-400b-977a-8f5f416a4541 Service_openshif tcp 172.30.26.159:2379 10.0.147.219:2379,10.0.163.212:2379,169.254.169.2:2379 tcp 172.30.26.159:9979 10.0.147.219:9979,10.0.163.212:9979,169.254.169.2:9979 debe7f3a-39a8-490e-bc0a-ebbfafdffb16 Service_openshif tcp 172.30.23.244:443 10.128.0.48:8443,10.129.0.27:8443,10.130.0.45:8443 8a749239-02d9-4dc2-8737-716528e0da7b Service_openshif tcp 172.30.124.255:8443 10.128.0.14:8443 880c7c78-c790-403d-a3cb-9f06592717a3 Service_openshif tcp 172.30.0.10:53 10.130.0.20:5353 tcp 172.30.0.10:9154 10.130.0.20:9154 d2f39078-6751-4311-a161-815bbaf7f9c7 Service_openshif tcp 172.30.26.159:2379 169.254.169.2:2379,10.0.163.212:2379,10.0.242.240:2379 tcp 172.30.26.159:9979 169.254.169.2:9979,10.0.163.212:9979,10.0.242.240:9979 30948278-602b-455c-934a-28e64c46de12 Service_openshif tcp 172.30.157.35:9443 10.130.0.43:9443 2cc7e376-7c02-4a82-89e8-dfa1e23fb003 Service_openshif tcp 172.30.159.212:17698 10.128.0.48:17698,10.129.0.27:17698,10.130.0.45:17698 e7d22d35-61c2-40c2-bc30-265cff8ed18d Service_openshif tcp 172.30.143.87:9001 10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,169.254.169.2:9001 75164e75-e0c5-40fb-9636-bfdbf4223a02 Service_openshif tcp 172.30.150.68:1936 10.129.4.8:1936,10.131.0.10:1936 tcp 172.30.150.68:443 10.129.4.8:443,10.131.0.10:443 tcp 172.30.150.68:80 10.129.4.8:80,10.131.0.10:80 7bc4ee74-dccf-47e9-9149-b011f09aff39 Service_openshif tcp 172.30.164.74:443 10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443 0db59e74-1cc6-470c-bf44-57c520e0aa8f Service_openshif tcp 10.0.163.212:31460 tcp 10.0.163.212:32361 c300e134-018c-49af-9f84-9deb1d0715f8 Service_openshif tcp 172.30.42.244:50051 10.130.0.47:50051 5e352773-429b-4881-afb3-a13b7ba8b081 Service_openshif tcp 172.30.244.66:443 10.129.0.8:8443,10.130.0.8:8443 54b82d32-1939-4465-a87d-f26321442a7a Service_openshif tcp 172.30.12.9:8443 10.128.0.35:8443NoteA partir de cette sortie tronquée, vous pouvez voir qu'il y a beaucoup de répartiteurs de charge OVN-Kubernetes. Les équilibreurs de charge dans OVN-Kubernetes sont des représentations de services.
24.2.4. Arguments de ligne de commande pour ovn-nbctl afin d'examiner le contenu de la base de données de la liaison descendante
Le tableau suivant décrit les arguments de ligne de commande qui peuvent être utilisés avec ovn-nbctl pour examiner le contenu de la base de données northbound.
| Argument | Description |
|---|---|
|
| Une vue d'ensemble du contenu de la base de données pour le trafic nord. |
|
| Affiche les détails associés au commutateur ou au routeur spécifié. |
|
| Afficher les routeurs logiques. |
|
|
Utilisation des informations du routeur à partir de |
|
| Affiche les détails de la traduction d'adresses réseau pour le routeur spécifié. |
|
| Afficher les commutateurs logiques |
|
|
Utilisation des informations sur le commutateur à partir de |
|
| Obtenir le type du port logique. |
|
| Montrer les équilibreurs de charge. |
24.2.5. Liste du contenu de la base de données OVN-Kubernetes en direction du sud
Les règles de flux logiques sont stockées dans la base de données southbound qui est une représentation de votre infrastructure. L'information à jour est présente sur le Raft leader OVN et cette procédure décrit comment trouver le Raft leader et l'interroger pour lister le contenu de la base de données OVN southbound.
Conditions préalables
-
Accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
L'OpenShift CLI (
oc) est installé.
Procédure
Trouver le chef de file du radeau OVN pour la base de données en direction du sud.
NoteLe chef de file du radeau stocke les informations les plus récentes.
Dressez la liste des pods en exécutant la commande suivante :
$ oc get po -n openshift-ovn-kubernetes
Exemple de sortie
NAME READY STATUS RESTARTS AGE ovnkube-master-7j97q 6/6 Running 2 (134m ago) 135m ovnkube-master-gt4ms 6/6 Running 1 (126m ago) 133m ovnkube-master-mk6p6 6/6 Running 0 134m ovnkube-node-8qvtr 5/5 Running 0 135m ovnkube-node-bqztb 5/5 Running 0 117m ovnkube-node-fqdc9 5/5 Running 0 135m ovnkube-node-tlfwv 5/5 Running 0 135m ovnkube-node-wlwkn 5/5 Running 0 128m
Choisissez au hasard l'un des pods principaux et exécutez la commande suivante pour trouver le chef de file du radeau OVN en direction du sud :
$ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \ -- /usr/bin/ovn-appctl -t /var/run/ovn/ovnsb_db.ctl \ --timeout=3 cluster/status OVN_Southbound
Exemple de sortie
Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker 1930 Name: OVN_Southbound Cluster ID: f772 (f77273c0-7986-42dd-bd3c-a9f18e25701f) Server ID: 1930 (1930f4b7-314b-406f-9dcb-b81fe2729ae1) Address: ssl:10.0.147.219:9644 Status: cluster member Role: follower 1 Term: 3 Leader: 7081 2 Vote: unknown Election timer: 16000 Log: [2, 2423] Entries not yet committed: 0 Entries not yet applied: 0 Connections: ->0000 ->7145 <-7081 <-7145 Disconnections: 0 Servers: 7081 (7081 at ssl:10.0.163.212:9644) last msg 59 ms ago 3 1930 (1930 at ssl:10.0.147.219:9644) (self) 7145 (7145 at ssl:10.0.242.240:9644) last msg 7871735 ms ago
Recherchez le pod
ovnkube-masterfonctionnant sur l'adresse IP10.0.163.212à l'aide de la commande suivante :$ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.163.212 | grep -v ovnkube-node
Exemple de sortie
ovnkube-master-mk6p6 6/6 Running 0 136m 10.0.163.212 ip-10-0-163-212.ec2.internal <none> <none>
Le pod
ovnkube-master-mk6p6fonctionne sur l'adresse IP 10.0.163.212.
Exécutez la commande suivante pour afficher toutes les informations stockées dans la base de données "southbound" :
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \ -c northd -- ovn-sbctl show
Exemple de sortie
Chassis "8ca57b28-9834-45f0-99b0-96486c22e1be" hostname: ip-10-0-156-16.ec2.internal Encap geneve ip: "10.0.156.16" options: {csum="true"} Port_Binding k8s-ip-10-0-156-16.ec2.internal Port_Binding etor-GR_ip-10-0-156-16.ec2.internal Port_Binding jtor-GR_ip-10-0-156-16.ec2.internal Port_Binding openshift-ingress-canary_ingress-canary-hsblx Port_Binding rtoj-GR_ip-10-0-156-16.ec2.internal Port_Binding openshift-monitoring_prometheus-adapter-658fc5967-9l46x Port_Binding rtoe-GR_ip-10-0-156-16.ec2.internal Port_Binding openshift-multus_network-metrics-daemon-77nvz Port_Binding openshift-ingress_router-default-64fd8c67c7-df598 Port_Binding openshift-dns_dns-default-ttpcq Port_Binding openshift-monitoring_alertmanager-main-0 Port_Binding openshift-e2e-loki_loki-promtail-g2pbh Port_Binding openshift-network-diagnostics_network-check-target-m6tn4 Port_Binding openshift-monitoring_thanos-querier-75b5cf8dcb-qf8qj Port_Binding cr-rtos-ip-10-0-156-16.ec2.internal Port_Binding openshift-image-registry_image-registry-7b7bc44566-mp9b8Cette sortie détaillée montre le châssis et les ports qui sont attachés au châssis qui, dans ce cas, sont tous les ports du routeur et tout ce qui fonctionne comme un réseau hôte. Tous les pods communiquent avec le réseau plus large en utilisant la traduction d'adresse du réseau source (SNAT). Leur adresse IP est traduite en adresse IP du nœud sur lequel le module fonctionne, puis envoyée sur le réseau.
Outre les informations relatives au châssis, la base de données de la sortie sud contient tous les flux logiques, qui sont ensuite envoyés à
ovn-controller, qui fonctionne sur chacun des nœuds.ovn-controllertraduit les flux logiques en règles de flux ouvert et programme finalementOpenvSwitchafin que vos pods puissent suivre les règles de flux ouvert et sortir du réseau.Exécutez la commande suivante pour afficher les options disponibles avec la commande
ovn-sbctl:$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \ -c northd -- ovn-sbctl --help
24.2.6. Arguments de ligne de commande pour ovn-sbctl afin d'examiner le contenu de la base de données de la liaison descendante
Le tableau suivant décrit les arguments de ligne de commande qui peuvent être utilisés avec ovn-sbctl pour examiner le contenu de la base de données de la liaison descendante.
| Argument | Description |
|---|---|
|
| Vue d'ensemble du contenu de la base de données de la direction sud. |
|
| Répertorie le contenu de la base de données de la sortie sud pour le port spécifié. |
|
| Dresser la liste des flux logiques. |
24.2.7. Architecture logique OVN-Kubernetes
OVN est une solution de virtualisation du réseau. Il crée des commutateurs et des routeurs logiques. Ces commutateurs et routeurs sont interconnectés pour créer n'importe quelle topologie de réseau. Lorsque vous exécutez ovnkube-trace avec le niveau de journal défini sur 2 ou 5, les composants logiques OVN-Kubernetes sont exposés. Le diagramme suivant montre comment les routeurs et les commutateurs sont connectés dans OpenShift Container Platform.
Figure 24.2. Composants du routeur et du commutateur OVN-Kubernetes
Les principaux composants impliqués dans le traitement des paquets sont les suivants :
- Routeurs de passerelle
-
Les routeurs passerelle, parfois appelés routeurs passerelle L3, sont généralement utilisés entre les routeurs distribués et le réseau physique. Les routeurs passerelle, y compris leurs ports de connexion logiques, sont liés à un emplacement physique (non distribué) ou à un châssis. Les ports de raccordement de ce routeur sont appelés ports l3gateway dans la base de données ovn-southbound (
ovn-sbdb). - Routeurs logiques distribués
- Les routeurs logiques distribués et les commutateurs logiques derrière eux, auxquels les machines virtuelles et les conteneurs s'attachent, résident effectivement sur chaque hyperviseur.
- Rejoindre le commutateur local
- Les commutateurs locaux Join sont utilisés pour connecter le routeur distribué et les routeurs de passerelle. Ils réduisent le nombre d'adresses IP nécessaires sur le routeur distribué.
- Commutateurs logiques avec ports de brassage
- Les commutateurs logiques avec ports de connexion sont utilisés pour virtualiser la pile du réseau. Ils connectent des ports logiques distants par le biais de tunnels.
- Commutateurs logiques avec ports localnet
- Les commutateurs logiques dotés de ports localnet sont utilisés pour connecter l'OVN au réseau physique. Ils relient les ports logiques distants en pontant les paquets vers les segments L2 physiques directement connectés à l'aide des ports localnet.
- Ports de brassage
- Les ports de brassage représentent la connectivité entre les commutateurs logiques et les routeurs logiques, ainsi qu'entre les routeurs logiques homologues. Une connexion unique possède une paire de ports de brassage à chacun de ces points de connectivité, un de chaque côté.
- ports l3gateway
-
les ports l3gateway sont les entrées de liaison de port dans le site
ovn-sbdbpour les ports de connexion logiques utilisés dans les routeurs passerelle. Ils sont appelés ports l3gateway plutôt que ports patch pour illustrer le fait que ces ports sont liés à un châssis tout comme le routeur gateway lui-même. - ports localnet
-
des ports localnet sont présents sur les commutateurs logiques pontés qui permettent une connexion à un réseau accessible localement à partir de chaque instance
ovn-controller. Cela permet de modéliser la connectivité directe au réseau physique à partir des commutateurs logiques. Un commutateur logique ne peut être relié qu'à un seul port localnet.
24.2.7.1. Installation de network-tools sur l'hôte local
Installez network-tools sur votre hôte local pour disposer d'une collection d'outils permettant de déboguer les problèmes de réseau des clusters OpenShift Container Platform.
Procédure
Clonez le dépôt
network-toolssur votre station de travail avec la commande suivante :$ git clone git@github.com:openshift/network-tools.git
Allez dans le répertoire du dépôt que vous venez de cloner :
$ cd network-tools
Facultatif : Liste de toutes les commandes disponibles :
$ ./debug-scripts/network-tools -h
24.2.7.2. Exécution de network-tools
Obtenez des informations sur les commutateurs logiques et les routeurs en exécutant network-tools.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous êtes connecté au cluster en tant qu'utilisateur disposant des privilèges
cluster-admin. -
Vous avez installé
network-toolssur l'hôte local.
Procédure
Dressez la liste des routeurs en exécutant la commande suivante :
$ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
Exemple de sortie
Leader pod is ovnkube-master-vslqm 5351ddd1-f181-4e77-afc6-b48b0a9df953 (GR_helix13.lab.eng.tlv2.redhat.com) ccf9349e-1948-4df8-954e-39fb0c2d4d06 (GR_helix14.lab.eng.tlv2.redhat.com) e426b918-75a8-4220-9e76-20b7758f92b7 (GR_hlxcl7-master-0.hlxcl7.lab.eng.tlv2.redhat.com) dded77c8-0cc3-4b99-8420-56cd2ae6a840 (GR_hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com) 4f6747e6-e7ba-4e0c-8dcd-94c8efa51798 (GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com) 52232654-336e-4952-98b9-0b8601e370b4 (ovn_cluster_router)
Dressez la liste des ports localnet en exécutant la commande suivante :
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnet
Exemple de sortie
Leader pod is ovnkube-master-vslqm _uuid : 3de79191-cca8-4c28-be5a-a228f0f9ebfc additional_chassis : [] additional_encap : [] chassis : [] datapath : 3f1a4928-7ff5-471f-9092-fe5f5c67d15c encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : br-ex_helix13.lab.eng.tlv2.redhat.com mac : [unknown] nat_addresses : [] options : {network_name=physnet} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 2 type : localnet up : false virtual_parent : [] _uuid : dbe21daf-9594-4849-b8f0-5efbfa09a455 additional_chassis : [] additional_encap : [] chassis : [] datapath : db2a6067-fe7c-4d11-95a7-ff2321329e11 encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : br-ex_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com mac : [unknown] nat_addresses : [] options : {network_name=physnet} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 2 type : localnet up : false virtual_parent : [] [...]Dressez la liste des ports
l3gatewayen exécutant la commande suivante :$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gateway
Exemple de sortie
Leader pod is ovnkube-master-vslqm _uuid : 9314dc80-39e1-4af7-9cc0-ae8a9708ed59 additional_chassis : [] additional_encap : [] chassis : 336a923d-99e8-4e71-89a6-12564fde5760 datapath : db2a6067-fe7c-4d11-95a7-ff2321329e11 encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : etor-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com mac : ["52:54:00:3e:95:d3"] nat_addresses : ["52:54:00:3e:95:d3 10.46.56.77"] options : {l3gateway-chassis="7eb1f1c3-87c2-4f68-8e89-60f5ca810971", peer=rtoe-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 1 type : l3gateway up : true virtual_parent : [] _uuid : ad7eb303-b411-4e9f-8d36-d07f1f268e27 additional_chassis : [] additional_encap : [] chassis : f41453b8-29c5-4f39-b86b-e82cf344bce4 datapath : 082e7a60-d9c7-464b-b6ec-117d3426645a encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : etor-GR_helix14.lab.eng.tlv2.redhat.com mac : ["34:48:ed:f3:e2:2c"] nat_addresses : ["34:48:ed:f3:e2:2c 10.46.56.14"] options : {l3gateway-chassis="2e8abe3a-cb94-4593-9037-f5f9596325e2", peer=rtoe-GR_helix14.lab.eng.tlv2.redhat.com} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 1 type : l3gateway up : true virtual_parent : [] [...]Dressez la liste des ports de correctifs en exécutant la commande suivante :
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patch
Exemple de sortie
Leader pod is ovnkube-master-vslqm _uuid : c48b1380-ff26-4965-a644-6bd5b5946c61 additional_chassis : [] additional_encap : [] chassis : [] datapath : 72734d65-fae1-4bd9-a1ee-1bf4e085a060 encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : jtor-ovn_cluster_router mac : [router] nat_addresses : [] options : {peer=rtoj-ovn_cluster_router} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 4 type : patch up : false virtual_parent : [] _uuid : 5df51302-f3cd-415b-a059-ac24389938f7 additional_chassis : [] additional_encap : [] chassis : [] datapath : 0551c90f-e891-4909-8e9e-acc7909e06d0 encap : [] external_ids : {} gateway_chassis : [] ha_chassis_group : [] logical_port : rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com mac : ["0a:58:0a:82:00:01 10.130.0.1/23"] nat_addresses : [] options : {chassis-redirect-port=cr-rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com, peer=stor-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com} parent_port : [] port_security : [] requested_additional_chassis: [] requested_chassis : [] tag : [] tunnel_key : 4 type : patch up : false virtual_parent : [] [...]
