序言

任何一件事情，只要坚持六个月以上，你都可以看到质的飞跃。

在上一篇文章中，【K8S系列】深入解析Pod对象(一)

我们深入解析了 Pod 的 API 对象，讲解了 Pod 和 Container 的关系。

作为 Kubernetes 项目里最核心的编排对象，Pod 携带的信息非常丰富。

今天，从一种特殊的 Volume ——Projected Volume 开始，主要讲解：

Secret
Downward API

从上面这两种类型展开，希望能帮助你更加深入地理解 Pod 对象各个重要字段的含义。

文章标记颜色说明：

黄色：重要标题
红色：用来标记结论
绿色：用来标记一级论点
蓝色：用来标记二级论点

1.Volume 简单介绍

Kubernetes（k8s）中的 Volume 是一种抽象概念，用于表示容器中的存储设备。

Volume 可以包含多个容器，以便它们可以在容器之间共享数据。Volume 在容器内部进行挂载，从而使容器中的应用程序可以像使用本地存储设备一样使用它们。

Kubernetes 中的 Volume 具有以下特点：

生命周期：Volume 可以独立于容器而存在，因此可以在容器之间共享和重用数据。

类型：Kubernetes 中支持多种类型的 Volume，例如 persistentVolumeClaim（PVC）emptyDir、hostPath、configMap、secret 、downwardAPI、projected、CSI等等。每种 Volume 类型都有其特定的用途和限制。

挂载方式：Volume 可以通过不同的挂载方式挂载到容器中，例如作为容器的文件夹、作为容器的环境变量等等。每种挂载方式也都有其特定的用途和限制。

存储介质：Volume 可以与不同的存储介质一起使用，例如本地磁盘、网络存储、云存储等等。

Kubernetes 中的 Volume 提供了一种灵活、可扩展的方式来管理容器中的数据存储。通过使用 Volume，可以轻松地实现容器之间的数据共享和数据持久化，从而使 Kubernetes 应用程序更加可靠和可维护。

2 Projected Volume 介绍

在 Kubernetes 中，有几种特殊的 Volume，它们存在的意义不是为了存放容器里的数据，也不是用来进行容器和宿主机之间的数据交换。

这些特殊 Volume 的作用，是为容器提供预先定义好的数据。

所以，从容器的角度来看，这些 Volume 里的信息就是仿佛是被 Kubernetes“投射”（Project）进入容器当中的。这正是 Projected Volume 的含义

详细介绍一下：

Kubernetes（k8s）中的 projected Volume 是一种特殊的 Volume 类型，可以把它翻译为“投射数据卷”。

简单说，它可以将多个 Volume 类型投影到一个 Volume 中。

它可以将多个 Volume 挂载到容器中，从而实现更加灵活和高效的容器化部署。

projected Volume 支持以下四种 Volume 类型的投影：

Secret：将 Kubernetes 中的 Secret 对象挂载到容器中，从而使容器可以访问加密的敏感信息，如密码、证书等。

ConfigMap：将 Kubernetes 中的 ConfigMap 对象挂载到容器中，从而使容器可以访问 ConfigMap 中的配置信息。

DownwardAPI：将容器的元数据（如 Pod 名称、命名空间、标签等）挂载到容器中，从而使容器可以访问自身的元数据。

ServiceAccountToken：将 ServiceAccount 的令牌挂载到容器中，从而使容器可以通过 API 服务器与 Kubernetes API 进行通信。

使用 projected Volume 可以将多个 Volume 类型投影到一个 Volume 中，从而简化 Volume 的管理和配置。

例如，可以将 ConfigMap 和 Secret 投影到一个 Volume 中，并将其挂载到容器中，以便容器可以访问配置信息和加密的敏感信息。

使用 projected Volume 可以提高容器应用程序的灵活性和可维护性，从而更加高效地进行容器化部署。

2.1 Secret

2.1.1 yaml讲解

我们先来看一下Secret，它的作用，是帮你把 Pod 想要访问的加密数据，存放到 Etcd 中。然后，就可以通过在 Pod 的容器里挂载 Volume 的方式，访问到这些 Secret 里保存的信息了。

Secret 最典型的使用场景，是存放数据库的 Credential 信息，比如下面这个例子：

文件名：test-projected-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume 
spec:
  containers:
  - name: test-secret-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: mysql-cred
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: mysql-cred
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: passward

小插曲：

在这个例子中，我们用到了BusyBox镜像，简单介绍下这个镜像：

BusyBox是一个开源项目，提供了一个类似于UNIX操作系统的命令行界面，它包含了许多常用的工具程序，如文件操作、文本处理、网络配置、系统监测等。它被设计成在嵌入式系统中使用，因为它占用的空间很小，可以在资源受限的设备上运行。

在容器技术中，BusyBox通常被用作一个基础镜像，因为它非常轻量级，可以帮助构建小型容器，这也是它被称为"微型容器"的原因。

另外，很多容器镜像都会以BusyBox为基础，通过添加其他应用程序和库来构建完整的应用程序容器。

言归正传，讲下yaml示例：

