-2

I create pod with pod.yaml. it's ok.

kind: Pod
...
spec:
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /opt/mysql/data
  containers:
  ...
  - name: mysql
    image: 172.21.32.6:5000/mysql:5.7-utf8
    ports:
    - containerPort: 3306
    volumeMounts:
    - name: mysql-data
      mountPath: /var/lib/mysql

But i run "kubectl get pv", it show: No resources found

What type of this volume, is it Persistent Volume or Ephemeral Volume? How can i delete it?

Tony.Luo
  • 13
  • 5
  • Ok, I found the answer: https://kubernetes.io/docs/concepts/storage/volumes/#hostpath, But why kubectl get pv show nothing? – Tony.Luo Aug 14 '23 at 08:36
  • Have you created the PV and PVC, If you haven't created a PV and then a PVC and used only a hostpath it will be simply like creating a mountpath without actual volume mounted. Refer this [official document](https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) for more information on creating PV and how to use it in a Pod. If possible update the case with the manifest files for PV and PVC. – Kranthiveer Dontineni Aug 14 '23 at 09:48

1 Answers1

0

A hostPath: volume embedded directly in a Pod spec isn't a PersistentVolume. PersistentVolumes and PersistentVolumeClaims are different API objects, which showed up later in Kubernetes's timeline. You could have a Pod volumes: to reference a persistentVolumeClaim:.

In most cases you shouldn't use hostPath: at all. It's an "escape hatch" that accesses content directly on the Node's filesystem, whichever Node that happens to be. If your Pod gets deleted and recreated on a different Node, you'll get that same directory path, but the content won't follow it and you'll start from a new empty directory. (Almost the only real use case is something like a log manager running as a DaemonSet, which runs on every Node.)

You also shouldn't usually directly create Pods, or PersistentVolumes, or PersistentVolumeClaims. For a stateful application like a database, use a StatefulSet to describe the application. Kubernetes will create both a Pod and a PersistentVolumeClaim for each replica, and then a storage provisioner within the cluster will create an underlying PersistentVolume. For the fragment you show in the question, the setup would look like:

apiVersion: apps/v1
kind: StatefulSet
spec:
  template:
    spec:
      containers:
        - name: mysql
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: mysql-data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
David Maze
  • 130,717
  • 29
  • 175
  • 215
  • (If you've done a similar setup in Docker, this is essentially the same as `docker run -v /host/path:/container/path` not showing up in `docker volume ls` output, again since a bind mount is not a named Docker volume.) – David Maze Aug 14 '23 at 12:19
  • Thank you for your very detailed and kind answer, It is much better than the obscure words in the document, I am a novice, and my English is not very good。（Others just simply click down button） – Tony.Luo Aug 15 '23 at 02:17