Un PID namespace virtualise l'espace des identifiants de processus (PID) : la numérotation et la visibilité des processus deviennent locales au namespace.

Ce qui est virtualisé
Numérotation indépendante : chaque namespace possède son propre compteur de PID, qui repart à 1. Un même processus a donc plusieurs PID : un dans son namespace et un dans chacun des namespaces ancêtres.
Visibilité : un processus ne voit que les processus de son propre namespace et de ses descendants. Les processus des namespaces ancêtres ou frères sont tout simplement inexistants pour lui.
Vue /proc : après montage d'un nouveau /proc (mount -t proc proc /proc), seuls les processus du namespace apparaissent, ce qui rend ps, top, kill cohérents avec l'isolation.

Hiérarchie
Les PID namespaces sont hiérarchiques (imbriqués jusqu'à 32 niveaux) : le parent voit les processus des enfants, jamais l'inverse.
Le namespace initial (hôte) est l'ancêtre de tous les autres.

Rôle particulier du PID 1
Le premier processus créé dans le namespace devient PID 1 et joue le rôle d'init : il adopte les processus orphelins du namespace.
Il bénéficie d'une protection : les signaux qu'il n'a pas explicitement gérés (hors signaux envoyés par le noyau) sont ignorés, même SIGKILL.
Si le PID 1 se termine, le noyau tue tous les processus restants du namespace (SIGKILL), et le namespace est détruit.

Signaux
Un processus ne peut pas viser un processus situé hors de son namespace : celui-ci n'a aucun PID visible dans son espace de noms, donc aucune capability (CAP_KILL incluse) ne permet de le cibler. Inversement, un processus d'un namespace ancêtre suffisamment privilégié peut signaler les processus des namespaces descendants (sauf la protection du PID 1 décrite ci-dessus).

Création
clone(CLONE_NEWPID) / unshare(CLONE_NEWPID) — nécessite CAP_SYS_ADMIN, sauf si le namespace est créé conjointement avec un user namespace (ex. unshare -Urpf --mount-proc), ce qui autorise un utilisateur non privilégié.
Particularité : unshare(CLONE_NEWPID) ne déplace pas le processus appelant ; c'est son premier enfant qui devient PID 1.

Cas d'usage
Conteneurs (Docker, LXC, Podman, Kubernetes) : chaque conteneur dispose de son propre PID 1 et d'un arbre de processus isolé, limitant l'observation et l'interférence avec les processus de l'hôte.

Inspection
ls -l /proc//ns/pid lien symbolique pid:[] identifiant le namespace
readlink /proc/self/ns/pid
lsns -t pid liste les PID namespaces

Ce que le PID namespace ne virtualise pas : le réseau, les points de montage, les UID/GID, le nom d'hôte ou les IPC — chacun relève d'un type de namespace distinct.