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类型是非常重要的。
? 在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
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 中将环境变量定义为键值对:
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：这表示如果本地已经存在相同的镜像，就使用它，否则不拉取新的镜像。?
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。
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 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。
如果通过 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 卷。
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 (网络文件系统) 挂载到你的 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 卷用来将持久卷（PersistentVolume）挂载到 Pod 中。 持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下“申领”持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
更多详情请参考持久卷。