Linux(企业级)——kubernetes(卷/volume)

最新推荐文章于 2021-08-30 11:17:11 发布

不问青黄

最新推荐文章于 2021-08-30 11:17:11 发布

阅读量176

点赞数

分类专栏： Linux 文章标签： kubernetes linux docker 运维

本文链接：https://blog.csdn.net/weixin_45699877/article/details/119250188

版权

Linux 专栏收录该内容

54 篇文章 2 订阅

订阅专栏

k8s中的卷/volume

1. EmptyDir卷
2. HostPath 卷
- 2.1 hostpath模式
- 2.2 nfs模式
3. PersistentVolume卷

1. EmptyDir卷

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

vim vol1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: vol1
spec:
  containers:
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    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

应用配置文件，进入终端创建大于100M 的文件，查看pod状态
在这里插入图片描述
一定时间后，pod会被终止

emptydir缺点：
不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；
影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；用户不能及时感知到内存不可用。

2. HostPath 卷

2.1 hostpath模式

hostPath 卷能将主机节点文件系统上的文件或目录挂载到 Pod 中。
具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 hostPath 使用的资源。
基础主机上创建的文件或目录只能由 root 用户写入。您需要在特权容器中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 hostPath 卷。

vim hostpath.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /mnt
      type: DirectoryOrCreate

kubectl apply -f  hostpath.yaml

此时会把分配节点的终端/mnt目录挂载至容器中的/test-pd下，在此目录下创建文件，在pod所在节点主机可以看见所创建的文件。
在这里插入图片描述

2.2 nfs模式

vim nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: ppp
spec:
  containers:
  - image: myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 172.25.52.1
      path: /mnt/nfs

应用创建节点，在真机目录下创建文件检验是否挂载成功。
在这里插入图片描述

3. PersistentVolume卷

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。

使用
Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。
释放
当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。
回收
PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外部存储（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是会被删除。
状态：
Available：空闲的资源，未绑定给PVC
Bound：绑定给了某个PVC
Released：PVC已经删除了，但是PV还没有被集群回收
Failed：PV在自动回收中失败了
命令行可以显示PV绑定的PVC名称。
访问模式
ReadWriteOnce – 该volume只能被单个节点以读写的方式映射
ReadOnlyMany – 该volume可以被多个节点以只读方式映射
ReadWriteMany – 该volume可以被多个节点以读写的方式映射
在命令行中，访问模式可以简写为：
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
回收策略
Retain：保留，需要手动回收
Recycle：回收，自动删除卷中数据
Delete：删除，相关联的存储资产，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都会被删除

当前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持删除操作。

3.1 静态pv

集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用
首先，配置nfs

yum install -y nfs-utils
mkdir -m 777 /mnt/nfs
vim /etc/exports

 /mnt/nfs	*(rw,sync,no_root_squash)

systemctl enable --now rpcbind
systemctl enable --now nfs

在这里插入图片描述
创建PV文件

 vim pv1.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv1
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /mnt/nfs
    server: 172.25.52.1

应用创建PV：

kubectl create -f pv1.yaml

在这里插入图片描述创建PVC文件

vim pvc1.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

应用配置文件查看pvc

kubectl create -f  pvc1.yaml

在这里插入图片描述
创建pod挂载

vim pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: myapp:v1
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: pv1
  volumes:
  - name: pv1
    persistentVolumeClaim:
      claimName: pvc1

kubectl create -f  pod1.yaml

在/mnt/nfs创建index.html
检测是否可以访问
在这里插入图片描述

3.2 动态pv

StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段，这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。
在这里插入图片描述

配置动态pv示例

首先准备nfs-client-provisioner镜像，上传至仓库默认项目；
编写配置文件

vim nfs-client-provisioner.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: westos.org/nfs
            - name: NFS_SERVER
              value: 172.25.52.1 #nfs服务器
            - name: NFS_PATH
              value: /mnt/nfs	#nfs共享路径
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.25.52.1	#nfs服务器
            path: /mnt/nfs	#nfs共享路径
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: westos.org/nfs
parameters:
  archiveOnDelete: "true"

配置文件中的archiveOnDelete: "true"表示删除pvc后，之前pod所有的数据会被打包存放，false表示删除pvc后数据与目录同步删除。
创建指定的namespace，并应用配置文件

kubectl create namespace nfs-client-provisioner
kubectl apply -f nfs-client-provisioner.yaml

在这里插入图片描述
由于并没有指定pod与对应pvc，因此此时pv与pvc为空，只有创建好的sc策略
编写pvc文件

cat test-claim.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim	#此处设定PVC名
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Mi

应用pvc文件之后会为pvc分配并绑定pv

kubectl apply -f test-claim.yaml

在这里插入图片描述创建pod，为其指定刚刚所创建的pvc

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: myapp:v1
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html #挂载目录
      name: pv1
  volumes:
  - name: pv1
    persistentVolumeClaim:
      claimName: test-claim #指定挂载pvc

应用创建pod，此时在nfs服务端会创建该pod对应pv目录，
命名规则为{namespace}-${pvcName}-${pvName

kubectl apply -f  pod.yaml

在这里插入图片描述在nfs服务端查看pv，向pv中创建web首页文件

cd default-test-claim-pvc-78566e02-2cb0-4c24-ab75-b9cacb5a142d/
echo hello > index.html

此时访问pod的80端口，可以看到刚刚添加的内容
在这里插入图片描述按顺序回收节点，回收pvc
此时nfs服务器上pv目录已经被打包，命名规则为archieved-${namespace}-${pvcName}-${pvName}

设置默认

默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储：（只能有一个默认StorageClass）
如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意味着它只能够跟 storageClassName 也是“”的 PV 进行绑定

#设定默认的sv
kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

在这里插入图片描述

3.3 StatefulSet

StatefulSet给所有的Pod进行了编号，编号规则是：$(statefulset名称)-$(序号)，从0开始。
Pod被删除后重建，重建Pod的网络标识也不会改变,Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来,并且为每个Pod提供了一个固定且唯一的访问入口,即Pod对应的DNS记录。
StatefulSet所控制的节点必须通过控制器指定副本数量进行增加或回收。
StatefulSet所控制的节点启动与回收都是按顺序进行。
创建headless 无头服务

vim headless.yaml

apiVersion: v1
kind: Service
metadata:
 name: nginx-svc
 labels:
  app: nginx
spec:
 ports:
 - port: 80
   name: web
 clusterIP: None
 selector:
  app: nginx

kubectl apply -f headless.yaml

在这里插入图片描述创建statefulset服务配置文件

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx-svc"
 replicas: 4
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: myapp:v1
     ports:
     - containerPort: 80
       name: web
     volumeMounts:
       - name: www
         mountPath: /usr/share/nginx/html
 # 添加PVC模板，为pod副本挂载pv        
 volumeClaimTemplates:
  - metadata:
     name: www
    spec:
     storageClassName: managed-nfs-storage
     accessModes:
     - ReadWriteOnce
     resources:
      requests:
       storage: 1Gi

应用模板，观察启动顺序，按顺序拉取镜像运行

kubectl apply -f nginx-svc.yaml

在这里插入图片描述
成功运行镜像之后，会建立响应数量的pv与pvc
查看statefulset控制器

此时在nfs服务端可以看到建立起来的pv目录

在这里插入图片描述
分别在目录中建立index.html，用于测试DNS解析与负载均衡

在master端，运行busybox镜像，测试地址解析与负载均衡。

kubectl run  demo --image=busyboxplus -it

通过nginx-svc可以成功解析到svc中的pod，并且访问时默认负载均衡
在这里插入图片描述

不问青黄

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Linux(企业级)——kubernetes(卷/volume)

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

扫一扫