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

这篇具有很好参考价值的文章主要介绍了【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

大家好,我是秋意零。

本专栏上一篇中,我们介绍了 Pod 的核心思想以及 Pod 的工作原理。今天我们还是探讨 Pod ,聊一聊 Pod 的基本概念。

👿 简介

  • 🏠 个人主页: 秋意零
  • 🧑 个人介绍:在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛”,并斩获多项奖项荣誉证书
  • 🎉 目前状况:24 届毕业生,拿到一家私有云(IAAS)公司 offer,暑假开始实习
  • 🔥 账号:各个平台, 秋意零 账号创作者、 云社区 创建者
  • 💕欢迎大家:欢迎大家一起学习云计算,走向年薪 30 万

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

系列文章目录


【云原生|探索 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…

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

一、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 对象属性级别与重要字段用法

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

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

在 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

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

节点选择(手动)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 对象属性级别与重要字段用法

这里 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 对象属性级别与重要字段用法

总结:凡是跟容器的 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 对象属性级别与重要字段用法文章来源地址https://www.toymoban.com/news/detail-470592.html

到了这里,关于【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

    大家好,我是秋意零。 上一篇中介绍了,Pod 的服务对象,从而对 Pod 有了更深的理解; 今天的主题是 Pod 健康检查和恢复机制,我们将结束 Pod 的内容。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持!在我主页推广区域,如图: 文章底部推广区域

    2024年02月09日
    浏览(39)
  • 【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎

    【云原生|探索 Kubernetes-1】容器的本质是进程 【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制 【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统 大家好,我是秋意零。 😈 CSDN作者主页 😎 博客主页 👿 简介 👻 普通本科生在读 在校期间参与众多计算机相关比赛,

    2024年02月06日
    浏览(55)
  • 【云原生|探索 Kubernetes 系列 6】从 0 到 1,轻松搭建完整的 Kubernetes 集群

    大家好,我是秋意零。 前面一篇中,我们介绍了 kubeadm 的工作流程。那么今天我们就实际操作一下,探索如何快速、高效地从 0 开始搭建一个完整的 Kubernetes 集群,让你轻松驾驭容器化技术的力量!! 👿 简介 🏠 个人主页 : 秋意零 🧑 个人介绍 :在校期间参与众多云计算

    2024年02月07日
    浏览(38)
  • 【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程

    大家好,我是秋意零。 在前面 4 个章节中,我们充分了解了容器技术和 Kubernes 原生时代引擎的架构和设计思想,今天分享的主要内容是,探索 Kubernetes 部署,深入解析其工作流程 👿 简介 🏠 个人主页 : 秋意零 🧑 个人介绍 :在校期间参与众多云计算相关比赛,如:🌟

    2024年02月06日
    浏览(48)
  • 【云原生 | Kubernetes 系列】K8s 实战 如何给应用注入数据 II 将pod数据传递给容器

    在上一篇文章中,我们学习了针对容器设置启动时要执行的命令和参数、定义相互依赖的环境变量、为容器设置环境变量,三种设置方式,本篇文章,我们将继续学习数据的传递。 有两种方式可以将 Pod 和 Container 字段传递给运行中的容器: 环境变量 卷文件 这两种呈现 Pod

    2024年01月25日
    浏览(123)
  • 【探索 Kubernetes|容器基础进阶篇 系列 4】理解现代云原生时代的引擎

    【云原生|探索 Kubernetes-1】容器的本质是进程 【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制 【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统 大家好,我是秋意零。 😈 CSDN作者主页 😎 博客主页 👿 简介 👻 普通本科生在读 在校期间参与众多计算机相关比赛,

    2024年02月08日
    浏览(47)
  • 【云原生 | Kubernetes 系列】K8s 实战 使用 Kustomize 对 Kubernetes 对象进行声明式管理

    Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理应用配置文件: 从其他来源生成资源 为资源设置贯穿性(Cross-Cutting)字段 组织和定制资源集合 ConfigMap 和 Secret 包含其他 Kubernetes 对象(如 Pod)所需要的配置或敏感数据。 ConfigMap 或 Secret 中数据的来

    2024年01月17日
    浏览(68)
  • 【云原生 | Kubernetes 系列】K8s 实战 Kubernetes 对象管理之指令式命令管理和配置文件命令式管理

    kubectl 工具能够支持三种对象管理方式: 声明式对象配置 指令式命令 指令式对象配置 前面我使用了两篇文章讲解了 使用配置文件对 Kubernetes 对象进行声明式管理 的相关知识点,本篇文章我将带领大家一起学习剩下的两个Kubernetes 对象管理的指令式命令管理和配置文件命令式

    2023年04月15日
    浏览(74)
  • 云原生Kubernetes:pod基础

    目录 一、理论 1.pod 2.pod容器分类 3.镜像拉取策略 4.pod 的重启策略 二、实验 1.Pod容器的分类 2.镜像拉取策略 三、问题 1.apiVersion 报错 2.pod v1版本资源未注册 3.格式错误 4.取行显示指定pod信息 四、总结 (1)  概念  Pod是kubernetes中最小的资源管理组件,Pod也是最小化运行容器化应

    2024年02月09日
    浏览(41)
  • 【云原生】Kubernetes之 Pod hook(钩子)

    Pod hook(钩子)是由 Kubernetes 管理的 kubelet 发起的,当容器中的进程启动前或者容器中的进程终止之前运行,这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。 Hook 的类型包括两种: exec:执行一段命令 HTTP:发送 HTTP 请求 示例如下: 说明: postStar

    2024年02月15日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包