Kubernetes之Projected Volume

云晓DwanCloud

已于 2024-03-31 22:44:44 修改

阅读量854

点赞数 28

分类专栏：云原生文章标签： kubernetes 容器云原生 docker

于 2024-03-31 22:39:25 首次发布

本文链接：https://blog.csdn.net/qq_38483331/article/details/137210531

版权

云原生专栏收录该内容

27 篇文章 2 订阅

订阅专栏

在 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: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      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-client
    image: mysql:5.7
    env:
      - name: MYSQL_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysql-auth
            key: username
      - name: MYSQL_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysql-auth
            key: password
    command: ["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-config
  namespace: default
data:
  special.level: very
  special.type: charm
---
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: 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: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
    volumeMounts:
    - name: config
      mountPath: /etc/nginx
  volumes:
  - name: config
    configMap:
      name: nginx-config
      items:
      - key: nginx.conf
        path: 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-example
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: client-container
      image: registry.k8s.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          if [[ -e /etc/podinfo/annotations ]]; then
            echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        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-container
      image: registry.k8s.io/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo "[$(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-agent
    image: 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() {
	// 读取 ServiceAccountToken
	tokenFile := "/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 访问 API
	clientset, 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())
	}

	// 进行监控数据采集逻辑 
	...
}

云晓DwanCloud

关注

28
点赞
踩
25

收藏

觉得还不错? 一键收藏
0
评论
Kubernetes之Projected Volume

在 Kubernetes 中,有几类特殊的 Volume,它们存在的意义不是为了存放容器里的数据,也不是用来进行容器和宿主机之间的数据交换。这些特殊 Volume 的作用是为容器提供预先定义好的数据。从容器的角度来看,这些 Volume 里的信息就好像是被 Kubernetes "投射"(Project)进入容器当中的,这就是 Projected Volume 的含义。
复制链接

扫一扫