简介：一份面向Kubernetes入门学习者的PPT课件，系统梳理k8s基础知识点，涵盖集群整体架构、核心组件职责、基础对象概念，并延伸讲解监控与日志、应用生命周期管理、调度、存储及集群安全等内容，适合正在搭建容器集群知识体系的开发运维人员。课件以图文方式展开，先介绍kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等组件作用，再解释Pod、Controller、Service、Label、Namespace等关键概念；同时列出kubectl cluster-info、describe、top等常用监控命令，并给出Deployment部署、升级、回滚示例，命令行与YAML两种方式均有涉及，便于对照学习。对组件职责、常用命令、部署流程都给出直观说明。资源包仅1个pptx文件，大小1.25MB，结构紧凑，打开即可直接浏览，也适合作为培训分享或自学速览材料。目前已有2187人学习下载，作为k8s入门课件，能帮助读者快速建立整体认知，并为后续深入实践打下基础。
1. 这个课件方向解决的不只是“会部署”
很多人第一次接触 Kubernetes 课件，是抱着“我要把集群搭起来跑个 demo”的念头来的。真正翻过内容后你会发现，一套合格的 K8s 课件其实要回答的是另一个问题：当你的应用从单机搬到集群，哪些地方会悄悄改变运行逻辑？Pod 调度、服务发现、配置注入、滚动更新，这些机制在课件里不是独立章节，而是一条从头串到尾的主线。能把这根线讲透的内容，才值得你花几个小时去啃；只教你怎么敲 kubectl 命令的课件，看完了你还是不会排障。
我自己带过几次内部培训，也帮人筛过不少网上流传的课件。我的判断标准很简单：这套材料能不能让一个熟悉 Docker 但没碰过 K8s 的开发者，在一周内从“看得懂”到“敢动手”。能，就是好课件；不能，再厚的 PDF 也是摆设。这篇文章我会把我认为一份合格 K8s 课件必须具备的知识结构、动手路径和常见坑点拆开讲，顺便把我踩过的跟课件相关的那些坑也一块儿说了。适合正在选课件自学的开发者，也适合要拿课件做内部培训的团队。
2. 先把 K8s 的核心抽象逻辑立住：课件里最该反复出现的三条主线
2.1 声明式状态：所有课件绕不开的第一课
Kubernetes 区别于 Docker Compose 这类工具，最根本的一点是工作方式从“指令式”变成了“声明式”。课件如果一上来就教命令，那基本是在误人子弟。声明式的意思是，你告诉集群“我想要什么状态”，比如“我要 3 个副本的 nginx”，集群自己会去达成并维持这个状态。
这里有个很关键的认知转折：当状态不匹配时，K8s 不会像脚本一样报错退出，而是会不断尝试协调（reconcile）。课件里必须要有这么一个对照实验，比如手动删掉一个 Pod，观察 ReplicaSet 控制器怎么把它补回来。这个实验做完，才算真正理解控制器模式。
# 查看某个 Deployment 对应的 ReplicaSet 和历史版本 kubectl rollout history deployment/nginx-deploy # 手动删除一个 Pod，然后马上看控制器反应 kubectl delete pod nginx-deploy-xxxxxxxxxx-yyyyy kubectl get pods -w这段命令里，rollout history用来查看滚动更新的历史记录，它展示的是声明式发布留下的“操作痕迹”。第二段是经典的自我修复验证：你删掉一个 Pod，控制器会立刻新起一个，因为声明状态写的是“副本数 = 3”。-w参数是 watch 模式，可以实时看到 Pod 的状态流转，从 Terminating 到 ContainerCreating 再到 Running。课件里如果没有这个演示，读者对控制器的理解会一直是纸面上的。
参数说明：rollout history后面跟的资源类型和名称是必填的；如果加了--revision可以看某个历史版本的详细信息。建议配合kubectl get replicaset一起看，因为每次发布都会生成新的 ReplicaSet，副本数会从旧到新迁移，这是判断发布是否健康的依据之一。
我倾向于认为，课件里关于声明式状态的篇幅不应该少于 20%。因为后面所有的内容，包括 HPA 弹性伸缩、StatefulSet 有状态服务、Operator 自定义控制器，全都建立在这个抽象之上。当你能用“声明状态 — 期望与实际比对 — 控制器纠正”这个闭环去理解问题，看任何 K8s 故障都不会懵。
2.2 网络与服务发现：课件里最容易含糊其辞的部分
很多入门课件把 Service、kube-proxy、DNS 分成几个孤立章节讲，结果读者学完还是不知道流量怎么从外面进到 Pod。一份负责任、有实操细节的 K8s 课件，一定会用一个完整的拓扑把四个角色串起来：Ingress → Service → EndpointSlice → Pod。
最直观的教学手段是画一张数据流图，并且配合一次真实的抓包做佐证。课件里用容器里临时装 tcpdump 来验证流量路径，这一步非常有效。常见的 CNI 插件里，Flannel 走 VXLAN 隧道，Calico 走纯三层 BGP 路由，前者适合内网，后者适合要 NetworkPolicy 的场景。
# 在 Pod 里临时装抓包工具，验证 Service 的负载均衡是否生效 kubectl exec -it nginx-deploy-xxxxxxxxxx-yyyyy -c nginx -- bash -c "apt update && apt install -y tcpdump" # 在同一个 Pod 里抓 80 端口流量，然后从集群外部多次访问 NodePort tcpdump -i eth0 -nn port 80这段演示有个容易翻车的地方：很多基础镜像不带包管理器，所以apt install会失败。更稳的做法是直接用一个预先装好 tcpdump 的测试镜像。用kubectl exec进入 Pod 后，-c nginx指定容器名，因为一个 Pod 里可能有好几个容器。抓包看到五元组里的目的 IP 是 ClusterIP 还是 Pod IP，能直接区分 Service 的 DNAT 是否生效。
参数说明：kubectl exec的-it是交互式终端，如果脚本里需要非交互执行，去掉-t就行。生产环境不建议随便 exec 进 Pod 装东西，调试完立刻删除这个测试 Pod，让控制器重建一个干净的副本。
课件里这个部分做得好不好，直接决定读者能不能应对“Service 不通”这类高频现场问题。判断标准就一条：读者能不能不假思索地说出排查链路——先看 Service 的 Endpoints 有没有地址，再看 kube-proxy 的 iptables 规则，最后看 CNI 插件是否健康。
2.3 存储与状态：课件里最容易被一句“生产环境别用”带过的内容
我见过不少入门课件，讲到 Volume 和 StatefulSet 时只有两张图，没有任何演示。这其实是一个巨大的缺失，因为无状态应用一套就熟，有状态应用的坑才是最劝退的那堆。一套真正完整、有实战操感的 K8s 课件，一定会安排一个用 StatefulSet 跑单节点 MySQL 的实验，并且会明确告诉你 Local PV 和 NFS 之间的取舍。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 5GiapiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: mysql replicas: 1 template: spec: containers: - name: mysql image: mysql:8.0 volumeMounts: - name: data mountPath: /var/lib/mysql volumeClaimTemplates: - metadata: name: data spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 5Gi很多新手搞不明白，为什么 StatefulSet 必须配一个serviceName。原因是每个 Pod 需要一个稳定的网络标识，也就是类似mysql-0.mysql.default.svc.cluster.local这样的 DNS 名字。这里的serviceName指定的是管理 Pod 网络身份的 Headless Service，没有它，Pod 的稳定域名就不存在。volumeClaimTemplates是 StatefulSet 专属的写法，每个副本会自动生成独立的 PVC，名字规则是${volumeClaimTemplateName}-${podName}，也就是上面例子里的># 控制节点初始化，注意替换为你自己的网段 kubeadm init --apiserver-advertise-address=192.168.1.10 --pod-network-cidr=10.244.0.0/16 # 工作节点加入集群，token 有效期为 24 小时 kubeadm join 192.168.1.10:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
这段命令中--pod-network-cidr必须和后面要安装的 CNI 插件网段一致。比如 Flannel 默认要求 10.244.0.0/16，Calico 则没有强制要求但默认会用 192.168.0.0/16。如果这里写错了，后面装完 CNI 插件所有跨节点通信都会挂掉，而且报错信息非常隐蔽，表面现象是 Pod 一直 ContainerCreating。--apiserver-advertise-address如果不填，默认用宿主机的默认路由 IP，在多网卡机器上很容易选错。
参数说明：--token和--discovery-token-ca-cert-hash是kubeadm init执行完以后输出在终端里的，复制时不要遗漏。token 的默认有效期是 24 小时，如果你隔了一天才来加入节点，需要重新生成。用kubeadm token create --print-join-command可以直接打印出新的加入命令，这个做法比手动拼命令不容易出错。
我一般会建议课件配套环境按“一主一从”起步，因为很多课件里讲到的调度特性，比如节点亲和性、DaemonSet 在每个节点跑一个，只有一个节点根本没法验证。等你有条件加到三个节点，再体会一下 etcd 多数派和调度器高可用的含义，那就又进了一层。
3.2 验证环境是否健康：比安装更重要的三件事
集群装完了，别急着部署应用。先做三件验证，凡是课件里给了健康检查清单的，基本都是良心课件。第一步检查所有系统组件的状态，第二步检查节点的 Ready 状态，第三步检查 CoreDNS 的解析，最后跑一个测试 Pod 确认集群端到端可用。
# 第一步：看系统组件是否健康 kubectl get pods -n kube-system # 第二步：看节点是否 Ready kubectl get nodes -o wide # 第三步：跑一个临时 Pod 测试 DNS 解析是否正常 kubectl run test-dns --image=busybox:1.36 --rm -it --restart=Never -- nslookup kubernetes.default.svc.cluster.local这三条命令看起来简单，但筛掉了大量环境问题。kubectl get pods -n kube-system里最该留意的是 CoreDNS 是否处于 Running，有多个副本时注意它们是否被调度到了不同节点。如果只有主节点工作，所有 Pod 都堆在一个节点上，说明其他节点的 Kubelet 没有正确注册，问题多半出在证书或 join 命令上。
注意，kubectl run里--restart=Never是必须的，否则它会创建一个 Deployment 而不是普通 Pod。--rm表示 Pod 运行结束后自动删除，配合-it使用可以拿到终端的输出。这里的 busybox 版本建议固定，不要在云环境里用 tag 为 latest 的镜像。
健康检查做完，整个集群的基本盘才算稳了。到这一步，你再看课件里那些花哨的部署示例，才不会因为基础环境问题被劝退。
4. 课件里的生产化内容：哪些值得信，哪些要打折看
4.1 资源配额应该重点看的 QoS 等级
我注意到大部分入门课件对资源管理一笔带过，都只写了resources: requests和limits怎么填。但真正有价值的，是把 Pod 的 QoS 等级讲清楚，并且告诉你不同等级被驱逐时的优先级。K8s 把 Pod 分成三类 QoS：Guaranteed、Burstable、BestEffort，节点内存不足时的驱逐顺序是反过来的。
resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi上面这段是 Guaranteed 等级的条件：requests 和 limits 必须同时设置，并且每个字段值必须相同。比如 cpu 都是 250m、memory 都是 512Mi，不能出现 requests 小于 limits 的情况。这个配置的代价是资源利用率偏低，因为实际运行中 Pod 很难用到上限，但系统会优先保证这个 Pod 不被驱逐。
课件里如果不说明这个细节，读者很可能随手把 limits 设置为 requests 的两倍，还以为是弹性。实际上只要 requests 不等于 limits，这个 Pod 就被判定为 Burstable，驱逐优先级在 Guaranteed 之后、BestEffort 之前。这里有一个隐性问题：如果集群资源已经不足，limits 设太大反而会让调度器认为节点容量吃紧，导致其他 Pod 调度失败。
课件里如果能用一个三 Pod 实验来演示驱逐顺序，那是最直观的：分别创建三个不同 QoS 等级的 Pod，然后用压力工具打满节点内存，观察 OOM 事件的先后顺序。kubectl describe node里能看到当前节点的资源分配情况，包括每个 Pod 的 requests 和 limits，这是排查调度问题最常用的一条命令。
4.2 探针类型与存活判断：课件里最容易讲错的三个细节
探针是一个课件里高频出现但经常讲错的知识点。最常见的错误是混淆了livenessProbe和readinessProbe的用途。用一句话区分：liveness 决定要不要重启你，readiness 决定要不要给你流量。如果一个 Pod 的 readiness 失败，它不会被杀死，只会从 Service 的 Endpoints 里摘掉；但 liveness 失败，kubelet 会根据restartPolicy重启容器。
livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5注意这里initialDelaySeconds的设定非常讲究。liveness 是 15 秒，readiness 是 5 秒，这是故意分开的。原因是应用进程起来需要时间，但接口通常先于主逻辑准备好。如果你把 liveness 的 initialDelaySeconds 设置太短，应用还没完成启动，探针就会连续失败，然后 kubelet 开始重启容器，形成一个“启动死循环”。这种现象在真实现场里经常出现，你看到的是 Pod 一直 CrashLoopBackOff，日志里却什么都没有。
periodSeconds也值得注意：太短会增加 kubelet 的压力，太长会导致故障响应变慢。常规建议是 liveness 10-15 秒、readiness 5-10 秒。还有一个隐藏坑：如果探测端口选的是进程监听的端口而不是健康检查接口，那么只要进程活着探测就永远通过，内存已经炸了都不会被发现。
课件里如果有“探针自测实验”，我建议一定要做：故意让 /ready 返回 500，看 Service 的 Endpoints 列表变化；再故意让 /healthz 超时，看 Pod 的重启次数。这两件事验证完，探针这块才算齐了。
4.3 滚动更新与回滚：课件里必须有但经常缩水的章节
滚动更新是 K8s 里最常用的发布方式，也是课件里最常被缩成“执行一条命令”的章节。实际上要讲清楚的东西不少：maxSurge和maxUnavailable怎么配合、新旧 ReplicaSet 如何交替、回滚时镜像版本怎么恢复。
# 触发一次滚动更新，修改镜像版本到 1.20.0 kubectl set image deployment/nginx-deploy nginx=nginx:1.20.0 --record # 观察滚动过程 kubectl rollout status deployment/nginx-deploy # 如果发现问题，回滚到上一个版本 kubectl rollout undo deployment/nginx-deploy--record这个参数值得解释一下：它会把当前变更命令记录到 Deployment 的 annotation 里，方便回滚时查看原因。很多人觉得它过时了，因为新版本里可以用别的方式记录变更原因，但--record在课堂演示和日常操作里仍然非常顺手。
maxSurge和maxUnavailable的默认值都是 25%，意思是更新时最多可以比期望副本数多出 25%，同时最多可以有 25% 的副本不可用。如果你对可用性要求很高，可以把maxUnavailable设为 0，代价是更新期间会有额外的临时副本占用资源。课件里如果能演示一次“故意把镜像版本改成不存在的 tag，观察 rollout 卡住的现场”，胜过讲十遍理论。
回滚操作有一个坑：kubectl rollout undo默认回滚到上一个版本，但如果你连续发布了很多次，建议先kubectl rollout history看版本列表，再用--to-revision指定版本。直接 undo 在多次发布后很可能会回滚到错误的版本。
5. 课件避坑指南：照着学也会翻车的 4 个高频问题
5.1 镜像拉不下来的问题
现象：Pod 一直显示 ImagePullBackOff，kubectl describe 里能看到Failed to pull image的报错，节点上手动 docker pull 却经常是好的。
原因：一半是镜像仓库网络问题或认证问题，另一半是镜像 tag 写得不对。很多人习惯写nginx而不是nginx:1.20.0，导致不同节点拉到的版本不一致。还有一个隐蔽原因：有些集群环境设置了 imagePullPolicy 为 Always，而本地有同名镜像，但仓库里根本没有这个 tag。
解决：先把镜像 tag 写明确，不要依赖 latest。然后检查节点的/etc/containerd/config.toml或/etc/docker/daemon.json，确认是否配了镜像加速器或私有仓库地址。如果拉了私有仓库的镜像，还要确认 imagePullSecret 是否在正确的 namespace 下，Secret 是 namespace 级别的，在 default 下创建的 Secret 对 kube-system 里的 Pod 不生效。
5.2 网络插件和初始化参数不一致的问题
现象：节点状态 Ready，但所有跨节点 Pod 之间 ping 不通；Calico 装完 etcd 里能看到节点，但 felix 一直报错。
原因：这个问题大概率是装 CNI 插件的时候网段和初始化参数不匹配。若你用的是 Flannel，Pod 的 CIDR 必须和kubeadm init里的--pod-network-cidr一致。有人先装了 Flannel，后来想换 Calico，发现两个插件的配置残留都在/etc/cni/net.d/目录里，导致 kubelet 不知道用哪个。
解决：换网络插件之前，先把/etc/cni/net.d/下的文件清理干净，然后重启 kubelet。在切换网络插件时，要先删除旧的 DaemonSet 和 ConfigMap，再清理节点上的 CNI 配置目录。建议一旦选定插件，不要轻易更换，除非你有充分的理由和足够的排障时间。
5.3 节点内存和 PVC 容量不足的问题
现象：StatefulSet 创建后 Pod 一直 Pending，事件里写着FailedScheduling和node(s) had insufficient memory或者no persistent volumes available。
原因：这通常不是调度器的问题，而是资源预留在作怪。节点的内存可能已经有一部分被系统组件占用了，比如 kube-system 里的 DaemonSet。PVC 则可能是因为 StorageClass 没有设置动态供应，或者集群里根本没有合适的 PV 可以绑定。
解决：先kubectl describe node看节点的 Allocatable 资源，那才是调度器真正会用的数字。再看 StorageClass 是否设置了provisioner，如果没有，你需要预先创建 PV 并设置好标签让 PVC 可以匹配。用kubectl get pvc -o wide可以看到 PVC 绑定到了哪个 PV。如果确实没有动态供应，最简单的办法是使用 Local Path Provisioner 这类轻量方案，它能让 StatefulSet 在单节点上跑起来，非常适合课件实验环境。
5.4 Dashboard 访问不了的问题
现象：Dashboard 安装完成后，通过 NodePort 访问总是提示无法连接，浏览器报 502 或者直接拒绝连接。
原因：最常见的两个原因，一是 Dashboard 的 Service 类型是 ClusterIP，根本没有暴露到集群外部；二是新版 Dashboard 默认启用了登录鉴权，没有 Token 或 kubeconfig 会被拦在登录页之外。还有一个原因：Dashboard 的 Pod 可能被调度到了没有外网 IP 的节点上，NodePort 只在那个节点上生效。
解决：把 Dashboard 的 Service 改成 NodePort 类型，或者用kubectl port-forward转发到本地访问。鉴权方面，用kubectl create token admin-user生成一个临时 Token 登录。强烈不建议为了图方便关掉鉴权，除非你的集群只有你自己能访问，并且你知道自己在做什么。
我在内部培训时见过有人把 Dashboard 的 Service 改成 LoadBalancer 并暴露到公网，然后忘了加密码保护，结果第二天集群里的命名空间就被清空了。这种场景基本等于上了一课，代价很高。
6. 用故障注入验证你的 K8s 学习成果：一个值得练到习惯的进阶方法
如果你看完课件，想知道自己是不是真的理解了 K8s，我推荐一个方法：故意弄坏集群，然后尝试自己修好。这个方法比把课件从头再看一遍有用得多。下面这几个故障注入实验，你可以在自己的实验环境里反复练习。
# 实验 1：删除一个关键系统组件，观察集群的反应 kubectl delete pod -n kube-system -l component=kube-apiserver # 实验 2：手动修改一个 Deployment 的副本数为 0 kubectl scale deployment nginx-deploy --replicas=0 # 实验 3：给节点打上不可调度的污点 kubectl taint nodes worker1 key=value:NoSchedule实验 1 的意义在于让你明白 kube-apiserver 是集群的大脑，它本身由 Static Pod 管理。你删掉它，kubelet 会尝试从/etc/kubernetes/manifests/目录下读取清单文件并重新拉起。如果这个过程没有发生，说明你的 kubelet 的静态 Pod 机制被破坏了，这时候要看 kubelet 的日志和 manifests 目录是否还在。
实验 2 则是验证你理解控制器的方式。kubectl scale --replicas=0会把 Deployment 的期望状态改为 0，对应 ReplicaSet 也会同步缩到 0。这看起来像是“删掉了应用”，但实际上 Deployment、ReplicaSet 都还在，只是副本数为 0。恢复时用kubectl scale --replicas=3即可。如果你理解了这个机制，就不会在生产环境里通过删 Deployment 来做发布回滚，因为那会丢掉 Deployment 的版本历史。
实验 3 是最接近生产环境的一次训练。加了NoSchedule污点之后，新的 Pod 不会调度到这个节点上，但已经运行在上面的 Pod 不会被驱逐。想要让 Pod 主动离开，你还需要额外执行kubectl drain，它会做优雅驱逐，把节点上的 Pod 迁移到其他节点。这个区别如果你不清楚，生产环境故障排查时一定会被坑。
我自己的习惯是每隔一段时间就做一轮这样的故障注入练习，每次都能发现自己对某个机制的认知有盲区。比如我第一次做实验 3 时，忘了有 DaemonSet 会忽略污点继续运行，以至于节点 drain 的时候发现 DaemonSet Pod 一直删不掉，被卡住了很久。后来反应过来，DaemonSet 默认带有对 NoSchedule 污点的容忍，这是设计上的行为。
最后说一个我在内部培训里总结的教训：看课件只是输入，真正的能力提升发生在你主动制造故障并修复它的过程中。如果你能把上面三个实验做到不看文档就顺利完成，再去看任何生产环境的问题，你至少不会连排查方向都找不对。希望这个思路能帮到你。
本文还有配套的精品资源，点击获取
