Volumes in Kubernetes - Part 2 (hostPath)

hostPath:
The emptyDir volume is a very basic volume and has a few downsides as well. Let's suppose if the count of pods running is more than one, and data is stored in these emptyDir volumes and if a pod crashes, the data stored in that volume also gets lost.
Here comes hostPath driver in the action.
hostPath driver basically allows us to map a path on the worker / slave node on which the pods are running to a specific path inside the pods, i.e. the data from inside of this path will be exposed to multiple pods, therefore, multiple pods can use same path on the host (worker) machine to store the data instead of specific path for specific pods.
hostPath is very much like the bind mount in docker, similar to docker we can perform read / write actions in this hostPath.

Syntax:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: <name_of_deployment>
spec:
    replicas: 1
    selector:
        matchLabels:
            a: b
    spec:
        template:
            metadata:
                labels: 
                    a: b
            containers:
                - name: <name_of_container>
                  image: deocker_repo/<image_name>
            volumes:
                - name: <name_of_volumes>
                  hostPath:
                      path: <path_on_the_host_machone_where_data_should_be_stored>
                      type: <declares_how_the_above_declare_path_is_to_be_handled>
                            DirectoryOrCreate

type: Directory defines the path that already exists.
Creates defines that the path does not exist but needs to be created.

Disadvantage of hostPath:
Let's suppose there are multiple pods, running on multiple slaves / worker nodes, now defining hostpath lets you map a volume on the slave / worker node to the N number of pods running on that particular slave / worker node i.e. all other pods that are running on other slaves / worker nodes will not be able to access the volume defined in this slave / worker node.