“k8s经典版k8s经典”通常是在描述 Kubernetes 传统、基础的集群组织方式：由控制平面负责接收期望状态、安排调度并持续协调，再由工作节点运行容器化应用。这里的“经典”强调的是常见的组件分工和控制流程，不代表另有一套独立的产品机制。理解这套架构，关键是看清控制平面、节点、Pod，以及它们如何协同维持应用运行。
经典架构的核心：声明状态，持续协调
Kubernetes 并不是收到一次部署命令后就停止工作的启动器。使用者通过 API 提交应用希望达到的状态，例如运行多少个副本、使用什么镜像、容器需要多少资源；控制平面保存并处理这些声明，控制器持续比较“期望状态”和“实际状态”，发现差异后推动集群调整。某个容器异常退出时，系统可以重新创建工作负载；节点暂时不可用时，控制逻辑也会尝试让符合条件的副本在其他节点运行。
这种模式常被称为声明式管理。使用者描述目标，集群负责执行和维持目标，而不是逐个手工指定每个容器启动在哪台机器上。因此，经典 Kubernetes 的重点不只是容器编排，还包括统一 API、调度决策和持续的状态收敛。
控制平面如何分工
- kube-apiserver：集群操作的主要入口。命令行工具、控制器和其他组件通过 API 读取或修改对象；请求经过认证、授权和校验后，才会进入集群状态管理流程。
- etcd：保存集群的关键状态数据。API 服务借助它记录诸如工作负载定义、节点信息和配置对象等内容。它承担的是状态存储职责，不负责直接启动容器。
- kube-scheduler：为尚未绑定节点的 Pod 选择合适的工作节点。调度会考虑节点资源余量、Pod 的资源请求、约束条件和亲和性等因素；它作出放置决策，但不亲自运行容器。
- kube-controller-manager：运行多种控制器，让实际状态逐渐接近期望状态。例如副本控制器会关注工作负载副本数，在数量不足时推动创建新的 Pod。
这些组件的职责彼此衔接：API 服务接收并提供对象状态，etcd保存状态，调度器决定 Pod 的落点，控制器则不断观察差异并采取行动。控制平面并非替每个应用处理业务逻辑，而是管理集群资源和编排过程。
工作节点怎样承载应用
工作节点是实际运行 Pod 的机器。节点上的 kubelet 与控制平面通信，读取分配给本节点的工作负载，并确保对应容器按照 Pod 规格运行；容器运行时负责创建、启动和管理容器。kube-proxy 通常参与实现 Service 的网络转发规则，使访问流量能够抵达后端 Pod。具体网络实现还可能由集群采用的网络插件承担，因此“经典架构”描述的是职责关系，并不意味着所有集群都使用同一种网络实现。
Pod 是 Kubernetes 调度和管理的基本工作单元，里面可以包含一个或多个共享网络环境的容器。应用通常不会长期绑定到某个具体 Pod：Pod 可能因故障或更新而被替换，控制器则依据工作负载定义补足副本。Service 为一组符合选择条件的 Pod 提供相对稳定的访问入口，避免调用方必须追踪每个 Pod 的变化。
从提交工作负载到应用运行
以部署一个应用为例，使用者先提交描述镜像、副本数和资源需求等内容的工作负载对象。API 服务校验后保存对象；负责该工作负载的控制器观察到副本尚未建立，便创建相应 Pod。调度器为未分配节点的 Pod 选择节点，目标节点上的 kubelet 随后调用容器运行时启动容器。容器正常运行后，节点持续上报状态，控制器也继续比较实际副本数与声明值。
如果某个 Pod 退出，控制器会察觉副本不足并推动补建；新 Pod 获得节点后，Service 会依据当前符合条件的后端提供访问。由此可见，调度负责“放在哪里”，节点组件负责“运行起来”，控制器负责“持续保持目标”，而服务抽象负责“稳定地找到可用后端”。
“经典”这个说法的实际语境
在讨论入门架构、集群组件或容器编排原理时，“k8s经典版”往往是对上述常见结构的口语化概括。它适合用来区分基础的控制平面与工作节点模型，以及围绕 Pod、工作负载和 Service 展开的管理思路；单凭“经典”二字，并不能推导出特定部署环境、专有功能或独立发行版本。
掌握这套原理后，排查问题也更有方向：对象无法创建，可先看 API 请求和资源定义；Pod 长时间未运行，可关注调度条件与节点状态；容器启动失败，重点转向节点执行与容器状态；服务访问异常，则进一步检查 Service 选择条件和集群网络。换句话说，k8s经典版k8s经典所指的核心并非某个单独组件，而是声明状态、分工执行、持续协调这一整套集群运行逻辑。
