《k8s权威指南》读书笔记-Pod的配置管理&获取Pod信息

2.Pod的配置管理

2.1 ConfigMap的产生背景

  • 外置化配置映射到容器内

    • 应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离，这样可以使应用程序被更好地复用，通过不同的配置也能实现更灵活的功能。将应用打包为容器镜像后，

    • 可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入。

  • 但在大规模容器集群的环境中，对多个容器进行不同的配置将变得非常复杂

    • 从Kubernetes 1.2开始提供了一种统一的应用配置管理方案—ConfigMap。本节对ConfigMap的概念和用法进行详细描述。

2.2 ConfigMap概述

ConfigMap供容器使用的典型用法如下

1. 生成为容器内的环境变量。

2. 设置容器启动命令的启动参数（需设置为环境变量）。

3. 以Volume的形式挂载为容器内部的文件或目录。

  ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用，既可以用于表示一个变量的值（例如apploglevel=info），也可以用于表示一个完整配置文件的内容（例如server.xml=<?xml...>...）

  可以通过YAML配置文件或者直接使用kubectl create configmap命令行的方式来创建ConfigMap。

2.3 创建ConfigMap资源对象

1.通过YAML配置文件方式创建

例子1

  下面的例子cm-appvars.yaml描述了将几个应用所需的变量定义为ConfigMap的用法：

image.png
image.png

执行kubectl create命令创建该ConfigMap：

image.png

查看创建好的ConfigMap：

image.png

例子2

  下面的例子cm-appconfigfiles.yaml描述了将两个配置文件server.xml和logging.properties定义为ConfigMap的用法，设置key为配置文件的别名，value则是配置文件的全部文本内容：

image.png
image.png

执行kubectl create命令创建该ConfigMap：

image.png

查看创建好的ConfigMap：

image.png

查看已创建的ConfigMap的详细内容，可以看到两个配置文件的全文：

image.png
image.png
image.png

2.通过kubectl命令行方式创建

 如果 <font color=green>不使用YAML文件</font>，<font color=apple green>也可以直接通过kubectl create configmap也可以创建ConfigMap</font>，可以使用参数--from-file或-from-literal指定内容，并且可以在一行命令中指定多个参数。

（1）基于文件创建

  通过--from-file参数从<font color=red>文件</font>中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个key的ConfigMap，语法为：


# kubeectl create configmap NAME --from-file=[key=]source  --from-file=[key=]source

[key=]source  可以指定，默认为文件名
例子
例子1：基于1个文件

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties

将产生以下 ConfigMap:


kubectl describe configmaps game-config-2

输出类似以下内容:


Name:         game-config-2

Namespace:    default

Labels:       <none>

Annotations:  <none>

Data

====

game.properties: #key是文件名

----

enemies=aliens

lives=3

enemies.cheat=true

enemies.cheat.level=noGoodRotten

secret.code.passphrase=UUDDLRLRBABAS

secret.code.allowed=true

secret.code.lives=30
例子2.基于多个文件

# kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties

#kubectl describe configmaps game-config-2

Name:         game-config-2

Namespace:    default

Labels:       <none>

Annotations:  <none>

Data

====

game.properties:#key是文件名

----

enemies=aliens

lives=3

enemies.cheat=true

enemies.cheat.level=noGoodRotten

secret.code.passphrase=UUDDLRLRBABAS

secret.code.allowed=true

secret.code.lives=30

ui.properties: #key是文件名

----

color.good=purple

color.bad=yellow

allow.textmode=true

how.nice.to.look=fairlyNice
例子3：指定key

# kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties

# kubectl get configmaps game-config-3 -o yaml

apiVersion: v1

kind: ConfigMap

metadata:

  creationTimestamp: 2016-02-18T18:54:22Z

  name: game-config-3

  namespace: default

  resourceVersion: "530"

  selfLink: /api/v1/namespaces/default/configmaps/game-config-3

  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

data:

  game-special-key: |

    enemies=aliens

    lives=3

    enemies.cheat=true

    enemies.cheat.level=noGoodRotten

    secret.code.passphrase=UUDDLRLRBABAS

    secret.code.allowed=true

    secret.code.lives=30

（2）基于目录创建

  通过--from-file参数从<font color=red>目录</font>中进行创建，该目录下的每个配置文件名都被设置为key，文件的内容被设置为value，语法为：


# kubectl create configmap NAME --from-file=config-files-dir
例子

# 创建本地目录

mkdir -p configure-pod-container/configmap/

# 将实例文件下载到 `configure-pod-container/configmap/` 目录

wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties

wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties

# 创建 configmap

kubectl create configmap game-config --from-file=configure-pod-container/configmap/

以上命令将 configure-pod-container/configmap 目录下的所有文件，也就是 game.properties 和 ui.properties 打包到 game-config ConfigMap 中。你可以使用下面的命令显示 ConfigMap 的详细信息：


#kubectl describe configmaps game-config

Name:         game-config

Namespace:    default

Labels:       <none>

Annotations:  <none>

Data

====

game.properties:#key是文件名

----

enemies=aliens

lives=3

enemies.cheat=true

enemies.cheat.level=noGoodRotten

secret.code.passphrase=UUDDLRLRBABAS

secret.code.allowed=true

secret.code.lives=30

ui.properties:#key是文件名

----

color.good=purple

color.bad=yellow

allow.textmode=true

how.nice.to.look=fairlyNice

configure-pod-container/configmap/ 目录中的 game.properties 和 ui.properties 文件出现在 ConfigMap 的 data 部分。


# kubectl get configmaps game-config -o yaml

apiVersion: v1

kind: ConfigMap

metadata:

  creationTimestamp: 2016-02-18T18:52:05Z

  name: game-config

  namespace: default

  resourceVersion: "516"

  selfLink: /api/v1/namespaces/default/configmaps/game-config

  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

data:

  game.properties: |

    enemies=aliens

    lives=3

    enemies.cheat=true

    enemies.cheat.level=noGoodRotten

    secret.code.passphrase=UUDDLRLRBABAS

    secret.code.allowed=true

    secret.code.lives=30   

  ui.properties: |

    color.good=purple

    color.bad=yellow

    allow.textmode=true

    how.nice.to.look=fairlyNice

（3）基于字面值创建

  使用--from-literal时会从<font color=red>字面值</font>中进行创建，直接将指定的key#=value#创建为ConfigMap的内容，语法为：


# kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2
例子

# kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

# kubectl get configmaps special-config -o yaml

apiVersion: v1

kind: ConfigMap

metadata:

  creationTimestamp: 2016-02-18T19:14:38Z

  name: special-config

  namespace: default

  resourceVersion: "651"

  selfLink: /api/v1/namespaces/default/configmaps/special-config

  uid: dadce046-d673-11e5-8cd0-68f728db1985

data:

  special.how: very

  special.type: charm

2.4 在Pod中使用ConfigMap

在Pod中的使用方式：

（1）通过环境变量获取ConfigMap中的内容。

（2）通过Volume挂载的方式将ConfigMap中的内容挂载为容器内部的文件或目录。

1.通过环境变量（env）方式使用ConfigMap

（1）使用单个 ConfigMap 中的数据定义容器环境变量


kubectl create configmap special-config --from-literal=special.how=very

将 ConfigMap 中定义的 special.how 值分配给 Pod 规范中的 SPECIAL_LEVEL_KEY 环境变量。


apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "/bin/sh", "-c", "env" ]

      env:

        #定义环境变量名

        - name: SPECIAL_LEVEL_KEY

          valueFrom:

            configMapKeyRef:

              # 环境变量的值取自special-config

              name: special-config

              # key为special.how

              key: special.how

  restartPolicy: Never  #重启策略

创建Pod


kubectl create -f pod-single-configmap-env-variable.yaml

使用kubectl create -f命令创建该Pod，由于是测试Pod，所以该Pod在执行完启动命令后将会退出，并且不会被系统自动重启（restartPolicy=Never）。

查看该Pod的日志，可以看到启动命令“env | grep special.how”的执行结果如下：


# kubectl logs pod-single-configmap-env-variable

special.how = very

（2）使用多个ConfigMap的数据定义容器的环境变量

首先创建ConfigMap


apiVersion: v1

kind: ConfigMap

metadata:

  name: special-config

  namespace: default

data:

  special.how: very

---

apiVersion: v1

kind: ConfigMap

metadata:

  name: env-config

  namespace: default

data:

  log_level: INFO

创建ConfigMap


kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml

在 Pod 规范中定义环境变量


apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "/bin/sh", "-c", "env" ]

      env:

        - name: SPECIAL_LEVEL_KEY

          valueFrom:

            configMapKeyRef:

              name: special-config

              key: special.how

        - name: LOG_LEVEL

          valueFrom:

            configMapKeyRef:

              name: env-config

              key: log_level

  restartPolicy: Never

创建Pod


kubectl create -f pod-multiple-configmap-env-variable.yaml

（3）将ConfigMap中的所有键值对配置为容器的环境变量

  上面都是使用了configMap中的部分key，在<font color=red>Kubernetes v1.6 和更高版本</font>中支持将所有键设置成容器环境变量。

例子：

创建一个包含多个键值对的 ConfigMap。


apiVersion: v1

kind: ConfigMap

metadata:

  name: special-config          #该configMap名字

  namespace: default

data:

  SPECIAL_LEVEL: very

  SPECIAL_TYPE: charm

创建 ConfigMap:


kubectl create -f configmap-multikeys.yaml

使用 envFrom 将所有 ConfigMap 的数据定义为容器环境变量，ConfigMap 中的键成为 Pod 中的环境变量名称。


apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "/bin/sh", "-c", "env" ]

      envFrom:

      - configMapRef:

          name: special-config

  restartPolicy: Never

创建 Pod:


kubectl create -f pod-configmap-envFrom.yaml
环境变量的命名规则

  需要说明的是，环境变量的名称受POSIX命名规范（[a-zA-Z_][a-zA-Z0-9_]*）约束，不能以数字开头。如果包含非法字符，则系统将跳过该条环境变量的创建，并记录一个Event来提示环境变量无法生成，但并不阻止Pod的启动。

2.通过volumeMount使用ConfigMap

例子

本节中的示例引用了一个名为 special-config 的 ConfigMap


apiVersion: v1

kind: ConfigMap

metadata:

  name: special-config

  namespace: default

data:

  SPECIAL_LEVEL: very

  SPECIAL_TYPE: charm

创建 ConfigMap:


kubectl create -f configmap-multikeys.yaml

例1.使用存储在 ConfigMap 中的数据填充数据卷

在 Pod 规约的 volumes 部分下添加 ConfigMap 名称。 这会将 ConfigMap 数据添加到指定为 volumeMounts.mountPath 的目录（在本例中为 /etc/config）。 command 部分引用存储在 ConfigMap 中的 special.level。


apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "/bin/sh", "-c", "ls /etc/config/" ]

      volumeMounts:                     #卷挂载

      - name: config-volume             #引用volume名字

        mountPath: /etc/config          #挂载到容器内的目录

  volumes:

    - name: config-volume              # 定义volume名字

      configMap:

      # 引用的configMap名字，不指定items，则使用volumeMount方式在容器内的目录下为每个item都生成一个文件名为key的文件

        name: special-config          

  restartPolicy: Never

创建 Pod:


kubectl create -f pod-configmap-volume.yaml

Pod 运行时，命令 ls /etc/config/ 产生下面的输出：


SPECIAL_LEVEL        #基于文件创建configMap， 如果不指定key,key默认是文件名

SPECIAL_TYPE

注意：

  如果在 /etc/config/ 目录中有一些文件，它们将被删除。

说明：

  文本数据会使用 UTF-8 字符编码的形式展现为文件。如果使用其他字符编码， 可以使用 binaryData。

例2.将 ConfigMap 数据添加到数据卷中的特定路径

  使用 path 字段为特定的 ConfigMap 项目指定预期的文件路径。 在这里，ConfigMap中，键值 SPECIAL_LEVEL 的内容将挂载在 config-volume 数据卷中 /etc/config/keys.properties 文件下。


apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "/bin/sh","-c","cat /etc/config/keys" ]      #子命令，可直接通过kubectl + command操作k8s资源

      volumeMounts:

      - name: config-volume

        mountPath: /etc/config

  volumes:

    - name: config-volume

      configMap:

        name: special-config

        items:

        - key: SPECIAL_LEVEL             #key=SPECIAL_LEVEL

          path: keys.properties          # value将以keys.properties 文件名进行挂载

  restartPolicy: Never

创建Pod：


kubectl create -f pod-configmap-volume-specific-key.yaml

当 pod 运行时，命令 cat /etc/config/keys 产生以下输出


very

注意：

/etc/config/ 目录中所有先前的文件都将被删除。

3.挂载的 ConfigMap 将自动更新

  更新已经在数据卷中使用的 ConfigMap 时，已映射的键最终也会被更新。 kubelet 在每次定期同步时都会检查已挂载的 ConfigMap 是否是最新的。 但是，它使用其本地的基于 TTL 的缓存来获取 ConfigMap 的当前值。 因此，从更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与 kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 TTL 一样长。

注意：

使用 ConfigMap 作为subPath的数据卷将不会收到ConfigMap更新。

4.使用ConfigMap的限制条件

  • 在 Pod 规范中引用之前，必须先创建一个 ConfigMap（除非将 ConfigMap 标记为"可选"）。

    • 如果引用的 ConfigMap 不存在，则 Pod 将不会启动。

    • 同样，引用 ConfigMap 中不存在的键也会阻止 Pod 启动。

  • 如果通过环境变量使用ConfigMap,那么无效的键将被忽略，可以启动pod。

    • 在事件日志中（InvalidVariableNames）。 日志消息列出了每个跳过的键。例如:

# kubectl get events

LASTSEEN FIRSTSEEN COUNT NAME          KIND  SUBOBJECT  TYPE      REASON                            SOURCE              MESSAGE

0s       0s        1     dapi-test-pod Pod              Warning   InvalidEnvironmentVariableNames   {kubelet, 127.0.0.1}  Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.

  • ConfigMap受Namespace限制，只有处于相同Namespace中的Pod才可以引用它。

  • ConfigMap中的配额管理还未能实现。

  • 静态Pod不支持ConfigMap

    • kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过 --manifest-url或--config自动创建的静态Pod将无法引用ConfigMap。

  • 在通过volumeMount使用ConfigMap时，在容器内部只能挂载为“目录”，无法挂载为“文件”。

    • 在挂载到容器内部后，在目录下将包含ConfigMap定义的每个item，如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖

    • 如果应用程序需要保留原来的其他文件，则需要进行额外的处理。可以将ConfigMap挂载到容器内部的临时目录，再通过启动脚本将配置文件复制或者链接到（cp或link命令）应用所用的实际配置目录下。

3.在容器内获取Pod信息(Downward API)

  我们知道，每个Pod在被成功创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某个Namespace中，那么我们如何在Pod的容器内获取Pod的这些重要信息呢？答案就是使用Downward API。

Downward API可以通过以下两种方式将Pod信息注入容器内部。

（1）环境变量：用于单个变量，可以将Pod信息和Container信息注入容器内部。

（2）Volume挂载：将数组类信息生成为文件并挂载到容器内部。

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

3.1 通过环境变量方式获取Pod信息

<font color=green>因为可以通过将Pod的信息(Pod中的字段值)或Container的信息（容器中的字段值）注入到Pod的环境变量中</font>，所以这个环境变量的值可能取自两个地方：

  • pod中的字段

    • pod中的字段获取的范围大于容器中的字段。

  • 容器中的字段

以上两种方式只是获取的范围不同。

文档地址：


https://kubernetes.io/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/

3.1.1 获取用Pod字段作为环境变量的值


apiVersion: v1

kind: Pod

metadata:

  name: dapi-envars-fieldref

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox

      command: [ "sh", "-c"]

      args:

      - while true; do

          echo -en '\n';

          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;

          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;

          sleep 10;

        done;

      env:                               #环境数组

        - name: MY_NODE_NAME             #第一个环境变量

          valueFrom:

            fieldRef:

              fieldPath: spec.nodeName  #从 Pod 的 spec.nodeName 字段获取变量值,本集群是通过minikube工具创建，nodeName=minikube

        - name: MY_POD_NAME

          valueFrom:

            fieldRef:

              fieldPath: metadata.name

        - name: MY_POD_NAMESPACE

          valueFrom:

            fieldRef:

              fieldPath: metadata.namespace

        - name: MY_POD_IP

          valueFrom:

            fieldRef:

              fieldPath: status.podIP

        - name: MY_POD_SERVICE_ACCOUNT

          valueFrom:

            fieldRef:

              fieldPath: spec.serviceAccountName

  restartPolicy: Never

注意到上面valueFrom这种特殊的语法是Downward API的写法。目前Downward API提供了以下变量。

  • metadata.name：Pod的名称，当Pod通过RC生成时，其名称是RC随机产生的唯一名称。

  • status.podIP：Pod的IP地址，之所以叫作status.podIP而非metadata.IP，是因为Pod的IP属于状态数据，而非元数据。

  • metadata.namespace：Pod所在的Namespace。

