导航：首页 > 服务器 >

Kubernetes中的常用储存类型有哪些

发表于：2026-11-01 作者：千家信息网编辑

千家信息网最后更新 2026年11月01日，今天就跟大家聊聊有关Kubernetes中的常用储存类型有哪些，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。下面将为大家介绍几种常用储存类型。

千家信息网最后更新 2026年11月01日Kubernetes中的常用储存类型有哪些

今天就跟大家聊聊有关Kubernetes中的常用储存类型有哪些，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

下面将为大家介绍几种常用储存类型。

默认情况下Pod挂载在磁盘上的文件生命周期与Pod生命周期是一致的，若Pod出现崩溃的情况，kubelet 将会重启它，这将会造成Pod中的文件将丢失，因为Pod会以镜像最初的状态重新启动。在实际应用当中，开发者有很多时候需要将容器中的数据保留下来，比如在Kubernetes中部署了MySql，不能因为MySql容器挂掉重启而上面的数据全部丢失；其次，在 Pod 中同时运行多个容器时，这些容器之间可能需要共享文件。也有的时候，开发者需要预置配置文件，使其在容器中生效，例如自定义了mysql.cnf文件在MySql启动时就需要加载此配置文件。这些都将是今天将要实战解决的问题。

SECRET

Secret对象允许您存储和管理敏感信息，例如密码，OAuth令牌和ssh密钥。将此类信息放入一个secret中可以更好地控制它的用途，并降低意外暴露的风险。

▌使用场景

鉴权配置文件挂载

▌使用示例

在CI中push构建好的镜像就可以将docker鉴权的config.json文件存入secret对象中，再挂载到CI的Pod中，从而进行权限认证。

首先创建secret

$ kubectl create secret docker-registry docker-config  --docker-server=https://hub.docker.com --docker-username=username --docker-password=passwordsecret/docker-config created

新建docker-pod.yaml文件，粘贴以下信息：

apiVersion: v1kind: Podmetadata:  name: dockerspec:  containers:  - name: docker    image: docker    command:      - sleep      - "3600"    volumeMounts:    - name: config      mountPath: /root/.docker/  volumes:  - name: config    secret:      secretName: docker-config      items:      - key: .dockerconfigjson        path: config.json        mode: 0644

Docker Pod挂载secret

$ kubectl apply -f docker-pod.yamlpod/docker created

查看挂载效果

$ kubectl exec docker -- cat /root/.docker/config.json{"auths":{"https://hub.docker.com":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}

清理环境

$ kubectl delete pod docker$ kubectl delete secret docker-config

ConfigMap

许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与docker image解耦ConfigMap API给我们提供了向容器中注入配置信息的机制，ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件。

▌使用场景

配置信息文件挂载

▌使用示例

使用ConfigMap中的数据来配置Redis缓存

创建example-redis-config.yaml文件，粘贴以下信息：

apiVersion: v1kind: ConfigMapmetadata:  name: example-redis-configdata:  redis-config: |    maxmemory 2b    maxmemory-policy allkeys-lru

创建ConfigMap

$ kubectl apply -f example-redis-config.yamlconfigmap/example-redis-config created

创建example-redis.yaml文件，粘贴以下信息：

apiVersion: v1kind: Podmetadata:  name: redisspec:  containers:  - name: redis    image: kubernetes/redis:v1    env:    - name: MASTER      value: "true"    ports:    - containerPort: 6379    resources:      limits:        cpu: "0.1"    volumeMounts:    - mountPath: /redis-master-data      name: data    - mountPath: /redis-master      name: config  volumes:    - name: data      emptyDir: {}    - name: config      configMap:        name: example-redis-config        items:        - key: redis-config          path: redis.conf

Redis Pod挂载ConfigMap测试

$ kubectl apply -f example-redis.yamlpod/redis created

查看挂载效果

$ kubectl exec -it redis redis-cli$ 127.0.0.1:6379> CONFIG GET maxmemory1) "maxmemory"2) "2097152"$ 127.0.0.1:6379> CONFIG GET maxmemory-policy1) "maxmemory-policy"2) "allkeys-lru"

清理环境

$ kubectl delete pod redis$ kubectl delete configmap example-redis-config

