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

    你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群，你可以通过 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

    要获知版本信息，请输入 .

    Downward API

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

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

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

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

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

    创建 Pod：

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

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

    1. kubectl get pods

    查看容器的日志：

    1. kubectl logs kubernetes-downwardapi-volume-example
    1. cluster="test-cluster1"
    2. rack="rack-22"
    3. zone="us-est-coast"
    5. build="two"
    6. builder="john-doe"

    进入 Pod 中运行的容器，打开一个 Shell：

    在该 Shell中，查看 labels 文件：

    1. /# cat /etc/labels

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

    1. cluster="test-cluster1"
    2. rack="rack-22"
    3. zone="us-est-coast"

    同样，查看annotations文件：

    1. /# cat /etc/annotations

    查看/etc/podinfo目录下的文件：

    1. /# ls -laR /etc/podinfo

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

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

    退出 Shell：

    1. /# exit

    存储容器字段

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

    pods/inject/dapi-volume-resources.yaml 通过文件将 Pod 信息呈现给容器 - 图1

    1. apiVersion: v1
    2. kind: Pod
    4.   name: kubernetes-downwardapi-volume-example-2
    5. spec:
    6.   containers:
    7.     - name: client-container
    8.       image: k8s.gcr.io/busybox:1.24
    9.       args:
    10.       - while true; do
    11.           echo -en '\n';
    12.           if [[ -e /etc/podinfo/cpu_limit ]]; then
    13.             echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
    14.           if [[ -e /etc/podinfo/cpu_request ]]; then
    15.             echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
    16.           if [[ -e /etc/podinfo/mem_limit ]]; then
    17.             echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
    18.           if [[ -e /etc/podinfo/mem_request ]]; then
    19.             echo -en '\n'; cat /etc/podinfo/mem_request; fi;
    20.           sleep 5;
    21.         done;
    22.       resources:
    23.         requests:
    24.           memory: "32Mi"
    25.           cpu: "125m"
    26.         limits:
    27.           memory: "64Mi"
    28.           cpu: "250m"
    29.       volumeMounts:
    30.         - name: podinfo
    31.           mountPath: /etc/podinfo
    32.   volumes:
    33.     - name: podinfo
    34.       downwardAPI:
    35.         items:
    36.           - path: "cpu_limit"
    37.             resourceFieldRef:
    38.               containerName: client-container
    39.               resource: limits.cpu
    40.               divisor: 1m
    41.           - path: "cpu_request"
    42.             resourceFieldRef:
    43.               containerName: client-container
    44.               resource: requests.cpu
    46.             resourceFieldRef:
    47.               containerName: client-container
    48.               resource: limits.memory
    49.               divisor: 1Mi
    50.           - path: "mem_request"
    51.             resourceFieldRef:
    52.               containerName: client-container
    53.               resource: requests.memory
    54.               divisor: 1Mi

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

    第一个元素指定名为 client-container 的容器中 limits.cpu 字段的值应保存在名为 cpu_limit 的文件中。

    创建Pod：

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

    打开一个 Shell，进入 Pod 中运行的容器：

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

    在 Shell 中，查看 cpu_limit 文件：

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

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

    • 能通过 fieldRef 获得的：

      • metadata.name - Pod 名称
      • metadata.namespace - Pod 名字空间
      • metadata.uid - Pod的UID, 版本要求 v1.8.0-alpha.2
      • metadata.labels['<KEY>'] - Pod 标签 <KEY> 的值 (例如, metadata.labels['mylabel']）； 版本要求 Kubernetes 1.9+
      • metadata.annotations['<KEY>'] - Pod 的注解 <KEY> 的值（例如, metadata.annotations['myannotation']）； 版本要求 Kubernetes 1.9+

    • 能通过 resourceFieldRef 获得的：

      • 容器的 CPU 约束值
      • 容器的 CPU 请求值
      • 容器的内存约束值
      • 容器的内存请求值
      • 容器的临时存储约束值, 版本要求 v1.8.0-beta.0
      • 容器的临时存储请求值, 版本要求 v1.8.0-beta.0

    此外，以下信息可通过 downwardAPI 卷从 fieldRef 获得：

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

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

    • status.podIP - 节点 IP
    • spec.serviceAccountName - Pod 服务帐号名称, 版本要求 v1.4.0-alpha.3
    • spec.nodeName - 节点名称, 版本要求 v1.4.0-alpha.3
    • - 节点 IP, 版本要求 v1.7.0-alpha.1

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

    你可以将键名投射到指定路径并且指定每个文件的访问权限。 更多信息，请参阅.

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

    接下来