14 | 深入解析Pod对象(一):基本概念

14 | 深入解析Pod对象(一):基本概念

朗读人:张磊    11′47′′ | 5.41M

你好,我是张磊。今天我和你分享的主题是:深入解析 Pod 对象之基本概念。

在上一篇文章中,我详细介绍了 Pod 这个 Kubernetes 项目中最重要的概念。而在今天这篇文章中,我会和你分享 Pod 对象的更多细节。

现在,你已经非常清楚:Pod,而不是容器,才是 Kubernetes 项目中的最小编排单位。将这个设计落实到 API 对象上,容器(Container)就成了 Pod 属性里的一个普通的字段。那么,一个很自然的问题就是:到底哪些属性属于 Pod 对象,而又有哪些属性属于 Container 呢?

要彻底理解这个问题,你就一定要牢记我在上一篇文章中提到的一个结论:Pod 扮演的是传统部署环境里“虚拟机”的角色。这样的设计,是为了使用户从传统环境(虚拟机环境)向 Kubernetes(容器环境)的迁移,更加平滑。

而如果你能把 Pod 看成传统环境里的“机器”、把容器看作是运行在这个“机器”里的“用户程序”,那么很多关于 Pod 对象的设计就非常容易理解了。

比如,凡是调度、网络、存储,以及安全相关的属性,基本上是 Pod 级别的。

这些属性的共同特征是,它们描述的是“机器”这个整体,而不是里面运行的“程序”。比如,配置这个“机器”的网卡(即:Pod 的网络定义),配置这个“机器”的磁盘(即:Pod 的存储定义),配置这个“机器”的防火墙(即:Pod 的安全定义)。更不用说,这台“机器”运行在哪个服务器之上(即:Pod 的调度)。

接下来,我就先为你介绍 Pod 中几个重要字段的含义和用法。

NodeSelector:是一个供用户将 Pod 与 Node 进行绑定的字段,用法如下所示:

apiVersion: v1
kind: Pod
...
spec:
nodeSelector:
disktype: ssd
复制代码

这样的一个配置,意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签(Label)的节点上;否则,它将调度失败。

NodeName:一旦 Pod 的这个字段被赋值,Kubernetes 项目就会被认为这个 Pod 已经经过了调度,调度的结果就是赋值的节点名字。所以,这个字段一般由调度器负责设置,但用户也可以设置它来“骗过”调度器,当然这个做法一般是在测试或者调试的时候才会用到。

HostAliases:定义了 Pod 的 hosts 文件(比如 /etc/hosts)里的内容,用法如下:

apiVersion: v1
kind: Pod
...
spec:
hostAliases:
- ip: "10.1.2.3"
hostnames:
- "foo.remote"
- "bar.remote"
...
复制代码

在这个 Pod 的 YAML 文件中,我设置了一组 IP 和 hostname 的数据。这样,这个 Pod 启动后,/etc/hosts 文件的内容将如下所示:

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote
复制代码

其中,最下面两行记录,就是我通过 HostAliases 字段为 Pod 设置的。需要指出的是,在 Kubernetes 项目中,如果要设置 hosts 文件里的内容,一定要通过这种方法。否则,如果直接修改了 hosts 文件的话,在 Pod 被删除重建之后,kubelet 会自动覆盖掉被修改的内容。

除了上述跟“机器”相关的配置外,你可能也会发现,凡是跟容器的 Linux Namespace 相关的属性,也一定是 Pod 级别的。这个原因也很容易理解:Pod 的设计,就是要让它里面的容器尽可能多地共享 Linux Namespace,仅保留必要的隔离和限制能力。这样,Pod 模拟出的效果,就跟虚拟机里程序间的关系非常类似了。

举个例子,在下面这个 Pod 的 YAML 文件中,我定义了 shareProcessNamespace=true:

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
shareProcessNamespace: true
containers:
- name: nginx
image: nginx
- name: shell
image: busybox
stdin: true
tty: true
复制代码

这就意味着这个 Pod 里的容器要共享 PID Namespace。

而在这个 YAML 文件中,我还定义了两个容器:一个是 nginx 容器,一个是开启了 tty 和 stdin 的 shell 容器。

我在前面介绍容器基础时,曾经讲解过什么是 tty 和 stdin。而在 Pod 的 YAML 文件里声明开启它们俩,其实等同于设置了 docker run 里的 -it(-i 即 stdin,-t 即 tty)参数。

如果你还是不太理解它们俩的作用的话,可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序,用于接收用户的标准输入,返回操作系统的标准输出。当然,为了能够在 tty 中输入信息,你还需要同时开启 stdin(标准输入流)。