在这个 Pod 中，定义了一个简单的容器。它声明挂载的 Volume，是 projected 类型。这个 Volume 的数据来源（sources），则是名为 user 和 pass 的 Secret 对象，分别对应的是数据库的用户名和密码。

这里用到的数据库的用户名、密码，就是以 Secret 对象的方式交给 Kubernetes 保存的。完成这个操作的指令，如下所示：

$ kubectl create secret generic user --from-file=./username.txt
$ kubectl create secret generic passward --from-file=./password.txt

如果要查看这些 Secret 对象的话，只要执行一条 kubectl get 命令就可以了：

kubectl get secrets

结果如下：

NAME           TYPE                                DATA      AGE
user          Opaque                                1         30s
passward      Opaque                                1         30s

又来一个小插曲：

除了使用 kubectl create secret 指令外，我们也可以直接通过编写 YAML 文件的方式来创建这个 Secret 对象，如：

apiVersion: v1
kind: Secret
metadata:
  name: mytestsecret
type: Opaque
data:
  user: YWRtaW4=
  passward: YWRtaW4xMjM0

注意：通过编写 YAML 文件创建出来的 Secret 对象只有一个。

它的 data 字段，是以 Key-Value 的格式保存了两份 Secret 数据。其中，“user”就是第一份数据的 Key，“passward”是第二份数据的 Key。

需要注意的是，Secret 对象要求这些数据必须是经过 Base64 转码的，以免出现明文密码的安全隐患。这个转码操作也很简单，比如：

➜  ~ echo -n 'admin' | base64
YWRtaW4=
➜  ~ echo -n 'admin1234' | base64
YWRtaW4xMjM0

Tips：

需要注意的是，像这样创建的 Secret 对象，它里面的内容仅仅是经过了转码，而并没有被加密。在真正的生产环境中，需要在 Kubernetes 中开启 Secret 的加密插件，增强数据的安全性

2.1.2 创建Pod

言归正传：

我们来创建一下这个 Pod，文件名为：test-projected-volume.yaml

kubectl create -f test-projected-volume.yaml

查看结果：

$ kubectl exec -it test-projected-volume -- /bin/sh
$ ls /projected-volume/
user
passward
$ cat /projected-volume/user
admin
$ cat /projected-volume/passward
admin1234

从上面结果中，可以看到，保存在 Etcd 里的用户名和密码信息，已经以文件的形式出现在了容器的 Volume 目录里。

而这个文件的名字，就是 kubectl create secret 指定的 Key，或者说是 Secret 对象的 data 字段指定的 Key。

更重要的是，像这样通过挂载方式进入到容器里的 Secret，一旦其对应的 Etcd 里的数据被更新，这些 Volume 里的文件内容，同样也会被更新。其实，这是 kubelet 组件在定时维护这些 Volume。

2.2 Downward API

2.2.1 yaml示例

Downward API：是让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息。

举例：

apiVersion: v1
kind: Pod
metadata:
  name: test-downwardapi-volume
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      projected:
        sources:
        - downwardAPI:
            items:
              - path: "labels"
                fieldRef:
                  fieldPath: metadata.labels

在这个 Pod 的 YAML 文件中，定义了一个简单的容器，声明了一个 projected 类型的 Volume。

只不过这次 Volume 的数据来源，变成了 Downward API。而这个 Downward API Volume，则声明了要暴露 Pod 的 metadata.labels 信息给容器。

2.2.2 Downward API 支持字段

Kubernetes Downward API 允许容器在运行时通过环境变量或卷挂载的方式获取 Pod 和容器的元数据信息。支持的字段包括：

metadata.name: Pod 的名称
metadata.namespace: Pod 的命名空间
metadata.labels: Pod 的标签
metadata.annotations: Pod 的注释
spec.nodeName: Pod 调度到的节点名称
spec.serviceAccountName: Pod 使用的服务账户名称
spec.containers[*].name: 容器名称
spec.containers[*].image: 容器使用的镜像名称
spec.containers[*].imagePullPolicy: 容器拉取镜像使用的策略
spec.containers[].ports[].containerPort: 容器暴露的端口号
spec.containers[].env[].name: 容器中定义的环境变量名称
spec.containers[].env[].value: 容器中定义的环境变量值
status.hostIP: Pod 调度到的节点的 IP 地址
status.podIP: Pod 的 IP 地址
status.podIPs[*].ip: Pod 的 IP 地址（多网卡情况下）
status.startTime: Pod 启动时间

需要注意的是，这些字段可能会因 Kubernetes 版本而有所不同，具体的支持情况需要参考相应版本的文档

不过，需要注意的是，Downward API 能够获取到的信息，一定是 Pod 里的容器进程启动之前就能够确定下来的信息。

而你如果想要获取 Pod 容器运行后才会出现的信息，比如，容器进程的 PID，那就肯定不能使用 Downward API 了，而应该考虑在 Pod 里定义一个 sidecar 容器。

其实，Secret、ConfigMap，以及 Downward API 这三种 Projected Volume 定义的信息，大多还可以通过环境变量的方式出现在容器里。

但是，通过环境变量获取这些信息的方式，不具备自动更新的能力。所以，一般情况下，都建议你使用 Volume 文件的方式获取这些信息。