创建pod


kubectl apply -f dapi-envars-pod.yaml

查看容器日志：


# kubectl logs dapi-envars-fieldref

minikube

dapi-envars-fieldref

default

172.17.0.4

default

注意：

当容器启动时，它将五个环境变量的值写入 stdout。每十秒重复执行一次。

接下来，通过打开一个 Shell 进入 Pod 中运行的容器：


# kubectl exec -it dapi-envars-fieldref -- sh

在 Shell 中，查看环境变量：


/# printenv

MY_POD_SERVICE_ACCOUNT=default

...

MY_POD_NAMESPACE=default

MY_POD_IP=172.17.0.4

...

MY_NODE_NAME=minikube

...

MY_POD_NAME=dapi-envars-fieldref

3.1.2 获取用Container字段作为环境变量的值

将容器资源信息注入为环境变量


apiVersion: v1

kind: Pod

metadata:

  name: dapi-envars-resourcefieldref

spec:

  containers:

    - name: test-container

      image: k8s.gcr.io/busybox:1.24

      command: [ "sh", "-c"]

      args:

      - while true; do

          echo -en '\n';

          printenv MY_CPU_REQUEST MY_CPU_LIMIT;

          printenv MY_MEM_REQUEST MY_MEM_LIMIT;

          sleep 10;

        done;

      resources:

        requests:

          memory: "32Mi"

          cpu: "125m"

        limits:

          memory: "64Mi"

          cpu: "250m"

      env:

        - name: MY_CPU_REQUEST

          valueFrom:

            resourceFieldRef:

              containerName: test-container

              resource: requests.cpu

        - name: MY_CPU_LIMIT

          valueFrom:

            resourceFieldRef:

              containerName: test-container

              resource: limits.cpu

        - name: MY_MEM_REQUEST

          valueFrom:

            resourceFieldRef:

              containerName: test-container

              resource: requests.memory

        - name: MY_MEM_LIMIT

          valueFrom:

            resourceFieldRef:

              containerName: test-container

              resource: limits.memory

  restartPolicy: Never

注意valueFrom这种特殊的Downward API语法，目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量。

  • requests.cpu：容器的CPU请求值。

  • limits.cpu：容器的CPU限制值。

  • requests.memory：容器的内存请求值。

  • limits.memory：容器的内存限制值。

创建Pod：


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

查看容器日志


# kubectl logs dapi-envars-resourcefieldref

1

1

33554432

67108864

3.2 通过volumeCount方式获取Pod信息

当然Pod的环境变量的取值可以通过Pod字段或Container字段指定，下面例子演示一个通过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字段，不是Pod中容器的字段。

创建 Pod：


kubectl apply -f dapi-volume.yaml

查看容器的日志：


# 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文件同理。

在输出中可以看到，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/podinfo/..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

3.3 Downward API的价值

  • 通过环境变量或文件方式获取Pod自身的名称、IP地址等信息，然后将这些信息写入主程序的配置文件中然后发布息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能

    • 在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。

    • 此时Downward API就可以派上用场了，具体做法是先编写一个预启动脚本或Init Container，通过环境变量或文件方式获取Pod自身的名称、IP地址等信息，然后将这些信息写入主程序的配置文件中，最后启动主程序。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,332评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,508评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,812评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,607评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,728评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,919评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,071评论 3赞 410
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,802评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,256评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,576评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,712评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,389评论 4赞 332
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,032评论 3赞 316
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,798评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,026评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,473评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,606评论 2赞 350

推荐阅读更多精彩内容

  • 2019-11-28 173
    16宿命：用概率思维提高你的胜算 以前的我是风险厌恶者，不喜欢去冒险，但是人生放弃了冒险，也就放弃了无数的可能。 ...
    yichen大刀阅读 6,041评论 0赞 4
  • 2019-11-28三数灯谜分析
    公元：2019年11月28日19时42分农历：二零一九年 十一月 初三日 戌时干支：己亥乙亥己巳甲戌当月节气：立冬...
    石放阅读 6,876评论 0赞 2
  • 断舍离第四天2019.11.28
    今天上午陪老妈看病，下午健身房跑步，晚上想想今天还没有断舍离，马上做，衣架和旁边的的布衣架，一看乱乱，又想想自己是...
    影子3623253阅读 2,908评论 1赞 8