于是,这个 Pod 被创建后,你就可以使用 shell 容器的 tty 跟这个容器进行交互了。我们一起实践一下:

$ kubectl create -f nginx.yaml
复制代码

接下来,我们使用 kubectl attach 命令,连接到 shell 容器的 tty 上:

$ kubectl attach -it nginx -c shell
复制代码

这样,我们就可以在 shell 容器里执行 ps 指令,查看所有正在运行的进程:

$ kubectl attach -it nginx -c shell
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
14 101 0:00 nginx: worker process
15 root 0:00 sh
21 root 0:00 ps ax
复制代码

可以看到,在这个容器里,我们不仅可以看到它本身的 ps ax 指令,还可以看到 nginx 容器的进程,以及 Infra 容器的 /pause 进程。这就意味着,整个 Pod 里的每个容器的进程,对于所有容器来说都是可见的:它们共享了同一个 PID Namespace。

类似地,凡是 Pod 中的容器要共享宿主机的 Namespace,也一定是 Pod 级别的定义,比如:

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
hostNetwork: true
hostIPC: true
hostPID: true
containers:
- name: nginx
image: nginx
- name: shell
image: busybox
stdin: true
tty: true
复制代码

在这个 Pod 中,我定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着,这个 Pod 里的所有容器,会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。

当然,除了这些属性,Pod 里最重要的字段当属“Containers”了。而在上一篇文章中,我还介绍过“Init Containers”。其实,这两个字段都属于 Pod 对容器的定义,内容也完全相同,只是 Init Containers 的生命周期,会先于所有的 Containers,并且严格按照定义的顺序执行。

Kubernetes 项目中对 Container 的定义,和 Docker 相比并没有什么太大区别。我在前面的容器技术概念入门系列文章中,和你分享的 Image(镜像)、Command(启动命令)、workingDir(容器的工作目录)、Ports(容器要开发的端口),以及 volumeMounts(容器要挂载的 Volume)都是构成 Kubernetes 项目中 Container 的主要字段。不过在这里,还有这么几个属性值得你额外关注。

首先,是 ImagePullPolicy 字段。它定义了镜像拉取的策略。而它之所以是一个 Container 级别的属性,是因为容器镜像本来就是 Container 定义中的一部分。

ImagePullPolicy 的值默认是 Always,即每次创建 Pod 都重新拉取一次镜像。另外,当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时,ImagePullPolicy 也会被认为 Always。

而如果它的值被定义为 Never 或者 IfNotPresent,则意味着 Pod 永远不会主动拉取这个镜像,或者只在宿主机上不存在这个镜像时才拉取。

其次,是 Lifecycle 字段。它定义的是 Container Lifecycle Hooks。顾名思义,Container Lifecycle Hooks 的作用,是在容器状态发生变化时触发一系列“钩子”。我们来看这样一个例子:

apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
复制代码

这是一个来自 Kubernetes 官方文档的 Pod 的 YAML 文件。它其实非常简单,只是定义了一个 nginx 镜像的容器。不过,在这个 YAML 文件的容器(Containers)部分,你会看到这个容器分别设置了一个 postStart 和 preStop 参数。这是什么意思呢?

先说 postStart 吧。它指的是,在容器启动后,立刻执行一个指定的操作。需要明确的是,postStart 定义的操作,虽然是在 Docker 容器 ENTRYPOINT 执行之后,但它并不严格保证顺序。也就是说,在 postStart 启动时,ENTRYPOINT 有可能还没有结束。

当然,如果 postStart 执行超时或者错误,Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息,导致 Pod 也处于失败的状态。

而类似地,preStop 发生的时机,则是容器被杀死之前(比如,收到了 SIGKILL 信号)。而需要明确的是,preStop 操作的执行,是同步的。所以,它会阻塞当前的容器杀死流程,直到这个 Hook 定义操作完成之后,才允许容器被杀死,这跟 postStart 不一样。

所以,在这个例子中,我们在容器成功启动之后,在 /usr/share/message 里写入了一句“欢迎信息”(即 postStart 定义的操作)。而在这个容器被删除之前,我们则先调用了 nginx 的退出指令(即 preStop 定义的操作),从而实现了容器的“优雅退出”。

在熟悉了 Pod 以及它的 Container 部分的主要字段之后,我再和你分享一下这样一个的 Pod 对象在 Kubernetes 中的生命周期

