【Linux39-9】k8s存储之卷(volumes)、挂载不同类型的卷(emptyDir、hostpath、nfs)


1. 卷简介


卷官方文档

  • Container 中的文件在磁盘上是临时存放的,这给容器中运行的较重要的应用 程序带来一些问题。问题(1)是当容器崩溃时文件丢失。kubelet 会重新启动容器, 但容器会以干净的状态重启。 问题(2)当在同一 Pod 中运行多个容器并共享文件时出现。 Kubernetes 卷(Volume) 这一抽象概念能够解决这两个问题。
  • Kubernetes卷具有明确的生命周期,与包裹它的Pod相同。因此,卷比Pod中运行的任何容器的存活期都长,在容器重新启动时数据也会得到保留。当然,当一个Pod不再存在时,卷也将不再存在。也许更重要的是,Kubernetes可以
    支持许多类型的卷,Pod也能同时使用任意数量的卷。
  • 卷不能挂载到其他卷,也不能与其他卷有硬链接。Pod 中的每个容器必须独立地指定每个卷的挂载位置。

2. 卷类型


  • awsElasticBlockStore 、azureDisk、 azureFile、 cephfs、cinder. configMap、 csi
  • downwardAPl. emptyDir. fc (fibre channel)、 flexVolume、 flocker
  • gcePersistentDisk、 gitRepo (deprecated). glusterfs、 hostPath. iscsi、 local
  • nfs、 persistentVolumeClaim、 projected、 portwonxVolume、quobyte、rbd
  • scalelO、 secret. storageos、vsphereVolume

2.1 emptyDir 卷


当Pod指定到某个节点上时,首先创建的是一个emptyDir卷,并且只要Pod在该节点上运行,卷就一直存在。就像 它的名称表示的那样,卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同,但是这些容器都可以读写emptyDir卷中相同的文件。当Pod因为某些原因被从节点上删除时,emptyDir 卷中的数据也会永久删除。

用途:

  • 缓存空间,例如基于磁盘的归并排序。
  • 为耗时较长的计算任务提供检查点,以便任务能方便地从崩溃前状态恢复执行。
  • 在 Web 服务器容器服务数据时,保存内容管理器容器获取的文件。

默认情况下,emptyDir 卷存储在该节点所使用的介质上;这里的介质可以是磁盘或 SSD 或网络存储。但是,你可以将 emptyDir.medium 字段设置为 “Memory”,以告诉 Kubernetes 为你挂载 tmpfs(基于 RAM 的文件系统)。 虽然 tmpfs 速度非常快,但是要注意它与磁盘不同。 tmpfs 在节点重启时会被清除,并且你所写入的所有文件都会计入容器的内存消耗,受容器内存限制约束。

emptyDir 示例:

1)创建目录

mkdir volumes
cd volumes/

2)编写文件创建卷类型为emptyDir的pod

# emptydir.yml 
apiVersion: v1
kind: Pod
metadata:
  name: vol1
spec:
  containers:
  - image: radial/busyboxplus
    name: vm1
    stdin: true
    tty: true
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - name: vm2
    image: myapp:v1
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      medium: Memory
      sizeLimit: 100Mi
# 如果未指定内存大小
# 则基于内存的卷的大小为 Linux 主机上内存的 50%

3)查看信息

在这里插入图片描述

kubectl describe pod vol1 | less

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

4)测试数据共享:在vm1的挂载路径下写入内容,最终在vm2(包含nginx的镜像容器)下能访问到,说明数据共享

在这里插入图片描述

5)测试内存限制:配置文件中已经设置内存最大为100Mi,占用200Mi内存,发现等待几分钟后pod的状态变为 Evicted(驱离),之所以不是立即被驱离,是因为kubelet是定期进行检查的,这里会有一个时间差。

在这里插入图片描述

