Kubernetes 入门：何时需要 K8s 与集群架构总览

写于 2017-06，背景：Kubernetes 1.7 刚 GA、Docker Swarm 还在与 K8s 掰手腕，etcd v3.2、Helm v2 已经成熟。本文聚焦"为什么需要 K8s"与"集群由哪些组件组成"，帮你建立全局视图。

一、为什么需要 Kubernetes

应用在不同规模下，对"运行环境"的需求完全不同：

规模	解决方案	痛点
1 台机器	docker + docker-compose	一台机器上启动 N 个容器，简单直接
3~5 台	每台单独配置 + 负载均衡器	应用升级、机器扩容、版本回滚需要手工操作
十几到几十台	重复性脚本 + Ansible	加机器 1 小时、版本回滚半小时、灰度发布？祈祷吧
上百到上千台	Kubernetes	一个 `kubectl scale` 完成扩容、`kubectl rollout undo` 完成回滚

Kubernetes（k8s） 是 Google 在 2014 年开源的容器编排系统（2015-07 v1.0 GA），前身是 Borg 系统。它的目标很简单：让你像操作一台机器一样操作上千台机器组成的集群。

“谈笑间，樯橹灰飞烟灭”——加机器、版本升级、灰度发布，都只是一个 YAML + 一个命令的事。

二、集群架构总览

K8s 集群分两类节点：

master（主节点）：控制平面，不跑业务负载，通常 1 个或 3 个（高可用）
worker（工作节点）：跑 Pod，可以是虚拟机或物理机，可以不断加

2.1 核心组件

组件	角色
`kube-apiserver`	API 服务器，对外暴露 Kubernetes HTTP API，是整个集群的"门卫"
`etcd`	分布式键值数据库，保存集群所有状态（Pod、Service、ConfigMap 等）
`kube-scheduler`	调度器，决定 Pod 调度到哪个 worker 节点
`kube-controller-manager`	控制器集合（Deployment/Node/Endpoint 等 30+ 控制器）
`cloud-controller-manager`	与云服务商集成（负载均衡、存储卷、节点生命周期）
`kubelet`	worker 节点上的"代理"，负责 Pod 生命周期
`kube-proxy`	worker 节点上的网络代理，维护 iptables/IPVS 规则
`container runtime`	容器运行时（containerd / CRI-O / Docker），真正运行容器

2.2 Pod 是什么

Pod 是 K8s 调度和管理的最小单位，不是容器。

一个 Pod 可以包含 1 个或多个容器
同一个 Pod 里的容器共享网络（同一个 IP）、存储卷、生命周期
Pod 有自己的虚拟 IP（ClusterIP）
主节点根据资源、亲和性、污点等策略，把 Pod 调度到合适的 worker

把 Pod 想象成"一个逻辑主机"，里面的容器就像同一台机器上的进程——它们共享网络、可以本地通信。

三、kubectl 速查

kubectl 是 K8s 的命令行工具，几乎所有操作都通过它完成。

3.1 查看基本信息

1
2
3
4
5
6
7
8
# 客户端 + 服务端版本
kubectl version

# 可用 API 版本
kubectl api-versions

# 某个资源类型的字段说明
kubectl explain deployment.apiVersion

3.2 命名空间

1
2
3
4
5
6
7
8
# 查所有命名空间下的资源
kubectl get all -o wide -A

# 查某个命名空间
kubectl get all -o wide -n test

# 删除命名空间（会删除里面所有资源）
kubectl delete ns dev

3.3 Pod 操作

1
2
3
4
5
6
7
8
# 强制删除卡在 Terminating 的 Pod
kubectl delete pods nacos-846d6cd5f7-t7h2x -n dev --grace-period=0 --force

# 查看 Pod 日志
kubectl logs -f pod-name -n namespace

# 进入 Pod 终端
kubectl exec -it pod-name -n namespace -- sh

3.4 资源缩写

资源	缩写
pods	po
services	svc
deployments	deploy
namespaces	ns
nodes	no
configmaps	cm
persistentvolumes	pv

