德胜门网站建设,中国建设企业网站,菏泽官方网站,c 网站开发教程 购物网站目录 volumeconfigMap介绍官网例子基于文件生成 ConfigMap使用 ConfigMap 数据定义容器环境变量使用单个 ConfigMap 中的数据定义容器环境变量 EmptyDirhostPathhostPath 配置示例 nfspersistentVolumeClaim volume
https://kubernetes.io/zh-cn/docs/concepts/storage/volume… 目录 volumeconfigMap介绍官网例子基于文件生成 ConfigMap使用 ConfigMap 数据定义容器环境变量使用单个 ConfigMap 中的数据定义容器环境变量 EmptyDirhostPathhostPath 配置示例 nfspersistentVolumeClaim 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:- ReadWriteOnceresources:requests:storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:volumes:- name: my-storagepersistentVolumeClaim:claimName: my-pvccontainers:- name: my-containerimage: my-imagevolumeMounts:- mountPath: /dataname: my-storage在此示例中我们创建了一个PersistentVolumeClaimmy-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-literalKEY1VALUE1 --from-literalKEY2VALUE2**YAML定义**以下是一个ConfigMap的YAML示例apiVersion: v1kind: ConfigMapmetadata:name: my-configdata:KEY1: VALUE1KEY2: VALUE2**从文件创建**还可以从文件创建ConfigMap例如从配置文件中读取键值对列表。将ConfigMap注入到Pod中 ConfigMap可以通过以下方式注入到Pod中- **作为环境变量**: 使用env字段将ConfigMap的数据注入为容器的环境变量。- **作为卷Volume**: 将ConfigMap数据作为文件挂载到容器中的某个路径上容器可以读取这些文件作为配置文件。示例以下是一个将ConfigMap作为环境变量注入到Pod中的示例apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- name: my-containerimage: my-imageenv:- name: KEY1valueFrom:configMapKeyRef:name: my-configkey: 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: testimage: busybox:1.28volumeMounts:- name: config-volmountPath: /etc/configvolumes:- name: config-volconfigMap:name: log-configitems:- key: log_levelpath: log_levellog-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/
[rootk8smaster configmap]# kubectl get cm
NAME DATA AGE
game-config 2 39s
kube-root-ca.crt 1 2d23h
[rootk8smaster configmap]# kubectl create configmap game-config --from-file/root/configmap/
configmap/game-config created
[rootk8smaster configmap]# kubectl get gf
error: the server doesnt have a resource type gf
[rootk8smaster configmap]# kubectl get cm
NAME DATA AGE
game-config 2 39s
kube-root-ca.crt 1 2d23h
[rootk8smaster configmap]# kubectl describe configmaps game-config
Name: game-config
Namespace: default
Labels: none
Annotations: noneDatagame.properties:
----
enemiesaliens
lives3
enemies.cheattrue
enemies.cheat.levelnoGoodRotten
secret.code.passphraseUUDDLRLRBABAS
secret.code.allowedtrue
secret.code.lives30
ui.properties:
----
color.goodpurple
color.badyellow
allow.textmodetrue
how.nice.to.lookfairlyNiceEvents: none
[rootk8smaster configmap]# kubectl get configmaps game-config -o yaml /root/configmap/game.yaml
[rootk8smaster configmap]# ls
game.properties game.yaml ui.properties基于文件生成 ConfigMap
cat EOF ./kustomization.yaml
configMapGenerator:
- name: game-config-4files:- configmap/game.properties
EOF应用Applykustomization 目录创建 ConfigMap 对象
kubectl apply -k .
[rootk8smaster ~]# kubectl get cm
NAME DATA AGE
game-config 2 8m9s
game-config-4-m9dm2f92bt 1 59s
kube-root-ca.crt 1 2d23h
[rootk8smaster ~]# kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: none
Annotations: noneDatagame.properties:
----
enemiesaliens
lives3
enemies.cheattrue
enemies.cheat.levelnoGoodRotten
secret.code.passphraseUUDDLRLRBABAS
secret.code.allowedtrue
secret.code.lives30
Events: none使用 ConfigMap 数据定义容器环境变量
使用单个 ConfigMap 中的数据定义容器环境变量 • 在 ConfigMap 中将环境变量定义为键值对: kubectl create configmap special-config --from-literalspecial.howvery这是一个 kubectl 命令用于在Kubernetes集群中创建一个名为 special-config 的ConfigMap并将一个键值对添加到该ConfigMap中。具体来说这个命令的含义如下 • kubectl create configmap special-config这部分命令告诉Kubernetes创建一个名为 special-config 的ConfigMap。 • --from-literalspecial.howvery这部分是 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 环境变量。 [rootk8smaster ~]# 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[rootk8smaster ~]# kubectl describe configmaps/special-config
Name: special-config
Namespace: default
Labels: none
Annotations: noneDataspecial.how:
----
very
Events: none• 将 ConfigMap 中定义的 special.how 赋值给 Pod 规约中的 SPECIAL_LEVEL_KEY 环境变量。 创建 pods/pod-single-configmap-env-variable.yaml [rootk8smaster configmap]# ls
game.properties game.yaml pod-single-configmap-env-variable.yaml ui.properties[rootk8smaster configmap]# wget https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml --no-check-certificateapiVersion: v1
kind: Pod
metadata:name: dapi-test-pod
spec:containers:- name: test-containerimage: busyboximagePullPolicy: IfNotPresentcommand: [ /bin/sh]args: [-c,env ;while true; do echo hello; sleep 100;done]env:# Define the environment variable- name: SPECIAL_LEVEL_KEYvalueFrom:configMapKeyRef:# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEYname: special-config# Specify the key associated with the valuekey: special.howrestartPolicy: 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来配置容器的环境变量。 [rootk8smaster configmap]# kubectl get pod
NAME READY STATUS RESTARTS AGE
dapi-test-pod 1/1 Running 0 21s
test-pd 1/1 Running 0 55m[rootk8smaster configmap]# kubectl logs dapi-test-pod
***
SPECIAL_LEVEL_KEYvery
***现在Pod 的输出包含环境变量 SPECIAL_LEVEL_KEYvery。
EmptyDir
apiVersion: v1
kind: Pod
metadata:name: test-pd
spec:containers:- image: registry.k8s.io/test-webservername: test-containervolumeMounts:- mountPath: /cachename: cache-volumevolumes:- name: cache-volumeemptyDir:sizeLimit: 500Mi启用pod
[rootk8smaster volume]# kubectl apply -f nginx.yaml
pod/test-pd created
[rootk8smaster volume]# kubectl get pod
NAME READY STATUS RESTARTS AGE
test-pd 1/1 Running 0 6s进入容器里面进入卷里面创建文件
[rootk8smaster volume]# kubectl exec -it test-pd -- bash
roottest-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
roottest-pd:/# cd cache/
roottest-pd:/cache# ls
roottest-pd:/cache# mkdir test查找pod调度到那个node上
[rootk8smaster 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查找卷
[rootk8snode2 ~]# find / -name test
***
/var/lib/kubelet/pods/bfe54579-84e1-4ef2-b85e-722b84d848d1/volumes/kubernetes.io~empty-dir/cache-volume/test
***
[rootk8snode2 ~]# cd /var/lib/kubelet/pods/bfe54579-84e1-4ef2-b85e-722b84d848d1/volumes/kubernetes.io~empty-dir/cache-volume/test
[rootk8snode2 test]# ls
[rootk8snode2 test]# cd ..
[rootk8snode2 cache-volume]# ls
testhostPath
警告
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: nginximagePullPolicy: IfNotPresentname: ydhnginx-2volumeMounts:- mountPath: /ydhdataname: cache-volume-2volumes:- name: cache-volume-2hostPath:# 宿主上目录位置path: /data# 此字段为可选type: DirectoryOrCreate进入容器创建文件
[rootk8smaster volume]# kubectl exec -it test-pd-2 -- bash
roottest-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
roottest-pd-2:/# cd ydhdata/
roottest-pd-2:/ydhdata# mkdir ydhtest
[rootk8snode2 /]# cd data/
[rootk8snode2 data]# ls
ydhtestnfs
nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除nfs 卷的内容在删除 Pod 时会被保存卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据并且这些数据可以在 Pod 之间共享。
apiVersion: v1
kind: Pod
metadata:name: test-pd
spec:containers:- image: registry.k8s.io/test-webservername: test-containervolumeMounts:- mountPath: /my-nfs-dataname: test-volumevolumes:- name: test-volumenfs:server: my-nfs-server.example.compath: /my-nfs-volumereadOnly: true说明
在使用 NFS 卷之前你必须运行自己的 NFS 服务器并将目标 share 导出备用。
还需要注意不能在 Pod spec 中指定 NFS 挂载可选项。 可以选择设置服务端的挂载可选项或者使用 /etc/nfsmount.conf。 此外还可以通过允许设置挂载可选项的持久卷挂载 NFS 卷。
如需了解用持久卷挂载 NFS 卷的示例请参考 NFS 示例。
persistentVolumeClaim
persistentVolumeClaim 卷用来将持久卷PersistentVolume挂载到 Pod 中。 持久卷申领PersistentVolumeClaim是用户在不知道特定云环境细节的情况下“申领”持久存储例如 GCE PersistentDisk 或者 iSCSI 卷的一种方法。
更多详情请参考持久卷。
