自定义运行的容器化应用
由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一类的命令都能在容器中获取到所有环境变量的列表。
标签：容器,name,Kubernetes,--,应用程序,v1,镜像,Pod,环境变量 From： https://www.cnblogs.com/zhangxin9/p/16806356.html