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

k8s pod深度解析

news 2025/7/1 5:04:43

目录

1：从使用的角度来看

2：从k8s的角度来看

3：pod的状态

二：pod探针

1：pod探针的实现方式

2：容器状态

3：pod探针类型

（1）存活探针

（2）就绪探针

（3）启动探针

三：pod镜像拉取策略和重启策略

1：镜像拉取策略

2：重启策略

1. Always（始终重启）

2. OnFailure（失败时重启）

3. Never（从不重启）

四：创建一个简单的pod

1：编写一个简单的pod

2：编写pod配置文件

3：pod文件语法

4：运行kubectl create命令创建pod

5：查看已经创建的pod

6：查看pod详细创建信息

7：删除pod

五：pod的基本用法

六：静态pod

七：pod启动过程与运行状态

八：故障排除步骤

一：什么是pod?

Pod 是 Kubernetes（K8s）中最小的部署和管理单元，它代表着一组紧密关联的容器集合，这些容器共享网络、存储等资源，共同完成特定的应用功能。

1：从使用的角度来看

  • 应用逻辑单元：Pod 可视为单个应用的实例，即使应用仅包含一个容器，也需运行在 Pod 中。例如，部署一个 Web 服务时，通常将该服务的容器放入 Pod 内。
  • 资源共享与协同：Pod 内的容器共享网络命名空间（IP 和端口）、存储卷（Volume）等资源。如一个 Web 容器与日志收集容器可共享数据卷，日志容器直接读取 Web 容器产生的日志文件。
  • 部署与扩展的基本单位：K8s 通过操作 Pod 实现应用的部署、扩缩容、滚动更新等。用户可通过 YAML 文件定义 Pod 的规格（如镜像、资源限制等），并提交给 K8s 集群执行。

2：从k8s的角度来看

  • 抽象层设计：K8s 不直接管理单个容器，而是通过 Pod 封装容器，简化集群管理复杂度。例如，Pod 可定义为 “运行 MySQL 主从实例的一组容器”，K8s 仅需管理该 Pod 对象，而非两个独立容器。
  • 调度与编排载体：Pod 是 K8s 调度的最小单位，集群根据资源需求、节点亲和性等策略将 Pod 调度到具体节点。每个 Pod 在节点上作为一个整体运行。
  • 与其他资源的关联：
    • ReplicaSet（副本集）：确保指定数量的 Pod 副本运行，用于实现应用的高可用性和扩缩容。
    • Deployment（部署）：通过管理 ReplicaSet 来控制 Pod 的滚动更新、回滚等生命周期操作。
    • Service（服务）：为 Pod 提供稳定的网络入口，通过标签选择器关联一组功能相同的 Pod。

3：pod的状态

Pod 的状态可通过kubectl get pods或kubectl describe pod <pod-name>查看，主要状态及含义如下：

（一）生命周期阶段（Phase）

状态说明
PendingPod 已被 K8s 接收，但尚未在节点上启动（如等待调度、拉取镜像等）。
RunningPod 已绑定到节点，所有容器已启动，至少一个容器正在运行或准备运行。
SucceededPod 内所有容器已成功执行并退出，且不会再重启。
FailedPod 内所有容器已退出，但至少有一个容器退出时失败（返回非零状态码）。
Unknown无法获取 Pod 状态（通常因与节点通信失败导致）。

（二）容器状态（Container State）

每个容器在 Pod 中可能处于以下状态：

  • Waiting：容器正在等待启动，常见原因包括：
    • 镜像拉取中（ContainerCreating子状态）。
    • 依赖的资源未就绪（如 Secret、ConfigMap 未加载）。
  • Running：容器已启动并运行，处于正常工作状态。
  • Terminated：容器已退出，可通过kubectl logs或describe查看退出原因：
    • 正常退出：容器完成任务后主动停止（如批处理作业）。
    • 异常退出：容器因错误崩溃（如代码异常、OOM Kill），K8s 会根据重启策略（restartPolicy）决定是否重启。

