k8s（五） - 技术栈

文章目录

前言
一、pod基础知识
- [1.1 pod定义](#1.1 pod定义)
- [1.2 Pause 容器](#1.2 Pause 容器)
- [1.3 Pod 中的共享资源](#1.3 Pod 中的共享资源)
- [1.4 pod的类型](#1.4 pod的类型)
- [1.5 pod容器](#1.5 pod容器)
- - [1.5.1 pod容器分类](#1.5.1 pod容器分类)
- [1.5.2 初始化容器的作用](#1.5.2 初始化容器的作用)
- - [1.5.3 容器启动顺序](#1.5.3 容器启动顺序)
  - [1.5.4 案例](#1.5.4 案例)
  - [1.5.5 Pod 的镜像拉取策略](#1.5.5 Pod 的镜像拉取策略)
  - [1.5.6 Pod 的重启策略](#1.5.6 Pod 的重启策略)
二、pod资源限制
- [2.1 资源类型与单位](#2.1 资源类型与单位)
- [2.2 案例](#2.2 案例)
三、探针（健康检查）
- [3.1 探针的类型](#3.1 探针的类型)
- [3.2 容器生命周期流程](#3.2 容器生命周期流程)
- [3.3 三种检查方法](#3.3 三种检查方法)
- - [3.3.1 exec（命令）](#3.3.1 exec（命令）)
  - [3.3.2 httpGet方式](#3.3.2 httpGet方式)
  - [3.3.3 tcpSocket方式](#3.3.3 tcpSocket方式)
- [3.4 pod容器的状态分类](#3.4 pod容器的状态分类)
总结

前言

本文学习pod的一些知识点，包括pod的概念，pod的创建的资源限制，pod的重启策略与拉取镜像策略，以及pod的健康检测（探针）等。

一、pod基础知识

1.1 pod定义

Pod 是 Kubernetes 中的最小部署单元，它代表集群中的一个运行进程。一个 Pod 可以包含一个或多个紧密耦合的容器，这些容器共享网络和存储资源。在 Kubernetes 中，Pod 是管理容器的基础结构，其他如 Deployment、StatefulSet、DaemonSet 等控制器对象都围绕 Pod 进行扩展。

pod是最小部署单位，用于放置应用容器，一个pod可以存放多个容器，同一个pod的容器可以网络联通（在同一个网段，并且在同一个命名空间）

1.2 Pause 容器

用来提供 Pod 的 Linux 命名空间基础。它使得 Pod 内的所有容器共享网络和存储资源。Pause 容器运行时，它会创建一个 Linux 命名空间，其他容器将共享该命名空间来进行网络通信和存储操作。

1.3 Pod 中的共享资源

网络共享：

每个 Pod 分配一个唯一的 IP 地址，Pod 内的所有容器共享该 IP 和端口。它们能够通过localhost 进行通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）

① 每个pod 分配一个独特IP地址

② pod 内部所有容器共享这个IP和端口，能通过 localhost直接通信

③ 与外界通信时, 必须使用宿主机的端口映射

存储共享：

Pod 可以指定多个共享的 Volume，这些 Volume 可以被 Pod 内的所有容器访问，确保容器重启后数据不会丢失。

① Pod可以指定多个共享的Volume，所有容器都可以访问

② Volume可以用来持久化存储，确保容器重启后数据不会丢失

1.4 pod的类型

1、自主式pod（静态pod），这种 Pod 不具备自我修复的能力。如果它所在的节点故障，Pod 会被删除，且不会自动恢复。

2、通过控制器器管理的pod：Kubernetes 中通常通过控制器（如 Deployment、StatefulSet）来管理 Pod。控制器提供副本管理、滚动升级、自动修复等功能。

1.5 pod容器

1.5.1 pod容器分类

1、应用容器：在容器中是核心容器，其他容器负责辅佐应用容器运行，在整个pod中必须要有至少一个应用容器，例如：nginx、tomcat、redis等

2、初始化容器：用于辅助应用容器运行的的容器，在pod中可以没有或有多个初始化容器，一般为配置环境、工具等

1.5.2 初始化容器的作用

因为init容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

1、Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。

2、Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

3、应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

4、Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

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

1.5.3 容器启动顺序

先创建并运行初始化容器在运行应用容器，初始化容器的启动原则是串行启动，需要先启动第一个初始化容器，并且等第一个初始化容器停止后再启动第二个，直到所有初始化容器启动完毕并停止后才会启动应用容器，如果在初始化容器过程中init容器失败，会从头重新启动容器，直到容器创建成功（always重启策略），并且在启动应用容器时为并行启动策略，也就是说同时启动所有应用容器，没有先后之分。

1.5.4 案例

编辑创建容器的yaml文件

（可以看到初始化容器始终没有完成）

kubectl logs myapp-pod -c init-myservice ------------------------------通过查看第一个初始化容器的创建日志来寻找问题

（没有配置service）

（创建完成）

1.5.5 Pod 的镜像拉取策略

1、IfNotPresent （默认）：如果本地已有镜像，不会拉取新的镜像，仅在本地缺失时拉取。

2、Always ：每次启动 Pod 时都会拉取镜像。

3、Never ：不拉取镜像，仅使用本地镜像。

1.5.6 Pod 的重启策略

1、Always ：无论容器的退出状态如何，都会重新启动。

2、OnFailure ：只有容器非正常退出（即退出码非 0）时，才会重启容器。

3、Never ：容器退出后不会重启。

二、pod资源限制

2.1 资源类型与单位

在 Kubernetes 中，为了合理管理集群中的资源，容器的 CPU 和内存资源都可以设置请求值（requests）和限制值（limits）。这些设置确保了容器的资源分配和限制，避免资源争用和过度使用。

资源请求与限制（Request和Limit）

请求（request）：当容器启动时，Kubernetes 会根据容器的资源请求来决定容器应该调度到哪个节点上。这个值表示容器在运行时最少需要的资源。

限制（limit）：容器在运行时可以使用的最大资源量。如果容器超过了这个限制，Kubernetes 会采取措施来控制容器的资源使用，防止过度消耗。

在 Kubernetes 中，CPU 的单位表示方式如下：

1、1 CPU = 1 vCPU（或 1 核心超线程）

2、CPU 请求和限制使用 "m"（毫核）作为单位。

3、带小数的 CPU 也是支持的，表示容器能获得的 CPU 时间片。例如， 0.25 表示该容器最多可以使用一个 CPU的四分之一。

内存的单位有两种表示方式：

十进制单位：如 1Gi , 1Mi , 1Ki ，分别为 1024Mi , 1024Ki 。Kubernetes 的内存限制通常使用这些基于 2 的指数单位。

十进制单位：如 1GB , 1MB 等，表示为以 10 为底的单位。

如果在创建容器时，达不到资源的最低要求，容器创建状态为pendin

2.2 案例

第一步创建yaml文件，并修改资源使资源达不到创建标准

当将资源设置到合理范围时，尝试创建容器

kubectl describe pod nginx ------------------------------查看该容器的详细信息

三、探针（健康检查）

3.1 探针的类型

1、启动探针：用于判断容器是否正常开启，如果探针返回结果为失败，则kubelet会立马删除该容器，且在启动探针运行过程中，其余探针不能运行，必须等启动探针检测结果通过后才可以。

2、就绪探针：用于判断容器是否准备好接受请求。如果探测失败，控制器control-manager会将与此pod同步的所有svc的endpoints中删除对应pod的ip，也就是断开同步，但是容器可以正常创建。

3、存活探针：用于判断容器是否正常创建并运行，如果探测结果为失败，kubelet会将pod杀死。

4、停止探针：用于容器正常停止，避免强制删除容器导致的数据丢失、服务中断，确保应用生命周期的完整性。

3.2 容器生命周期流程

第一步初始化容器，并行的方式来创建应用容器所需的配置环境、工具等

第二步创建并运行应用容器

第三步启动探针进行健康检测，主要检测容器是否可以正常启动，应用容器是否可以正常运行。

第四步就绪探针进行健康检测，检测容器是否可以接受请求，如果不能，控制器（control-manager）会将所有与该pod同步的svc断开该pod的连接，也就是在svc的endpoints中删除pod的ip地址。

第五步存活探针进行健康检测，主要作用是定期检测容器是否正常创建并运行，如果检测结果为失败，则kubelet会将此pod删除。

第六步优雅退出，用于容器的正常退出，避免强制删除容器导致的数据丢失、服务中断，确保应用生命周期的完整性。

3.3 三种检查方法

3.3.1 exec（命令）

简单来说就是在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

接下来将会举一个案例（通过exec检查方法使用存活探针）

该yaml文件大致原理为：在创建容器时同时创建一个文件，并且让生命探针去检测此文件是否有，前30秒文件存在，因此检测成功，30秒之后删除文件，文件不存在，因此检测失败，kubelet会删除该pod，并重新创建一个新pod，因此我们只需要查看30秒之后pod的状态有没有发送改变即可。

failureThreshold: 1 ------------------------------------------检查失败之后，重建次数

initialDelaySeconds: 5 ------------------------------------------第一次检测前要等5秒

periodSeconds: 5 ------------------------------------存活检测间隔时间

timeoutSeconds: 1---------------------------------------超时时间，默认为1，就比如说要是查找该文件时，1秒钟之内还是找不到文件就会返回检测失败。

3.3.2 httpGet方式

原理：直接向pod容器发送请求，如果状态码为200到400之间则为健康，400以上则检测失败

案例：

port: http ------------------------------------------默认端口为80

path: /index.html ------------------------------------------请求路径为index.html

initialDelaySeconds: 1 ------------------------------------------第一次检测要等1秒

periodSeconds: 3 ------------------------------------检测间隔时间为3秒

timeoutSeconds: 10 ---------------------------------------超时时间为10秒

由于容器中存在index.html文件，因此容器会正常启动

删除index.html之后再查看pod状态

kubectl exec -it nginx-httpget -- rm -rf /usr/share/nginx/html/index.html ------------------删除容器中index.html文件

这里可以发现详细信息中显示无法找到页面，导致重建pod

3.3.3 tcpSocket方式

这种方式的主要原理就是与容器尝试建立指定端口连接，如果无法连接，就说明检测失败。

这里我们案例的原理是：指定容器中nginx的端口为80，而检测的端口不为80，使在连接端口时无法找到端口，从而连接失败，检测失败。

在pod详细信息可以看到，端口连接被拒绝，因为8080端口在容器中并没有开启。

3.4 pod容器的状态分类

1.Pending（挂起中）

含义：Pod已被Kubernetes API接受，但尚未完成调度或容器启动

典型场景：

1、等待调度到合适节点（资源不足、节点选择器不匹配等）

2、正在下载容器镜像（特别是大体积镜像）

3、等待存储卷绑定（PVC未完成绑定）

总结

本文学习pod的一些知识点，包括pod的概念，pod的创建的资源限制，pod的重启策略与拉取镜像策略，以及pod的健康检测（探针）等。