Kubernetes 架构入门：从一次应用部署认识组件与资源
在一台机器上运行容器时，我们可以直接启动进程、映射端口、挂载目录。机器增加后，还要决定应用放在哪里、故障后怎样恢复、扩容后流量如何到达新实例。Kubernetes 把这些工作拆成可协作的组件，并用 API 对象记录我们希望应用达到的状态。
本文从容器编排要解决的问题开始，再沿着一次部署请求认识控制平面、工作节点和常用资源。阅读时只需了解镜像与容器的基本概念；文中的 kubectl 查询命令需要已经配置好的集群访问凭据。
Kubernetes 负责什么
Kubernetes 简称 K8s，名称来自希腊语“舵手”。它是开源的容器编排平台，提供应用部署、调度、扩缩容和故障恢复等机制。它可以作为 PaaS 的基础，但日志平台、持续交付、完整监控和数据库备份等能力，通常还需要其他系统配合。官方对其定位和边界的说明见Kubernetes 概述。
Kubernetes 借鉴了 Google 在 Borg 等集群系统上的生产经验，2014 年开源，2015 年 7 月发布 1.0，随后加入 CNCF，2018 年成为 CNCF 毕业项目。学习架构时，比记住发展时间更有用的是理解它的声明式管理方式：提交期望状态，由组件不断比较现实与期望，再采取动作缩小差距。
从单机容器走向集群
单机 Docker 本身已有网络、卷、健康检查等能力。困难主要出现在多节点协作：一台宿主机不可用后，谁在其他机器重新创建实例；多个副本同时上线时，谁组织更新、服务发现和流量转发。
| 日常问题 | Kubernetes 提供的机制 | 还需配置的条件 |
|---|---|---|
| 容器退出或节点故障 | kubelet 重启容器，控制器按需创建替代 Pod | 控制器、资源容量与存储必须允许恢复 |
| 扩容后发现新实例 | Service 与 EndpointSlice 记录后端 | 标签、就绪状态和网络正确 |
| 发布新版本或回退 | Deployment 等控制器组织更新与回滚 | 探针、更新策略、镜像和应用兼容性合理 |
| 按负载增减容量 | HPA 调整副本，节点自动扩缩容器管理节点 | 指标系统和节点供应能力需另行接入 |
| 管理配置与数据 | ConfigMap、Secret、PVC 等 API | 存储、凭据保护与备份方案需单独设计 |
| 区分团队和环境 | Namespace、RBAC、配额与 NetworkPolicy | Namespace 本身不提供完整安全或网络隔离 |
Kubernetes 还能通过生命周期钩子、探针和资源限制管理应用运行过程。它提供健康检查的 liveness、readiness、startup 三类语义，具体可用的检查方式应按探针类型选择。滚动更新遵循控制器的更新策略、可用副本限制与就绪条件，并不保证所有新副本都先于旧副本启动。
开发和运维的工作发生了什么变化
对开发人员，统一日志入口能减少逐机登录；镜像与 CI/CD 流水线能让多环境发布更一致；Namespace 和声明式清单有助于复制环境。Service 等机制承担了一部分服务发现与负载均衡工作，Helm 等工具可以复用应用的安装参数。
对运维人员，镜像与清单减少了重复配置，控制器能处理部分实例故障，扩容也有统一 API。中间件可以借助 Helm 或 Operator 部署和管理。不过，“一键安装”并不等于已经完成高可用设计；备份还原、数据库容灾、端口与网络冲突仍需要工程判断。容器使用独立网络空间能减少部分端口冲突，hostNetwork、hostPort 等配置仍会受宿主机端口约束。
集群本身也增加了网络、证书、存储和版本维护的工作。日志采集、监控告警、链路追踪、DevOps 与服务网格等生态组件，是在明确需求后逐步补充的能力。
控制平面：保存状态并作出调度与协调决定
一个集群由控制平面和工作节点组成。控制平面负责 API、状态存储、调度与控制循环；工作节点提供 Pod 的运行环境。小型实验中，两种角色可以放在同一台机器上，生产环境则通常采用多实例控制平面。
kube-apiserver：API 入口
用户、控制器和节点通过 API server 读取或修改 Kubernetes 对象。API server 处理认证、授权、准入和对象校验，再把可持久化的集群状态保存到 etcd。它还提供 watch 接口，让组件观察资源变化。
对 Kubernetes API 对象的协作主要经由 API server，但不能理解成集群内所有网络通信都要由它转发。例如业务 Pod 之间直接通信，API server 也会主动访问 kubelet，控制平面组件还可能访问外部云 API。
etcd：集群状态存储
etcd 是分布式键值存储，也是控制平面的核心依赖。对于 Kubernetes 内置的 API 存储路径，通常由 API server 访问 etcd，其他组件通过 API server 访问对象，不能绕过 API 直接修改数据库。
etcd 使用多数派机制。生产集群常用 3 或 5 个成员，3 个成员能容忍 1 个成员故障，5 个能容忍 2 个；成员越多也会增加写入协调开销，因此无需为了高可用盲目增加数量。低延迟、可靠的磁盘和定期快照恢复演练都很重要。
kube-scheduler：为 Pod 选择节点
调度器观察尚未绑定节点的 Pod，按资源请求、亲和性、污点与容忍等条件筛选节点，再为候选节点评分。选择完成后，通过 API 绑定目标节点。容器的实际启动由该节点的 kubelet 与运行时执行。
“选择最合适节点”不表示总能放下 Pod。如果所有节点都不满足约束，Pod 会保持 Pending，事件中通常能看到资源不足或约束不匹配的原因。
kube-controller-manager：持续比较期望与实际状态
controller manager 运行多种控制器。例如 Deployment 控制器维护 ReplicaSet，ReplicaSet 控制器维护 Pod 数量。实际状态偏离目标时，相应控制器通过 API 创建、更新或删除对象。
在常见高可用部署中，scheduler 与 controller manager 的多个实例通过选主协作，通常由一个领导实例执行相应控制循环。领导信息可通过 Lease 对象观察：
kubectl get leases -n kube-system备用实例主要用于故障接替，简单增加实例数通常不会让同一控制循环按实例数成倍加速。组件职责见官方组件说明。云环境还可能运行 cloud-controller-manager，用于连接云负载均衡、节点和路由等接口。
kubeadm 如何运行这些组件
kubeadm 默认把 API server、scheduler、controller manager，以及本地 etcd 配置为静态 Pod。kubelet 配置中的 staticPodPath: /etc/kubernetes/manifests 指定了清单目录；kubelet 直接监视其中的清单并启动组件，不依赖 API server 先创建这些 Pod。
这个字段在 kubelet 的配置文件中，而不是每份静态 Pod 的 YAML 中。不要把备份清单也放进该监视目录，否则 kubelet 可能尝试加载它们。外部 etcd 或托管控制平面会采用不同部署方式。
工作节点：让 Pod 真正运行起来
kubelet 与容器运行时
kubelet 是节点代理，负责观察分配给本节点的 Pod，协调容器运行、卷挂载、探针以及状态上报。它通过 CRI 与 containerd、CRI-O 等运行时交互；运行时通常在创建 Pod sandbox 时协调 CNI 配置网络。CSI 驱动及其节点组件参与卷的挂载，控制器侧组件则可能负责供应和附加卷。
这种分工使 Kubernetes 不必直接实现每一种容器运行时、网络和存储系统。containerd 的具体调用链可结合 24-k8s基础-容器运行时-containerd.md 理解。
kube-proxy 与 Service 转发
kube-proxy 观察 Service 和 EndpointSlice 等资源，在节点上维护转发规则，让访问 Service 的流量到达后端 Pod。具体实现可能采用 iptables、IPVS 或 nftables，取决于集群版本与配置。它不是所有外部流量的唯一入口，也不负责创建或维护 EndpointSlice 对象。
有些网络方案可以替代其数据转发功能。例如启用并正确配置 Cilium 的 kube-proxy replacement 后，可以不再运行 kube-proxy；仅安装某个 CNI，并不自动意味着已经完成替代。
CoreDNS 与 Calico 等插件
CoreDNS 为集群提供 DNS 解析。普通 Service 名称通常解析到 Service IP，Headless Service 则可返回后端 Pod 地址；外部域名可转发给上游 DNS。
Calico 是一种网络方案，可为 Pod 分配 IP，并通过路由或封装等方式实现跨节点通信。实际数据路径受所选模式影响，不能把所有 Calico 集群都等同于同一种 Linux 转发配置。控制平面节点通常也有 kubelet 和运行时，是否运行 kube-proxy、网络插件和普通业务 Pod，取决于集群架构与污点配置。
一次 Deployment 请求经过哪些组件
理解职责后，可以把一次应用部署连接起来：
- 用户通过
kubectl提交 Deployment，API server 完成认证、授权、准入与校验，将对象保存到 etcd。 - Deployment 控制器观察对象，创建或调整 ReplicaSet；ReplicaSet 控制器创建缺少的 Pod。这些对象也通过 API server 持久化。
- scheduler 观察未调度的 Pod，为其选择节点，并提交绑定结果。
- 目标节点的 kubelet 观察到 Pod，协调存储，通过 CRI 调用运行时创建 sandbox 与容器，并上报状态。
- 配置了 Service 时，EndpointSlice 控制器根据选择器及 Pod 状态维护后端记录；kube-proxy 或替代实现据此更新转发规则。
这些步骤由不同控制循环异步完成。kubectl apply 返回成功，只代表 API 已接受对象，还需要观察调度、镜像拉取、就绪探针与应用本身是否正常。
用 API 资源表达应用
Pod 与控制器
Pod 是 Kubernetes 创建和调度的最小单元，可以包含一个或多个紧密协作的容器。它们共享网络空间，并能通过声明的卷共享文件。容器在原 Pod 中重启时，Pod 的身份可以保持不变；Pod 被删除后再创建，才是具有新 UID 的另一个对象。
直接创建的 Pod 没有上层工作负载控制器负责补副本。Deployment 等控制器创建的 Pod 被删除后，在控制器仍需要该副本的前提下会补建。标签与选择器负责匹配，ownerReferences 记录对象的所有权，不能只凭标签断定一个 Pod 归谁管理。
| 资源 | 管理重点 | 常见用途 |
|---|---|---|
| ReplicaSet | 维持所需副本数 | 通常由 Deployment 管理，不直接承担滚动升级编排 |
| Deployment | 管理 ReplicaSet 与版本发布 | 无状态服务的扩缩容、滚动升级和回滚 |
| StatefulSet | 稳定身份、顺序和存储关联 | 需要固定序号与独立持久卷的有状态应用 |
| DaemonSet | 每个符合条件节点一份 Pod | 节点日志、网络和监控代理 |
| Job | 跟踪有限任务的成功完成 | 一次性脚本、数据处理、备份 |
| CronJob | 按计划创建 Job | 定期备份、清理和报表 |
| HPA | 依据指标调整可扩缩目标的副本数 | 自动调整 Deployment 等资源的容量 |
服务、配置、存储和命名空间
Service 为一组后端提供稳定访问入口，EndpointSlice 记录后端地址；Endpoints 是历史接口，新设计应关注 EndpointSlice。Ingress 表达 HTTP/HTTPS 入口路由，需要 Ingress 控制器实现，Gateway API 则提供另一套网关资源模型。集群内部服务调用常被称为东西向流量，从外部进入应用的访问常被称为南北向流量。
ConfigMap 保存普通配置，Secret 保存需要受控访问的数据；Secret 的 Base64 编码不等于加密。PV 描述可用持久存储，PVC 表达应用的存储申请。
Namespace 提供资源名称与管理边界，大部分应用资源都属于命名空间。Pod 不能直接挂载另一命名空间的 ConfigMap，但跨命名空间网络访问通常默认可行；API 是否允许读取其他命名空间对象，取决于调用者身份与 RBAC。需要网络隔离时，还应配置受网络插件支持的 NetworkPolicy。
用 kubectl 查找资源类型
kubectl 通过 kubeconfig 找到 API server，并获取访问所需身份。kubeadm 管理员常在控制平面上使用 /etc/kubernetes/admin.conf，也可以把授权的 kubeconfig 放在 $HOME/.kube/config。admin.conf 具有很高权限，不应作为所有用户通用的配置分发；普通用户应领取与职责匹配的凭据。
kubectl config current-context
kubectl api-resourceskubectl api-resources 可以查询资源名称、缩写、API 组以及是否属于命名空间。集群安装 CRD 后还会出现新的资源类型，因此本机输出比记忆固定清单更可靠。
| 资源分类 | 资源名称 | 缩写 | 资源作用 |
|---|---|---|---|
| 集群级别资源 | nodes | no | 集群组成部分 |
| namespaces | ns | 管理命名空间边界 | |
| pod资源 | pods | po | 装载容器 |
| pod资源控制器 | replicationcontrollers | rc | 控制pod资源 |
| replicasets | rs | 控制pod资源 | |
| deployments | deploy | 控制pod资源 | |
| daemonsets | ds | 控制pod资源 | |
| jobs | 控制pod资源 | ||
| cronjobs | cj | 控制pod资源 | |
| horizontalpodautoscalers | hpa | 控制pod资源 | |
| statefulsets | sts | 控制pod资源 | |
| 服务发现资源 | services | svc | 服务访问或入口规则 |
| ingress | ing | 服务访问或入口规则 | |
| 存储资源 | volumeattachments | 存储 | |
| persistentvolumes | pv | 存储 | |
| persistentvolumeclaims | pvc | 存储 | |
| 配置资源 | configmaps | cm | 配置 |
| secrets | 配置 |