K8s(九)—volume.md

2023-12-16 04:49:07

volume

https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/

在Kubernetes中,Volume是一种抽象的概念,用于将持久化存储附加到Pod中,以便容器可以读取和写入数据。Volumes提供了一种在Pod之间共享数据、将数据持久化存储以及将数据从主机挂载到容器中的方法。以下是关于Kubernetes中Volume的详细解释:

Volume的基本概念

  • ?

    容器存储抽象: Volume是Kubernetes的容器存储抽象,它使容器能够在不同的Pod之间共享数据,或者将数据持久化存储到底层存储设备上。

  • ?

    生命周期绑定: Volume的生命周期与Pod紧密绑定,当Pod被删除时,与之关联的Volume也会被删除(除非它被配置为保留)。

  • ?

    挂载点: Volume在Pod中通过一个或多个挂载点(mount points)进行访问。容器可以将这些挂载点用作文件或目录的存储位置。

内置Volume类型

Kubernetes支持多种内置Volume类型,每种类型都有不同的用途和特性,包括但不限于:

  • ?

    EmptyDir: 空目录,生命周期与Pod相同,适合临时存储。

  • ?

    HostPath: 主机文件系统的目录,适合与主机共享文件。

  • ?

    PersistentVolumeClaim (PVC): PVC允许动态分配持久卷,并且可以用于数据持久性存储。

  • ?

    ConfigMap和Secret: 将ConfigMap和Secret数据作为文件或环境变量挂载到容器中。

持久卷(Persistent Volumes)和持久卷声明(Persistent Volume Claims)

  • ?

    持久卷(PV)是集群级别的存储资源,它们独立于Pod的生命周期。

  • ?

    持久卷声明(PVC)是Pod对PV的请求。PVC允许开发人员声明他们需要多少存储以及存储的属性(例如访问模式和存储类)。

  • ?

    PVC与PV进行绑定,Pod再引用PVC,使得数据持久化存储可以动态地分配给Pod。

存储类(Storage Class)

  • ?

    存储类是一种用于动态分配PV的资源管理策略。它允许管理员定义不同类型的存储(如本地存储、网络存储等)以及各种参数。

  • ?

    当PVC没有指定存储卷时,存储类可以根据要求动态创建PV。

Volume的使用场景

  • ?

    共享配置文件: 使用ConfigMap Volume或Secret Volume将配置文件共享给多个容器。

  • ?

    数据持久化: 使用PersistentVolume和PersistentVolumeClaim来实现数据的持久性存储,例如数据库数据。

  • ?

    临时存储: 使用EmptyDir Volume来创建在Pod之间共享的临时目录。

  • ?

    日志和监控数据: 使用HostPath Volume将日志文件或监控数据存储到宿主主机上以供分析。

Volume的声明

  • ?

    在Pod的定义中,可以通过volumes字段声明要使用的Volume。

  • ?

    在容器的定义中,可以通过volumeMounts字段将Volume挂载到容器的指定路径。

示例

以下是一个使用PersistentVolumeClaim和Volume的示例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc
  containers:
    - name: my-container
      image: my-image
      volumeMounts:
        - mountPath: /data
          name: my-storage

在此示例中,我们创建了一个PersistentVolumeClaim(my-pvc),然后在Pod中使用该PVC来创建一个Volume,并将它挂载到容器的/data路径上。

总之,Kubernetes的Volume是一种强大的机制,用于处理容器存储需求,它提供了多种选项,使得在容器化应用程序中管理数据变得更加灵活和可靠。不同类型的Volume适用于不同的用例,根据应用程序的需求来选择适当的Volume类型是非常重要的。

configMap

介绍

? 在Kubernetes中,ConfigMap(配置映射)是一种用于将配置数据以键值对的形式存储并注入到容器中的资源。ConfigMap允许将配置信息从容器镜像中分离出来,从而使配置更易于管理和修改。以下是关于Kubernetes中ConfigMap的详细解释:

