Comment utiliser ss dans un espace de nom de réseau spécifique ?

Alors que j'étudiais certains problèmes de réseau TCP dans les conteneurs, j'ai essayé d'utiliser ss pour jeter un coup d'oeil dans la pile TCP du réseau de conteneurs.

Nous utilisons Amazon Linux dans AWS :

# uname -a
Linux 4.14.173-137.229.amzn2.x86_64 #1 SMP Wed Apr 1 18:06:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

ss a le commutateur cli suivant pour cela :

       -N NSNAME, --net=NSNAME
              Switch to the specified network namespace name.

lsns me donne le résultat suivant :

# lsns | grep net
4026531993 net       225     1 root      /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026532284 net         2 26244 root      /pause

C'est pause créé pour chaque Kubernetes pod -- c'est le conteneur qui crée l'espace de nom du réseau.

J'essaie de jeter un coup d'oeil dans l'espace de nom du réseau de pods en exécutant ss :

# ss -tp -N 4026532284
Cannot open network namespace "4026532284": No such file or directory

Ce qui est intéressant, c'est que ip netns list ne renvoie aucun espace de noms de réseau :

# ip netns list
#

Existe-t-il un moyen de consulter les espaces de noms des réseaux des pods K8 à partir de l'espace de noms du réseau racine, c'est-à-dire à partir de netns 1 ?

# ss --version
ss utility, iproute2-ss180129

# lsns --version
lsns from util-linux 2.30.2

# rpm -qi iproute
Name        : iproute
Version     : 4.15.0
Release     : 1.amzn2.0.4
Architecture: x86_64
Install Date: Sat 07 Mar 2020 03:42:24 AM UTC
Group       : Applications/System
Size        : 1321292
License     : GPLv2+ and Public Domain
Signature   : RSA/SHA256, Fri 21 Feb 2020 09:00:29 PM UTC, Key ID 11cf1f95c87f5b1a
Source RPM  : iproute-4.15.0-1.amzn2.0.4.src.rpm
Build Date  : Fri 21 Feb 2020 07:56:50 PM UTC
Build Host  : build.amazon.com
Relocations : (not relocatable)
Packager    : Amazon Linux
Vendor      : Amazon Linux
URL         : http://kernel.org/pub/linux/utils/net/iproute2/
Summary     : Advanced IP routing and network device configuration tools

Mise à jour : Mar Dec 1 11:35:39 UTC 2020

Après avoir lutté, j'ai finalement décidé de strace ceci.

Il s'avère que ss est un outil génial, mais lorsqu'il s'agit de l'utiliser avec des conteneurs, il laisse un peu à désirer, mais je pense qu'il y a plus d'un "coupable" impliqué.

ss ne prend pas la peine de chercher le PID réel du processus qui crée les espaces de noms du réseau, mais va plutôt directement vérifier /var/run/netns :

openat(AT_FDCWD, "/var/run/netns/4026532284", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "Cannot open network namespace \"4"..., 70Cannot open network namespace "4026532284": No such file or directory
) = 70

Maintenant, je pense que c'est dû à la façon dont iproute Le paquet crée network namespaces c'est-à-dire que, compte tenu de la ss est livré avec iproute paquet l'hypothèse ip fait au sujet des espaces de noms de réseau est : "Hé, tous les noms de réseau devraient être trouvés dans /var/run/netns répertoire, parce que, comme, pourquoi pas et aussi cela fera des vies de iproute facile pour les développeurs, ou autre.

Il s'avère que c'est une fausse supposition faite sur ss / iproute ou l'absence d'"accord" sur les outils et les conteneurs modernes. iproute l'interopérabilité, mais cela explique en quelque sorte la sortie vide de

ip netns list

Donc la façon ip crée des espaces de noms de réseaux (afin qu'ils puissent être inspectés par ss ) ne correspond manifestement pas à la façon dont kubernetes et ses semblables les créent, ce qui fait que iproute Les utilitaires du paquet sont à la limite de l'inutile dans le grand schéma des choses.