Downward API有提供了两种方式来实现从容器内部获取POD信息的方法:
环境变量的方式
Downward API 卷文件挂载
通过这两种方式,可以将pod的标签信息,资源信息,状态信息传递到Pod内部。
参考链接
1、使用pod参数方式
使用如下文件:
创建pod之后,通过logs查看:
登录pod,可以直接查看,发现环境变量中已经加载了这些参数:
通过yaml文件中指定的valueFrom这种方式的Downward语法获取相关Pod信息。
2、 使用容器参数方式
如下文件:
运行此pod,查看日志:
1、使用Pod 参数
创建如下文件:
通过downward API的volume方式,将pod的labels中的所有参数和annotations中的所有参数传递给了pod内。
在对应的路径下,有一个隐藏的文件目录,存放了这两个文件。
2、通容器参数传递资源配额
如下Pod文件:
通过如下方式,查看pod中传递的参数:
Downward API的应用主要是在某些场景中,集群中的每个节点将需要将自身的标识(ID)及进程绑定IP地址等信息事先写入配置文件中,进程启动时读取这些信息发布到服务的注册中心,实现集群节点的自动发现功能。
当我们执行<code>kubectl describe pod &lt;pod-name&gt;</code>时,会发现Pod都会有一个状态值,下面列举了Pod的5中状态:
Pending: API server 已经创建该Pod,但是Pod内还有一个或多个容器镜像没有创建,一般是在下载镜像。
Running: Pod内的所有容器均已经创建,且至少有一个容器处于运行状态、正在启动或重启状态。
Succeeded: Pod内所有容器均已经成功执行退出,且不再重启
Failed: Pod内所有容器均已退出,但至少有一个容器退出为失败状态。
Unknown: 由于某种原因无法获取Pod状态,可能由于网络通信不畅导致。
Pod的重启策略应用于Pod中的所有容器,并且仅在Pod所处的Node上由Kubelet进行判断和重启操作。
RestartPolicy包含三个设定:
Always: 当容器失效时,由kubelet自动重启该容器。
OnFailure: 当容器终止运行且退出码不为0时,由Kubelet自动重启该容器。
Never: 不论容器的运行状态如何,Kubelet都不会重启该容器。
当管理Pod的控制包括ReplicationController、Job、DaemonSet以及直接通过Kubelet管理(静态Pod),对应的控制器对Pod的重启策略要求如下:
RC和DaemonSet,ReplicaSet,Deployment: 必须设置为Always,需要保证容器的持续运行
Job: OnFailure 或Never,确保容器不再执行
kubelet: 在Pod失效时自动重启它,不论将RestartPolicy设置为什么值,也不会对Pod进行健康检查。
对Pod的健康状态检查可以通过两类探针来检查:LivenessProbe和ReadinessProbe。
livenessProbe: 判断容器是否存活(running),如果检测到容器不健康,则kubelet将杀掉该容器,并根据容器的重启策略做相应的处理。如果容器不包含LivenessProbe探针,则返回永远是Success。
readinessProbe: 用于判断容器是否启动完成(ready),可以接受请求。如果ReadinessProbe探针检测到失败,则Pod的状态将被修改。Endpoint Controller将从Service的EndPoint中删除包含该容器所在的Pod的EndPoint。
容器的探针对容器有3中实现方式:
ExecAction: 在容器内执行一条命令,如果命令的返回码为0,则表示容器健康。
TCPSocketAction: 通过容器的端口号和IP地址执行TCP检测,如果能够建立TCP连接表示容器健康。
HTTPGetAction: 通过容器的IP地址、端口号及路径调用HTTP Get方法,如果相应的状态码大于等于200且小于400,则认为容器状态健康。
下面是对应的三个示例,阐述了这3中实现方式:
1、使用ExecAction方式:
通过如下命令,可以查看到pod的健康状态和重启次数:
2、使用TCPSockAction
如下文件示例:
3、使用HTTPGetAction
readinessProbe 和livenessProbe 用法十分相似,只需要把 readinessProbe替换为livenessProbe即可。它们可以同时使用在同一个容器上,来确保流量不会流入未准备好的容器,并且让容器在失败的时候重新启动。