ConfigMap的基本概念

 **配置数据存储**: ConfigMap用于存储配置数据,这些数据通常以**键值对**的形式存在。键值对中的键(key)是配置的名称,而值(value)是配置的内容。
 **解耦配置**: ConfigMap将配置数据从应用程序容器中分离出来,从而使得应用程序可以更容易地配置和修改,而不需要重新构建镜像。
 **不敏感数据**: ConfigMap通常用于存储非敏感数据,如应用程序配置、环境变量、命令行参数等。

创建和管理ConfigMap

 **命令行创建**:可以使用`kubectl create configmap`命令或从YAML文件创建ConfigMap。例如:

 ```
 kubectl create configmap my-config --from-literal=KEY1=VALUE1 --from-literal=KEY2=VALUE2
 ```
 **YAML定义**:以下是一个ConfigMap的YAML示例:

 ```
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: my-config
 data:
   KEY1: VALUE1
   KEY2: VALUE2
 ```
 **从文件创建**:还可以从文件创建ConfigMap,例如从配置文件中读取键值对列表。

将ConfigMap注入到Pod中

 ConfigMap可以通过以下方式注入到Pod中:

 - 

   **作为环境变量**: 使用`env`字段将ConfigMap的数据注入为容器的环境变量。

 - 

   **作为卷(Volume)**: 将ConfigMap数据作为文件挂载到容器中的某个路径上,容器可以读取这些文件作为配置文件。
 示例:以下是一个将ConfigMap作为环境变量注入到Pod中的示例:

 ```
 apiVersion: v1
 kind: Pod
 metadata:
   name: my-pod
 spec:
   containers:
     - name: my-container
       image: my-image
       env:
         - name: KEY1
           valueFrom:
             configMapKeyRef:
               name: my-config
               key: KEY1
 ```

使用场景

 **应用程序配置**: 将应用程序的配置信息(如数据库连接字符串、端口号、日志级别等)存储在ConfigMap中,使应用程序更易于配置和管理。
 **环境变量注入**: 使用ConfigMap将环境变量注入到容器中,以自定义容器的行为。
 **配置文件挂载**: 将配置文件存储在ConfigMap中,并将其作为卷挂载到容器中,以供应用程序读取。

更新和维护

 ConfigMap的数据可以随时更新,Kubernetes会自动将更新后的数据应用到Pod中。
 当ConfigMap更新时,使用该ConfigMap的Pod可以实时感知到这些变化。

? 总之,ConfigMap是Kubernetes中一种重要的资源,用于存储和注入配置数据,以实现应用程序的可配置性和可维护性。通过将配置数据与容器镜像分离,ConfigMap使得应用程序的配置更加灵活,允许在不重新构建容器镜像的情况下进行配置更改。这在微服务和容器化应用程序中非常有用,因为它使配置管理变得更加简单且易于维护。

官网

? configMap卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 configMap 类型的卷引用,然后被 Pod 中运行的容器化应用使用。

引用 configMap 对象时,你可以在卷中通过它的名称来引用。 你可以自定义 ConfigMap 中特定条目所要使用的路径。 下面的配置显示了如何将名为 log-config 的 ConfigMap 挂载到名为 configmap-pod 的 Pod 中:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

log-config ConfigMap 以卷的形式挂载,并且存储在 log_level 条目中的所有内容都被挂载到 Pod 的 /etc/config/log_level 路径下。 请注意,这个路径来源于卷的 mountPathlog_level 键对应的 path

说明:

在使用 ConfigMap 之前你首先要创建它。

ConfigMap 总是以 readOnly 的模式挂载。

容器以 subPath 卷挂载方式使用 ConfigMap 时,将无法接收 ConfigMap 的更新。

文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式,可使用 binaryData 字段。

例子

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/

# 将示例文件下载到 `/root/configmap/` 目录
wget https://kubernetes.io/examples/configmap/game.properties 

