SupportConsoleDéveloppeursCommencer un essaiContact

24.4. Tracer Openflow avec ovnkube-trace

Les flux de trafic OVN et OVS peuvent être simulés dans un seul utilitaire appelé ovnkube-trace. L'utilitaire ovnkube-trace exécute ovn-trace, ovs-appctl ofproto/trace et ovn-detrace et met en corrélation ces informations dans un seul résultat.

Vous pouvez exécuter le binaire ovnkube-trace à partir d'un conteneur dédié. Pour les versions postérieures à OpenShift Container Platform 4.7, vous pouvez également copier le binaire sur un hôte local et l'exécuter à partir de cet hôte.

Note

Les binaires des images Quay ne fonctionnent pas actuellement pour les environnements à double pile IP ou IPv6 uniquement. Pour ces environnements, vous devez compiler à partir des sources.

24.4.1. Installation de ovnkube-trace sur l'hôte local

L'outil ovnkube-trace trace des simulations de paquets pour un trafic UDP ou TCP arbitraire entre des points d'un cluster OpenShift Container Platform piloté par OVN-Kubernetes. Copiez le binaire ovnkube-trace sur votre hôte local pour qu'il puisse être exécuté sur le cluster.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez une variable pod en utilisant la commande suivante : 

    $  POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master -o name | head -1 | awk -F '/' '{print $NF}')

  2. Exécutez la commande suivante sur votre hôte local pour copier le binaire des pods ovnkube-master: 

    $  oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace ovnkube-trace

  3. Rendez ovnkube-trace exécutable en exécutant la commande suivante : 

    $  chmod +x ovnkube-trace

  4. Affichez les options disponibles sur ovnkube-trace en exécutant la commande suivante : 

    $  ./ovnkube-trace -help

    Résultats attendus

    I0111 15:05:27.973305  204872 ovs.go:90] Maximum command line arguments set to: 191102
