当前位置：首页 > news >正文

kubernetes高级调度

news 2025/7/12 7:51:23

一. 初始化容器 Initcontainer

1:Initcontainer 的基本概念

2. 延迟指定时间后启动

3. 使用初始化容器修改内核参数

4. 等待依赖服务启动

4. pause 容器

二. 临时容器Ephemeral Container

1:临时容器的概念

三. 自动扩缩容 HPA

1. 什么是 HPA

2. HPA 的工作原理

3. HPA 的工作流程

4. HPA 的应用场景

5. HPA 实践--实现 web 服务器的自动伸缩特性

一. 初始化容器 Initcontainer

初始化容器是用来进行初始化操作的。很多情况下，程序的启动需要依赖各类配置、资源。但是又不能继承在原有的启动命令或者镜像当中，因为程序的镜像可能并没有加载配置命令，此时 Initcontainer 就起了很大的作用。

1:Initcontainer 的基本概念

Initcontainer 是 Kubernetes 的初始化容器(也可称之为 Init 容器)，它是一种特殊的容器，在Pod 内的应用容器启动之前运行，可以包括一些应用镜像中不存在的使用工具和安装脚本，用以在程序启动时进行初始化，比如创建文件、修改内核参数、等待依赖程序启动等。

每个 Pod 中可以包含多个容器,同时 Pod 也可以有一个或多个先于应用程序启动的 Init 容器,在 Pod定义中和 container 同级,按顺序逐个执行,当所有的 Init 容器运行完成时,Kubernetes 才会启动 Pod内的普通容器。

Init 容器与普通的容器非常像，除了如下几点:

他们总是运行到完成。
上一个运行完成才会运行下一个。
如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止，但是如果 Pod 对应的 restartPolicy 值为 Never，Kubernetes 则不会重新启动 Pod。

为Pod 设置 Init 容器需要在 Pod的 spec 中添加 initcontainer 字段,该字段和应用的 containers属组同级相邻，配置方式和 containers 中的普通容器差不多，Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。但是 Init 容器对资源请求和限制的处理稍有不同，Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe，因为他们必须在 Pod 就绪之前运行完成。

备注:
lifecycle 主要指的是容器在其运行环境中经历的不同阶段，以及 Kubernetes 如何管理和响应这些阶段的能力。Kubernetes 提供了容器生命周期钩子(container Lifecycle Hooks)，这是一种允许用户指定在容器生命周期的特定点上运行代码片段或命令的功能。

容器生命周期钩子主要包括以下两个部分:
Poststart:这个钩子在容器被创建之后立即调用，但需要注意的是，在钩子执行的时候容器内的主进程尚未启动。这可以用于执行一些初始化任务，比如建立文件系统的缓存目录或其他类型的准备动作。

Prestop:这个钩子在发送信号给容器内的主进程之前调用，这意味着这是在容器被终止之前可以执行一些清理工作的最后机会。它常被用来做一些资源释放的工作，比如关闭已经打开的数据库连接或网络连接等。

在生产环境中，为了应用的安全和优化镜像的体积，业务镜像一般不会安装高危工具和并不常用的运维工具，比如 cur1、sed、awk、python 或 dig 等，同时建议使用非 root 用户去启动容器。但是某些应用启动之前可能需要检查依赖的服务有没有成功运行，或者需要更高的权限去修改一些系统级的配置，而这些检测或配置更改都是一次性的，所以在制作业务镜像时没有必要为了一次配置的变更去安装一个配置工具，更没有必要因为使用一次高权限而把整个镜像改成以root 身份运行。

考虑到上述问题和需求，Kubernetes 引入了初始化容器的概念，Init 容器具有与应用容器分离的单
独镜像，其启动相关代码具有如下优势:

Init 容器可以包含安装过程中应用容器中不存在的实用工具或个性化代码。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
Init 容器可以以 root 身份运行，执行一些高权限命令。
Init 容器相关操作执行完成后就会退出，不会给业务容器带来安全隐患。

由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足一组先决条件，Pod内的所有应用容器才会并行启动。

2. 延迟指定时间后启动

创建一个 pod，initcontainers 指定初始化容器，command:["sh","-c","sleep 15"]表示初始化容器需要休眠 15 秒。

创建后不断查看pod启动状态，15秒后会发现pod开始启动

3. 使用初始化容器修改内核参数

在容器里修改内核参数，实际上修改的就是物理机的内核参数，为了安全性，一般不允许在容器里修改内核参数，Seccomp 代表安全计算(Secure computing)模式，seccomp控制了容器能做哪些操作，添加 securitycontext 参数之后就可以修改内核参数了。

创建一个 pod，initcontainers 初始化容器里的 securitycontext:privileged:true 表示该容器具有特权，可以执行命令"sh","-c","/sbin/sysct1 -w vm.swappiness=0"，vm.swappiness 设置为8表示尽量少使用 swap 内存。

创建查看分配到那个节点上了

