Kubernetes之存储卷Volume

Kubernetes存储卷详解:Volume、PVC、ConfigMap与Secret
本文详细介绍了Kubernetes中的存储卷Volume,包括emptyDir、hostPath、PersistentVolumeClaim&PersistentVolume、configMap和secret的使用。重点讲解了各种类型的特点和使用场景,如emptyDir作为临时存储,hostPath提供节点级持久性,PVC和PV用于动态存储管理,configMap和secret则用于存储配置信息和敏感数据。

目前有两个问题摆在大家面前:
第一、由于容器本身是非持久化的,当容器崩溃后,kubelet将以镜像的初始状态重新启动容器,但是此时之前容器的数据已经丢失,我们该如何保护好容器的数据呢?
第二、在同一Pod中的容器往往需要共享一些数据,此时我们又该如何实现呢?

kubernetes为了解决以上问题,引入了存储卷Volume。

  • Kubernetes中的卷有明确的寿命——与封装它的Pod相同,所以卷的生命比Pod中的所有容器都长,当容器重启时数据仍然存在。
  • 同时卷是独立于容器之外的,容器可以引用卷中的数据就可以达到共享数据的目的
    在这里插入图片描述

在Pod中通过指定下面的字段来使用存储卷:

  • spec.volumes:通过此字段提供指定的存储卷
  • spec.containers.volumeMounts:通过此字段将存储卷挂接到容器中

一、存储卷类型

当前kubernetes支持如下所列存储卷类型

  • awsElasticBlockStore
  • azureDisk
  • azureFile
  • cephfs
  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • fc (fibre channel)
  • flocker
  • gcePersistentDisk
  • gitRepo (deprecated)
  • glusterfs
  • hostPath
  • iscsi
  • local
  • nfs
  • persistentVolumeClaim
  • projected
  • portworxVolume
  • quobyte
  • rbd
  • scaleIO
  • secret
  • storageos
  • vsphereVolume
  • configMap

二、存储卷使用实例

1. emptyDir

属于本地存储,只要Pod一删,emptyDir也将会一并删除,所以其生命周期和Pod一样,它是当临时目录或缓存使用的,没有持久性。下面我们创建一个使用emptyDir存储卷的Pod。
创建Pod配置清单文件(使用volumes和volumeMounts字段):

[root@master manifests]# vim pod-vol-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-demo
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    magedu.com/created-by: "cluster admin"
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html/
  - name: busybox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: html
      mo
从你的描述来看,这是一个 Kubernetes 中 StatefulSet 的事件日志信息。以下是对你提到的问题的分析以及解决方法: ### 日志分析 1. **Normal SuccessfulCreate** 表示 `statefulset-controller` 成功创建了一个名为 `data-mysql-0` 的 PersistentVolumeClaim 一个名为 `mysql-0` 的 Pod。 2. **Warning FailedCreate** 表示多次尝试创建 Pod `mysql-0` 都失败了,并给出了具体的错误原因: - 错误的核心是 Volume Mounts 中引用了一些不存在的卷名称(如 `"conf"`、`"config-map"`),导致 Pod 创建失败。 - 具体表现为以下几个字段无效: - `spec.containers[0].volumeMounts[1].name` - `spec.initContainers[0].volumeMounts[0].name` - `spec.initContainers[0].volumeMounts[1].name` - `spec.initContainers[1].volumeMounts[1].name` ### 解决方案 #### 1. 检查 YAML 文件中的卷配置 打开对应的 StatefulSet 或者 Deployment 定义文件(通常是 `.yaml` 格式),检查以下部分是否存在并正确命名: ```yaml volumes: - name: conf configMap: name: your-configmap-name ``` 如果缺少上述内容,则需要添加正确的卷定义。 同时,在容器初始化容器的 `volumeMounts` 中也需要正确引用该卷名,例如: ```yaml containers: - name: mysql-container volumeMounts: - mountPath: /etc/mysql/conf.d name: conf # 确保这里的 name 与 volumes.name 匹配 initContainers: - name: init-something volumeMounts: - mountPath: /tmp/config name: conf # 同样需要匹配 - mountPath: /etc/config/map name: config-map # 如果这个也找不到,请确认是否已经定义 ``` #### 2. 确认 ConfigMap 存在 确保所有引用到的 ConfigMap 已经存在并且名字一致。可以运行以下命令验证: ```bash kubectl get configmaps | grep <your-configmap-name> ``` 如果没有找到相关的 ConfigMap,你需要先创建它。例如: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: your-configmap-name data: custom.conf: | some_config_value=example ``` 然后应用此配置文件: ```bash kubectl apply -f your-configmap.yaml ``` #### 3. 更新资源后重新部署 修改完所有的错误之后,记得更新你的工作负载: ```bash kubectl delete sts mysql kubectl apply -f your-statefulset-definition.yaml ``` --- ### 总结 通过对 Pod 定义文件中卷及其挂载点的一致性存在的检查,能够有效定位问题所在,并通过修正相应的配置达到解决问题的目的。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值