emptyDir的缺点:

  • 不能及时禁止用户使用内存,虽然过1-2分钟kubelet会见pod驱离,但是在这个时间内,其实对node还是有风险的。
  • 影响kubernets调度,因为empty dir并不涉及node的resources,这样会造成Pod “偷偷”使用了node的内存,但是调度器并不知道。
  • 用户不能及时感知到内存不可用。

2.2 hostpath


hostPath 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 虽然这不是大多数 Pod 需要的,但是它为一些应用程序提供了强大的逃生舱。

hostPath 的一些用法:

  • 运行一个需要访问 Docker 引擎内部机制的容器;请使用 hostPath 挂载 /var/lib/docker 路径。
  • 在容器中运行 cAdvisor 时,以 hostPath 方式挂载 /sys
  • 允许 Pod 指定给定的 hostPath 在运行 Pod 之前是否应该存在,是否应该创建以及应该以什么方式存在。

支持的 type 值:

取值 行为
空字符串(默认)用于向后兼容,这意味着在安装 hostPath 卷之前不会执行任何检查。
DirectoryOrCreate 如果在给定路径上什么都不存在,那么将根据需要创建空目录,权限设置为 0755,具有与 Kubelet 相同的组和所有权。
Directory 在给定路径上必须存在的目录。
FileOrCreate 如果在给定路径上什么都不存在,那么将在那里根据需要创建空文件,权限设置为 0644,具有与 Kubelet 相同的组和所有权。
File 在给定路径上必须存在的文件。
Socket 在给定路径上必须存在的 UNIX 套接字。
CharDevice 在给定路径上必须存在的字符设备。
BlockDevice 在给定路径上必须存在的块设备。

当使用这种类型的卷时要小心,因为:

  • 具有相同配置(例如基于同一 PodTemplate 创建)的多个 Pod 会由于节点上文件的不同,而在不同节点上有不同的行为
  • 下层主机上创建的文件或目录只能由 root 用户写入。你需要在 特权容器 中以 root 身份运行进程,或者修改主机上的文件权限以便容器能够写入 hostPath

hostpath 示例:

1)创建类型为hostpath的pod,curl 访问失败

# hostpath.yml 
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: myapp:v1
    name: vm1
    volumeMounts:
    - mountPath: /usr/share/nginx/html # 容器内部的挂载目录
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /webdata # node主机上目录位置
      type: DirectoryOrCreate

在这里插入图片描述

2)发现此容器在node节点server3上,创建测试页,回到master节点发现能成功访问

在这里插入图片描述
在这里插入图片描述

3)删除pod,在node节点的目录及内容也不会消失

在这里插入图片描述
在这里插入图片描述

2.3 nfs


nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除,nfs 卷的内容在删除 Pod 时会被保存,卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据,并且这些数据可以在 Pod 之间共享。

  • 在使用 NFS 卷之前,必须运行自己的 NFS 服务器并将目标 share 导出备用。

nfs 示例:

k8s卷挂载之nfs示例

1)在指定主机 192.168.17.250 搭建nfs服务器

1.安装nfs
yum install -u nfs-utils
2.创建挂载目录
mkdir /nfsdata
chmod 777 /nfsdata/
3.编辑nfs配置文件
vim /etc/exports
/nfsdata	*(rw,no_root_squash)
4.让新设置的文件生效
exportfs -rv
5.开启nfs服务
systemctl enable --now nfs
6.显示nfs输出目录列表
showmount -e

在这里插入图片描述
在这里插入图片描述

2)创建 nfs 类型的pod,发现未成功Running时,检查此容器的node节点是否安装nfs-utils,安装后成功Running

# nfs.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pd
spec:
  containers:
  - image: myapp:v1
    name: vm1
    volumeMounts:
    - mountPath: /usr/share/nginx/html #容器挂载目录
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 192.168.17.250 #nfs服务器地址
      path: /nfsdata

在这里插入图片描述

3)此时访问容器IP会失败,在nfs服务器上创建测试页后,成功访问!

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/weixin_46069582/article/details/114069043