Cloud Native 5 min read

Debugging Kubernetes Container Networks with nsenter and Temporary Pods

This article explains how to use the nsenter tool to enter a container's network namespace for packet capture and other host‑level debugging, provides scripts for logging into Kubernetes nodes, shows a DaemonSet deployment for persistent access, and compares nsenter with the newer kubectl debug temporary container approach.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Debugging Kubernetes Container Networks with nsenter and Temporary Pods

In a Kubernetes cloud environment, containers often lack network debugging tools such as tcpdump, making packet capture difficult. The nsenter utility can enter a specific namespace and is commonly used for container debugging.

Debugging Container Network

Using nsenter, you can easily enter the container's network namespace from the host with the following command:

# 设置containerid
containerid=xxx
# 获取容器主进程
pid=$(docker inspect -f {{.State.Pid}} $containerid)
# 进入容器networker namespace
nsenter -n --target $pid

After entering, you can run host tools such as tcpdump, netstat, and other networking commands inside the container.

Logging into a Kubernetes Node

If you only have Apiserver permissions, you can still log into a node using nsenter. A temporary login script is shown below (requires privileged and hostPID permissions):

node=xxx
cmd='[ "nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "--"]'
overrides="$(cat <<EOT
{
  "spec": {
    "nodeName": "$node",
    "hostPID": true,
    "hostNetwork": true,
    "containers": [
      {
        "securityContext": {"privileged": true},
        "image": "alpine",
        "name": "nsenter",
        "stdin": true,
        "stdinOnce": true,
        "tty": true,
        "command": $cmd
      }
    ],
    "tolerations": [{"operator": "Exists"}]
  }
}
EOT)"

pod="kube-nodeshell-$(env LC_ALL=C tr -dc a-z0-9 </dev/urandom | head -c 6)"
kubectl run --image=alpine --restart=Never --rm --overrides="$overrides" -it $pod

The principle is that hostPID=true shares the host's PID namespace, allowing the container to see all host processes; then nsenter enters the host's mount, uts, ipc, net, and pid namespaces to obtain a shell similar to the host.

If you need frequent access, you can deploy a DaemonSet that runs an nsenter pod on each node (recommended only for testing environments due to security risks):

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-nodehsell
  labels:
    app: kube-nodehsell
spec:
  selector:
    matchLabels:
      app: kube-nodehsell
  template:
    metadata:
      labels:
        app: kube-nodehsell
    spec:
      tolerations:
      - operator: "Exists"
      containers:
      - name: kube-nodehsell
        image: alpine
        command:
        - nsenter
        - --target
        - "1"
        - --mount
        - --uts
        - --ipc
        - --net
        - --pid
        - --
        - sleep
        - infinity
        securityContext:
          privileged: true
      hostIPC: true
      hostPID: true
      hostNetwork: true
      priorityClassName: system-node-critical

All related files are available in the kube-nodeshell repository.

Temporary Containers

Since Kubernetes 1.18, temporary containers can be added to a pod using the kubectl debug command, which also allows logging into a node shell for simple debugging tasks. Compared with the nsenter method, kubectl debug only shares the pid and hostNetwork, while nsenter provides more flexibility to use host tools and perform privileged operations.

-END-

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeKubernetesDaemonSetcontainer networkingnsenter
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.