Kubernetes 是什么：从控制循环理解容器编排

Kubernetes 是管理容器化工作负载和服务的开源平台。你声明希望使用的应用镜像、副本数量和访问方式，Kubernetes 的控制组件持续观察集群，让实际状态接近期望状态。容器运行应用，Kubernetes 则管理应用周围的部署、调度和更新过程。

理解这层分工，比记住组件名称更重要。Kubernetes 可以调度 Pod、替换失败的工作负载实例、协调滚动更新，并通过 Service 为不断变化的 Pod 提供访问抽象；它不会替你构建源代码，也不能保证订单金额正确、所有网络和存储故障都能自动恢复。它同样不指定唯一的日志或监控后端。官方概述同时说明了这些能力与边界。

本文面向需要理解控制循环、选择工作负载类型或判断是否采用 Kubernetes 的工程师。文章由观测云编辑部依据官方文档编写，决策表和排障顺序是编辑整理的方法，不是 Kubernetes 项目的官方采用标准。下文的故障实验尚未执行，没有实测恢复时间或产品性能结论。

先分清四件事

• 镜像、容器和 Pod 不同。 镜像封装应用及依赖，容器是基于镜像运行的实例。Pod 是 Kubernetes 创建和管理的最小可部署计算单元，可以包含一个或多个紧密协作、共享网络与存储上下文的容器。
• 期望状态不等于业务正确。 控制器可以按声明维持三个 Pod，却不能据此证明支付、权限判断或数据库写入正确。
• 自愈有条件。 重启和替换受策略、健康检查及资源条件约束。不断重启并不能修好代码缺陷。
• Service 不是可用性证明。 稳定的访问入口仍需要可用后端、有效路由、健康依赖和正确的应用响应。

从控制循环理解 Kubernetes

Kubernetes API 中的对象表达运行意图。对于同时包含这两个字段的对象，spec 描述期望状态，status 记录组件报告的实际状态。控制组件持续处理二者的差异，具体语义见对象模型。

用户或自动化声明期望状态
          ↓
Kubernetes API 对象（spec）
          ↓
控制器观察并调整实际状态
          ↓
工作负载控制器按需创建或替换 Pod
          ↓
调度器为尚未分配 Node 的 Pod 选择节点
          ↓
kubelet 通过容器运行时运行容器
          ↓
status、条件和事件反映当前进展
          └────────→ 继续协调

应用和用户结果 → 指标、日志、链路与请求检查
              → 团队修正代码、配置、策略或声明

上半部分是平台协调过程，下半部分是团队判断业务是否正确的证据路径。它们相关，但不是同一件事。图中箭头表示逻辑关系，不是所有网络调用的固定时序。

例如，一个 Deployment 声明 replicas: 3，当前只有两个符合要求的 Pod，控制器可以创建第三个。若新 Pod 拉不到镜像，期望副本数仍是三个，但可用副本可能不足。Kubernetes 会暴露差异，不会替你猜测正确的镜像地址。

这些组件独立地重复协调，而不是中央程序依次执行完一串步骤就结束。如果声明本身有误，反复重试也需要团队修改声明才能解决。

控制平面、节点和 Pod

官方组件文档将集群分为控制平面和工作节点。实际部署位置及托管责任可能不同，但组件职责可以这样理解。

Pod 中的容器共同调度到同一节点。Pod 本身是临时实体；需要替换时，控制器通常创建新的 Pod，而不是把同一个 Pod 身份搬到另一台机器。详见 Pod 生命周期。

托管 Kubernetes 可以转移部分控制平面运维工作，但工作负载、身份权限、网络策略、数据保护、遥测和事故响应的责任仍需按具体服务与合同划分。

按生命周期选择工作负载

工作负载资源的差异，主要在于身份、完成条件和运行方式。

数据库放进 StatefulSet，不代表已经有备份；Agent 的 DaemonSet 显示可用，也不代表数据已经到达存储。先明确身份、数据、放置和失败要求，再选资源类型。

Service 放在哪一层

Service描述一组逻辑后端及访问策略，后端通常是 Pod。Pod 地址随替换变化，客户端仍可以通过 Service 访问。

排查访问失败时，需要同时核对 selector、Pod 标签、EndpointSlice、readiness、端口和网络路径。Service 存在不能证明 DNS、网络策略、负载均衡、TLS、数据库或外部 API 都正常，更不能证明 HTTP 200 中的业务内容正确。

还要区分“EndpointSlice 有地址”和“后端可以接收普通流量”。未就绪的 Pod 仍可能出现在 EndpointSlice；ready、serving、terminating 是不同条件，publishNotReadyAddresses: true 还会影响 ready 的表示。具体依据见 EndpointSlice 文档。

平台自动化之后，团队还要负责什么

自愈文档说明了重启策略、工作负载替换及存储恢复的边界。Deployment 文档也明确：更新停滞时平台报告状态，不能假定它必然自动回滚代码和数据。

平台收敛与业务成功要分别验证

