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

      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。

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
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。