四、版本节奏

K8s 一年发布 3 个版本（1.x 时代），从 1.28 起改为每年 4 个版本：

大版本	GA 时间	维护状态
1.28	2023-08-16	支持到 2024-10-28
1.27	2023-06-14	支持到 2024-06-28
1.26	2022-12-08	支持到 2024-02-28
1.25	2022-08-23	已 EOL

版本约定：x.y.z，x 是大版本，y 是次要版本，z 是补丁版本。例如 1.28.5 是 1.28 的第 5 个补丁。

升级建议：生产集群不要追新，每年升 1~2 个次要版本即可。大版本升级前必须看 CHANGELOG 里 kubelet 参数、API 废弃、依赖变化。

五、何时不该上 K8s

不是所有场景都适合 K8s：

单机应用：直接 docker-compose，引入 K8s 反而增加复杂度
状态强一致的服务（如传统 MySQL 主从）：运维复杂度高，不如托管 RDS
小团队（< 5 人）：学习曲线陡峭，K8s 本身的运维成本可能高于业务价值
没有 DevOps 文化：K8s 是工具，本质还是要 CI/CD + GitOps + 监控告警体系

决策树：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
应用规模 → 单机？
   ↓ yes
  docker-compose
   ↓ no
应用规模 → 3~10 台？
   ↓ yes
  docker swarm 或 k3s（轻量）
   ↓ no
业务高可用要求？
   ↓ 高
  Kubernetes（生产集群 + 高可用 + GitOps）
   ↓ 低
  k3s / kubeadm 单 master

六、前置知识 / 下一步

前置：

熟练使用 Docker（构建镜像、容器操作、网络模式）
理解 Linux 网络（iptables、IPVS、网桥）
掌握至少一种证书签发工具（cfssl / openssl）

下一步：

K8s 工具链速装（2018-12-15）—— kubectl / kubeadm / minikube / helm 一文搞定
二进制部署完整路径（2020-03-15）—— 理解集群组件如何协作
Kubeadm 一键部署（2022-06-15）—— 生产环境最常见的部署方式

参考资料

2024+ 视角

2017 年的 K8s 1.7 时代组件到 2024-2026 年的 1.30-1.32 时代，主要变化如下：

版本节奏从 1.28 起改为每年 4 个 minor 版本（之前 3 个），EOL 窗口从 9 个月延长到 14 个月。生产规划可按"每年升 2 个 minor"来排。
sidecar 容器 GA（1.28-1.29）：原生 sidecarContainers 字段替代了"边车 hack"（同 Pod 多个 initContainer），Lifecycle Hook 触发更可靠，影响了 Istio/Envoy 链路代理的部署方式。
Gateway API 1.0 GA（2024）：Ingress 资源正式进入"维护模式"，新部署推荐 Gateway + HTTPRoute。Cilium、Istio、Contour、Traefik 都已全面支持。
容器运行时全面 containerd：Docker Shim 在 1.24 已移除，1.30+ 集群几乎全部使用 containerd / CRI-O。nerdctl 替代 docker CLI。
Pod Scheduling 进化：K8s 1.30 GA 的 DRA（Dynamic Resource Allocation） 让 GPU/NPU 等异构资源调度更精细；noderelabeling 与 Scheduling Framework 扩展点稳定，Karpenter / Kueue 等调度器大规模落地。
可观测性标配：OpenTelemetry 取代 OpenTracing/Jaeger 客户端，K8s 1.30+ 的 APIServerTracing 默认开启 OTLP 导出，配合 Pixie / eBPF 实现无侵入链路追踪。
生产默认配置变化：PodSecurityPolicy 1.25 移除，全面改用 PSA（Pod Security Admission） + pod-security.kubernetes.io/enforce=restricted；--feature-gates=RemoveSelfLink=false 之类的旧开关已被清理。

结论：2017 年这篇文章的"集群组件图"和"kubectl 速查"基本功没有过时，但落地工具链（Ingress→Gateway、Docker→containerd、PSP→PSA）需要 2024 视角的更新。