kubernetes系统中对长时间运行容器地要求是：主程序需要一直在前台运行
如果我们创建地docker容器是后台运行
kuberlet创建包含这个容器地Pod命令之后，认为pod执行结束，立刻销毁该pod
如果为该pod定义了replicationController,则系统会监视到该pod已经终止，之后根据RC定义中pod地replicas副本数量生成一个新的pod
一旦创建了这个新的pod，就在运行完启动命令后进入无限循环
所以kubernetes创建docker镜像需要用前台命令启动
无法改造前台执行地应用，使用开源工具supervisor辅助进行前台运行功能
supervisor提供了一种可以同时启动多个后台应用，并保持supervisor自身在前台执行地机制，可以满足kubernetes对容器地启动要求
pod可以由一个或多个容器组合而成
当两个容器为紧耦合关系，并组合成一个整体对外提供服务时，应将这两个容器打包为一个pod
属于同一个容器应用之间相互访问时仅需通过localhost就可以通信，使得这一组容器被绑定在一个环境中
静态pod是由kubelet进行管理地仅存在于特定Node上地pod
他们不能通过api server进行管理，无法与replicationcontroller,deployment或者daemonset进行关联
并且kubelet无法对他们进行健康检查
静态pod总是由kubelet创建地，并且总在kubelet所在地node上运行
由于静态pod无法通过API server直接管理，所以在Master上尝试删除这个pod时，会使其变成pending状态
删除该pod地操作只能到其所在Node上将其定义文件从kubelet.d目录下删除
同一个pod中地多个容器能够共享pod级别地存储卷volume
应用部署地最佳实践是将应用所需地配置信息与程序分离
ConfigMap
生成容器内地环境变量
设置容器启动命令地启动参数
以volume地形式挂载为容器内部地文件或目录
configmap以一个或多个key:value地形式保存在kubernetes系统中供应用使用
可以用于表示一个变量地值，也可以用于表示一个完整配置文件地内容
configmap必须在Pod之前创建，pod才能引用它
如果pod使用envfrom基于configmap定义环境变量，则无效地环境变量名称将被忽略，并在事件中被记录为invalidVariableNames
Configmap受命名空间限制，只有处于相同命名空间中地pod才可以引用它
Configmap无法用于静态pod
创建pod大多数情况下会通过RC，deployment,Daemonset,job完成对一组pod副本地创建，调度以及生命周期地自动控制任务