K
Q

Drawback of hostPath in Kubernetes

6/21/2019

I have setup and Kubernetes cluster from kubespray - ansible script. Now i have created a deployment with volume to be mounted as hostPath in spec.template.spec.volumes. And i have mounted the volume on all my nodes via nfs file-system. Now i read in k8s documentation its not good practice but need to understand the harmfulness for the hostPath. Below is sample yaml file.

spec:
  containers:
  - image: test:latest
    imagePullPolicy: Always
    name: test1
    ports:
    - containerPort: 4006
      protocol: TCP
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - name : test-data
      mountPath : /RIC/
    - name : test-config
      mountPath : /xyz/abc.config
      subPath : abc.config
  volumes:
  - name : test-data
    hostPath :
      path : /nfs-mount/RIC/
  - name : test-config
    configMap :
      name : test-config
-- Ankit Saxena
kubernetes

Similar Questions

Run kubernetes job worker queue on cassandra timeseries
Kubernetes DNS and NetworkPolicy with Calico not working
Connecting my GKE cluster to our local db on premise
Kops' Kubelet PKI management
Missing the required parameter 'namespace' when calling listNamespacedConfigMap(Async) in Spring Boot Cloud Kubernetes local tests

3 Answers

6/21/2019

There are some reasons:

  1. Allowing HostPaths on production clusters is not a good idea from security point of view , if your pod is hacked and someone gets access to your host becuase he can write to hostPath , then your entire cluster is hacked...

  2. Using hostPaths are not portable , you can use the same paths using kubernetes local volume provisoner if you are deploying some stateful set such as elasticsearch or some database etc.

  3. Using local volume provisoner is not useful for other deployments that for example if a node goes down you need the pod to be scheduled on other node where your locally provisoned volume will not be available.

  4. Therefore , use the NFS share directly from kubernetes instead of using it as hosthpath or local volume. for example:

volumes:
      - name: test-data
        nfs:
          path: /projects/test/dev/data
          server: 192.168.1.11

This way , you dont have to allow hostPaths , or dont have to manage mounting nfs on hosts yourself , or dont have to manage local volumes etc

-- Ijaz Ahmad Khan
Source: StackOverflow
6/21/2019

if the pod is crashed then kubernetes would spin up new pod. the new pod might get scheduled on different node in the cluster. in that case the data would be lost. To overcome this problem, You might have to add a label to specific node. and get the pod always scheduled to that labled node, that way local hostpath volume gets mounted to the pod. in the worst case scenario, if the node is crashed then you will lose the data.

-- P Ekambaram
Source: StackOverflow
6/21/2019

Every time you add a new deployment you would first need to add an NFS volume and mount it on every node.

If you could add your NFS storage system as a storage provider Kubernetes would take over most of the tasks. Kubernetes would create a volume in your storage system if you add a KubernetesPersistence volume object and mount the volume to the node where the pod is scheduled.

-- Lukas Eichler
Source: StackOverflow