Understanding the Kubernetes HostPath Volume

Kubernetes HostPath Volume is a type of persistent storage available to your Kubernetes Pods.

In earlier posts, we saw Kubernetes emptyDir Volume & also using a git repository as a Kubernetes Volume. In both of those cases, however, the volume’s content gets deleted when a pod is torn down.

However, the hostPath contents don’t get deleted. The new pod will basically see whatever was left by the previous pod.

1 – When to use a Kubernetes hostPath Volume?

Most applications don’t need a hostPath volume.

This is because the hostPath volume is tied to the node on which the pod is running. However, when a Kubernetes pod is deleted, there’s no guarantee that the new pod will be run on the same node or any other node.

This makes hostPath volumes unsuitable for storing application data or database records.

Few use cases where the hostPath volume type works well:

• For a container that needs access to the Docker internals of the Kubernetes cluster.
• For running cAdvisor in a container to get an understanding of the resource usage.

By the way, if you are interested in Cloud Native technologies, you’d love the Progressive Coder Newsletter where I talk about such concepts & more in a fun & interesting manner.

Subscribe now to join along.

2 – Kubernetes hostPath Volume Example

You can see a Kubernetes hostPath volume in action by checking one of the Kubernetes cluster-level containers.

For example, you can describe the kube-proxy pod running in the kube-system namespace of your cluster.

First get the exact name of the pod.

$ kubectl get po --namespace kube-system
NAME                                     READY   STATUS    RESTARTS          AGE
coredns-78fcd69978-gzkct                 1/1     Running   15 (55m ago)      292d
coredns-78fcd69978-hj4kt                 1/1     Running   15 (55m ago)      292d
etcd-docker-desktop                      1/1     Running   15 (55m ago)      292d
kube-apiserver-docker-desktop            1/1     Running   15 (55m ago)      292d
kube-controller-manager-docker-desktop   1/1     Running   15 (55m ago)      292d
kube-proxy-6m5lg                         1/1     Running   15 (55m ago)      292d
kube-scheduler-docker-desktop            1/1     Running   15 (55m ago)      292d
storage-provisioner                      1/1     Running   21 (55m ago)      292d
vpnkit-controller                        1/1     Running   564 (3m21s ago)   292d

Then, describe the contents of pod.

$ kubectl describe po kube-proxy-6m5lg --namespace kube-system

As you can see, the kube-proxy pod uses a couple of hostPath volumes.

Volumes:
  kube-proxy:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kube-proxy
    Optional:  false
  xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
  lib-modules:
    Type:          HostPath (bare host directory volume)
    Path:          /lib/modules
    HostPathType:  

Here’s a sample YAML file to define a pod with a hostPath volume type.

volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /var/data
      # this field is optional
      type: Directory

3 – Types of hostPath Volume

As you may have noticed, the hostPath volume also has a field HostPathType associated with it.

There are various types of hostPath supported by Kubernetes. Here’s the list (taken from the official Kubernetes documentation)

In case you aren’t sure of what type you need, leaving the HostPathType as blank is the best way forward.

4 – Pitfalls of Kubernetes hostPath Volume

Here are the main disadvantages of hostPath volume:

• HostPaths risk exposing privileged system credentials that can be used for attacking other parts of the cluster.
• Pods with hostPath configuration may behave differently on different nodes.
• The files or directories created on the hosts need privileged root access on the Containers or we’ve to modify the file permissions on the host.

Conclusion

Kubernetes hostPath volume can keep data persisted across the pod lifecycle and even after a pod has been deleted.

However, their usage is restricted to a node level and as such their use for applications is minimal.

Nevertheless, it’s a handy tool for certain situations when you need to access the node’s filesystem from the Kubernetes Pod.

To create persistent storage in Kubernetes, you need to look into Kubernetes Persistent Volume Claim.

Anyways, before we end this post, a quick reminder about the Progressive Code Newsletter where I explain software concepts using a fun approach so that you never forget what you’ve learned. I’m 100% sure you’d love it.

Subscribe now and see you over there.