Usage of ./ovnkube-trace:
  -dst string
    	dest: destination pod name
  -dst-ip string
    	destination IP address (meant for tests to external targets)
  -dst-namespace string
    	k8s namespace of dest pod (default "default")
  -dst-port string
    	dst-port: destination port (default "80")
  -kubeconfig string
    	absolute path to the kubeconfig file
  -loglevel string
    	loglevel: klog level (default "0")
  -ovn-config-namespace string
    	namespace used by ovn-config itself
  -service string
    	service: destination service name
  -skip-detrace
    	skip ovn-detrace command
  -src string
    	src: source pod name
  -src-namespace string
    	k8s namespace of source pod (default "default")
  -tcp
    	use tcp transport protocol
  -udp
    	use udp transport protocol

    Les arguments de ligne de commande pris en charge sont des constructions Kubernetes familières, telles que les espaces de noms, les pods, les services, de sorte que vous n'avez pas besoin de trouver l'adresse MAC, l'adresse IP des nœuds de destination ou le type ICMP.

    Les niveaux d'enregistrement sont les suivants :

    • 0 (production minimale)
    • 2 (plus d'informations sur les résultats des commandes de suivi)
    • 5 (sortie de débogage)

24.4.2. Exécution de ovnkube-trace

Lancer ovn-trace pour simuler la transmission de paquets au sein d'un réseau logique OVN.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
  • Vous avez installé ovnkube-trace sur l'hôte local

Exemple : Test du fonctionnement de la résolution DNS à partir d'un module déployé

Cet exemple illustre comment tester la résolution DNS d'un module déployé vers le module DNS central qui fonctionne dans le cluster.

Procédure

  1. Démarrez un service web dans l'espace de noms par défaut en entrant la commande suivante : 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  2. Liste des pods fonctionnant dans l'espace de noms openshift-dns: 

    oc get pods -n openshift-dns

    Exemple de sortie

    NAME                  READY   STATUS    RESTARTS   AGE
dns-default-467qw     2/2     Running   0          49m
dns-default-6prvx     2/2     Running   0          53m
dns-default-fkqr8     2/2     Running   0          53m
dns-default-qv2rg     2/2     Running   0          49m
dns-default-s29vr     2/2     Running   0          49m
dns-default-vdsbn     2/2     Running   0          53m
node-resolver-6thtt   1/1     Running   0          53m
node-resolver-7ksdn   1/1     Running   0          49m
node-resolver-8sthh   1/1     Running   0          53m
node-resolver-c5ksw   1/1     Running   0          50m
node-resolver-gbvdp   1/1     Running   0          53m
node-resolver-sxhkd   1/1     Running   0          50m

  3. Exécutez la commande suivante ovn-kube-trace pour vérifier que la résolution DNS fonctionne : 

    $ ./ovnkube-trace \
  -src-namespace default \ 1
  -src web \ 2
  -dst-namespace openshift-dns \ 3
  -dst dns-default-467qw \ 4
  -udp -dst-port 53 \ 5
  -loglevel 0 6
    1
    Espace de noms du pod source
    2
    Nom du pod source
    3
    Espace de noms du pod de destination
    4
    Nom du pod de destination
    5
    Utilisez le protocole de transport udp. Le port 53 est le port utilisé par le service DNS.
    6
    Définir le niveau de journalisation à 1 (0 est le niveau minimal et 5 est le niveau de débogage)

    Résultats attendus

    I0116 10:19:35.601303   17900 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from web to dns-default-467qw
ovn-trace destination pod to source pod indicates success from dns-default-467qw to web
ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-467qw
ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-467qw to web
ovn-detrace source pod to destination pod indicates success from web to dns-default-467qw
ovn-detrace destination pod to source pod indicates success from dns-default-467qw to web

    La sortie indique le succès du pod déployé vers le port DNS et indique également qu'il est réussi dans l'autre sens. Vous savez donc que le trafic bidirectionnel est supporté sur le port UDP 53 si mon pod web veut faire de la résolution DNS à partir du core DNS.

Si, par exemple, cela n'a pas fonctionné et que vous souhaitiez obtenir ovn-trace, ovs-appctl ofproto/trace et ovn-detrace, ainsi que d'autres informations de type débogage, augmentez le niveau du journal à 2 et exécutez à nouveau la commande de la manière suivante : 

$ ./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 2

Les résultats de cette augmentation du niveau de journalisation sont trop nombreux pour être énumérés ici. En cas d'échec, la sortie de cette commande montre quel flux laisse tomber ce trafic. Par exemple, une politique de réseau d'entrée ou de sortie peut être configurée sur le cluster qui n'autorise pas ce trafic.

Exemple : Vérification à l'aide de la sortie debug d'un refus par défaut configuré

Cet exemple montre comment identifier, à l'aide de la sortie de débogage, qu'une stratégie de refus par défaut à l'entrée bloque le trafic.

Procédure

  1. Créez le fichier YAML suivant qui définit une politique deny-by-default pour refuser l'entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml: 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default
spec:
  podSelector: {}
  ingress: []

  2. Appliquez la politique en entrant la commande suivante : 

    $ oc apply -f deny-by-default.yaml

    Exemple de sortie

    networkpolicy.networking.k8s.io/deny-by-default created

  3. Démarrez un service web dans l'espace de noms default en entrant la commande suivante : 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  4. Exécutez la commande suivante pour créer l'espace de noms prod: 

    $ oc create namespace prod

  5. Exécutez la commande suivante pour étiqueter l'espace de noms prod: 

    $ oc label namespace/prod purpose=production

  6. Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms prod et démarrer un shell : 

    $ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
  7. Ouvrez une autre session de terminal.

  8. Dans cette nouvelle session de terminal, exécutez ovn-trace pour vérifier l'échec de la communication entre le pod source test-6459 fonctionnant dans l'espace de noms prod et le pod de destination fonctionnant dans l'espace de noms default: 

    $ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

    Résultats attendus

    I0116 14:20:47.380775   50822 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates failure from test-6459 to web

  9. Augmentez le niveau de journalisation à 2 pour révéler la raison de l'échec en exécutant la commande suivante : 

    $ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 2

    Résultats attendus

    ct_lb_mark /* default (use --ct to customize) */
------------------------------------------------
 3. ls_out_acl_hint (northd.c:6092): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 32d45ad4
    reg0[8] = 1;
    reg0[10] = 1;
    next;
 4. ls_out_acl (northd.c:6435): reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid f730a887 1
    ct_commit { ct_mark.blocked = 1; };

    1
    Le trafic entrant est bloqué en raison de la politique de refus par défaut en place

  10. Créez une politique qui autorise le trafic de tous les pods dans un espace de noms particulier avec un label purpose=production. Sauvegardez le YAML dans le fichier web-allow-prod.yaml: 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

  11. Appliquez la politique en entrant la commande suivante : 

    $ oc apply -f web-allow-prod.yaml

  12. Exécutez ovnkube-trace pour vérifier que le trafic est maintenant autorisé en entrant la commande suivante : 

    $ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

    Résultats attendus

    I0116 14:25:44.055207   51695 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from test-6459 to web
ovn-trace destination pod to source pod indicates success from web to test-6459
ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
ovn-detrace source pod to destination pod indicates success from test-6459 to web
ovn-detrace destination pod to source pod indicates success from web to test-6459

  13. Dans le shell ouvert, exécutez la commande suivante : 

     wget -qO- --timeout=2 http://web.default

    Résultats attendus

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

24.4.3. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.