Pod 生命周期的变化,主要体现在 Pod API 对象的Status 部分,这是它除了 Metadata 和 Spec 之外的第三个重要字段。其中,pod.status.phase,就是 Pod 的当前状态,它有如下几种可能的情况:

  1. Pending。这个状态意味着,Pod 的 YAML 文件已经提交给了 Kubernetes,API 对象已经被创建并保存在 Etcd 当中。但是,这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如,调度不成功。

  2. Running。这个状态下,Pod 已经调度成功,跟一个具体的节点绑定。它包含的容器都已经创建成功,并且至少有一个正在运行中。

  3. Succeeded。这个状态意味着,Pod 里的所有容器都正常运行完毕,并且已经退出了。这种情况在运行一次性任务时最为常见。

  4. Failed。这个状态下,Pod 里至少有一个容器以不正常的状态(非 0 的返回码)退出。这个状态的出现,意味着你得想办法 Debug 这个容器的应用,比如查看 Pod 的 Events 和日志。

  5. Unknown。这是一个异常状态,意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver,这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题。

更进一步地,Pod 对象的 Status 字段,还可以再细分出一组 Conditions。这些细分状态的值包括:PodScheduled、Ready、Initialized,以及 Unschedulable。它们主要用于描述造成当前 Status 的具体原因是什么。

比如,Pod 当前的 Status 是 Pending,对应的 Condition 是 Unschedulable,这就意味着它的调度出现了问题。

而其中,Ready 这个细分状态非常值得我们关注:它意味着 Pod 不仅已经正常启动(Running 状态),而且已经可以对外提供服务了。这两者之间(Running 和 Ready)是有区别的,你不妨仔细思考一下。

Pod 的这些状态信息,是我们判断应用运行情况的重要标准,尤其是 Pod 进入了非“Running”状态后,你一定要能迅速做出反应,根据它所代表的异常情况开始跟踪和定位,而不是去手忙脚乱地查阅文档。

总结

在今天这篇文章中,我详细讲解了 Pod API 对象,介绍了 Pod 的核心使用方法,并分析了 Pod 和 Container 在字段上的异同。希望这些讲解能够帮你更好地理解和记忆 Pod YAML 中的核心字段,以及这些字段的准确含义。

实际上,Pod API 对象是整个 Kubernetes 体系中最核心的一个概念,也是后面我讲解各种控制器时都要用到的。

在学习完这篇文章后,我希望你能仔细阅读 $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/api/core/v1/types.go 里,type Pod struct ,尤其是 PodSpec 部分的内容。争取做到下次看到一个 Pod 的 YAML 文件时,不再需要查阅文档,就能做到把常用字段及其作用信手拈来。

而在下一篇文章中,我会通过大量的实践,帮助你巩固和进阶关于 Pod API 对象核心字段的使用方法,敬请期待吧。

思考题

你能否举出一些 Pod(即容器)的状态是 Running,但是应用其实已经停止服务的例子?相信 Java Web 开发者的亲身体会会比较多吧。

感谢你的收听,欢迎你给我留言,也欢迎分享给更多的朋友一起阅读。

版权归极客邦科技所有,未经许可不得转载

