核心定位 ：Kubernetes（K8s）是开源容器编排平台，通过声明式 API 实现容器化应用的自动化部署、扩缩、运维。
设计哲学：你声明期望状态（desired state），K8s 控制平面持续驱动实际状态（actual state）向期望状态收敛。
表 1：K8s 集群架构总览 ------ 两大平面
| 平面 |
组成 |
职责 |
运行位置 |
| 控制平面（Control Plane） |
API Server、etcd、Scheduler、Controller Manager、Cloud Controller Manager |
决策中枢：接收请求、调度决策、状态维护、故障自愈 |
Master 节点 |
| 工作节点（Worker Node） |
kubelet、kube-proxy、Container Runtime、CNI 插件 |
执行层：运行 Pod、维护网络、上报状态 |
Node 节点 |
一句话：控制平面是"大脑"，工作节点是"手脚"，etcd 是"记忆"。
表 2：七大核心组件 ------ 逐一拆解
| 组件 |
核心职责 |
关键特性 |
通信方式 |
默认端口 |
| kube-apiserver |
集群唯一入口，认证/授权/访问控制/API 注册发现 |
所有操作必经之路，无缓存，水平扩展 |
REST API + watch |
6443 |
| etcd |
分布式键值存储，保存集群全部状态 |
最终一致性，Raft 协议，仅 apiserver 可直接读写 |
仅 apiserver 访问 |
2379-2380 |
| kube-scheduler |
Pod → Node 调度，按策略选最优节点 |
过滤（Filtering）→ 打分（Scoring）两阶段 |
watch apiserver 获取未调度 Pod |
10251 |
| kube-controller-manager |
维护集群状态：故障检测、自动扩缩、滚动更新 |
内置多控制器：Node/Job/Deployment/Endpoint 等 |
watch apiserver 监测变化 |
10252 |
| kubelet |
节点代理，维护容器生命周期，管理 Volume/网络 |
驱动 CRI 运行容器，上报节点/Pod 状态 |
对接 apiserver + CRI |
10250 |
| kube-proxy |
Service 的 cluster 内部负载均衡与服务发现 |
iptables / IPVS / eBPF 三种模式 |
watch apiserver 获取 Service/Endpoint |
--- |
| Container Runtime |
镜像管理 + Pod/容器真正运行 |
CRI 接口（docker/containerd/CRI-O） |
kubelet 通过 CRI 调用 |
--- |
表 3：组件通信全景 ------ 谁跟谁说话
| 发起方 |
目标 |
通信方式 |
说明 |
| 用户 / kubectl |
API Server |
REST API |
唯一入口 |
| API Server |
etcd |
Raft 协议 |
唯一能直接读写 etcd 的组件 |
| Scheduler |
API Server |
watch |
监听未绑定 Node 的 Pod |
| Controller Manager |
API Server |
watch |
监听资源变化，驱动收敛 |
| kubelet |
API Server |
REST + watch |
上报节点/Pod 状态，获取任务 |
| kube-proxy |
API Server |
watch |
监听 Service/Endpoint 变化 |
| API Server |
kubelet |
直接调用 |
logs/exec/attach 等操作（默认不校验证书） |
| kubelet |
Container Runtime |
CRI |
创建/启停容器 |
| kubelet |
CNI 插件 |
调用 |
Pod 网络配置 |
| kubelet |
CSI 插件 |
调用 |
存储卷挂载 |
铁律：所有组件间通信都经过 API Server（除 apiserver 直接调用 kubelet 的特殊操作），etcd 只有 apiserver 能碰。
表 4：Pod ------ K8s 最小调度单元
| 属性 |
说明 |
| 定义 |
一个或多个紧密耦合的容器，共享网络/存储，作为整体调度 |
| 网络 |
所有容器共享一个 Network Namespace（同 IP、同端口空间） |
| 存储 |
可共享 Volume（emptyDir/hostPath/PV） |
| 生命周期 |
短暂的，创建→运行→终止，不可复活（被 Controller 重建） |
| 两种用法 |
① 单容器 Pod（最常见）② 多容器 Pod（sidecar/init container 模式） |
| Init Container |
在主容器启动前按顺序执行，成功后不再重启 |
| 容器重启策略 |
Always（默认）、OnFailure、Never |
表 5：工作负载控制器 ------ 6 大 Controller 对比
| 控制器 |
用途 |
Pod 名称 |
适用场景 |
副本管理 |
| Deployment |
无状态应用部署 |
随机（deploy-xxx-xxx） |
Web 服务、API、微服务 |
ReplicaSet 管理 |
| StatefulSet |
有状态应用 |
固定有序（app-0, app-1, app-2） |
数据库、Kafka、ZooKeeper |
固定标识 + 有序启停 |
| DaemonSet |
每个 Node 跑一个 |
与 Node 同名 |
日志采集（Fluentd）、监控（Prometheus Node Exporter） |
1 per Node |
| Job |
一次性任务 |
随机 |
批处理、数据迁移 |
成功后停止 |
| CronJob |
定时任务 |
Job + 时间戳 |
定时备份、定时清理 |
按 Schedule 创建 Job |
| ReplicaSet |
副本集（底层） |
随机 |
Deployment 的底层实现，一般不直接用 |
精确副本数 |
表 6：服务发现与负载均衡 ------ Service + Ingress
| 资源 |
作用范围 |
负载均衡方式 |
核心机制 |
| ClusterIP（默认） |
集群内部 |
iptables / IPVS |
虚拟 IP + kube-proxy 转发到 Endpoint |
| NodePort |
集群外部 → Node |
iptables / IPVS |
每个 Node 开放固定端口（30000-32767） |
| LoadBalancer |
集群外部 → LB |
云厂商 LB |
自动创建外部负载均衡器 |
| ExternalName |
外部服务映射 |
DNS CNAME |
将 Service 映射到外部域名 |
| Ingress |
L7（HTTP/HTTPS）路由 |
Nginx/Traefik/Envoy |
基于路径/域名的路由规则 |
Service vs Ingress 对比
| 对比项 |
Service |
Ingress |
| OSI 层 |
L4（TCP/UDP） |
L7（HTTP/HTTPS） |
| 负载均衡 |
IP + 端口 |
域名 + 路径 |
| 外部访问 |
需 NodePort / LoadBalancer |
直接暴露 HTTP/HTTPS |
| 适用场景 |
通用服务发现（所有协议） |
Web 应用路由（HTTP/HTTPS） |
| 协议支持 |
TCP / UDP / SCTP |
仅 HTTP / HTTPS / gRPC |
| 路由能力 |
无（随机分发） |
有（基于路径/域名/Host） |
| TLS 终止 |
❌ 不支持 |
✅ 原生支持 |
| 跨命名空间访问 |
❌ 不行（需 Full DNS） |
✅ 可以（通过 Ingress 规则） |
| 配置复杂度 |
简单（几行 YAML） |
较复杂（需 Ingress Controller） |
| 典型用法 |
Pod ↔ Pod 通信 |
外部用户 → Web 应用 |
| 判断 |
理由 |
| Service = 内部通信 |
解决"Pod 怎么找到 Pod"的问题 |
| Ingress = 外部入口 |
解决"用户怎么访问 Web 应用"的问题 |
| 两者配合使用 |
Ingress 接收外部流量 → 转发给 Service → Service 负载均衡到 Pod |
类比：Service 是公司内部的分机号（IP+端口），Ingress 是公司的前台总机（域名+路径，帮你转接到正确的分机）。
表 7：配置与存储 ------ 4 大核心资源
| 资源 |
用途 |
关键特性 |
典型使用场景 |
| ConfigMap |
明文配置 |
key-value，不加密，1MB 限制 |
环境变量、配置文件挂载 |
| Secret |
敏感配置 |
Base64 编码（非加密），与 ConfigMap 类似 API |
密码、Token、证书 |
| PersistentVolume（PV） |
集群级存储资源 |
独立于 Pod 生命周期，由管理员预置 |
NFS、Ceph、云盘 |
| PersistentVolumeClaim（PVC） |
用户存储请求 |
动态绑定 PV，用户按需申请 |
Pod 声明需要 10Gi 存储 |
| 存储类型 |
生命周期 |
绑定方式 |
适用场景 |
| emptyDir |
与 Pod 同生共死 |
自动创建 |
临时缓存、共享数据 |
| hostPath |
与 Node 绑定 |
指定 Node 路径 |
节点级日志、Docker 镜像缓存 |
| PV + PVC |
独立于 Pod |
动态/静态绑定 |
数据库、持久化应用 |
| ConfigMap/Secret 挂载 |
独立于 Pod |
手动挂载 |
配置文件、环境变量 |
表 8：安全与权限 ------ RBAC 模型
| 资源 |
作用域 |
用途 |
| ServiceAccount |
Namespace |
Pod 的身份标识（谁在跑） |
| Role |
Namespace |
定义某命名空间内的权限 |
| ClusterRole |
集群级 |
定义跨命名空间的权限 |
| RoleBinding |
Namespace |
将 Role 绑定到用户/SA |
| ClusterRoleBinding |
集群级 |
将 ClusterRole 绑定到用户/SA |
| 典型 ClusterRole |
权限 |
用途 |
| cluster-admin |
全部 |
超级管理员 |
| admin |
大部分 |
命名空间管理员 |
| edit |
读写（无权限管理） |
开发者 |
| view |
只读 |
只读用户 |
| system:node |
节点管理 |
kubelet |
表 9：资源管理 ------ 配额与自动扩缩
| 资源 |
作用域 |
用途 |
| ResourceQuota |
Namespace |
限制该命名空间的总资源（CPU/内存/Pod 数等） |
| LimitRange |
Namespace |
限制单个 Pod/Container 的默认/最大/最小资源 |
| HPA（HorizontalPodAutoscaler） |
Deployment/RS/StatefulSet |
根据 CPU/内存/自定义指标自动扩缩 Pod 副本数 |
| VPA（VerticalPodAutoscaler） |
Pod |
自动调整 Pod 的 CPU/内存 request/limit |
| 对比项 |
HPA |
VPA |
| 扩缩方向 |
水平（副本数） |
垂直（资源大小） |
| 触发指标 |
CPU / 内存 / 自定义指标 |
CPU / 内存实际使用 |
| 典型场景 |
流量高峰自动加机器 |
资源不足自动加配置 |
| 能否同时用 |
✅ 可以（但需注意冲突） |
✅ 可以 |
| 作用对象 |
Deployment / StatefulSet / ReplicaSet |
Pod（直接修改容器 resources） |
| 缩容策略 |
✅ 支持（按 cooldown 周期逐步缩） |
❌ 不支持（只增不减） |
| 是否需要重启 Pod |
❌ 不需要 |
✅ 需要（修改 resources 需重建 Pod） |
| 推荐使用方式 |
大多数场景的首选 |
配合 HPA 使用，处理"单 Pod 资源不足" |
表 10：网络模型 ------ 三层通信
| 层级 |
技术 |
作用 |
| Cluster Network（Pod 网络） |
CNI 插件（Calico/Flannel/Cilium） |
Pod ↔ Pod 跨节点通信 |
| Service Network（虚拟网络） |
kube-proxy（iptables/IPVS/eBPF） |
Service → Pod 负载均衡 |
| Ingress Network（入口网络） |
Ingress Controller（Nginx/Traefik） |
外部 HTTP/HTTPS → Service 路由 |
| 通信场景 |
路径 |
| Pod → Pod（同节点） |
共享 bridge / veth，直接通信 |
| Pod → Pod（跨节点） |
CNI 隧道（VXLAN / IPIP / BGP） |
| Pod → Service |
iptables / IPVS 规则 → Endpoint |
| 外部 → Pod |
Ingress → Service → Endpoint → Pod |
表 11：扩展机制 ------ 4 种扩展模式
| 扩展模式 |
说明 |
典型案例 |
| API 扩展（CRD） |
添加自定义资源类型，kubectl 可直接管理 |
Prometheus Operator、Cert-Manager |
| 调度扩展 |
替换/增强调度器，Webhook 过滤节点 |
自定义调度策略（GPU 亲和性） |
| 插件扩展（Binary Plugin） |
kubelet 调用二进制插件 |
CNI（网络）、CSI（存储）、Device Plugin（GPU） |
| Webhook 扩展 |
API Server 调用远程 HTTP 服务做准入/变更 |
准入控制器（验证镜像签名）、变更控制器（注入 Sidecar） |
| 准入控制阶段 |
触发时机 |
典型用途 |
| Mutating |
请求到达 apiserver 后、存入 etcd 前 |
注入 Sidecar、修改默认值 |
| Validating |
请求存入 etcd 后、返回前 |
验证镜像策略、资源配额检查 |
表 12：Namespace ------ 资源隔离
| 特性 |
说明 |
| 作用 |
逻辑隔离，将集群资源划分为多个虚拟集群 |
| 默认 |
default、kube-system、kube-public、kube-node-lease |
| 资源归属 |
Pod/Service/Deployment 属于 Namespace；Node/PV 不属于 |
| 配额 |
可配合 ResourceQuota 限制每个 Namespace 的资源总量 |
| 典型划分 |
dev / test / staging / prod，或按团队划分 |
表 13：Label & Selector ------ K8s 的"标签系统"
| 概念 |
规则 |
用途 |
| Label |
key 最长 63 字节，value 最长 253 字节，可为空 |
标记资源，多对多 |
| Selector |
=、!=、in、notin、exists、!exists |
筛选资源，一对多 |
| 匹配逻辑 |
AND 关系（同一组内），OR 关系（多组用逗号分隔） |
Service 选 Pod、Deployment 管理 ReplicaSet |
| 典型 Label |
示例 |
| app |
app=nginx |
| tier |
tier=frontend |
| env |
env=prod |
| version |
version=v2.1 |
表 14：Pod 生命周期与状态机
| 状态 |
说明 |
触发条件 |
| Pending |
等待调度 |
刚创建，Scheduler 还未分配节点 |
| Running |
运行中 |
容器已启动，至少一个容器在运行 |
| Succeeded |
成功完成 |
Job/CronJob 任务成功退出 |
| Failed |
失败 |
Job/CronJob 任务失败退出 |
| Unknown |
状态未知 |
与 Node 失联，通常 Node 挂了 |
| CrashLoopBackOff |
反复崩溃重启 |
容器启动后立即退出，kubelet 反复重启 |
| ImagePullBackOff |
拉取镜像失败 |
镜像不存在/网络不通/认证失败 |
| CreateContainerConfigError |
配置错误 |
ConfigMap/Secret 引用不存在 |
| Evicted |
被驱逐 |
节点资源不足，kubelet 主动驱逐 |
| Terminating |
终止中 |
删除操作已发出，等待 grace period 结束 |
表 15：部署方式对比
| 方式 |
适用场景 |
难度 |
代表工具 |
| kubeadm |
生产/学习，自建集群 |
⭐⭐⭐ |
官方推荐 |
| kops |
AWS 生产集群 |
⭐⭐⭐⭐ |
AWS 官方 |
| kubespray（Kubespray） |
多云/混合云 |
⭐⭐⭐ |
Ansible 自动化 |
| Minikube |
本地学习/开发 |
⭐ |
单节点 |
| Kind |
CI/CI 测试 |
⭐ |
Docker 内运行 |
| K3s / K3d |
边缘/IoT/轻量生产 |
⭐⭐ |
Rancher |
| 托管服务（EKS/GKE/ACK） |
生产（不想管控制平面） |
⭐ |
云厂商 |
表 16：K8s 版本演进 ------ 关键里程碑
| 版本 |
时间 |
关键变化 |
| v1.0 |
2015.07 |
正式发布，Google 捐赠给 CNCF |
| v1.5 |
2016.12 |
引入 RBAC（之前是 ABAC） |
| v1.9 |
2017.12 |
Apps/v1 稳定（Deployment/DaemonSet/StatefulSet） |
| v1.14 |
2019.03 |
kubectl 插件机制（kubectl krew） |
| v1.16 |
2019.09 |
Deprecated APIs 移除（如 extensions/v1beta1） |
| v1.19 |
2020.08 |
Ingress v1 稳定，PodSecurityPolicy 废弃 |
| v1.20 |
2020.12 |
Dockershim 移除（不再支持 Docker） |
| v1.22 |
2021.08 |
移除 Dockershim，PV 回收策略 GA |
| v1.24 |
2022.05 |
Dockershim 完全移除，仅支持 CRI Runtime |
| v1.25 |
2022.08 |
PodSecurity admission 替代 PSP |
| v1.27 |
2023.04 |
移除 in-tree 存储插件，CSI 全面接管 |
| v1.28 |
2023.08 |
SidecarContainers 特性 GA |
| v1.30 |
2024.04 |
结构化日志，Graceful Node Shutdown GA |
| v1.31 |
2025.04 |
持续演进中（2026 年 6 月当前最新约 v1.32） |
铁律：每 4 个月一个 Minor 版本，每年 3 个；API 废弃周期约 12-18 个月。
表 17：kubectl 核心命令速查
| 操作 |
命令 |
| 查看资源 |
kubectl get pods -n namespace |
| 查看详情 |
kubectl describe pod pod-name |
| 查看日志 |
kubectl logs pod-name -f |
| 进入容器 |
kubectl exec -it pod-name -- /bin/sh |
| 应用配置 |
kubectl apply -f xxx.yaml |
| 删除资源 |
kubectl delete -f xxx.yaml |
| 扩缩副本 |
kubectl scale deployment xxx --replicas=5 |
| 滚动更新 |
kubectl set image deployment/xxx container=image:v2 |
| 查看事件 |
kubectl get events --sort-by=.metadata.creationTimestamp |
| 排错 |
`kubectl get pod -o yaml |
表 18：K8s 生态全景 ------ 周边项目
| 类别 |
项目 |
用途 |
| 服务网格 |
Istio / Linkerd / Cilium Service Mesh |
微服务间流量管理、可观测性、安全 |
| GitOps |
ArgoCD / Flux |
声明式持续交付，Git = 单一事实来源 |
| Helm |
Helm 3 |
K8s 包管理器（Chart = K8s 应用模板） |
| 监控 |
Prometheus + Grafana |
指标采集与可视化 |
| 日志 |
EFK（Elasticsearch+Fluentd+Kibana）/ Loki |
日志采集与查询 |
| CI/CD |
Tekton / Jenkins X |
K8s 原生 CI/CD 管道 |
| 策略引擎 |
OPA / Kyverno |
准入控制、策略即代码 |
| 多集群管理 |
Karmada / ClusterAPI |
多集群调度与生命周期管理 |
| Dashboard |
Kubernetes Dashboard |
Web UI 管理界面 |
| 包管理 |
Kustomize |
原生配置管理（kubectl 内置） |
表 19：K8s vs Docker Swarm vs Nomad ------ 快速对比
| 维度 |
Kubernetes |
Docker Swarm |
HashiCorp Nomad |
| 复杂度 |
高 |
低 |
中 |
| 生态 |
最丰富 |
有限 |
中等 |
| 调度能力 |
最强（可扩展） |
基础 |
强（非容器也能调） |
| 服务发现 |
Service + Ingress |
内置 DNS |
Consul 集成 |
| 学习曲线 |
陡峭 |
平缓 |
中等 |
| 企业采用率 |
⭐⭐⭐⭐⭐ |
⭐⭐ |
⭐⭐⭐ |
| 适用场景 |
大规模生产 |
小团队/简单场景 |
混合工作负载 |
最终结论
| 判断 |
理由 |
| K8s = 云原生操作系统 |
它管理的不是单台机器，而是整个数据中心的计算资源 |
| 声明式是灵魂 |
你说"我要 3 个副本"，K8s 负责怎么实现、怎么维持 |
| 控制平面是单点 |
etcd 挂了 = 集群脑死亡，所以高可用部署至少 3 个 Master |
| Docker 已被淘汰 |
v1.24 起移除 Dockershim，现在必须用 containerd/CRI-O |
| 学 K8s 的正确路径 |
Pod → Deployment → Service → Ingress → ConfigMap/Secret → RBAC → Network Policy → Helm/GitOps |
| 2026 年的 K8s |
全面 CSI/CNI、eBPF 网络、Sidecar 原生支持、结构化日志、AI 调度探索 |
一句话：Kubernetes 不是一个工具，而是一套"让容器自动运行"的操作系统。学会它，你管理的不再是服务器，而是整个应用的生命周期。