前言
大家好,我是秋意零。
本专栏上一篇中,我们介绍了 Pod 的核心思想以及 Pod 的工作原理。今天我们还是探讨 Pod ,聊一聊 Pod 的基本概念。👿 简介
- 🏠 个人主页: 秋意零
- 🧑 个人介绍:在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛”,并斩获多项奖项荣誉证书
- 🎉 目前状况:24 届毕业生,拿到一家私有云(IAAS)公司 offer,暑假开始实习
- 🔥 账号:各个平台, 秋意零 账号创作者、 云社区 创建者
- 💕欢迎大家:欢迎大家一起学习云计算,走向年薪 30 万
系列文章目录
【云原生|探索 Kubernetes 系列 1】容器的本质是进程
【云原生|探索 Kubernetes 系列 2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统
【云原生|探索 Kubernetes 系列 4】现代云原生时代的引擎
【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程
【云原生|探索 Kubernetes 系列 6】从 0 到 1,轻松搭建完整的 Kubernetes 集群
【云原生|探索 Kubernetes 系列 7】探究 Pod 有什么用,为什么需要它
正文开始:
- 快速上船,马上开始掌舵了(Kubernetes),距离开船还有 3s,2s,1s…
一、Pod 生命周期
首先,我们来介绍一下 Pod 的生命周期,如图:
- Infra :首先容器环境初始化由 Infra 容器负责(共享网络和卷);
- Init C:接着到达 initContainer 容器,Init C 容器的执行顺序严格根据自己定义的顺序保持一致,并且在 Main C 主容器(也就是 Containers)之前执行;Init C 只有执行成功才会执行下一个 Init C,都执行成功才会到 Main C 主容器。
- Start :在 Main C 主容器之前,还有一个 START 操作,是在 Main C 主容器启动时执行的,类似 Docker 的 ENTRYPROINT。
- Rediness:就绪检测,可以是检测 Pod 里的服务启动没,不仅仅是 Pod Running 了,因为即使是 Pod Running 了,里面服务没有启动也是没有意义的。比如:检测 Web 服务是否能正常访问了,如果正常,那么 Pod 状态才 Running。
- Liveness:存活检测。还是以 Web 服务为例,如果我们容器在运行过程中,这个 Web 服务挂了,导致 Web 服务无法访问,那么这个时候我们也不能把这个 Pod 视为正常运行的 Pod,而 Liveness 存活检测,就是为了预防这种情况发生。如:我们可以设置每隔多久就检测一次 Web 服务是否正常,如果不正常就会导致 Pod 重新启动(No Running 状态)。
- Stop:Stop 发生的时机,则是容器被杀死之前(比如,收到了 kill 信号),而需要明确的是,Stop 操作的执行,是与 kill 信号同步的。所以,它会阻塞当前的容器杀死流程,直到这个 Stop 定义操作完成之后,才允许容器被杀死。
Pod 状态
Pod 生命周期的变化,主要体现在 Pod API 对象的 Status 部分,这是它除了 Metadata 和 Spec 之外的第三个重要字段。pod.status.phase
字段就是 Pod 的当前状态,有如下几种可能的情况:
- Pending:挂起等待状态。Pod 的 YAML 文件已经提交给了 Kubernetes,API 对象已经被创建并保存在 Etcd 当中。但是因为某些原因,调度不成功,不能被顺利创建。
- Running:正在运行状态。Pod 已经与节点绑定,并调度成功。Pod 中容器创建成功,并至少有一个容器正在运行中。
- Succeeded:运行成功状态。Pod 里面的容器都正常运行完毕,并且已经正常退出了。
- Failed:失败状态。Pod 里至少有一个容器以不正常的状态(非 0 的返回码)退出。这个一般需要查看 Pod 的 Events 和日志解决。
- Unknown:未知状态(异常状态)。 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver,这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题。
而其中,Ready 这个细分状态非常值得我们关注:它意味着 Pod 不仅已经正常启动(Running 状态),而且已经可以对外提供服务了。这两者之间(Running 和 Ready)是有区别的。
二、如何区分 Pod 的 API 对象属性级别
Pod 中包含了容器。那么,我们怎么在写 YAML 文件时,怎么区分 Pod 这个 API 对象中,那些是 Pod 属性里的字段,那些是 containers(容器)属性里的字段呢?
其实,我们可以形象的把虚拟机里面的属性,如:内存、磁盘、网络 等资源,对应到 Pod 中,这样 Pod 就是扮演的 “虚拟机” 的角色。但是,不要把我们本专栏文章中的第 4 篇,提到的 Kubernetes 比作 “操作系统” 的概率混淆。
- Kubernetes 比作 “操作系统”,这个概念是 “宿主机” 的概念,而 Pod 是宿主机虚拟出来的 “虚拟机” 的概念。
- 就好比,我们自己 Windosws 电脑中,安装了 VMware 虚拟化软件,在这个虚拟软件中又安装了一个 CentOS 系统一样。
所以,你把 Pod 看作是 “虚拟机”,把容器还是看做虚拟机里面的 “程序进程”,这样 Pod 的 API 对象里面的属性字段,那些是 Pod 属性里的,那些是 containers(容器)属性里的,就能一清二楚了。
结论:凡是和网络、存储、CPU、内存、调度这种虚拟机操作系统 “机器” 相关的,那么一般都是 Pod 级别的属性。
- 比如:配置 Pod 网络(虚拟机网卡)、配置 Pod 存储(虚拟机磁盘)、配置 Pod 在 Kuberentes 集群中那个 Node 计算节点运行(调度)。
三、重要字段用法
Kubernetes 中有个很重要概率 “标签”:
- “标签” 是由
Key=Value
键值对组成,它是为了标识某个对象(即:Node、Pod、Service、Job 等)。如果我们为某两个对象打了同样的 “标签”,那么它们之前是可以通过“标签” 来与之关联和选择某个对象的依据。 - 比如:一个 Pod 和 Service 对象,都打了
web: app
(YAML 文件中的格式)标签,那么它们之间就关联起来了,这样我们访问 Service 的 虚拟 IP 时,就相当于在访问这个 Pod。
节点选择 NodeSelector
NodeSelector 是 Pod 去找对应 Node 计算节点与之绑定的字段,用法如下:
- 1.首先,我们查看 Node 节点标签。
这里也可以自己为 Node 节点打标签,命令:
kubectl label
。
kubectl get node --show-labels=true
在 Pod 中,spec.nodeSelector
字段下写上 kubernetes.io/hostname: worker01
,那么这个 Pod 在运行之前进入调度队列时,就一定会在 worker01 节点运行,如果这个标签或者节点不存在,那么 Pod 就一直处于挂起状态并调度失败,否则则调度成功。
cat > web-qyl.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: web
name: web
spec:
nodeSelector:
kubernetes.io/hostname: worker01
containers:
- image: nginx
name: nginx
imagePullPolicy: IfNotPresent
EOF
- 2.运行 Pod,并查看 Pod 详细信息(
-o wide
是详细输出)。
kubectl apply -f web-qyl.yaml
kubectl get pod -o wide
节点选择(手动)NodeName
NodeName 字段,手动将对象调度到 NodeName 所指定的节点名称上。
这个指其实是 kube-scheduler 组件负责设置赋值的。调度和创建过程:
- 这时有个 Pod 需要创建,首先 kube-scheduler 会监听 kube-apiserver 的消息,发现 Pod 的创建请求,这时 kube-scheduler 会检查 NodeName 字段是否为空,为空就代表没有被调度;
- 这时根据 Pod 的调度策略,还是更具 kube-schedule r默认的调度策略来调度到对应的 Node 节点上,选中一个 Node 节点后,kube-scheduler 会为 NodeName 字段赋值对应节点名称;
- 然后把 Pod 定义资源存回 kube-apiserver,kube-apiserver 会通知 kubelet 创建运行 Pod,然后再通过 kube-apiserver 把 Pod 状态信息给 Etcd 存储起来。
这样就完成了整个调度和创建过程。
总结:所以,我们这里直接使用 NodeName 字段为其赋了值,那么 kube-scheduler 判断 NodeName 这个值是否为空时,发现有值,那么这个调度过程就是完成了的。
主机名 IP 映射 HostAliases
HostAliases 是定义了 Pod 的 /etc/hosts 文件中的内容,用法如下:
cat > hostaliases-qyl.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: hostaliases-qyl
name: hostliases-qyl
spec:
hostAliases:
- ip: "192.168.200.1"
hostnames:
- "vm1.com"
- "vm2.com"
- ip: "192.168.200.2"
hostnames:
- "vm.com"
containers:
- image: busybox
name: busybox
imagePullPolicy: IfNotPresent
command: [ "/bin/sh", "-c", "sleep 3600" ]
EOF
上诉中,我们在 spec.hostAliases
字段下,写了两组 ip
和 hostnames
的配置。我运行 Pod 后,查看 /etc/hosts 文件内容:
- 可以看到,我框出的内容,就是
spec.hostAliases.ip.hostnames
设置的内容; - 在 Kubernetes 中,要配置 hosts 文件,一定要通过这种方式。因为如果,你进入 Pod 中的容器修改,那么 Pod 被删除或者重建后,这个 hosts 文件内容也会变成最初默认内容,非常麻烦。
kubectl apply -f hostaliases-qyl.yaml
kubectl get -f hostaliases-qyl.yaml -owide
kubectl exec -it pod/hostliases-qyl -- cat /etc/hosts
这里 spec.hostAliases
字段,也体现了跟 “虚拟机机器” 相关的配置外,也会发现,凡是跟容器的 Linux Namespace 相关的属性,也一定是 Pod 级别的。
- 原因是,Pod 的设计,就是要让它里面的容器尽可能多地共享 Linux Namespace,仅保留必要的隔离和限制能力。这样,Pod 的效果,就和虚拟机里面程序间的关系非常类似了。
这里,我们开启 shareProcessNamespace=true
,意味着 Pod 里的容器要共享 PID Namespace ,举个例子:
cat > nginx-shell.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: shell-qyl
name: shell-qyl
spec:
shareProcessNamespace: true
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
- image: busybox
name: busybox
imagePullPolicy: IfNotPresent
command: [ "/bin/sh", "-c", "sleep 3600" ]
EOF
kubectl apply -f nginx-shell.yaml
执行 ps
命令,查看进程:
- 这里,可以看到有我们容器中的 nginx 容器的
nginx -g daemon off;
进程,和 busybox 容器sleep 3600
进程,以及 Infra 容器的/pause
进程; - 这意味着 Pod 中每个容器进程,对于所有容器都是可见的;
总结:凡是跟容器的 Linux Namespace 相关的属性,也一定是 Pod 级别的。
容器列表 Containers
containers 可以算是 Pod 中最重要的字段了,本专栏。上一篇文章中(第 7 篇),我们提到了一个 containers 字段中的属性 initContainers ,这两个字段都是对 Pod 中容器的定义,定义的内容也完全相同,不同的是它们的启动顺序不同。initContainers 定义的容器,会在 containers 定义的容器之前运行,并严格按照定义的顺序执行。
containers 字段定义的内容就是为了创建容器的相关属性,比如:image(镜像)、ports(端口)、command(启动命令)、volumeMounts(挂载卷)、imagePullPolicy(镜像拉取策略)、name(容器名称)。
镜像拉取策略 ImagePullPolicy
imagePullPolicy 的取值有:
- 默认值是 Always(总是):每次创建 Pod 都重新拉取一次镜像,不管你本地是否已经存在了该镜像;
- Never 或者 IfNotPresent:只在宿主机上不存在这个镜像时才拉取。
生命周期挂钩 Lifecycle
Lifecycle,它定义的是 Container Lifecycle Hooks(生命周期挂钩)。顾名思义,Container Lifecycle Hooks 的作用,是在容器状态发生变化时(如:启动、停止之前)触发一系列 “钩子” 。
我们来看个例子:
- postStart:在容器启动后,立刻执行一个指定的操作。如果 postStart 执行超时或者错误,Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息,导致 Pod 也处于失败的状态。
- preStop:容器被杀死之前(kill 命令)执行的操作,而需要明确的是,kill 命令 与 preStop 操作的执行,是同步的。所以,它会阻塞当前的容器杀死(kill)流程,直到这个 Hook 定义操作完成之后,才允许容器被杀死。
我们在容器成功启动之后,在 /usr/share/message 里写入了一句 “Hello World”。而在这个容器被删除之前,我们则先调用了 nginx 的退出指令,从而实现了容器的 “优雅退出”。
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-qyl
spec:
containers:
- name: nginx-qyl
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", echo "Hello World" > /usr/share/message]
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
总结
今天介绍了,Pod 的基本概念。
重点说明了,Pod 的 API 对象属性字段,那些是属于 Pod 级别,那些是属于容器级别的。所以你应该了解了,能够区分大部分 Pod 的 API 对象属性字段的级别是什么。
之后介绍了,Pod 的一些常用字段的用法。文章来源:https://www.toymoban.com/news/detail-470592.html
文章来源地址https://www.toymoban.com/news/detail-470592.html
到了这里,关于【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!