【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法

前言

大家好,我是秋意零。

本专栏上一篇中,我们介绍了 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 有什么用,为什么需要它



文章目录

  • 前言
  • 系列文章目录
  • 一、Pod 生命周期
    • Pod 状态
  • 二、如何区分 Pod 的 API 对象属性级别
  • 三、重要字段用法
    • 节点选择 NodeSelector
    • 节点选择(手动)NodeName
    • 主机名 IP 映射 HostAliases
    • 容器列表 Containers
      • 镜像拉取策略 ImagePullPolicy
      • 生命周期挂钩 Lifecycle
  • 总结

正文开始

  • 快速上船,马上开始掌舵了(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 定义操作完成之后,才允许容器被杀死。

【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法_第1张图片

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 字段下,写了两组 iphostnames 的配置。我运行 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

【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法_第2张图片

这里 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 中每个容器进程,对于所有容器都是可见的;
    【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法_第3张图片

总结:凡是跟容器的 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 的一些常用字段的用法。

【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法_第4张图片

你可能感兴趣的:(#,深入探索,Kubernetes,kubernetes,云原生,容器,云计算,Pod)