1. Identify and target a Kube Worker using a label

First, find a label to address a specific kubernetes worker:

$ kubectl get nodes — show-labels

The kubernetes.io/hostname label is unique for each node. Let's try that:

2. Create a Support pod

Next, create a pod for worker analysis which simply sleeps for an hour while we shell in and interactively explore the host FS. Here’s the complete Pod manifest ( analyse-worker-fs.yml ):

Here we create a hostPath volume that captures the entire root FS ( / ) of the worker and mounts it in the busybox container at the mount point /host .¹ For this to work, your kube credentials must have permission to create a hostPath volume at the root of the worker FS. We ensure it gets scheduled on our target Kube Worker ( kubernetes.io/hostname=ip-10-1-79-78.cryptocracy.org ) by using a nodeSelector in the pod spec.

Create the pod:

If the pod already exists, delete it and create a new one.

3. Launch an interactive shell

Launch an interactive shell:

Now you’re root with access to the complete worker root FS, mounted at /host !

4. Analyse the Worker host root filesystem

You can analyse the big things on host root FS

Some of the biggest opportunities for housekeeping might be found in /host/var/cache and /host/var/crash .

Permission denied? Need more capabilities?

For example, you want to change a host kernel parameter:

Or, you want access to host devices?

To grant fine-grained kernel capabilities for your maintenance task, use:

For possible capability constants, refer to capability.h in the Linux kernel source.

Note that the CAP prefix is omitted in the podSpec. See the kube docs for more details.

Alternatively, use a privileged container: