Kubernetes基础课程

Kubernetes 快速上手的教程是个陷阱。一条友好的 kubectl run 加 kubectl port-forward，会让人觉得它只是种更友好的跑 Docker 的方式——直到一个 Pod 在 Pending 里坐了一个小时、你的 Service 没有端点、或一次因镜像拉取错误而静默回滚的部署。从“我能跑一个演示 Pod”到“我能跑一个真实负载”，这段落差正是多数新手卡住的地方。这篇课程型指南要建立的是你真正需要的运行模型：控制平面和节点各干什么、Pod/Deployment/Service/Ingress 怎么拼在一起、以及为什么每一个你跳过的 YAML 字段都是一个你在无意中替自己做的决定。

控制平面与节点：集群里谁在干什么

一个 Kubernetes 集群分成控制平面和工作节点，这个划分解释了大部分看起来像魔法的东西。控制平面跑着 API server（所有命令的唯一入口）、scheduler（决定每个 Pod 跑在哪个节点）、controller manager（把期望状态和现实对齐）以及 etcd（集群的“真相来源”数据库）。工作节点跑一个 kubelet（节点上跟控制平面对话的代理）、一个容器运行时，还有管网络的 kube-proxy。搞懂这个划分，你就知道问题在哪：API server 挂掉会挡掉一切，kubelet 出问题只影响那一个节点上的负载。

Pending 卡住的 Pod 通常是新手最常见的困惑，但通常不是应用 bug。它意味着 scheduler 没能给它排上位置——要么节点缺所需资源、要么有个 taint 挡住它、要么没有匹配的节点。看到 Pending 时，你在排的是 scheduler 和节点 taint/标签，不是应用。同理，CrashLoopBackOff 是你的应用运行时挂了，ImagePullBackOff 是镜像名、tag 或 registry 凭证有误。命名出错的那一层——scheduler、运行时还是镜像——是每次修复的第一步。

Pod、Deployment 与无状态工作负载模型

Pod 是最小的可调度单元：一个或多个共享网络命名空间和存储的容器。实操里大多 Pod 只跑一个容器，而你几乎从不直接建 Pod——你建一个 Deployment（或其他工作负载控制器），由它替你管理一个管理若干 Pod 的 ReplicaSet。Deployment 给你声明式控制：指定复本数和容器镜像，控制器建立一个“对账循环”，让现实持续贴合你声明的状态。编辑 spec，Kubernetes 滚动到新版本；杀掉一个 Pod，它重新调度一个替代的。

无状态模型是关键的心智切换。Deployment 管理的 Pod 随时可被替换，它们的 IP 是临时的，文件系统是一次性的。所以状态（数据库文件、上传物、缓存）必须放在 Pod 之外的持久卷里，这也是为什么 Deployment 适合无状态服务。当你需要唯一标识、稳定的有状态组件（数据库 leader、共识参与者）时，改用 StatefulSet——一个更难用、但保持稳定标识和顺序的独立控制器。前置做对 Deployment/StatefulSet 的选择，能避免后面痛苦的迁移。

把它们串起来：Service 与 Ingress

因为 Pod IP 是临时的，你没法可靠地按 IP 连 Pod。Service 是坐在一组 Pod（按标签选中）前面、给它们稳定集群内 DNS 名并在背后 Pod 间做负载均衡的稳定抽象。当 Service 报 0 个 endpoints，通常是标签不匹配——你的 Service selector 跟 Pod 上的标签对不上。这是早年集群里“为什么我的应用连不上？”的头号原因，而且纯粹是 YAML 打字错误，不是深奥魔法。

把 Service 暴露给外部走 Ingress（或云平台上的 LoadBalancer 类型 Service）。Ingress 规则把主机名和路径映射到 Service，背后是个 ingress controller（比如 NGINX Ingress、Traefik，或云负载均衡）。ClusterIP 类型只内部可用；NodePort 在每个节点暴露一个高位端口；LoadBalancer 分配一个外部地址。要内化这条层级：Service 按标签选 Pod，Ingress 把外部流量路由到 Service，而就绪健康检查决定 Service 把流量发给哪些 Pod。

ConfigMap、Secret，以及传配置的正确姿势

把配置硬编码进容器镜像，是版本管理和密钥泄露的来源，Kubernetes 给了你两个机制来避免。ConfigMap 以键值对保存非机密配置，挂成文件或暴露成环境变量。Secret 对敏感材料（凭证、API 密钥、令牌）做同样的事——凡是你绝不会提交进镜像的东西，都是它的正确归宿。两者都跟容器镜像解耦，所以你能把同一份镜像用不同配置部署进不同环境，这正是支撑从开发到预发到生产的晋升流程的模式。

安全细节很重要。Kubernetes 里的 Secret 默认只做了 base64 编码，不是静态加密——除非你为 etcd 开启静态加密、并用 RBAC 管控谁能读改 Secret，否则它只是混淆而非保护。像对待任何生产凭证那样认真：轮换、收紧访问范围、需要更强保证时优先外部密钥库（SealedSecret 或 external-secrets operator）。现在要建立的习惯是：Secret 待在镜像和 Pod spec 之外。

存储：持久卷，以及为什么状态很难

当应用需要能挺过 Pod 重启的文件时，你需要持久存储。持久卷（PV）是由管理员或 StorageClass 动态供给的集群存储；持久卷声明（PVC）是应用申请存储、并绑定到一个 PV 的东西。Pod 再挂载 PVC。在托管集群（EKS、GKE、AKS）里，一个默认 StorageClass 会在你建 PVC 时自动供给云盘——很方便，但也意味着每个 PVC 都花真金白银、有该亲手设的默认大小和性能档。

把 Kubernetes 心智模型和可能来自的单主机路径对照一下：一旦你把 Kubernetes 看成容器基础之上的编排层，一大类“为什么这么复杂”的挫败感就消失了——这正是先精通单主机容器流程划得来的原因。Docker Compose 指南展示了一套没有调度器的多服务栈长什么样；Docker 入门指南则把镜像、容器和网络夯实。无状态模型、健康检查、滚动更新这些你在 Compose 里练过的东西几乎一比一迁移，所以如果容器直觉已经很敏锐，Kubernetes 的学习曲线会大幅缩短。

命名空间、资源限制，以及安全地共用集群

一队人的集群很快就变成很多工作负载的集群，命名空间是隔离它们的第一个工具。命名空间划分集群资源、界定名称范围，并为 RBAC 和网络策略给出一条隔离边界。把不同环境（dev、staging、prod）拆到不同命名空间，别让每个工作负载都挤在 default——否则一个跑偏的重名或一次误删 kubectl delete 会抹掉重要的东西。

同样重要的是资源管理。给每个容器设 requests 和 limits：requests 告诉 scheduler 预留多少 CPU/内存，limits 封顶一个失控容器能消耗多少。没有它们，一个吃内存的 Pod 就能拖垮整个节点，更糟的是在请求中途被 OOM 杀掉还没警告。你每个没设的字段都是一个你没自觉选择的默认；在共享集群里，request/limit 的默认正是最容易引发故障的部分。给每个工作负载都加上，并对照 requests 监控实际用量，以免过度预留浪费钱、或预留不足引发驱逐。

托管 Kubernetes 与自建路线对比

学习用 Minikube 或 kind 在笔记本上跑，是最快拿到实操手感的路。真实负载用国内托管方案（阿里云 ACK、腾讯云 TKE、华为云 CCE）能卸掉沉重的控制平面运维负担；只有你有运维团队和理由，才选自建。价格大致跟着节点和资源用量走，控制平面费用是主要差异点。

发布、健康检查与无恐惧地跑一次部署

Deployment 的真正威力在安全变更：把旧 Pod 换成新 Pod 的滚动更新，以及新版没通过就绪检查时的自动回滚。要受益，你的镜像 tag 必须真的变（每次部署复用 latest 会废掉这个——控制器看不到 spec 变化），而且你的 Pod 要有反映真实就绪状态的就绪探针，而不是只反映容器启动。给每个工作负载设 readinessProbe 和 livenessProbe：就绪探针管控流量，存活探针重启卡住的容器。没有它们，Kubernetes 就假定容器一启动即就绪——这是慢启动时流量失败的常见原因。

用 kubectl rollout status 和 kubectl rollout undo 管理发布，用 strategy 参数（maxUnavailable、maxSurge）控制滚动替换的激进程度。按 tag 或 digest 固定镜像，并知道“坏镜像”（tag 对但入口坏了）照样会滚动——这正是上线前冒烟测试和好探针胜过“赌一把”的原因。版本化镜像、健康探针、回滚意识这套纪律，正是把 kubectl apply 从手雷变成可控部署的东西。

不慌不忙地调试一个集群

出问题时从外向内走一条标准梯子：kubectl get events 看集群级信号，kubectl get pods 看状态（Pending、CrashLoopBackOff、ImagePullBackOff、Running with 0/1 ready），kubectl describe pod 看详细原因，kubectl logs 和 kubectl exec 看应用级洞察，用 kubectl get endpoints 确认 Service 背后的副本健康。每一级都把故障钉到一层：没有端点的 Service 指向标签不匹配，CrashLoopBackOff 指向应用启动，Pending 指向 scheduler 和节点容量。

趁还没压力时先建立调试习惯。留一个 kubectl get all -n <ns> 的别名、学会用 kubectl logs -f 流式看日志、习惯用 kubectl exec -it 钻进容器折腾。要知道从第一个 Pod 到生产级集群的实践旅程——镜像工作流、健康探针、资源限制、存储、安全——是一门真课程，Kubernetes 基础指南用一套上手实验序列补全本课程。压力下调试，主要靠一条可重复的梯子、和能准确说出哪一层在失败的词汇，两者都能先在本地集群（零风险）上刻意练出来。

从演示到真实负载：“生产就绪”到底要什么

让一个 Pod 跑起来是第一天；做一个你敢让真实流量上的负载是更长的路。生产就绪意味着每个工作负载都有资源 requests 和 limits、就绪和存活探针、版本化镜像和一个明确回滚计划。意味着你依赖的东西复本数 ≥2、一个 access mode 正确的 StorageClass、隔离环境的命名空间、以及限制谁能创建或修改工作负载的 RBAC。还意味着监控（Prometheus/Grafana 或托管栈）和日志覆盖到你定义的范围、而不是你以为的范围。容器原生的运维模式——镜像卫生、健康检查、依赖接线——在 Docker DevOps 指南里讲得很透，和本课程配套读正合适。

它还意味着把安全当作默认姿态：Secrets 作用域受限并轮换、镜像最小权限、该上就上的网络策略、以及升级和补丁的计划——这都在安全基础同伴文章里。这些都不酷，而这正是重点。Kubernetes 奖励那些尊重其模型的团队——声明式状态、临时 Pod、把存储当一等公民、在保护你的字段上保持纪律。掌握了这套运行模型，这个平台就不再是神秘之源，而成为你部署所赖的、平淡可靠的地基。

为什么我的 Pod 一直卡在 Pending 什么都不做？

Pending 意味着 scheduler 还没排上这个 Pod，几乎总是节点资源不足、节点上有 taint、或节点选择器/标签不匹配。跑 kubectl describe pod <name> 看 Events 段，它会写明调度原因。修 resource requests、去掉或容忍 taint、或纠正节点亲和性；这是个调度问题，不是应用问题。

就绪探针和存活探针有什么不同，两个都要吗？

就绪管控 Pod 是否收流量（应用没就绪时把它从 Service 摘掉）；存活负责重启卡死或死锁的容器。凡是服务流量的都两个都用。就绪保护用户免受启动中或过载应用的拖累；存活恢复僵死的进程。跳过探针意味着 Kubernetes 在容器一启动时就假定它就绪——这是慢启动时流量失败的常见原因。

Pod 明明在跑，为什么我的 Service 没有端点？

几乎总是标签选择器不匹配：Service 的 selector 标签配不上 Pod 上的标签。用 kubectl get pods --show-labels 核对并对比。也确认 Pod 是 Running 且 Ready；就绪的 Pod 才会出现在 Service 的 endpoints 里。这是新集群里“我的应用连不上”最常见的原因。

什么时候用 StatefulSet 而不是 Deployment？

应用需要稳定、唯一标识、每实例绑定稳定持久存储、以及有序部署/扩缩时用 StatefulSet——这正是数据库、缓存和共识系统的画像。无状态、可自由扩缩替换的服务用 Deployment。对要用状态的工作负载选 Deployment 会引发丢数据和标识问题；对无状态工作负载选 StatefulSet 则只是徒增复杂。

延伸阅读

想把容器这半边也补扎实，本站英文站的 Docker Compose 指南 和 2026 Docker 入门指南 是天然的前序；安全侧可读 Kubernetes 安全基础。对中文读者，本站的 Python 自动化脚本 和 AI 办公自动化 能帮你把集群外的运维脚本也顺手自动化起来。