在分配的那个节点上查看swappiness值是否为0

4. 等待依赖服务启动

有时某些服务需要依赖其他组件才能启动，比如后端应用需要数据库启动之后，应用才能正常启动，此时需要检测数据库实例是否正常，等待数据库可以正常使用时，在启动后端应用，此时可以使用初始化容器进行控制。

(1)创建第一个Pod

该 Pod 内要依赖两个条件才能启动，一个是利用 busybox 容器检测 redis-service 服务是否生成第二个是检测 mysql-server 服务是否生成。

(2)创建一个被依赖的service

(3)创建第二个被依赖的service

这里可以发现，当把redis-service 和 mysq1-service 两个服务创建出来后，nginx 的 Pod 就正常运行了。

4. pause 容器

在 Kubernetes 中，pause 容器并不是指暂停容器的执行，而是指一个特殊的辅助容器，它被用于每个Pod 以帮助实现网络命名空间。pause 容器是 Kubernetes 中每个 Pod 的第一个容器，它的主要作用是作为 Pod 内所有其他容器共享网络命名空间的基础。

每个 Kubernetes Pod 都有一个 pause 容器，它是 Pod 的第一个容器，也是唯一必须运行的容器。即使 Pod 中的其他容器都停止了,，只要 pause 容器还在运行，Pod 就不会被 Kubernetes 认为是完全停止的。

(1)pause 容器的作用

网络命名空间:pause 容器为 Pod 内的所有容器提供了一个共享的网络命名空间。这意味着 Pod 内的所有容器都共享同一个 IP 地址和端口空间，从而使得它们可以直接通过 1ocalhost 或者其他指定方式相互通信。
网络接口:pause 容器负责设置 Pod 的网络接口,使得 Pod 内的容器能够通过这个接口访问外部网络。
稳定性:如果 Pod 中的所有声明的容器都被删除或停止，pause 容器将保持运行，从而保证 Pod 的网络命名空间不会丢失。这也意味着 Pod 的网络配置仍然保留，直到整个 Pod 被删除。
生命周期管理:pause 容器是一个非常简单的容器，其镜像只包含一个命令/pause，该命令实际上是一个无限循环，保持容器处于运行状态。它不执行任何业务逻辑，仅仅是作为 Pod 网络基础设施的部分。

(2)使用 pause 容器的好处

简化了 Pod 内的网络配置。
提高了 Pod 网络的一致性。
减少了管理 Pod 网络复杂性的开销。

总的来说，pause 容器对于实现 Kubernetes Pod 的网络功能至关重要，它是 Kubernetes 网络模型的一个核心组成部分。

(3)Pause 容器实现

Pod 里的多个容器怎么去共享网络?

比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 NetworkNamespace。在 Kubernetes 里的解法是这样的:它会在每个 Pod 里，额外起一个 Infra(基础)container 小容器来共享整个 Pod 的 Network Namespace。

Infra container 是一个非常小的容器，大概 700KB 左右，是一个 ( 语言写的、永远处于 “暂停”状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace的方式加入到 Infra container 的Network Namespace 中。

所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即:它们看到的网络设备、IP 地址、Mac 地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个Infra container。这就是 Pod 解决网络共享的一个解法。

在 Pod 里面，一定有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个Infra container 的 IP 地址。所以大家看到的都是同一份，而其他所有网络资源，都是一个 Pod份，并且被 Pod 中的所有容器共享。这就是Pod 的网络实现方式。

由于需要有一个相当于中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes 里面，它是允许去单独更新 Pod 里的某一个镜像的，即:做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。

查看nginx的pod运行主机

在分配到的那个节点查看pod中的pause容器

二. 临时容器Ephemeral Container

再生产环境中，为了优化镜像的体积和提高镜像的安全性，并不会在容器中安装太多高危工具。比如cur1、wget、dig 以及常用的 net-tools 等。这样做虽然提高了镜像的安全性，但是也带来了一些不便比如无法査看容器内的进程情况、无法査看容器内的链接情况、服务出了问题无法很方便的进行排査等。因为上述操作并非经常使用，所以我们并没有必要从一开始就安装这些工具，但是等到用他们的时候再安装也是一件很麻烦的事情，那么我们该如何处理这个问题呢?

为了解决这类问题，在 1.16 版本后，Kubernetes 引入了 Ephemeral containers 的概念，可以不用安装第三方工具即可实现在线 Debug 操作。

1:临时容器的概念

临时容器与其他容器的不同之处在于，临时容器是被临时添加到 Pod 上，用于在线调试应用的，他永远不会自动重启，因此不适用与构建应用程序，临时容器的声明和普通容器类似，但是临时容器没有端口配置，因此不能使用像 ports、livenessprobe、readnessProbe、resources 这样的字段，当然，临时容器只是用来调试程序的，它的状态不会影响其他正常容器，所以它并不需要这些字段配置。

临时容器使用 API 中一种特殊的 Ephemeral containers 处理器进行创建，而不是直接添加到pod.spec 字段，因此无法使用 kubectl edit 来添加临时容器，与常规容器一样，将临时容器添加到 Pod后，将不能更改或删除临时容器，但是当添加了临时容器的 Pod 重启后，临时容器就会被销毁。

因为临时容器是为了调试程序而设计的，所以在添加临时容器时，最好使用一个包含所有常用工具的镜像进行创建。当业务容器崩溃或容器镜像不包含调试工具而导致 kubectl exec 不可用时，临时容器对于交互故障排査和在线 Debug 很有用。尤其是在使用像不包含任何 shel1 和其他工具的 destroless 镜像作为基础镜像时，虽然可以减少攻击面和漏洞，但对于问题的排査会变得尤为棘手，此时临时容器就可以发挥很大的作用，带来诸多便利性。

创建好容器时里面命令是无法使用的

(3)为nginx的pod创建临时容器

备注:

tomcat-test:pod 的名字
--target=tomcat-java，pod 中源容器的名称
--image=busybox:1.28:该 pod 中临时容器使用的镜像

执行后稍等一会，能够进入 tomcat 容器的交互界面

(4)查看nginx-test这个pod是否已有临时容器

中间一部分省略

三. 自动扩缩容 HPA

在集群安装的过程中，我们可以安装一个叫 Metrics Server 的组件，该组件在集群中负责采集 Pod和 Node 的度量值指标，比如 Pod 的 CPU、内存使用率和节点的内存、CPU 使用率,而且安装的 Dashboard可以展示 CPU、内存信息也是依靠 Metrics Server 的。当然，该组件不仅仅是用来展示数据的，还可以使用 Metrics Server 提供的数据结合 Kubernetes 的 HPA 功能实现 Pod 的自动扩缩容。

1. 什么是 HPA

HPA(Horizontal Pod Autoscaler，水平 Pod 自动伸缩器)可以根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量。注意 HPA 不适用于无法缩放的对象,比如 Daemonset。

HPA 控制器会定期调整 RC或 Deployment 的副本数，以使观察到的平均 CPU 利用率与用户指定的目标相匹配。

HPA 需要 Metrics server获取度量指标,如果已经部署了Server，本节的实践部就分无Metr1cS须再次安装 Metrics Server。如果没有安装Metrics server，可以参考其他实验文档自行部署。

2. HPA 的工作原理

HPA 根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量
HPA 控制器会定期调整 RC(Replication controller)或 Deployment 的副本数，以使观察到的平均 CPU 利用率(或其他度量标准)与用户指定的目标相匹配。
HPA 需要 Metrics Server 获取度量指标，Metrics Server 负责采集 Pod 和 Node 的度量值指标，如 CPU、内存使用率等。

3. HPA 的工作流程

配置 HPA:使用 kubectl autoscale 命令为 Deployment、Replicaset 或 Statefulset 等资源创建 HPA 对象，并指定目标 CPU 利用率、最小副本数和最大副本数。
度量指标采集: Metrics Server 定期采集 Pod 和 Node 的度量值指标，并将这些数据提供给 HPA控制器。
伸缩决策:HPA 控制器根据当前 Pod 的度量指标和目标利用率进行比较，如果当前利用率高于目标利用率，则增加 Pod 副本数;如果当前利用率低于目标利用率，则减少 Pod 副本数(在最小副本数和最大副本数之间调整)
Pod 伸缩:Kubernetes 根据 HPA 控制器的决策自动调整 Pod 的副本数，以实现自动扩缩容。

4. HPA 的应用场景

应对流量波动:在 web 服务中，流量可能会随时间变化而波动。HPA可以根据流量变化自动调整Pod 副本数，以确保服务的稳定性和响应速度。
资源优化:通过自动扩缩容，HPA可以在保证服务质量的同时最大化资源利用率，降低运营成本

5. HPA 实践--实现 web 服务器的自动伸缩特性

在生产环境中，总会有一些意想不到的事情发生，比如公司网站流量突然升高，此时之前创建的 Pod已不足以支撑所有的访问，而运维人员也不可能 24 小时守着业务服务，这时就可以通过配置 HPA，实现负载过高的情况下自动扩容 Pod 副本数以分摊高并发的流量，当流量恢复正常后，HPA 会自动缩减 Pod 的数量。

测试实现一个 Web 服务器的自动伸缩特性

(1)首先用Deployment 启动一个Nginx 服务(须配置 requests 参数)

(2)配置nginx-server的Service

(3)使用kubectl autoscale命令创建HPA

此 HPA 将根据CPU的使用率自动增加和减少副本数量，上述设置的是 CPU 使用率超过 10%(--cpu-percent 参数指定)就会增加 Pod 的数量，以保持所有 Pod 的平均 CPU 利用率为 18%,允许最大的 Pod 数量为 10(--max),最少的 Pod 数为1(--min)。