wget https://kubernetes.io/examples/configmap/ui.properties

# 创建 ConfigMap
kubectl create configmap game-config --from-file=/root/configmap/
[root@k8smaster configmap]# kubectl get cm
NAME               DATA   AGE
game-config        2      39s
kube-root-ca.crt   1      2d23h
[root@k8smaster configmap]# kubectl create configmap game-config --from-file=/root/configmap/
configmap/game-config created
[root@k8smaster configmap]# kubectl get gf
error: the server doesn't have a resource type "gf"
[root@k8smaster configmap]# kubectl get cm
NAME               DATA   AGE
game-config        2      39s
kube-root-ca.crt   1      2d23h
[root@k8smaster configmap]# kubectl describe configmaps game-config
Name:         game-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Events:  <none>
[root@k8smaster configmap]# kubectl get configmaps game-config -o yaml >/root/configmap/game.yaml
[root@k8smaster configmap]# ls
game.properties  game.yaml  ui.properties
基于文件生成 ConfigMap
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
  files:
  - configmap/game.properties
EOF

应用(Apply)kustomization 目录创建 ConfigMap 对象:

kubectl apply -k .
[root@k8smaster ~]# kubectl get cm
NAME                       DATA   AGE
game-config                2      8m9s
game-config-4-m9dm2f92bt   1      59s
kube-root-ca.crt           1      2d23h
[root@k8smaster ~]# kubectl describe configmaps/game-config-4-m9dm2f92bt
Name:         game-config-4-m9dm2f92bt
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events:  <none>
使用 ConfigMap 数据定义容器环境变量
使用单个 ConfigMap 中的数据定义容器环境变量
  • ?

    在 ConfigMap 中将环境变量定义为键值对:

    kubectl create configmap special-config --from-literal=special.how=very
    

这是一个 kubectl 命令,用于在Kubernetes集群中创建一个名为 special-config 的ConfigMap,并将一个键值对添加到该ConfigMap中。具体来说,这个命令的含义如下:

  • ?

    kubectl create configmap special-config:这部分命令告诉Kubernetes创建一个名为 special-config 的ConfigMap。

  • ?

    --from-literal=special.how=very:这部分是 kubectl 命令的选项,用于指定要添加到ConfigMap中的数据。具体来说,它包含了一个键值对,键是 special.how,值是 very。这意味着创建的ConfigMap中将包含一个键为 special.how,值为 very 的项。

运行这个命令后,将在Kubernetes集群中创建一个名为 special-config 的ConfigMap,该ConfigMap包含一个键为 special.how,值为 very 的配置项。这个ConfigMap可以被Pod引用,以便在容器中使用这个配置项的值作为环境变量、命令参数或其他配置选项。例如,可以在上一个回答中提到的Pod配置中引用这个ConfigMap,将 special.how 的值分配给 SPECIAL_LEVEL_KEY 环境变量。

[root@k8smaster ~]# kubectl get cm
NAME                       DATA   AGE
game-config                2      12m
game-config-4-m9dm2f92bt   1      5m7s
kube-root-ca.crt           1      2d23h
special-config             1      16s
[root@k8smaster ~]# kubectl describe configmaps/special-config
Name:         special-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
special.how:
----
very
Events:  <none>
  • ?

    将 ConfigMap 中定义的 special.how 赋值给 Pod 规约中的 SPECIAL_LEVEL_KEY 环境变量。

    创建 pods/pod-single-configmap-env-variable.yaml

    [root@k8smaster configmap]# ls
    game.properties  game.yaml  pod-single-configmap-env-variable.yaml  ui.properties
    
    [root@k8smaster configmap]# wget https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml --no-check-certificate
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: busybox
          imagePullPolicy: IfNotPresent
          command: [ "/bin/sh"]
          args: ["-c","env ;while true; do echo hello; sleep 100;done"]
          env:
            # Define the environment variable
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
                  name: special-config
                  # Specify the key associated with the value
                  key: special.how
      restartPolicy: Never
    

    这是一个Kubernetes Pod的配置文件,用于创建一个名为 “dapi-test-pod” 的Pod。以下是配置文件中各部分的详细解释:

      apiVersion 和 kind

    • ?

      apiVersion: v1 表示使用Kubernetes的v1版本API。

    • ?

      kind: Pod 指定创建的资源类型为Pod。

      metadata

    • ?

      name: dapi-test-pod 定义了Pod的名称为 “dapi-test-pod”。

      spec

    • ?

      containers:这是一个容器列表,用于定义Pod中的容器。

      • ?

        name: test-container:定义了容器的名称为 “test-container”。

      • ?

        image: busybox:指定了容器要使用的镜像,这里是一个名为 “busybox” 的轻量级Linux发行版。

      • ?

        imagePullPolicy: IfNotPresent:这表示如果本地已经存在相同的镜像,就使用它,否则不拉取新的镜像。

      • ?

        commandargs:这两个字段定义了容器的启动命令和参数。

        • ?

          command: [ "/bin/sh"]:指定容器要执行的命令为 “/bin/sh”。

        • ?

          args: ["-c","env ;while true; do echo hello; sleep 100;done"]:这些参数将传递给命令,容器将在启动后运行 /bin/sh -c "env ;while true; do echo hello; sleep 100;done" 这个Shell命令。

      • ?

        env:这里定义了容器的环境变量。

        • ?

          name: SPECIAL_LEVEL_KEY:指定环境变量的名称为 “SPECIAL_LEVEL_KEY”。

        • ?

          valueFrom:这里使用了 valueFrom 来从ConfigMap引用值。

          • ?

            configMapKeyRef:这是引用ConfigMap的方式。

            • ?

              name: special-config:指定了ConfigMap的名称为 “special-config”。

            • ?

              key: special.how:指定了要引用的ConfigMap中的键为 “special.how”。

    • ?

      restartPolicy: Never:定义了Pod的重启策略为 “Never”,这意味着一旦容器退出,Pod将不会自动重启。

    ? 这个配置文件创建了一个Pod,其中包含一个名为 “test-container” 的容器,该容器使用BusyBox镜像,运行一个无限循环的Shell命令,每隔100秒输出 “hello”。此容器还引用了一个名为 “special-config” 的ConfigMap,并将其中的 “special.how” 键的值分配给环境变量 “SPECIAL_LEVEL_KEY”。这个配置演示了如何在Pod中使用ConfigMap来配置容器的环境变量。

    [root@k8smaster configmap]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    dapi-test-pod   1/1     Running   0          21s
    test-pd         1/1     Running   0          55m
    
    [root@k8smaster configmap]# kubectl logs dapi-test-pod
    ***
    SPECIAL_LEVEL_KEY=very
    ***
    

    现在,Pod 的输出包含环境变量 SPECIAL_LEVEL_KEY=very

EmptyDir

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

启用pod

[root@k8smaster volume]# kubectl apply -f nginx.yaml 
pod/test-pd created
[root@k8smaster volume]# kubectl get pod
NAME      READY   STATUS    RESTARTS   AGE
test-pd   1/1     Running   0          6s

进入容器里面,进入卷里面创建文件

[root@k8smaster volume]# kubectl exec -it test-pd -- bash
root@test-pd:/# ls
bin   cache  docker-entrypoint.d   etc	 lib	media  opt   root  sbin  sys  usr
boot  dev    docker-entrypoint.sh  home  lib64	mnt    proc  run   srv	 tmp  var
root@test-pd:/# cd cache/
root@test-pd:/cache# ls
root@test-pd:/cache# mkdir test

查找pod调度到那个node上

[root@k8smaster volume]# kubectl get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
test-pd   1/1     Running   0          85s   10.244.185.201   k8snode2   <none>           <none>

