Kubernetes之Projected Volume
目录
四种Projected Volume
Secret
使用方法
应用场景
示例
ConfigMap
使用方法
应用场景
示例
Downward API
使用方法
应用场景
示例
ServiceAccountToken
使用方法
应用场景
示例
在 Kubernetes 中,有几类特殊的 Volume,它们存在的意义不是为了存放容器里的数据,也不是用来进行容器和宿主机之间的数据交换。这些特殊 Volume 的作用是为容器提供预先定义好的数据。从容器的角度来看,这些 Volume 里的信息就好像是被 Kubernetes "投射"(Project)进入容器当中的,这就是 Projected Volume 的含义。
四种Projected Volume
Secret：用于存储敏感信息，如密码、OAuth 令牌、SSH 密钥等，以防止这些信息被暴露在 Pod 的配置中或者存储在容器镜像里。
ConfigMap：用于存储非敏感信息，如配置文件、命令行参数等，使得应用配置可以从镜像内容中解耦，提高灵活性和可维护性。
Downward API：允许容器访问 Pod 本身的信息（如 Pod 名称、命名空间、IP 地址等），使容器能够更好地了解自己的运行环境。
ServiceAccountToken：提供对 Kubernetes API 的访问令牌，允许容器内的应用程序与 Kubernetes API 交互，进行自动化管理操作。（严格来说算是Secret的一种）
这些类型的投射数据卷对于保护敏感信息、配置管理、自动化运维等场景至关重要。相比于通过环境变量传递信息，使用投射数据卷的方式能够更安全、更灵活地管理这些信息，并且支持自动更新，大大提高了云原生应用的可维护性和可扩展性。
Secret
Secret 是 Kubernetes 用来保存敏感数据的一种资源对象,例如密码、OAuth Token、SSH 密钥等。将这些敏感信息放到 Secret 中比直接放到 Pod 定义或 Docker 镜像中要更加安全和灵活。
使用方法
Secret 可以通过 Volume 或者环境变量的方式使用,以 Volume 方式使用的例子如下，
在这个例子中,Secret mysecret 被挂载到容器的 /etc/foo 目录,容器内的应用可以通过读取 /etc/foo 目录下的文件来获取 Secret 的内容。:
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mypodimage: redisvolumeMounts:- name: foomountPath: "/etc/foo"readOnly: truevolumes:- name: foosecret:secretName: mysecret应用场景
- 保存数据库连接字符串、用户名密码等敏感信息。
- 保存 SSL/TLS 证书信息。
- 保存 API Token、OAuth Token 等认证信息。
示例
使用 Secret 存储数据库用户名密码：
1、首先使用 kubectl 命令创建一个 Secret:
kubectl create secret generic mysql-auth --from-literal=username=admin --from-literal=password='S!B\*d$zDsb='2、在 Pod 中使用这个 Secret
apiVersion: v1
kind: Pod
metadata:name: mysql-client
spec:containers:- name: mysql-clientimage: mysql:5.7env:- name: MYSQL_USERNAMEvalueFrom:secretKeyRef:name: mysql-authkey: username- name: MYSQL_PASSWORDvalueFrom:secretKeyRef:name: mysql-authkey: passwordcommand: ["mysql", "-u$(MYSQL_USERNAME)", "-p$(MYSQL_PASSWORD)"] MySQL 客户端就可以使用 Secret 中存储的用户名密码连接数据库了,而不需要将这些敏感信息硬编码到应用代码或配置文件中。
ConfigMap
ConfigMap 是 Kubernetes 用来存储应用配置信息的资源对象。它可以存储环境变量、命令行参数或者配置文件等数据,这些数据可以被 Pod 中的容器使用。使用 ConfigMap 可以将应用的配置信息与容器镜像解耦,便于应用配置的修改和管理。
使用方法
与 Secret 类似,ConfigMap 也可以通过 Volume 或环境变量的方式在 Pod 中使用,以 Volume 方式使用的例子如下:
这个例子中,ConfigMap special-config 被挂载到容器的 /etc/config 目录,容器内可以通过读取 /etc/config 目录下的文件来获取 ConfigMap 的内容。
apiVersion: v1
kind: ConfigMap
metadata:name: special-confignamespace: default
data:special.level: veryspecial.type: charm
---
apiVersion: v1
kind: Pod
metadata:name: dapi-test-pod
spec:containers:- name: test-containerimage: registry.k8s.io/busyboxcommand: [ "/bin/sh", "-c", "ls /etc/config/" ]volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:name: special-configrestartPolicy: Never
应用场景
- 存储应用的环境变量配置,如 JVM 参数、日志级别等。
- 存储应用的配置文件,如 nginx 配置、redis 配置等。
- 存储部署相关的元数据,如应用的版本号、Git Commit ID 等。
示例
使用 ConfigMap 存储 nginx 配置
1、首先创建一个包含 nginx 配置的 ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:name: nginx-config
data:nginx.conf: |user nginx;worker_processes 1;events {worker_connections 10240;}http {server {listen 80;server_name localhost;location / {root /usr/share/nginx/html;index index.html index.htm;}}}2、在 nginx 的 Pod 中使用这个 ConfigMap:
apiVersion: v1
kind: Pod
metadata:name: nginx
spec:containers:- name: nginximage: nginx:1.7.9ports:- containerPort: 80volumeMounts:- name: configmountPath: /etc/nginxvolumes:- name: configconfigMap:name: nginx-configitems:- key: nginx.confpath: nginx.conf这样,nginx 容器启动时就会加载 ConfigMap 中的配置文件,无需将配置文件打包到镜像中,非常方便进行配置管理。同时由于配置与镜像解耦,也便于单独修改配置而不影响镜像。
Downward API
Downward API 让 Pod 里的容器能够获取到 Pod 本身的元数据信息,如 Pod 的名称、命名空间、标签、注解等。它使得容器内的应用能够不依赖 Kubernetes API 就可以直接获取一些运行时需要的信息。
使用方法
使用 Downward API,有两种方式可以将 Pod 信息呈现给容器:
- 通过环境变量。
- 通过 Volume 文件。
通过 Volume 文件方式使用 Downward API
apiVersion: v1
kind: Pod
metadata:name: kubernetes-downwardapi-volume-examplelabels:zone: us-est-coastcluster: test-cluster1rack: rack-22annotations:build: twobuilder: john-doe
spec:containers:- name: client-containerimage: registry.k8s.io/busyboxcommand: ["sh", "-c"]args:- while true; doif [[ -e /etc/podinfo/labels ]]; thenecho -en '\n\n'; cat /etc/podinfo/labels; fi;if [[ -e /etc/podinfo/annotations ]]; thenecho -en '\n\n'; cat /etc/podinfo/annotations; fi;sleep 5;done;volumeMounts:- name: podinfomountPath: /etc/podinfovolumes:- name: podinfodownwardAPI:items:- path: "labels"fieldRef:fieldPath: metadata.labels- path: "annotations"fieldRef:fieldPath: metadata.annotations
在这个例子中,Pod 的 Labels 和 Annotations 信息被作为文件挂载到容器的 /etc/podinfo 目录。容器内可以通过读取 /etc/podinfo/labels 和 /etc/podinfo/annotations 文件来获取这些信息。
Downward API 支持的字段
| 访问方式 | 可访问的字段 | 描述 |
|---|---|---|
| fieldRef | spec.nodeName | 获取宿主机的名字，即运行该 Pod 的节点名称 |
| status.hostIP | 获取宿主机的 IP 地址 | |
| metadata.name | 获取 Pod 的名称 | |
| metadata.namespace | 获取 Pod 所在的命名空间 | |
| status.podIP | 获取分配给 Pod 的 IP 地址 | |
| spec.serviceAccountName | 获取 Pod 所使用的 Service Account 名称 | |
| metadata.uid | 获取 Pod 的唯一标识符（UID） | |
| metadata.labels['<KEY>'] | 获取指定 <KEY> 的 Label 值。您需要替换 <KEY> 为实际的 Label 键 | |
| metadata.annotations['<KEY>'] | 获取指定 <KEY> 的 Annotation 值。同样地，需要将 <KEY> 替换为实际的 Annotation 键 | |
| metadata.labels | 获取 Pod 的所有 Label | |
| metadata.annotations | 获取 Pod 的所有 Annotation | |
| resourceFieldRef | limits.cpu | 获取容器的 CPU 使用上限 |
| requests.cpu | 获取容器请求的 CPU 资源量 | |
| limits.memory | 获取容器的内存使用上限 | |
| requests.memory | 获取容器请求的内存资源量 |
应用场景
- 让容器知道自己所在 Pod 的基本信息,如名称、IP、所属的 Node 等,用于日志记录或服务发现。
- 将 Pod 的标签或注解传递给容器,基于这些信息进行某些操作,如改变配置等。
- 某些 Operator 或 Controller 可能会给 Pod 添加一些元数据,并希望 Pod 内部能够获取到,Downward API 就很适合这种场景。
示例
容器内获取 Pod 信息写入日志
假如需要容器内的应用将一些日志信息和 Pod 名称、所在命名空间等元数据关联起来并输出,就可以使用 Downward API,像这样配置 Pod:
apiVersion: v1
kind: Pod
metadata:name: dapi-envars-fieldref
spec:containers:- name: test-containerimage: registry.k8s.io/busyboxcommand: [ "sh", "-c"]args:- while true; doecho "[$(date)] Hello from the $(MY_POD_NAME) pod in the $(MY_POD_NAMESPACE) namespace on node $(MY_NODE_NAME)" >> /var/log/hello.log;sleep 10;done;env:- name: MY_POD_NAME #通过Downward API获取Pod名称valueFrom:fieldRef:fieldPath: metadata.name- name: MY_POD_NAMESPACE #通过Downward API获取namespace名称valueFrom:fieldRef:fieldPath: metadata.namespace- name: MY_NODE_NAME #通过Downward API获取Node名称valueFrom:fieldRef:fieldPath: spec.nodeName
这样,容器内的脚本就可以获取 Pod 的名称、命名空间、所在节点等信息,并将其写入日志。当然,Pod 的这些元数据也可以单独记录在日志中,供后续进行过滤查询分析等操作。
ServiceAccountToken
Service Account 是 Kubernetes 中的一种资源,它为 Pod 中运行的进程提供了一种身份标识。每个 namespace 都有一个默认的 default service account。 当创建 Pod 时,如果没有指定 service account,会自动使用 default service account。
每个 Service Account 都有一个对应的 Secret,其中包含了访问 Kubernetes API 所需的授权 Token。Kubernetes 会自动将这个 Secret 以 Volume 的形式挂载到使用该 Service Account 的所有 Pod 中,挂载路径为 /var/run/secrets/kubernetes.io/serviceaccount。
严格来说，Kubernetes 的 Projected Volume 只有三种，因为第四种 ServiceAccountToken，只是一种特殊的 Secret。
使用方法
一般不需要特别配置什么,Pod 创建完成后,容器内就可以直接从默认路径 /var/run/secrets/kubernetes.io/serviceaccount 读取授权信息和文件。
例如,容器内可以直接读取 /var/run/secrets/kubernetes.io/serviceaccount/token 文件获取 JWT Token,用于调用 Kubernetes API。
应用场景
- Pod 内的应用需要访问 Kubernetes API,如监控应用通过 API 查询指标数据。
- Operator 或 Controller 需要通过 API 控制其他资源。
- 自研的 PaaS 平台组件,需要通过 Kubernetes API 实现平台功能。
示例
Pod 内访问 Kubernetes API
自研的监控 Agent,需要它能够访问 Kubernetes API 获取集群的监控指标数据,就可以利用默认的 ServiceAccountToken,Agent 的 Pod 配置如下:
apiVersion: v1
kind: Pod
metadata:name: my-monitor-agent
spec:containers:- name: my-monitor-agentimage: my-monitor-agent:v1.0
Agent 的代码中,可以这样读取 ServiceAccountToken 并访问 API:
Go代码
import ("io/ioutil"metav1 "k8s.io/apimachinery/pkg/apis/meta/v1""k8s.io/client-go/kubernetes""k8s.io/client-go/rest"
)func main() {// 读取 ServiceAccountTokentokenFile := "/var/run/secrets/kubernetes.io/serviceaccount/token"token, err := ioutil.ReadFile(tokenFile)if err != nil {panic(err.Error())}// 创建 k8s 配置config := &rest.Config{Host: "https://kubernetes.default.svc",BearerToken: string(token),TLSClientConfig: rest.TLSClientConfig{Insecure: true},}// 创建 clientset 访问 APIclientset, err := kubernetes.NewForConfig(config)if err != nil {panic(err.Error())}// 调用 API 获取 Pod 列表pods, err := clientset.CoreV1().Pods("").List(metav1.ListOptions{})if err != nil {panic(err.Error())}// 进行监控数据采集逻辑 ...
}