最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

k8s 深入篇———— pod 实战[六]

来源:博客园

前言

pod 实战一下,主要是一些例子。

正文

例子一

pod 实例的选择:

NodeSelector:是一个供用户将 Pod 与 Node 进行绑定的字段


(资料图)

NodeName:一旦 Pod 的这个字段被赋值,Kubernetes 项目就会被认为这个 Pod 已经经过了调度,调度的结果就是赋值的节点名字。

所以,这个字段一般由调度器负责设置,但用户也可以设置它来“骗过”调度器,当然这个做法一般是在测试或者调试的时候才会用到。

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

例如:

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

127.0.0.1 localhost...10.244.135.10 hostaliases-pod10.1.2.3 foo.remote10.1.2.3 bar.remote

如果设置:shareProcessNamespace=true.

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

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

然后就运行成功了。

kubectl exec -it nginx /bin/bash

如果一个 Pod 中有多个容器,使用 kubectl exec 进入容器时需要指定容器名称。可以使用以下命令指定容器名称:

kubectl exec -it  -c  sh其中,`` 是 Pod 的名称,`` 是容器名称。如果不指定容器名称,默认进入第一个容器。

那么我们进入第二个容器看下,因为第一个容器没有安装ps等一些基本的命令。

stdin 是 Kubernetes 中容器的一个属性,用于指定容器是否需要一个标准输入(stdin)。当 stdin 属性设置为 true 时,容器会打开一个 STDIN 文件描述符,并等待输入。这通常用于在容器中运行交互式应用程序,例如 bash shell。当 stdin 属性设置为 false 时,容器不会打开 STDIN 文件描述符,并且不会等待输入。这通常用于在容器中运行后台进程,例如 Web 服务器或数据库。需要注意的是,如果 stdin 属性设置为 true,而容器本身没有能力处理输入,那么容器将会无限期地等待输入,直到手动停止容器。因此,在使用 stdin 属性时,需要确保容器本身能够处理输入。

使用:

kubectl attach -it nginx -c shell

这里我们可以看到infra 程序,并且可以看到nginx,是因为shareProcessNamespace 为true了。

默认情况下,只有网络namespace 是共享的。

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

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

ImagePullPolicy 的值默认是 Always,即每次创建 Pod 都重新拉取一次镜像。另外,当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时,ImagePullPolicy 也会被认为Always。而如果它的值被定义为 Never 或者 IfNotPresent,则意味着 Pod 永远不会主动拉取这个镜像,或者只在宿主机上不存在这个镜像时才拉取

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

我们来看这样一个例子:

这是一个来自 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 生命周期的变化,主要体现在 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和日志。

  1. 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”状态后,你一定要能迅速做出反应,根据它所代表的异常情况开始跟踪和定位,而不是去手忙脚乱地查阅文档

下一节k8s,进阶例子。

关键词: