【云原生技术】Pod 列表新增时间字段:取值口径与获取方式

Pod 列表新增时间字段:取值口径与获取方式

下面给出 3 个时间字段的定义、取值规则、数据来源(K8s API)、边界情况。建议你在文档里把它们称为"创建时间 / 运行时间 / 就绪时间",避免一个"启动时间"引发歧义。


1) 创建时间(CreatedAt)

定义

Pod 对象在 K8s 中被创建并持久化的时间。

取值

  • CreatedAt = pod.metadata.creationTimestamp

数据来源

  • K8s API:GET /api/v1/namespaces/{ns}/pods(List Pod)或 GET pod

展示/说明

  • 一定有值(除非数据异常)
  • 不代表容器启动、也不代表可接入流量

2) 运行时间(RunningAt,建议叫"容器开始运行时间/首次运行时间/最近运行时间"要先定口径)

K8s 没有 Pod 级别统一 startedAt 字段,通常从容器状态推导。你需要在文档里明确口径,否则实现会不一致。

推荐口径(用于 Pod 列表最直观)

RunningAt = 业务容器中"最后一个进入 Running"的时间

即:在选定的业务容器集合中取最大值。

取值规则
  1. pod.status.containerStatuses[] 取每个容器的:
    • state.running.startedAt(容器处于 Running 时才有)
  2. 过滤规则(可选但强烈建议写清):
    • 默认只统计业务容器 ,不统计明显的基础设施 sidecar
      • 例如:istio-proxylinkerd-proxyvault-agent 等(你们平台若有固定名单,可配置化)
    • 如果无法区分业务/sidecar:则统计全部容器(简单但会导致"RunningAt 被 sidecar 影响")
  3. 聚合:
    • RunningAt = max(startedAt 列表)
  4. 若列表为空(如 Pending、ImagePullBackOff、CrashLoopBackOff 且未进入 Running):
    • RunningAt = null
数据来源
  • K8s API:Pod List/Get 返回的 status.containerStatuses
边界情况说明(文档要写)
  • 容器重启state.running.startedAt 会更新为"最近一次启动时间"。
    • 如果你们更想要"首次启动时间",K8s 原生字段不保证保留,需要平台侧记录(见下扩展)。
  • 多容器 Pod:按上述聚合规则取值。
  • 还没 Running:为空,前端可显示 "---/未运行"。

可选增强(如果你们需要"首次运行时间 FirstRunningAt"):平台做 watch 记录"第一次观察到任一业务容器进入 Running 的时间",写库或 annotation。


3) 就绪时间(ReadyAt,可服务时间,最接近"真的启动完成能接流量")

推荐口径

ReadyAt = Pod Ready 条件首次变为 True 的时间(首次可服务时间)

取值优先级(建议写成两级方案,便于落地)

方案 A(优先,若字段可用):直接取 condition 的时间

pod.status.conditions[] 找到:

  • type == "Ready"status == "True"
  • 取该条 condition 的时间字段(不同版本字段表现略有差异,文档里可以这么写):
    • 优先取 lastTransitionTime(Ready 从 False→True 的时间)
    • 若无/不可靠,可退化使用 lastProbeTime(但很多环境为空,不建议依赖)

若找不到 Ready=True:

  • ReadyAt = null

数据来源:Pod status.conditions(Pod List/Get)

方案 B(最稳,跨版本一致):平台侧记录 readyAt

如果你们发现 lastTransitionTime 不满足(缺失/不准确/不想受版本影响),就采用平台侧记录法:

  • 平台组件 watch Pod(informer)
  • 当检测到 Ready 条件首次 为 True 时:
    • 写入平台数据库 readyAt
    • 或写入 Pod annotation:platform.xxx/readyAt=RFC3339时间
  • Pod 列表展示优先使用平台记录值

边界情况说明

  • Ready=True 后又变 False(抖动)
    • "首次 ReadyAt"通常不变(表达首次可服务时刻)
    • 你们也可以另加"最近就绪时间 LastReadyAt"(需求没要求可不做)
  • 没有 readinessProbe:某些场景 Ready 可能很快 True(只代表 K8s 认为可用,不代表业务完全健康),需在文档里提示"Ready 取决于探针定义"。

建议在需求里明确的字段与返回结构(示例)

  • createdAt:string(datetime, RFC3339)
  • runningAt:string(datetime, RFC3339) | null
  • readyAt:string(datetime, RFC3339) | null
  • phase:Pending/Running/Succeeded/Failed/Unknown(辅助理解)

实现备注(你可放到"取数逻辑/伪代码")

  • createdAt:直接读
  • runningAt:
    • containerStatusesstate.running.startedAt
    • 过滤 sidecar(可配置)
    • 取 max
  • readyAt:
    • conditions 找 Ready=True 的 lastTransitionTime
    • 若缺失则为空(或采用平台记录)

相关推荐
DeeplyMind2 小时前
第27章 常见问题与解决方案
运维·docker·容器
nix.gnehc2 小时前
在K8s集群中部署Traefik并验证Python HTTP服务
python·http·kubernetes
!chen2 小时前
Ubuntu 上 Docker 的配置及代理
ubuntu·docker·eureka
ayaya_mana2 小时前
Linux一键部署Docker与镜像加速配置
linux·运维·docker
nix.gnehc2 小时前
深入浅出 K8s 内外部通信:全场景方案解析与生产实践
云原生·容器·kubernetes
市安3 小时前
基于 Alpine 构建轻量 Nginx 错误页面 Docker 镜像
运维·nginx·docker·alpine
DeeplyMind3 小时前
第26章 Docker监控与日志
docker·容器·eureka
DeeplyMind3 小时前
第25章 Docker安全
安全·docker·容器
努力搬砖的咸鱼3 小时前
用 Ingress 统一管理多个微服务的入口
微服务·云原生·容器·架构·kubernetes