下面是用于说明边界的假设，不是实测结果。

因此，一次恢复确认至少需要平台证据与业务结果两部分。前者包括 spec、status、条件、事件和 EndpointSlice，后者包括真实请求、业务不变量、日志、链路、应用指标或用户体验。

一个尚未执行的故障实验

这个实验计划用于观察：错误镜像声明怎样造成期望与实际状态的差异，恢复原镜像后平台及请求结果如何变化。本文没有运行或独立复现此实验，没有可报告的输出或恢复时间。

执行前应使用隔离的非生产集群，并记录 Kubernetes 精确补丁版本、kind 或同类工具版本、运行时、宿主机系统及架构。所有镜像使用不可变 digest，副本数和更新策略显式写入清单，保存清单校验值、时间与命令版本。公开记录不得包含凭证、kubeconfig、客户标识或内部地址。

实验步骤如下，不能将预期当作结果：

1. 在隔离 namespace 中部署一个最小应用及 ClusterIP Service，用已核对的镜像 digest，并定义包含预期响应内容的请求检查。
2. 保存健康基线：清单、Deployment 状态、Pod 条件、Service 与 EndpointSlice、事件、更新状态、应用响应和退出码。
3. 仅将 Deployment 镜像改为故意不可用的测试引用，不同时改动探针、副本、selector 或 Service。
4. 记录替代 Pod 无法就绪时的 Deployment、ReplicaSet、Pod 状态与事件，以及实际请求结果。
5. 恢复原镜像 digest，再记录就绪状态、EndpointSlice 与请求结果。不要预先认定请求必然中断，旧的 Ready Pod 可能仍在服务。
6. 删除实验 namespace，确认集群中没有残留资源或临时凭证；需要保留的脱敏证据单独存放。

常见的工作假设是出现 ErrImagePull 或 ImagePullBackOff，但仓库策略、缓存、准入规则、运行时和 Kubernetes 版本会影响具体表现，必须以实际记录为准。

以下是拟使用的只读采集命令，<recorded-pod-name> 需替换为当次记录的 Pod 名称：

kubectl -n k8s-definition-lab get deployment,replicaset,pod,service,endpointslice -o wide
kubectl -n k8s-definition-lab describe deployment demo
kubectl -n k8s-definition-lab describe pod <recorded-pod-name>
kubectl -n k8s-definition-lab get events --sort-by=.metadata.creationTimestamp
kubectl -n k8s-definition-lab rollout status deployment/demo --timeout=120s

这些命令不能证明业务正确。实验还需要实际请求及预期响应、脱敏原始输出，并由第二位工程师按相同输入复现。若结果不同于假设，应报告差异。

为什么仍然需要可观测性

官方可观测性文档把组件与应用的指标、日志和链路作为理解系统状态的证据。组件能输出信号，不等于集群已经统一存储、保留和关联它们。

排障时可以分三层：集群和节点证据用于判断平台是否具备运行条件；对象和工作负载证据用于定位协调在哪里受阻；应用和用户证据用于确认服务实际是否正确。Kubernetes 组件可以暴露 Prometheus 格式的指标，kube-state-metrics 提供对象状态信息，但端点权限、稳定性、采集与保留仍须配置。需要集中历史日志时，也必须将日志保存到容器生命周期之外。

Pending 包括等待调度和调度后的镜像下载，不能直接归因于 scheduler。关联三层证据时，应保留集群、namespace、工作负载、Pod、容器、服务、环境、版本和 trace 上下文；不要为了关联而采集凭证、个人资料或无限增长的用户标识。

是否值得采用 Kubernetes

下面是条件式决策表，不是打分排名。安全、数据恢复或责任归属的缺口，不能用其他项目的几个“是”抵消。

当问题明确、资源模型合适、责任人到位，且关键安全与恢复条件可验证时，再推进有界原型。若只增加控制平面、网络、存储和升级负担，却没有解决实际问题，应比较更简单的容器或应用平台。

部署地点也是选型的一部分。应逐项核对实际区域、可用区、数据路径、流量费用、支持覆盖和跨境要求。其他地区的服务说明，不能直接证明目标地区的可用性或合同条件；这些需要在具体供应商评估中确认。

下一步

理解组件后，可以继续阅读官方的组件、工作负载及 Service 文档。

在观测云中实施采集时，先核对 Kubernetes 集成、Prometheus 自动发现与 ServiceMonitor / PodMonitor 支持字段。对象查看方式见容器基础设施文档。这些资料说明产品的配置路径，不是所有环境都已验证的证明。

需要评估商业监控方案时，再参考观测云 Kubernetes 监控，用自己的集群核对权限、标签、信号缺失、延迟和回滚。

资料依据

技术机制于 2026 年 10 月 27 日对照 Kubernetes 官方英文文档复核；本文是文档型指南，未运行上述实验。

• Kubernetes 概述、对象和控制器
• Pod 生命周期、工作负载及 Deployment
• Service、EndpointSlice和探针
• 自愈边界与可观测性