EmptyDir

当使用emptyDir卷的Pod在节点创建时，会在该节点创建一个新的空目录，只要该Pod运行在该节点，该目录会一直存在，Pod内的所有容器可以将改目录挂载到不同的挂载点，但都可以读写emptyDir内的文件。当Pod不论什么原因被删除，emptyDir的数据都会永远被删除（一个Container Crash 并不会在该节点删除Pod，因此在Container crash时，数据不会丢失）。默认情况下，emptyDir支持任何类型的后端存储：disk、ssd、网络存储。也可以通过设置 emptyDir.medium 为Memory，kubernetes会默认mount一个tmpfs（RAM-backed filesystem），因为是RAM Backed,因此 tmpfs 通常很快。但是会在容器重启或者crash时，数据丢失。

▌使用场景

同一Pod内各容器共享存储

▌使用示例

在容器a中生成hello文件，通过容器b输出文件内容

创建test-emptydir.yaml文件，粘贴以下信息：

apiVersion: v1kind: Podmetadata:  name: test-emptydirspec:  containers:  - image: alpine    name: container-a    command:      - /bin/sh    args:      - -c      - echo 'I am container-a' >> /cache-a/hello && sleep 3600    volumeMounts:    - mountPath: /cache-a      name: cache-volume  - image: alpine    name: container-b    command:      - sleep      - "3600"    volumeMounts:    - mountPath: /cache-b      name: cache-volume  volumes:  - name: cache-volume    emptyDir: {}

创建Pod

kubectl apply -f test-emptydir.yamlpod/test-emptydir created

测试

$ kubectl exec test-emptydir -c container-b -- cat /cache-b/helloI am container-a

清理环境

$ kubectl delete pod test-emptydir

HostPath

将宿主机对应目录直接挂载到运行在该节点的容器中。使用该类型的卷，需要注意以下几个方面：

使用同一个模板创建的Pod，由于不同的节点有不同的目录信息，可能会导致不同的结果
如果kubernetes增加了已知资源的调度，该调度不会考虑hostPath使用的资源
如果宿主机目录上已经存在的目录，只可以被root可以写，所以容器需要root权限访问该目录，或者修改目录权限

▌使用场景

运行的容器需要访问宿主机的信息，比如Docker内部信息/var/lib/docker目录，容器内运行cadvisor，需要访问/dev/cgroups

▌使用示例

使用Docker socket binding模式在列出宿主机镜像列表。

创建test-hostpath.yaml文件，粘贴以下信息：

apiVersion: v1kind: Podmetadata:  name: test-hostpathspec:  containers:  - image: docker    name: test-hostpath    command:      - sleep      - "3600"    volumeMounts:    - mountPath: /var/run/docker.sock      name: docker-sock  volumes:  - name: docker-sock    hostPath:      path: /var/run/docker.sock      type: Socket

创建test-hostpath Pod

$ kubectl apply -f test-hostpath.yamlpod/test-hostpath created

测试是否成功

$ kubectl exec test-hostpath docker imagesREPOSITORY      IMAGE ID        CREATED         SIZEdocker          639de9917ae1    13 days ago     171MB...

NFS存储卷

NFS 卷允许将现有的 NFS（网络文件系统）共享挂载到您的容器中。不像 emptyDir，当删除 Pod 时，nfs 卷的内容被保留，卷仅仅是被卸载。这意味着 nfs 卷可以预填充数据，并且可以在 pod 之间共享数据。 NFS 可以被多个写入者同时挂载。

重要提示：您必须先拥有自己的 NFS 服务器然后才能使用它。

▌使用场景

不同节点Pod使用统一nfs共享目录

▌使用示例

创建test-nfs.yaml文件，粘贴以下信息：

apiVersion: apps/v1kind: Deploymentmetadata:  name: test-nfsspec:  selector:    matchLabels:      app: store  replicas: 2  template:    metadata:      labels:        app: store    spec:      volumes:      - name: data        nfs:          server: nfs.server.com          path: /      affinity:        podAntiAffinity:          requiredDuringSchedulingIgnoredDuringExecution:          - labelSelector:              matchExpressions:              - key: app                operator: In                values:                - store            topologyKey: "kubernetes.io/hostname"      containers:      - name: alpine        image: alpine        command:          - sleep          - "3600"        volumeMounts:        - mountPath: /data          name: data

