Kubernetes-Pod
Basic Concept
Pod是Kubernetes中的最小编排单位,凡是调度、网络、存储,以及安全相关的属性,基本上是Pod级别的。
Important Field
NodeSelector
NodeSelector是一个供用户将Pod与Node进行绑定的字段,用法如下:
1 | apiVersion: v1 |
这样的配置,意味着这个Pod永远只能运行在携带了标签disktype:ssd
标签(Label)的节点上;否则,它将调度失败。
NodeName
一旦Pod的这个字段被赋值,Kubernetes项目就会被认为这个Pod已经经过了调度,调度的结果就是赋值的节点名字。所以,这个字段一般由调度器负责设置,但用户也可以设置它来“骗过”调度器,当然这个做法一般是在测试或者调试的时候才会用到。
HotAliases
定义了Pod的hosts文件(比如/etc/hosts)里的内容,用法如下:
1 | apiVersion: v1 |
在这个Pod的YAML文件中,设置了一组IP和hostname的数据。这样,这个Pod启动后,/etc/hosts文件的内容将如下所示:
1 | kubectl exec -it host-pod -- /bin/sh |
在Kubernetes在,如果要设置hosts文件里的内容,一定要通过这种方法。否则,如果直接修改了hosts文件的话,在Pod被删除重建之后,kubelet会自动覆盖掉被修改的内容。
shareProcessNamespace
除了上述跟机器相关的配置外,凡是跟容器的Namespace相关的属性,也一定是Pod级别的。这个原因也很容易理解:Pod的设计,就是要让它里面的容器尽可能多地共享Linux Namespace,仅保留必要的隔离和限制能力。这样,Pod模拟出的效果,就跟虚拟机里程序间的关系非常类似了。
举个例子,在下面这个Pod的YAML文件中,定义shareProcessNamespace=true
:
1 | apiVersion: v1 |
这就意味着这个Pod里的容器要共享PID Namespace。
而在这个YAML文件中,还定义了两个容器:一个是nginx容器,一个是开启了tty和stdin的shell容器。Pod的YAML文件里声明开启它们俩,其实等同于设置了docker run里的-it(-i即stdin,-t即tty)参数。tty就是Linux给用户提供的一个常驻小程序,用于接收用户的标准输入,返回操作系统的标准输出。为了能够在tty中输入信息,还需要同时开启stdin标准输入流。
于是,这个Pod被创建以后,就可以使用shell容器的tty跟这个容器进行交互了。
1 | kubectl create -f test-nginx-pod-1.yaml |
可以看到,在这个容器里,我们不仅可以看到它本身的ps ax指令,还可以看到nginx容器的进程,以及Infra容器的/pause进程。这就意味着,整个Pod里的每个容器的进程,对于所有容器来说都是可见的:它们共享了同一个PID Namespace。
类似地,凡是Pod中的容器要共享宿主机的Namespace,也一定是Pod级别的定义,比如:
1 | apiVersion: v1 |
在这个Pod中,定义了共享宿主机的Network、IPC和PID Namespace。这意味着,这个Pod里的所有容器,会直接使用宿主机的网络、直接与宿主机进行IPC通信、看到宿主机里正在运行的所有进程。
containers
Pod里最重要的字段就是”Containers”了。同时还有个字段”Init Containers”。其实,这两个字段都属于Pod对容器的定义,内容也完全相同,只是”Init Containers”的生命周期,会先于所有的”Containers”,并且严格按照定义的顺序执行。
ImagePullPolicy
它定义了镜像拉取的策略,是一个Container级别的属性,是因为容器镜像本来就是Container定义中的一部分。
有三个值:
- Always:默认值,每次创建Pod都重新拉取一次镜像。
- Never:Pod永远不会主动拉取这个镜像,或者只在宿主机上不存在这个镜像时才拉取。
- IfNotPresent:宿主机上不存在这个镜像时才拉取。
Lifycycle
它定义的是Container Lifecycle Hooks,是在容器状态发生变化时出发一系列“钩子”。
如下是一个Kubernetes官方文档的Pod的YAML文件:
1 | apiVersion: v1 |
在这个YAML文件中,容器分别设置了一个postStart
和preStop
参数。
postStart
指的是,在容器启动后,立刻执行一个指定的操作。需要明确的是,postStart
定义的操作,虽然是Docker容器ENTRYPOINT执行之后,但它并不严格保证顺序。也就是说,在postStart
启动后,ENTRYPOINT有可能还没有结束。
当然,如果postStart
执行超时或者错误,Kubernetes会在该Pod的Events中报出该容器启动失败的错误消息,导致Pod也处于失败的状态。
而类似地,preStop
发生的时机,则是容器被杀死之前(比如,收到了SIGKILL信号)。需要明确的是,preStop
操作的执行,是同步的。所以,它会阻塞当前的容器杀死流程,知道这个Hook定义操作完成之后,才允许容器被杀死,这跟postStart
不一样。
在上面的例子中,我们在容器启动成功之后,展示了欢迎信息。而在这个容器被删除之前,我们则先调用了nginx的退出指令,从而实现了容器的优雅退出。
Pod对象在Kubernetes中的生命周期
Pod生命周期的变化,主要体现在Pod API对象的Status部分,这是它除了Metadata和Spec之外的第三个重要字段。其中,pod.status.phase,就是Pod的当前状态,它有如下几种可能的情况:
- Pending。这个状态意味着,Pod的YAML文件已经提交给了kubernetes,API对象已经被创建并保存到Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建。比如,调度不成功。
- Running。这个状态下,Pod已经调度成功,跟一个具体的节点绑定。它包含的容器都已经创建成功,并且至少有一个正在运行中。
- Succeeded。这个状态意味着,Pod里的所有容器都正常运行完毕,并且已经退出了。这种情况在运行一次性任务时最为常见。
- Failed。这个状态下,Pod里至少有一个容器以不正常的状态(非0的返回码)退出。这个状态的出现,意味着你得想办法Debug这个容器的应用,比如查看Pod的Events和日志。
- Unknown。这是一个异常状态,意味着Pod的状态不能持续地被Kubelet汇报给kube-apiserver,这很有可能是主从节点(Master和Kubelet)间的通信出现了问题。
更进一步地,Pod对象的Status字段,还可以更细分出一组Conditions。这些细分状态的值包括:PodScheduled、Ready、Initialized,以及Unschedulable。它们主要用于描述造成当前Status的具体原因是什么。
Advanced Usage
在Kubernetes中,有几种特殊的Volume,它们存在的意义不是为了存放容器里面的数据,也不是用来进行容器和宿主机之间的数据交换,而是为容器提供预先定义好的数据。
类型 | 说明 |
---|---|
Secret | 存储敏感信息 |
ConfigMap | 存储配置信息 |
Downward API | 共享POD信息 |
ServiceAccountToken | 存储授权信息 |
另外,Kubernetes可以通过Probe对Pod进行健康检查,同时指定Pod恢复机制。
Secret
Secret的作用,是把Pod想要访问的加密数据,存放到Etcd中。
然后,就可以通过在Pod容器里挂在Volume的方式,访问到这些Secret里保存的信息了。
可以通过文件创建secret,例如:
1 | kubectl create secret generic pass --from-file=./password.txt |
也可以通过YAML构造一个secret对象:
1 | 生成base64编码的密钥 |
编写Pod的YAML:
1 | $ cat ./k-pod.yaml |
生成Pod对象并找到secret:
1 | kubectl create -f ./k-pod.yaml |
ConfigMap
ConfigMap保存不需要加密的、应用所需的配置信息。
ConfigMap的用法几乎与Secret完全相同,可以通过.properties文件创建,也可以直接通过YAML创建。
可以通过.properties文件来创建ConfigMap:
1 | properties文件内容 |
Downward API
Downward API的作用是让Pod里的容器能够直接获取到这个Pod API对象本身的信息。
比如,在下面的YAML中:
1 | apiVersion: v1 |
定义一个容器,声明了一个projected类型的Volume。Volume的数据来源是Downward API,Downward API Volume,则声明了要暴露的Pod的metadata.labels
信息给容器。
通过这样的声明方式,当前Pod的Labels字段的值,就会被Kubernetes自动挂在成为容器里的/etc/podinfo/labels文件。
创建这个Pod并查看日志:
1 | kubectl create -f downwardapi.yaml |
目前,Downward API支持的字段:
1 |
|
仅供参考,使用时可以查阅官方文档。
不过,需要注意的是,Downward API能够获取到的信息,一定是Pod里的容器进程启动之前就能够确定下来的信息。而如果想要获取Pod容器运行后才会出现的信息,比如,容器进程的PID,那就肯定不能使用Downward API了,而应该考虑在Pod里定义一个sidecar容器。
ServiceAccountToken
Service Account对象的作用,就是Kubernetes系统内置的一种服务账户,它是对Kubernetes进行权限分配的对象。
像这样的Service Account的授权信息和文件,实际上保存在它所绑定的一个特殊的Secret对象里的,即ServiceAccountToken。任何运行在Kubernetes集群上的应用,都必须使用这个ServiceAccountToken里保存的首选信息,也就是Token,才可以合法访问API Server。
Probe
在Kubernetes中,可以为Pod里的容器定义一个健康检查“探针”(Probe)。这样,kubelet就会根据这个Probe的返回值决定这个容器的状态,而不是直接以容器镜像是否运行(来自Docker返回的信息)作为依据。这种机制,是生产环境中保证应用健康存活的重要手段。
比如下面Kubernetes官方文档的一个例子,定义了健康检查规则(livenessProbe):cat /tmp/healthy,如果这个文件存在,那么该命令返回结果为0,Pod就会认为容器是健康的。这个健康检查在容器启动5S后开始执行(initialDelaySeconds),每5S执行一次(periodSeconds)。
1 | apiVersion: v1 |
下面进行实践:
1 | 创建这个Pod |
可以看到最后Pod虽然在Events中报告了一个异常,最后Pod的状态虽然是Running,但是Restart字段已经从0变为2,意味着这个容器已经被Kubernetes重启2次了,在重启的过程了,Pod保持Running状态不变。
需要注意的是:Kubernetes并没有Docker的Stop语义,所以虽然是Restart(重启),但实际却是重新创建了容器。
restartPolicy
Kubernetes在容器不健康的情况下重新创建新的容器,这就是Kubernetes的Pod恢复机制,即restartPolicy
。
Pod的恢复过程,永远都是发生在当前节点上,而不会跑到别的节点上去。事实上,一旦一个Pod与一个节点(Node)绑定,除非这个绑定发生了变化(pod.spec.node
字段被修改),否则它永远都不会离开这个节点。这也就意味着,如果这个宿主机宕机了,这个Pod也不会主动迁移到其他节点上去。
而如果想让Pod出现在其他的可用节点上,就必须使用Deployment这样的控制器来管理Pod,那么只需要一个Pod副本。这就是一个单Pod和Deployment和一个Pod最主要的区别。
restartPolicy
的恢复策略:
策略 | 描述 |
---|---|
Always | 默认值,任何情况下,容器不在Running状态,就自动重启容器。 |
OnFailure | 容器在Failed状态才重启容器。 |
Never | 从来不重启容器。 |
基本的设计原理:
- 只要Pod的
restartPolicy
指定的策略允许重启异常的容器(比如:Always),那么这个Pod就会保持Running状态,并进行容器重启。否则,Pod就会进入Failed状态。 - 对于包含多个容器的Pod,只有它里面所有的容器都进入异常状态后,Pod才会进入Failed状态。在此之前,Pod都是Running状态。此时,Pod的READY字段会显示正常容器的个数。
如果一个Pod里只有一个容器,这个容器异常退出了,那么只有当restartPolicy=Never
时,这个Pod才会进入Failed状态。而其他情况下,由于Kubernetes会自动重启,所以Pod的状态保持Running不变。
如果一个Pod里有多个容器,仅有一个容器异常余处,它会始终保持Running状态,哪怕restartPolicy=Never
。只有当所有容器也异常退出之后,这个Pod才会进入Failed状态。