精选留言

  • 龙坤
    你好,我进入shell容器,然后执行ps ax,跟例子的结果不一样。例子代码也一样,添加了shareProcessNamespace: true了,为什么不行呢,请问可能出现的原因在哪里
    / # ps
    PID USER TIME COMMAND
    1 root 0:00 sh
    10 root 0:00 ps

    2018-09-26
  • blackpiglet
    对于 Pod 状态是 Ready,实际上不能提供服务的情况能想到几个例子:
    1. 程序本身有 bug,本来应该返回 200,但因为代码问题,返回的是500;
    2. 程序因为内存问题,已经僵死,但进程还在,但无响应;
    3. Dockerfile 写的不规范,应用程序不是主进程,那么主进程出了什么问题都无法发现;
    4. 程序出现死循环。
    2018-09-24
    作者回复

    课代表来了

    2018-09-25

  • asdf100
    本地测试的进入shell容器后执行ps ax,跟例子的结果不一样。没有看到nginx窗口里的nginx进程信息,为什么,我看也有人遇到这个问题.
    / # ps
    PID USER TIME COMMAND
    1 root 0:00 sh
    10 root 0:00 ps
    2018-09-30
    作者回复

    你看看sharepid功能开启了没

    2018-09-30

  • Jeff.W
    POD的直议是豆荚,豆荚中的一个或者多个豆属于同一个家庭,共享一个物理豆荚(可以共享调度、网络、存储,以及安全),每个豆虽然有自己的空间,但是由于之间的缝隙,可以近距离无缝沟通(Linux Namespace相关的属性)。
    2018-10-12
  • 两两
    pod runing好理解,但k8s怎么知道容器runing呢,通过什么标准判断?应用死循环,k8s怎么能感知?
    2018-09-26
    作者回复

    liveness和readiness啥区别?

    2018-09-26

  • 柳旭
    停止服务,即对外不再提供服务,这种情况可以发生在容器内的服务需要获取某种资源但获取不到又在不断重试。
    2018-09-25
  • loda
    请教个问题,当资源不足的时候,在调用k8s扩容会出现失败,然后一直pending,表示资源不够。怎么能在请求失败前提前检测到该现象呢,避免在继续出现pending请求?

    如果要每次扩容前都全量扫描一个所有pod和node,然后计算剩余资源,开销也太大了;
    如果要维护一个和kube-scheduler缓存一致的资源池,会不会又出现数据不一致的问题

    业界在碰到该类问题的时候,都是怎么处理的呢?
    2018-09-25
    作者回复

    这个不难处理,后面专门有讲解scaling的文章

    2018-09-25

  • hexinzhe
    比较想要知道优雅停机方面的更详细内容,比如说terminationgraceperiodseconds与prestop之间的关系,两者怎么用
    2018-09-25
    作者回复

    前者就是sig term的超时时间。后者是要你自己编写逻辑处理的。

    2018-09-25

  • Geek_700d17
    中秋快乐

    看了老师的讲解,对Pod的认识更全面了,把Pod看做虚拟机,确实很形象,以前对Pod的疑惑都没了
    2018-09-24
  • AFA
    您好,pod结构体的文件目录是不是要指定kuber版本号?不指定版本号是不是有可能找不到?
    2018-09-24
    作者回复

    pod版本早就固定下来啦,v1

    2018-09-24

  • 混沌渺无极
    各位,中秋节好。
    如果entrypoint是一个一直运行的命令,那postStart会执行吗?还是启动一个协程成执行entrypoint,然后再运行一个协程执行这个postStart,所以这两个命令的执行状态是独立的,没有真正的先后关系。
    2018-09-24
    作者回复

    文中不是已经解释了?当然会执行,不管entrypoint。

    2018-09-24

  • pytimer
    老师,问一下,我看pod.status.phase是running,但是Ready是false,如果我想判断pod状态,要怎么做
    2018-09-24
    作者回复

    看events

    2018-09-24

  • FonZie
    你好,我看了评论去的很多遇到了实验结果和文章中的不符合,我根据你的回复查看了api-service的配置,默认是有一个--feature-gates=AllAlpha=true。这个应该就是你说的1.11默认开启的参数吧,但是我还是看不到nginx的进程。这会是什么原因造成的。
    2018-10-08
    作者回复

    可以先检查一下kubelet log

    2018-10-08

  • 安排
    你好,我进入shell容器,然后执行ps ax,跟例子的结果不一样。例子代码也一样,添加了shareProcessNamespace: true了,为什么不行呢,请问可能出现的原因在哪里
    / # ps
    PID USER TIME COMMAND
    1 root 0:00 sh
    10 root 0:00 ps

    请问怎么开启sharepid功能呢?
    2018-10-05
    作者回复

    apiserver 加—feature-gates=PodShareProcessNamespace=true 1.11后已经默认开启了

    2018-10-05

  • eason2017
    好文章顶!
    2018-09-30
  • 旺旺
    nginx的yaml文件,后面几行好像少了2个空格缩进,应该是下面这样的吧:
    root@k8s-master:~/k8s# cat nginx.yaml
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx
    spec:
    shareProcessNamespace: true
    containers:
    - name: nginx
    image: nginx
    - name: shell
    image: busybox
    stdin: true
    tty: true
    2018-09-28
    作者回复

    可能屏幕适配的问题

    2018-09-29

  • 刘家兴
    error: error validating "liujx-nginx-pod-shareProcessNamespace.yaml": error validating data: ValidationError(Pod.spec): unknown field "shareProcessNamespace" in io.k8s.api.core.v1.PodSpec; if you choose to ignore these errors, turn validation off with --validate=false

    老师这是咋回事儿
    2018-09-28
    作者回复

    这是个新功能,你确定一下集群版本,还有是不是开启了

    2018-09-28

  • 龙坤
    NAME READY STATUS RESTARTS AGE
    coredns-78fcdf6894-f6gn5 0/1 CrashLoopBackOff 12 45m
    coredns-78fcdf6894-hnnbf 0/1 CrashLoopBackOff 12 45m

    NAME ADY STATUS RESTARTS AGE
    coredns-78fcdf6894-f6gn5 1/1 Running 12 42m
    coredns-78fcdf6894-hnnbf 1/1 Running 12 42m

    Events信息:
    Message
    ----------------
    0/1 nodes are available: 1 node(s) were not ready.
    Successfully assigned kube-system/coredns-78fcdf6894-f6gn5 to zcloud-13-3-master
    Container image "k8s.gcr.io/coredns:1.1.3" already present on machine
    Created container
    Started container
    Killing container with id docker://coredns:Container failed liveness probe.. Container will be killed and recreated.
    Liveness probe failed: HTTP probe failed with statuscode: 503
    Back-off restarting failed container

    问题:这个pod有时候 0/1 有时候 1/1。不知道什么原因,望老师指点下
    2018-09-27
  • 北卡
    k8s pod type struct 路径改了,最新的路径在: kubernetes/staging/src/k8s.io/api/core/v1/types.go
    2018-09-27
    作者回复

    你要是愿意的话,可以找到好几份呢 :-)

    2018-09-27

  • 北卡
    只要容器没有down掉,pod就会处于running状态。pod只会监控到容器的状态,但不会监控容器里面程序的运行状态。如果程序处于死循环,或者其他bug状态,但并没有异常退出,此刻容器还是会处于存活状态,但实际上程序已经不能工作了。
    日常使用的感受是这样的,不知道对不。
    2018-09-27
  • 徐海浪
    以前我对容器的认识还不深,竟然用tail -f Catalina.out作为前台进程,这样即使tomcat进程挂掉,容器还是正在运行。应用不可用tomcat进程还在经常会遇到,比如内存溢出,或者应用依赖的数据库等外部系统动荡导致应用不正常。怎么在应用的角度来决定容器是否应该退出?应用提供一个健康检查url,跑前台shell定期检查该url,状态不对则shell退出,从而容器退出。
    2018-09-26
    作者回复

    吃一堑长一智

    2018-09-26

  • Vincen
    pod对象中的有些字段不能够在deployment中使用比如文章中提到的HostAliases,我们通常使用deployment来部署pod。这种情况怎么办?
    2018-09-26
    作者回复

    这个字段为啥不能用?

    2018-09-26

  • Anker
    Yaml文件kind赋值为Pod,会存在单点问题吧。如果这个Pod挂掉了,对应的服务也会挂掉。在生产环境中,使用Deployment,启用多个pod副本。可以讲讲这个高可用问题
    2018-09-25
  • 虎虎❤️
    老师,pod的/etc/hosts文件怎么理解?是pause 容器的文件吗?
    2018-09-25
    作者回复

    文件系统是隔离的呀

    2018-09-25

  • 姜戈
    通过node selector将任务调度到了woker1 成功运行之后 再修改worker1的label, 任务会重新调度吗?
    2018-09-25
    作者回复

    不会

    2018-09-25

  • 杨孔来
    老师,如果pod中的image更新了(比如 通过jenkins发布了新版本),我想通过重启pod,获取最新的image,有什么命令,可以优雅的重启pod,而不影响当前pod提供的业务吗
    2018-09-25
    作者回复

    不是讲了prestop hook了?

    2018-09-25

  • ethfoo
    如果pod加了健康检查,是不是就不关心应用进程是不是容器的初始化进程呢?因为应用进程挂了,虽然容器不会自动退出,但是kubelet会主动去kill掉这个容器
    2018-09-25
    作者回复

    可以这么理解

    2018-09-25

  • 古董级大叔
    actuator健康检查为down的时候,服务已经不能服务了,但是服务还是启动的
    2018-09-25
  • 巩夫建
    中秋节快乐,感谢作者地产出。知识点很丰富,对实际工作帮助很大。有个标签的问题求解一下,如果node1打了标签ssd,其他node没有打标签,如果一个没有标记标签的pod,在资源充足的情况下会偶发部署到node1上吗?如果资源不充足,会去占用node1的资源吗?
    回答作业题,java的项目经常由于oom,导致pod正常,里面的子进程被kill掉。现在是关闭oom,是否有其他更优方案?
    2018-09-24
    作者回复

    调度部分自会介绍。

    2018-09-25

  • Vincent
    思考题是Java web项目内存溢出?
    2018-09-24
    作者回复

    嗯,这正是一个常见情况。

    2018-09-25

  • hugeo
    springboot启动的时候报错了,服务没起起来,但是pod是running
    2018-09-24
  • 广兴
    老师您好,您提出的思考题能以java web解释下原因吗?还没实践过,想知道答案,谢谢
    2018-09-24
    作者回复

    先让子弹飞一会儿

    2018-09-24