创建测试deployment

$ kubectl apply -f test-nfs.yamldeployment/test-nfs created

查看pod运行情况

$ kubectl get po -o wideNAME                        READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODEtest-nfs-859ccfdf55-kkgxj   1/1       Running   0          1m        10.233.68.245   uat05     test-nfs-859ccfdf55-aewf8   1/1       Running   0          1m        10.233.67.209   uat06

进入Pod中进行测试

# 进入uat05节点的pod中$ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh# 创建文件$ echo "uat05" > /data/uat05# 退出uat05节点的pod$ edit# 进入uat06节点的pod中$ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh# 查看文件内容$ cat /data/uat05uat05

清理环境

$ kubectl delete deployment test-nfs

PersistentVolumeClaim

上面所有例子中我们都是直接将存储挂载到的pod中，那么在kubernetes中如何管理这些存储资源呢？这就是Persistent Volume和Persistent Volume Claims所提供的功能。

● PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 将如何提供存储的细节抽象了出来。为此，我们引入两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含 Volume 的实现，即 NFS、iSCSI 或特定于云供应商的存储系统。
PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）。虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但用户需要具有不同性质（例如性能）的 PersistentVolume 来解决不同的问题。集群管理员需要能够提供各种各样的 PersistentVolume，这些PersistentVolume 的大小和访问模式可以各有不同，但不需要向用户公开实现这些卷的细节。对于这些需求，StorageClass 资源可以实现。

● 在实际使用场景里，PV 的创建和使用通常不是同一个人。这里有一个典型的应用场景：管理员创建一个 PV 池，开发人员创建 Pod 和 PVC，PVC 里定义了Pod所需存储的大小和访问模式，然后 PVC 会到 PV 池里自动匹配最合适的 PV 给 Pod 使用。

▌使用示例

创建PersistentVolume

apiVersion: v1kind: PersistentVolumemetadata:  name: mypvspec:  capacity:    storage: 5Gi  volumeMode: Filesystem  accessModes:    - ReadWriteOnce  persistentVolumeReclaimPolicy: Recycle  storageClassName: slow  mountOptions:    - hard    - nfsvers=4.0  nfs:    path: /tmp    server: 172.17.0.2

创建PersistentVolumeClaim

kind: PersistentVolumeClaimapiVersion: v1metadata:  name: myclaimspec:  accessModes:    - ReadWriteOnce  volumeMode: Filesystem  resources:    requests:      storage: 5Gi  volumeName: mypv

创建Pod绑定PVC

kind: PodapiVersion: v1metadata:  name: mypodspec:  containers:    - name: myfrontend      image: nginx      volumeMounts:      - mountPath: "/var/www/html"        name: mypd  volumes:    - name: mypd      persistentVolumeClaim:        claimName: myclaim

查看pod运行情况验证绑定结果

$ kubectl get po -o wideNAME    READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODEmypod   1/1       Running   0          1m        10.233.68.249   uat05     $ kubectl exec -it mypod sh$ ls /var/www/html

清理环境

$ kubectl delete pv mypv$ kubectl delete pvc myclaim$ kubectl delete po mypod

使用configMap对redis进行缓存配置，这样即使redis容器挂掉重启configMap中的配置依然会生效。接着又使用emptyDir来使得同一Pod中多个容器的目录共享，在实际应用中开发者通常使用initContainers来进行预处理文件，然后通过emptyDir传递给Containers。然后再使用hostPath来访问宿主机的资源，当网路io达不到文件读写要求时，可考虑固定应用只运行在一个节点上然后使用hostPath来解决文件读写速度的要求。

NFS和PersistentVolumeClaim的例子实质上都是试容器挂载的nfs服务器共享目录，但这些资源一般都只掌握在了管理员手中，开发人员想要获取这部分资源那么就不是这么友好了，动态存储类（StorageClass）就能很好的解决此类问题。

看完上述内容，你们对Kubernetes中的常用储存类型有哪些有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。

很赞哦！