（三）常见状态事件（Events）

  • Pulling image：K8s 正在拉取容器镜像。
  • Created container：容器已创建。
  • Started container：容器已启动。
  • Failed to pull image：镜像拉取失败（如仓库认证错误、镜像不存在）。
  • OOMKilled：容器因内存不足被系统终止。
  • Back-off：容器重启失败后，K8s 等待一段时间再重试（退避策略）。

二：pod探针

1：pod探针的实现方式

Pod 探针通过容器内的检测机制监控应用状态，主要实现方式包括：

  • 命令检测（Exec Action）：在容器内执行指定命令，根据命令返回值（0 表示成功，非 0 表示失败）判断状态。
    ▶ 示例：执行cat /app/health.txt，若文件存在则返回成功。
  • HTTP 请求检测（HTTP Get Action）：向容器内指定端口的 URL 发送 HTTP 请求，根据响应状态码（2xx 或 3xx 表示成功）判断。
    ▶ 示例：访问http://localhost:8080/health，若返回 200 则正常。
  • TCP 连接检测（TCP Socket Action）：尝试与容器指定端口建立 TCP 连接，若连接成功则状态正常。
    ▶ 示例：检测端口8080是否可连接，用于判断服务是否启动。

2：容器状态

探针通过持续检测，将容器状态划分为：

  1. Running（运行中）：容器已启动，探针检测通过。
  2. Failed（失败）：探针检测失败，容器可能异常或未正常响应。
  3. Waiting（等待）：容器未完全启动，或探针未开始检测（如启动初期）。
  4. Unknown（未知）：探针无法获取状态（如网络故障、容器未启动）。

3：pod探针类型

（1）存活探针

  • 作用：判断容器是否 “存活”，若检测失败，kubelet 会重启容器，尝试恢复应用。
  • 应用场景：
    ▶ 处理临时故障（如内存溢出后重启），避免因容器卡死导致服务不可用。
  • 配置示例：
livenessProbe:exec:command: ["sh", "-c", "pidof myapp"]  # 检测进程是否存在initialDelaySeconds: 10  # 启动10秒后开始检测periodSeconds: 5  # 每5秒检测一次

（2）就绪探针

  • 作用：判断容器是否 “准备就绪”，若检测通过，Pod 会被加入服务的负载均衡后端；失败则从负载均衡中移除。
  • 应用场景：
    ▶ 确保服务完全启动（如数据库连接初始化完成）后再接收流量，避免请求失败。
  • 配置示例：
readinessProbe:httpGet:path: "/health"port: 8080timeoutSeconds: 3  # 超时时间3秒successThreshold: 1  # 1次成功即认为就绪

（3）启动探针

  • 作用：针对启动缓慢的容器，替代存活探针优先检测，避免因启动时间长被误判为失败而反复重启。
  • 应用场景：
    ▶ 大数据服务、AI 模型加载等启动耗时较长的场景。
  • 配置示例：
startupProbe:tcpSocket:port: 9090failureThreshold: 30  # 允许30次失败（延长检测周期）periodSeconds: 10  # 每10秒检测一次

三：pod镜像拉取策略和重启策略


1：镜像拉取策略

镜像拉取策略重启策略典型场景
AlwaysAlways开发环境微服务，需频繁更新和高可用
IfNotPresentOnFailure生产环境批处理任务
NeverNever离线一次性脚本任务

2：重启策略

重启策略用于控制 Pod 内容器的重启行为，主要有以下三种：

1. Always（始终重启）
  • 策略描述：无论容器因何种原因退出（正常 / 异常），Kubernetes 都会自动重启容器。
  • 适用场景：
    • 长期运行的服务（如 Web 服务器、数据库），确保服务高可用。
    • 容器意外崩溃时，自动恢复服务。
2. OnFailure（失败时重启）
  • 策略描述：仅当容器以非零状态码（异常）退出时，才会重启容器；若容器正常退出（状态码为 0），则不重启。
  • 适用场景：
    • 批处理任务（如数据处理 Job），正常完成后无需重启。
    • 容器因错误崩溃时自动重试，正常结束时不重复执行。
3. Never（从不重启）
  • 策略描述：无论容器如何退出，Kubernetes 都不会自动重启容器。
  • 适用场景：
    • 一次性任务（如临时脚本），执行完毕后无需维持运行。
    • 需要人工干预处理的异常场景，避免自动重启掩盖问题。

四：创建一个简单的pod

1：编写一个简单的pod

  • Pod 是 Kubernetes 中最小的调度单元，可包含一个或多个容器（通常为 1 个主容器 + 辅助容器）。
  • 示例场景：创建一个运行 Nginx 服务的 Pod。

2：编写pod配置文件

apiVersion: v1              # API 版本
kind: Pod                   # 资源类型为 Pod
metadata:name: nginx-pod           # Pod 名称labels:app: nginx              # 标签，用于筛选资源
spec:containers:- name: nginx-container   # 容器名称image: nginx:latest     # 容器镜像ports:- containerPort: 80     # 容器暴露端口resources:requests:memory: "128Mi"      # 内存请求cpu: "250m"          # CPU 请求limits:memory: "256Mi"      # 内存限制cpu: "500m"          # CPU 限制

3：pod文件语法

  • metadata：定义 Pod 的元数据（名称、标签、命名空间等）。
  • spec：定义 Pod 的核心规格，包括容器列表、资源限制、卷（Volume）、网络策略等。
  • status：运行时由 Kubernetes 自动填充，显示 Pod 的当前状态（如 IP 地址、容器状态等）。

4：运行kubectl create命令创建pod

  • 命令格式：kubectl create -f <配置文件路径>
  • 示例：kubectl create -f nginx-pod.yaml
  • 说明：-f 参数指定配置文件，Kubernetes 会根据文件内容创建 Pod。

5：查看已经创建的pod

  • 命令：kubectl get pods（默认查看当前命名空间下的 Pod）
  • 扩展：kubectl get pods -n <命名空间>（查看指定命名空间的 Pod）
  • 输出示例：

    plaintext

    NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          2m

6：查看pod详细创建信息

  • 命令：kubectl describe pod <pod名称>
  • 作用：获取 Pod 的详细状态、事件（Events）、调度节点、容器日志等信息，用于调试。

7：删除pod

  • 命令：kubectl delete pod <pod名称>
  • 说明：Pod 被删除后，若未通过控制器（如 Deployment）管理，将不会自动重建。

五：pod的基本用法

  1. 核心功能场景

    • 单容器 Pod：最常见的用法，如运行 Web 服务、数据库等单一功能组件。
    • 多容器 Pod：通过 “边车模式”（Sidecar）实现辅助功能，例如：
      • 主容器运行应用，边车容器负责日志收集、监控数据上报。
    • 共享资源：同一 Pod 内的容器共享网络命名空间（IP 地址、端口）和卷（Volume）。

  2. 常用操作命令

    • 进入 Pod 容器：kubectl exec -it <pod名称> -- /bin/bash
    • 查看容器日志：kubectl logs <pod名称> [-c <容器名称>]
    • 更新 Pod 配置：通常通过控制器（如 Deployment）实现，而非直接修改 Pod。

六：静态pod

  1. 定义与特点

    • 由 kubelet 直接管理（非通过 API Server），无需控制器即可运行。
    • 通常用于部署 Kubernetes 系统组件（如 kube-apiserver、etcd 等）。
    • 配置文件存放路径：/etc/kubernetes/manifests/（默认），kubelet 会定期监控该目录。

  2. 与普通 Pod 的区别

    维度静态 Pod普通 Pod
    管理方式由节点上的 kubelet 直接管理由 API Server 和控制器管理
    生命周期随节点启动而自动创建，删除需手动修改配置由控制器或用户命令创建 / 删除
    应用场景系统组件、节点级服务

七：pod启动过程与运行状态

  1. 启动流程（关键阶段）

    1. 调度阶段：Scheduler 选择合适的节点运行 Pod。
    2. 创建容器阶段：kubelet 在节点上拉取镜像、创建容器。
    3. 初始化容器（Init Container）：若定义了初始化容器，会先依次运行完毕。
    4. 主容器启动：主容器启动后，执行健康检查（Readiness Probe/Liveness Probe）。

  2. 常见状态（STATUS）

    • Pending：Pod 已创建，但镜像未拉取或节点资源不足。
    • Running：容器正在运行，健康检查通过。
    • CrashLoopBackOff：容器崩溃后重启，通常因代码错误或配置问题导致。
    • ImagePullBackOff：镜像拉取失败，检查镜像名称、仓库权限等。
    • Terminating：Pod 正在被删除，等待容器优雅关闭。

八：故障排除步骤

  1. 基础排查流程

    • 步骤 1：确认 Pod 状态
      kubectl get pods 查看状态，重点关注 READY 列（如 0/1 表示容器未启动）。
    • 步骤 2：查看详细事件
      kubectl describe pod <pod名称> 查看调度失败、镜像拉取错误等事件。
    • 步骤 3：检查容器日志
      kubectl logs <pod名称> 定位应用层错误（如代码异常、配置错误）。
    • 步骤 4：进入容器调试
      kubectl exec -it <pod名称> -- /bin/bash 检查文件系统、网络连接等。

  2. 典型故障场景与解决方案

    • 场景 1：Pod 无法调度
      • 原因：节点资源不足、节点标签不匹配（通过 nodeSelector 限制）。
      • 解决：释放节点资源或修改 Pod 的节点选择器。
    • 场景 2：容器反复重启（CrashLoopBackOff）
      • 原因：应用启动失败（如端口被占用、配置文件缺失）。
      • 解决：查看日志定位错误，修复应用或配置。
    • 场景 3：网络不通
      • 原因：Service 配置错误、网络插件（如 Calico）故障。
      • 解决：检查 Service 端口映射，重启网络插件或节点。
http://www.xdnf.cn/news/1074745.html

相关文章：

  • k8s创建定时的 Python 任务（CronJob）
  • 【c/c++1】数据类型/指针/结构体，static/extern/makefile/文件
  • 机器学习9——决策树
  • 新生代潜力股刘小北：演艺路上的璀璨新星
  • ROS常用的路径规划算法介绍
  • 面试复盘6.0
  • Java面试宝典：基础四
  • SpringSecurity6-oauth2-三方gitee授权-授权码模式
  • 详解快速排序
  • 宏任务与微任务和Dom渲染的关系
  • 左神算法之螺旋打印
  • Redis Cluster Gossip 协议
  • 在Linux系统中部署Java项目
  • 设计模式之装饰者模式
  • 2.安装Docker
  • 怎样学习STM32
  • 暴力风扇方案介绍
  • HarmonyOS实战：自定义表情键盘
  • FPGA实现CameraLink视频解码，基于Xilinx ISERDES2原语，提供4套工程源码和技术支持
  • llama.cpp学习笔记：后端加载
  • 图书管理系统练习项目源码-前后端分离-使用node.js来做后端开发
  • Conda 环境配置之 -- Mamba安装（causal-conv1d、mamba_ssm 最简单配置方法）-- 不需要重新配置CDUA
  • 领域驱动设计(DDD)【26】之CQRS模式初探
  • AlpineLinux安装部署elasticsearch
  • Kafka4.0初体验
  • Python爬虫：Requests与Beautiful Soup库详解
  • 重写(Override)与重载(Overload)深度解析
  • 【C++】C++中的友元函数和友元类
  • 71. 简化路径 —day94
  • Bugku——WEB篇（持续更新ing）