Kubernetes--管理Pod对象的容器(2)

自定义运行的容器化应用

由Docker镜像启动容器时运行的应用程序在相应的Dockerfile中由ENTRYPOINT指令进行定义，传递给程序的参数则通过CMD指令指定，ENTRYPOINT指令不存在时，CMD可用于同时指定程序及其参数。例如，在某工作节点上运行下面的命令获取ikubernetes/myapp:v1镜像中定义的CMD和ENTRYPOINT，命令如下：

docker inspect ikubernetes/myapp:v1@ -f {{.Config.Cmd}}

[nginx -g deamon off;]

docker inspect ikubernetes/myapp:v1 -f {{.Config.Entrypoint}}

[]

容器的command字段能够指定不同于镜像默认运行的应用程序，并且可以同时使用args字段进行参数传递，它们将覆盖镜像中的默认定义。不过，如果仅为容器定义了args字段，那么它将作为参数传递给镜像中默认指定运行的应用程序；如果仅为容器定义了command宇字段，那么它将覆盖镜像中定义的程序及参数，并以无参数方式运行应用程序。例如下面的资源清单文件将镜像 ikubernetes/myapp:v1的默认应用程序修改为了“/bin/sh”，传递应用的参数修改为了 “-c while true; do sleep 30; done”：

apiVersion: v1

kind: Pod

metadata:

  name: pod-with-custom-command

spec:

  containers:

  - name: myapp

    image: alpine:latest

    command: ["/bin/sh"]

    args: ["-c","while true; do sleep 30; done"]

自定义args，也是向容器中的应用程序传递配置信息的常用方式之一，对于非云原生(cloud native)的应用程序，这几乎也是最简单的配置方式。另一个常用的方式是使用环境变量。

环境变量

非容器化的传统管理方式中，复杂应用程序的配置信息多数由配置文件进行指定，用户可借助于简单的文本编辑器完成配置管理。然而，对于容器隔离出的环境中的应用程序，用户就不得不穿透容器边界在容器内进行配置编辑并进行重载，这种方式复杂且低效。于是，由环境变量在容器启动时传递配置信息就成为一种备受青睐的方式。

注意：这种方式依赖于应用程序支持通过环境变量进行配置的能力，否则，用户在制作Docker镜像时需要通过entrypoint脚本完成环境变量到程序配置文件的同步。

向Pod对象中的容器环境变量传递数据的方法有两种：env和envFrom，这里重点介绍第一种方式。第二种方式大家可自行查阅哦~

通过环境变量配置容器化应用时，需要在容器配置段中嵌套使用env字段，它的值是一个由环境变量构成的列表。环境变量通常由name和value字段构成。

name: 环境变量的名称，必选字段。
value< string>:传递给环境变量的值,通过$(VAR_NAME)引用,逃逸格式为“$$(VAR_NAME)”，默认值为空。

下面配置清单中定义的Pod对象为其容器filebeat传递了两个环境变量，REDIS_HOST定义了filebeat收集的日志信息要发往的Redis主机地址，LOG_LEVEL则定义了filebeat的日志级别：

apiVersion: v1

kind: Pod

metadata:

  name: pod-with-env

spec:

  containers:

  - name: filebeat

    image: ikubernetes/filebeat:5.6.5-alpine

    env:

    - name: REDIS_HOST

      value: db.ilinux.io:6379

    - name: LOG_LEVEL

      value: info

　　这些环境变量可直接注入容器的shell环境中，无论它们是否真正被用到，使用printenv一类的命令都能在容器中获取到所有环境变量的列表。