树叶云kubernetes教程:Kubernetes 通过文件将Pod信息呈现给容器

通过文件将 Pod 信息呈现给容器

此页面描述 Pod 如何使用 DownwardAPIVolumeFile 把自己的信息呈现给 Pod 中运行的容器。 ​DownwardAPIVolumeFile ​可以呈现 Pod 和容器的字段。

在开始之前

你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 如果你还没有集群,你可以通过 Minikube 构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

  • Katacoda
  • 玩转 Kubernetes

要获知版本信息,请输入 kubectl version

Downward API 

有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器:

  • 环境变量
  • 卷文件

这两种呈现 Pod 和 Container 字段的方式都称为 “Downward API”。

存储 Pod 字段 

在这个练习中,你将创建一个包含一个容器的 Pod。Pod 的配置文件如下:

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: 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;
          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 有一个 ​downwardAPI ​类型的卷,并且挂载到容器中的 ​/etc/podinfo​ 目录。

查看 ​downwardAPI ​下面的 ​items ​数组。 每个数组元素都是一个 DownwardAPIVolumeFile 对象。 第一个元素指示 Pod 的 ​metadata.labels​ 字段的值保存在名为 ​labels ​的文件中。 第二个元素指示 Pod 的 ​annotations ​字段的值保存在名为 ​annotations ​的文件中。

说明: 本示例中的字段是Pod字段,不是Pod中容器的字段。

创建 Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml

验证Pod中的容器运行正常:

kubectl get pods

查看容器的日志:

kubectl logs kubernetes-downwardapi-volume-example

输出显示 ​labels ​和 ​annotations ​文件的内容:

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

build="two"
builder="john-doe"

进入 Pod 中运行的容器,打开一个 Shell:

kubectl exec -it kubernetes-downwardapi-volume-example -- sh

在该 Shell中,查看 ​labels​ 文件:

/# cat /etc/podinfo/labels

输出显示 Pod 的所有标签都已写入 ​labels ​文件。

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

同样,查看 ​annotations ​文件:

/# cat /etc/podinfo/annotations

查看 ​/etc/podinfo​ 目录下的文件:

/# ls -laR /etc/podinfo

在输出中可以看到,labels 和 annotations 文件都在一个临时子目录中。 在这个例子,..2982_06_02_21_47_53.299460680。 在 /etc/podinfo 目录中,..data 是一个指向临时子目录 的符号链接。/etc/podinfo 目录中,labels 和 annotations 也是符号链接。

drwxr-xr-x  ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels

/etc/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r--  ... Feb  6 21:47 annotations
-rw-r--r--  ... Feb  6 21:47 labels

用符号链接可实现元数据的动态原子性刷新;更新将写入一个新的临时目录, 然后通过使用 rename(2) 完成 ..data 符号链接的原子性更新。

说明: 如果容器以 subPath卷挂载方式来使用 Downward API,则该容器无法收到更新事件。

退出 Shell:

/# exit

存储容器字段 

前面的练习中,你将 Pod 字段保存到 ​DownwardAPIVolumeFile ​中。 接下来这个练习,你将存储 Container 字段。这里是包含一个容器的 Pod 的配置文件:

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example-2
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox:1.24
      command: ["sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          if [[ -e /etc/podinfo/cpu_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
          if [[ -e /etc/podinfo/cpu_request ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
          if [[ -e /etc/podinfo/mem_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
          if [[ -e /etc/podinfo/mem_request ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_request; fi;
          sleep 5;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
              divisor: 1m
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
              divisor: 1m
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
              divisor: 1Mi
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory
              divisor: 1Mi

在这个配置文件中,你可以看到 Pod 有一个 ​downwardAPI ​卷, 并且挂载到容器的 ​/etc/podinfo​ 目录。

查看 ​downwardAPI ​下面的 ​items ​数组。每个数组元素都是一个 DownwardAPIVolumeFile。

第一个元素指定在名为 ​client-container​ 的容器中, 以 ​1m​ 所指定格式的 ​limits.cpu​ 字段的值应保存在名为 ​cpu_limit ​的文件中。 ​divisor ​字段是可选的,默认值为 1,表示 CPU 的核心和内存的字节。

创建Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml

打开一个 Shell,进入 Pod 中运行的容器:

kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh

在 Shell 中,查看 ​cpu_limit ​文件:

/# cat /etc/podinfo/cpu_limit

你可以使用同样的命令查看 ​cpu_request​、​mem_limit ​和 ​mem_request ​文件.

Downward API 的能力 

下面这些信息可以通过环境变量和 ​downwardAPI ​卷提供给容器:

能通过 ​fieldRef ​获得的:

  • metadata.name​ – Pod 名称
  • metadata.namespace​ – Pod 名字空间
  • metadata.uid​ – Pod 的 UID
  • metadata.labels['<KEY>']​ – Pod 标签 ​<KEY>​ 的值 (例如:​metadata.labels['mylabel']​)
  • metadata.annotations['<KEY>']​ – Pod 的注解 ​<KEY>​ 的值 (例如:​metadata.annotations['myannotation']​)

能通过 ​resourceFieldRef ​获得的:

  • 容器的 CPU 约束值
  • 容器的 CPU 请求值
  • 容器的内存约束值
  • 容器的内存请求值
  • 容器的巨页限制值(前提是启用了 ​DownwardAPIHugePages ​特性门控)
  • 容器的巨页请求值(前提是启用了 ​DownwardAPIHugePages ​特性门控)
  • 容器的临时存储约束值
  • 容器的临时存储请求值

此外,以下信息可通过 ​downwardAPI ​卷从 ​fieldRef ​获得:

  • metadata.labels​ – Pod 的所有标签,以 ​label-key="escaped-label-value"​ 格式显示,每行显示一个标签
  • metadata.annotations​ – Pod 的所有注解,以 ​annotation-key="escaped-annotation-value"​ 格式显示,每行显示一个标签

以下信息可通过环境变量获得:

  • status.podIP​ – Pod IP 地址
  • spec.serviceAccountName​ – Pod 服务帐号名称
  • spec.nodeName​ – 调度器总是尝试将 Pod 调度到的节点的名称
  • status.hostIP​ – Pod 分配到的节点的 IP

说明: 如果容器未指定 CPU 和内存限制,则 Downward API 默认将节点可分配值 视为容器的 CPU 和内存限制。

投射键名到指定路径并且指定文件权限 

你可以将键名投射到指定路径并且指定每个文件的访问权限。

Downward API 的动机 

对于容器来说,有时候拥有自己的信息是很有用的,可避免与 Kubernetes 过度耦合。 Downward API 使得容器使用自己或者集群的信息,而不必通过 Kubernetes 客户端或 API 服务器来获得。

一个例子是有一个现有的应用假定要用一个非常熟悉的环境变量来保存一个唯一标识。 一种可能是给应用增加处理层,但这样是冗余和易出错的,而且它违反了低耦合的目标。 更好的选择是使用 Pod 名称作为标识,把 Pod 名称注入这个环境变量中。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/173838.html<

(0)
管理的头像管理
上一篇2025-03-23 23:34
下一篇 2025-03-23 23:35

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注