K8s（九）—volume.md

- volume
- - configMap
  - - 介绍
    - 官网
    - 例子
    - [基于文件生成 ConfigMap](#基于文件生成 ConfigMap)
    - [使用 ConfigMap 数据定义容器环境变量](#使用 ConfigMap 数据定义容器环境变量)
    - - [使用单个 ConfigMap 中的数据定义容器环境变量](#使用单个 ConfigMap 中的数据定义容器环境变量)
  - EmptyDir
  - hostPath
  - - [hostPath 配置示例](#hostPath 配置示例)
  - nfs
  - persistentVolumeClaim

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 路径下。请注意，这个路径来源于卷的 mountPath 和 log_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。以下是配置文件中各部分的详细解释：
1.
1.

apiVersion 和 kind：
- •
  
  apiVersion: v1 表示使用Kubernetes的v1版本API。
- •
  
  kind: Pod 指定创建的资源类型为Pod。
1. metadata：
- •
  
  name: dapi-test-pod 定义了Pod的名称为 "dapi-test-pod"。
1. spec：
- •
  
  containers：这是一个容器列表，用于定义Pod中的容器。
  - •
    
    name: test-container：定义了容器的名称为 "test-container"。
  - •
    
    image: busybox：指定了容器要使用的镜像，这里是一个名为 "busybox" 的轻量级Linux发行版。
  - •
    
    imagePullPolicy: IfNotPresent：这表示如果本地已经存在相同的镜像，就使用它，否则不拉取新的镜像。
  - •
    
    command 和 args：这两个字段定义了容器的启动命令和参数。
    - •
      
      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 卷）的一种方法。

更多详情请参考持久卷。