在k8snode2查找卷

[root@k8snode2 ~]# find / -name "test"
***
/var/lib/kubelet/pods/bfe54579-84e1-4ef2-b85e-722b84d848d1/volumes/kubernetes.io~empty-dir/cache-volume/test
***
[root@k8snode2 ~]# cd /var/lib/kubelet/pods/bfe54579-84e1-4ef2-b85e-722b84d848d1/volumes/kubernetes.io~empty-dir/cache-volume/test
[root@k8snode2 test]# ls
[root@k8snode2 test]# cd ..
[root@k8snode2 cache-volume]# ls
test

hostPath

警告:

HostPath 卷存在许多安全风险,最佳做法是尽可能避免使用 HostPath。 当必须使用 HostPath 卷时,它的范围应仅限于所需的文件或目录,并以只读方式挂载。

如果通过 AdmissionPolicy 限制 HostPath 对特定目录的访问,则必须要求 volumeMounts 使用 readOnly 挂载以使策略生效。

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

例如,hostPath 的一些用法有:

  • ?

    运行一个需要访问 Docker 内部机制的容器;可使用 hostPath 挂载 /var/lib/docker 路径。

  • ?

    在容器中运行 cAdvisor 时,以 hostPath 方式挂载 /sys

  • ?

    允许 Pod 指定给定的 hostPath 在运行 Pod 之前是否应该存在,是否应该创建以及应该以什么方式存在。

除了必需的 path 属性之外,你可以选择性地为 hostPath 卷指定 type

支持的 type 值如下:

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

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

  • ?

    HostPath 卷可能会暴露特权系统凭据(例如 Kubelet)或特权 API(例如容器运行时套接字),可用于容器逃逸或攻击集群的其他部分。

  • ?

    具有相同配置(例如基于同一 PodTemplate 创建)的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。

  • ?

    下层主机上创建的文件或目录只能由 root 用户写入。 你需要在特权容器中以 root 身份运行进程,或者修改主机上的文件权限以便容?能够写入 hostPath 卷。

hostPath 配置示例
apiVersion: v1
kind: Pod
metadata:
  name: test-pd-2
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: ydhnginx-2
    volumeMounts:
    - mountPath: /ydhdata
      name: cache-volume-2
  volumes:
  - name: cache-volume-2
    hostPath:
    	 # 宿主上目录位置
        path: /data
        # 此字段为可选
        type: DirectoryOrCreate

进入容器创建文件

[root@k8smaster volume]# kubectl exec -it test-pd-2 -- bash
root@test-pd-2:/# ls
bin   docker-entrypoint.d   home   media  proc	sbin  tmp  ydhdata
boot  docker-entrypoint.sh  lib    mnt	  root	srv   usr
dev   etc		    lib64  opt	  run	sys   var
root@test-pd-2:/# cd ydhdata/
root@test-pd-2:/ydhdata# mkdir ydhtest
[root@k8snode2 /]# cd data/
[root@k8snode2 data]# ls
ydhtest

nfs

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

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /my-nfs-data
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com
      path: /my-nfs-volume
      readOnly: true

说明:

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

还需要注意,不能在 Pod spec 中指定 NFS 挂载可选项。 可以选择设置服务端的挂载可选项,或者使用 /etc/nfsmount.conf。 此外,还可以通过允许设置挂载可选项的持久卷挂载 NFS 卷。

如需了解用持久卷挂载 NFS 卷的示例,请参考 NFS 示例

persistentVolumeClaim

persistentVolumeClaim 卷用来将持久卷(PersistentVolume)挂载到 Pod 中。 持久卷申领(PersistentVolumeClaim)是用户在不知道特定云环境细节的情况下“申领”持久存储(例如 GCE PersistentDisk 或者 iSCSI 卷)的一种方法。

更多详情请参考持久卷

文章来源:https://blog.csdn.net/qq_51010919/article/details/135027204
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。