简介：面向容器与云原生入门学习者的 Kubernetes 课件，围绕 k8s 基础知识点展开，适合希望系统梳理集群架构、核心对象与日常运维命令的读者。压缩包内含 1 个 pptx 演示文稿，约 1.25MB，以分章幻灯片组织内容，便于课堂讲授或自学时按目录推进。课件从 Kubernetes 的定位与集群组件讲起，说明接口服务、控制器管理器、调度器、键值存储、节点代理与网络代理等角色职责，并解释 Pod、控制器、服务、标签、命名空间等概念；随后延伸到指标监控、资源用量查看、组件与应用日志定位，以及部署控制器的创建、发布、升级、回滚和弹性伸缩。内容还串联调度、存储、集群安全等章节，目录由浅入深，能帮助读者建立从架构认识到命令实践的知识框架，也适合作为面试复习、课堂汇报或整理学习笔记的提纲。目前已有 2191 人学习下载，可作为入门梳理与后续实验的索引。
1. 集群地图：从 kubectl 到 kubelet 的一条控制链
很多人第一次接触 k8s，会以为 kubectl 是在直接指挥某台机器上的容器。实际不是：kubectl 只把请求发给 kube-apiserver，apiserver 校验后写进 etcd，controller-manager 和 scheduler 各自盯着状态变化去做事，最后 kubelet 在节点上把 Pod 变成一组真正运行的容器。把这条链记住，后面所有对象、命令、报错都能挂上去——apiserver 是唯一入口，etcd 是唯一状态源，scheduler 决定"放哪"，kubelet 负责"跑起来"，kube-proxy 负责"能访问"。这份课件沿基本概念、监控与日志、应用生命周期、调度、存储、集群安全六块展开，适合已经能敲几条 kubectl、但知识点在脑子里还是散落状态的人，用来把碎片串成一张能复习的地图。
2. 核心对象：Pod、Controller、Service、Label、Namespace 的复习重点
k8s 的对象看着多，真正需要先吃透的是五个：Pod、Controller、Service、Label、Namespace。课件把它们放在基本概念一章，是因为后面监控、生命周期、调度、存储、安全全都建立在这五个词上——Pod 是调度和存储的载体，Controller 是生命周期的执行者，Service 和 Label 决定了服务能不能被访问到，Namespace 决定了安全边界画在哪。复习时不要只背定义，要能回答"这个对象解决的是哪一类问题、少了它会出现什么现象"。
2.1 五个对象的分工：一句话定义与它挡掉的问题
把五个对象并排放在一张表里看，比逐个背定义更容易形成结构感。表格最后一列是复习时最容易背漏的部分，也是做题和实操时最常出错的地方。
| 对象 | 一句话定义 | 挡掉的问题 | 容易背漏的点 |
|---|---|---|---|
| Pod | 最小部署单元，一组共享网络命名空间的容器集合 | 把必须紧耦合的进程放在一起调度 | "最小"指调度单位，不是容器数量 |
| Controller | 一类资源的控制器，负责把实际状态拉回期望状态 | 手工维持副本数与版本 | 一个资源对应一个控制器 |
| Service | 为一组 Pod 定义稳定的访问入口和访问策略 | Pod 重建后 IP 变化导致调用方失联 | Service 本身不跑进程，靠 selector 选 Pod |
| Label | 附加在资源上的键值对 | 让对象之间可以关联、查询、筛选 | 键值差一个字符，关联就断 |
| Namespace | 对象的逻辑分区 | 多团队多环境共用一个集群时的隔离 | 是逻辑隔离，不是网络隔离 |
这张表读下来会发现一个规律：越是被叫作"基础概念"的对象，越不是孤立存在的。Pod 需要 Controller 来维持数量，Controller 需要 Label 来选中 Pod，Service 需要 Label 来找到后端，Namespace 则给这一整套东西划出作用范围。单独背任何一个都记不牢，按"谁依赖谁"去记，回忆时能顺藤摸瓜。
2.2 Pod 为什么是"一组容器"：共享网络与共享存储的实现
容器之间靠 Namespace 做隔离，Pod 反其道而行，要在容器之间做共享。课件里点明了实现方式：每个 Pod 先启动一个 infra container（也叫 pause 容器），由它先占住一个网络命名空间，其余容器再加入这个命名空间。于是这些容器看到的网络设备、IP 地址、Mac 地址完全一样，彼此可以用 127.0.0.1 直接通信，端口也不会冲突。这正是 nginx 加 php 这类组合被塞进同一个 Pod 的原因——它们本来就要在本地互相调用。
存储共享靠的是挂载同一个卷。下面这个双容器 Pod 把两件事放在一起演示：一个容器写日志，另一个容器读同一份日志。
apiVersion: v1 kind: Pod metadata: name: web-with-log spec: containers: - name: web # 主应用容器，日志写在 /var/log/nginx image: nginx:1.15 volumeMounts: - name: logs # 引用下方 volumes 里同名的卷 mountPath: /var/log/nginx - name: exporter # 旁路容器，读同一份日志做采集 image: busybox command: ["sh", "-c", "tail -f /data/access.log"] volumeMounts: - name: logs mountPath: /data volumes: - name: logs # 名字必须与两个 volumeMounts 的 name 完全一致 emptyDir: {}两个容器共享同一个 emptyDir，web 写进去，exporter 从另一个路径读出来；它们同时共享网络命名空间，exporter 访问 127.0.0.1 就能打到 nginx。需要留意的是 emptyDir 的生命周期跟 Pod 绑定，Pod 一删数据就没了，要跨 Pod 保留就得换成持久卷——这条线索会直接接到存储那一章。
2.3 五种 Controller 的选型：无状态、有状态、守护、一次性、定时
Controller 是"期望状态"模型的执行者，课件列了五种，选型判断其实只有两个维度：这个工作负载需不需要稳定身份，以及它是一直跑还是跑完就结束。
| 类型 | 适用场景 | 副本与调度特点 | 典型误用 |
|---|---|---|---|
| Deployment | 无状态应用，如 Web 前端、API 服务 | 副本可互换，滚动更新 | 拿它跑数据库，Pod 重建后身份对不上 |
| StatefulSet | 有状态应用，如数据库、消息队列 | 每个副本有稳定网络标识与存储 | 当成普通 Deployment 随意扩缩 |
| DaemonSet | 每个节点都要跑一份，如日志采集、网络插件 | 节点增加自动补 Pod | 用它跑只需要单实例的服务 |
| Job | 一次性任务，如数据迁移、批处理 | 跑完即止，可设重试次数 | 用 Deployment 跑批处理，跑完还在重启 |
| CronJob | 定时任务，按时间表创建 Job | 依赖调度表达式 | 表达式时区与预期不一致 |
误用最多的两种情况，一是拿 Deployment 跑有状态服务，Pod 重建后数据卷和网络标识全变，应用自己认不回来；二是拿 Deployment 跑一次性任务，任务跑完了容器退出又被拉起来，日志里全是重复执行。复习时把这张表和"这个负载能不能随便换一个副本顶上"这个问题绑在一起，判断会快很多。
2.4 Label 与 Namespace：两个被低估的"胶水"对象
Label 是 k8s 里对象之间建立关系的唯一手段。Service 靠 selector 找 Pod，Deployment 靠 selector 管自己创建的 Pod，节点靠标签参与调度。它本身不产生任何运行时行为，但一旦对不上，表现出来的是"服务不通""副本数不对"这类看起来像网络或调度问题的现象。Namespace 则把对象逻辑分区，kubectl 默认在 default 里操作，跨命名空间必须显式指定，同名对象可以在不同命名空间共存。
# 给节点打标签，为后续调度做准备 kubectl label node node-1 disktype=ssd # 按标签筛选 Pod，并显示标签，用来核对 selector 能不能命中 kubectl get pods -l app=nginx --show-labels # 查看 Service 背后的 Endpoints，列表为空通常意味着 selector 没匹配上 kubectl get endpoints web第三条命令是排查服务失联最快的一步：Endpoints 为空，说明 Service 的 selector 与任何 Pod 的标签都不匹配，或者匹配上了但 Pod 没有 Ready。先看这里，比一上来就怀疑网络插件要省时间得多。标签和命名空间都属于"平时不觉得重要、出问题时第一个被怀疑"的类型，复习时值得单独留一页。
3. 应用生命周期：Deployment 的创建、升级、伸缩与回滚
课件把应用生命周期单独成章，是因为这是日常操作密度最高的一块：部署、发布、升级、扩容、回滚、删除，几乎每天都在重复。这一章的重点不是背命令，而是理解"期望状态"这套模型——你提交的是一个目标，控制器负责把集群慢慢推到那个目标上，中间的进度、失败、回滚都有对应的观察手段。命令记不住可以查，模型没建立起来，出问题时连该看哪条输出都不知道。
3.1 命令行快速跑通一次部署与发布
先用命令行走一遍最短路径，建立"创建—暴露—访问"的完整印象，再去看 YAML 会轻松很多。
# 创建一个 Deployment，镜像用课件里的示例应用 kubectl create deployment web --image=java-demo # 确认 Deployment 和 Pod 都起来了 kubectl get deploy,pods # 把 Deployment 暴露成 Service，类型为 NodePort，对外提供访问 kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web # 查看 Service 分配到的端口 kubectl get service web参数里最容易混淆的是两个端口：--port是 Service 自己暴露的端口，--target-port是容器实际监听的端口，写反或写错的表现是 Service 存在、Endpoints 也有，但访问就是不通。--type=NodePort会在每个节点上开一个高位端口，适合临时验证；正式对外一般换成别的类型或走入口层。--name不写会默认沿用 Deployment 的名字，显式写出来在排查时更清楚。
3.2 YAML 的四层骨架：apiVersion、kind、metadata、spec
命令行能快速起步，但真正落到版本管理里的都是 YAML。课件的 Deployment 示例可以拆成四层来看，每一层出错的表现都不一样。
| 字段 | 作用 | 写错会怎样 |
|---|---|---|
| apiVersion | 指定资源所属的 API 组和版本 | 与 kind 不匹配时直接报找不到资源 |
| kind | 资源类型 | 拼错会提示服务端没有这个资源 |
| metadata | 名称、命名空间、标签等元数据 | 缺 name 无法创建，标签错会导致关联断 |
| spec | 资源规格，不同资源结构完全不同 | 缩进错是最常见的 YAML 翻车点 |
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 # 期望副本数，控制器会持续向这个数字对齐 selector: matchLabels: app: nginx # 必须与下面 template 里的标签逐字一致 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15 ports: - containerPort: 80selector.matchLabels和template.metadata.labels是同一组键值，只改一边不改另一边，提交时会直接报 selector 不匹配。replicas是期望值不是上限，节点资源不够时 Pod 会停在 Pending 而不是自动少跑几个。YAML 的层级靠缩进表达，同一层级多一个空格或少一个空格，报错信息往往指向别处，这是新手最常卡住的地方。
3.3 升级、回滚、伸缩、删除的标准动作
滚动更新是 Deployment 最有价值的能力，配套的观察和回退命令要一起记住，否则升级出问题时没有后悔药。
# 升级镜像，触发一次滚动更新 kubectl set image deployment/web nginx=nginx:1.15 # 观察滚动更新进度，卡住时会停在某个副本数上 kubectl rollout status deployment/web # 查看历史版本，确认要回退到哪一版 kubectl rollout history deployment/web # 回退到上一版，或指定具体版本号 kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision=2 # 手动扩到 10 个副本 kubectl scale deployment web --replicas=10 # 基于 CPU 的自动伸缩，副本在 10 到 15 之间浮动 kubectl autoscale deployment web --min=10 --max=15 --cpu-percent=80 # 删除资源，deploy 与 svc 要分别删 kubectl delete deploy/web kubectl delete svc/webrollout status是升级过程中最该盯的命令，它把"现在推进到第几个副本了"直接打出来，卡住时能立刻发现是新版本起不来还是探针没过。rollout undo默认回上一版，带--to-revision可以跳到指定版本，但要先rollout history确认版本号对应的内容。自动伸缩依赖 metrics-server 提供 CPU 数据，集群里没装或没跑起来，HPA 的指标会一直显示 unknown，看起来像"配了没生效"。
3.4 镜像拉取策略与资源配额：两个必须写对的字段
imagePullPolicy有三个取值，默认行为跟镜像 tag 有关，这一点经常被误解。
| 取值 | 行为 | 适用场景 |
|---|---|---|
| IfNotPresent | 宿主机上不存在时才拉取 | 固定版本镜像，日常最常用 |
| Always | 每次创建 Pod 都重新拉取 | 使用 latest 或需要强制更新 |
| Never | 永不主动拉取，只用本地已有镜像 | 离线环境、预置镜像 |
apiVersion: v1 kind: Pod metadata: name: web spec: containers: - name: java image: java-demo imagePullPolicy: IfNotPresent # 本地没有才去拉，避免每次重建都走网络 resources: requests: # 调度依据：节点至少要有这么多空闲资源 memory: "64Mi" cpu: "250m" limits: # 运行时上限：超过内存会被 OOMKill memory: "128Mi" cpu: "500m"requests和limits的分工是这一节的核心：requests 是调度器判断节点放不放得下的依据，limits 是容器运行时能用的上限。CPU 单位里的m表示千分之一核，250m就是四分之一核、1000m等于一核。只写 limits 不写 requests，调度器会按 limits 的默认规则处理，容易出现节点看着还有余量、Pod 却调不上去的情况；内存 limits 给小了，进程一涨就被 OOMKill，日志里只留下一行退出码，很容易误判成应用 bug。
4. 监控与日志：集群状态、资源利用率与两级日志链路
监控与日志这一章在课件里篇幅不大，但它是排障时真正救命的部分。复习时把它拆成两层：一层是"集群和资源现在什么状态"，用 cluster-info、describe、get --watch 和 top 解决；另一层是"出问题时去哪里看日志"，组件日志和应用日志走的是完全不同的路径。很多人排障慢，不是不会命令，而是不知道先看哪一层，于是在错误的日志文件里翻了半小时。
4.1 集群与资源状态：几条命令的分工
# 集群整体信息与各组件地址 kubectl cluster-info # 集群详细状态转储，组件异常时用来抓现场 kubectl cluster-info dump # 看某个资源的详细信息和事件，Pending、拉镜像失败都在这 kubectl describe pod my-pod # 持续观察 Pod 状态变化，适合盯着启动过程 kubectl get pod my-pod --watchdescribe输出末尾的 Events 是排查启动失败的第一现场：镜像拉不动、调度失败、探针失败、卷挂载不上，都会按时间顺序留在这里。--watch适合配合另一个窗口做操作，改完 YAML 就能看到状态从 Pending 到 ContainerCreating 再到 Running 的迁移过程，卡在哪一步一目了然。cluster-info dump输出量很大，一般在怀疑控制面组件异常时才用，平时看cluster-info确认各组件地址就够。
4.2 资源利用率：metrics-server 与 cAdvisor 的分工
kubectl top不是 kubectl 自己算出来的，它向 metrics-server 要数据，metrics-server 再从各节点的 cAdvisor 采集容器资源消耗。这条链路任何一环断了，top 都会报错或没有输出。所以看到 top 不可用时，排查顺序是：metrics-server 的 Pod 是否在跑、apiserver 的聚合层是否注册成功、节点上的 kubelet 是否正常。
# 节点维度的 CPU 与内存消耗 kubectl top node node-1 # Pod 维度的消耗，用来定位是哪个 Pod 在吃资源 kubectl top pod my-pod # 确认 metrics-server 是否正常运行，通常位于 kube-system kubectl get pods -n kube-system | grep metricstop 反映的是瞬时值，做容量规划要看一段时间的趋势，而不是某一眼的数字。单看一个 Pod 的 top 意义有限，把它和这个 Pod 的 requests、limits 放在一起对比才有判断力：接近 limits 说明配额给紧了或者真有异常，远低于 requests 说明申请多了、节点利用率被浪费。
4.3 组件日志：systemd 管理与容器管理两条路
组件日志走哪条路径，取决于这个组件是怎么部署的。kubelet 一般由 systemd 托管，日志进 journalctl；kube-proxy、网络插件这类以静态 Pod 形式运行的组件，日志要用 kubectl logs 看，命名空间通常是 kube-system。系统层面的记录还会落在系统日志文件里。
# kubelet 由 systemd 管理，用 journalctl 跟踪 journalctl -u kubelet -f # kube-proxy 以 Pod 形式运行，按 Pod 名取日志 kubectl logs kube-proxy-btz4p -n kube-system # 系统日志里找内核与容器运行时相关的记录 tail -n 100 /var/log/messages先确认组件是 systemd 服务还是静态 Pod，再去选对应的命令，这一步能省掉大量无效翻找。另外kubectl logs对静态 Pod 同样适用，但 Pod 名带随机后缀，每次重建都会变，脚本里最好用标签选择器取，而不是写死名字。
4.4 应用日志：kubectl logs 的三种用法与落盘
# 看容器标准输出，最简单的一种 kubectl logs my-pod # 持续跟踪，等价于 tail -f kubectl logs -f my-pod # Pod 内有多个容器时必须指定容器名，否则直接报错 kubectl logs -f my-pod -c webkubectl logs只能看到写到标准输出的内容。应用如果把日志写进文件，就得靠挂载卷把目录带出来，或者用旁路容器采集。下面这个 Pod 把容器内的日志目录挂到节点上，Pod 重建后文件还在。
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: web image: nginx:1.15 volumeMounts: - name: logs # 必须与下面 volumes 的 name 一致 mountPath: /var/log/nginx volumes: - name: logs # 这里写的是 logs，不能换成别的名字 hostPath: path: /tmp/logs # 节点上的目录，Pod 重建后日志仍在 type: DirectoryvolumeMounts.name和volumes.name是一对引用关系，写成两个不同名字，Pod 会停在 ContainerCreating 并报找不到卷，报错信息里提到的是卷名，很容易被误读成存储插件的问题。hostPath 把节点目录挂进容器，适合单机排查和验证，多节点环境下每个节点的目录是独立的，Pod 调度到哪台机器日志就在哪台，不适合当生产方案。
5. 易错点排查：镜像拉取、资源写法与 Service 失联的坑
这一章按"概念、配置、排查"三类整理课件里最容易反复踩的点。三类错误的共同特征是：命令没错、YAML 也能提交，但结果和预期不一样，而且报错信息往往指向别处。复习时把每条当成一个"症状—原因—动作"的小病例记住，比单纯背字段有用得多。
5.1 概念类易错：把 Pod 当成一台稳定的机器
易漏点：认为 Pod 重建后 IP、名称、本地存储都还在，于是把连接地址、缓存目录直接写死在 Pod 里。
为什么漏："Pod 是短暂的"在定义里只有几个字，实际影响却分散在网络、存储、服务发现三个地方；只要不触发重建，这个错误可以潜伏很久，一滚动更新就集中爆发。
怎么补：记住稳定的是 Controller 和 Service，不是 Pod。需要稳定网络标识用 StatefulSet，需要稳定访问入口用 Service，需要数据不丢用持久卷。每次写业务 YAML 前先问一句"这个 Pod 死了以后谁来接住"，答案落在哪个对象上，配置就往哪个方向写。
5.2 配置类易错：imagePullPolicy 与 resources 写反
易漏点一：镜像 tag 用了 latest，策略却写 IfNotPresent，节点上一直跑旧镜像，升级看起来"没生效"。
为什么漏：默认策略的判定条件和 tag 有关，很多人以为只要写了 IfNotPresent 就是"每次都检查"，实际上本地有镜像就直接用。
怎么补：固定版本用 IfNotPresent，latest 或需要强制更新用 Always，离线环境用 Never。更重要的是升级时改 tag 而不是依赖策略，镜像版本写死在 YAML 里，回滚才有明确的落点。
易漏点二：requests 和 limits 只写一个，或者两个数值写反。
为什么漏：两个字段名相近、在示例里经常并排出现，抄的时候容易错行；而且写错之后 Pod 照样能起来，问题要等到资源紧张才暴露。
怎么补：requests 决定调度，limits 决定运行时上限。内存 limits 给小了会被 OOMKill，CPU limits 给小了会一直被限流、表现为"服务没挂但特别慢"。写完用kubectl describe pod核对实际生效的配额，比盯着 YAML 看更可靠。
5.3 排查类易错：Service 访问不通与日志对不上
易漏点：Service 建好了但访问不通，第一反应是去查网络插件和防火墙。
为什么漏：网络问题听起来最像"访问不通"的原因，而 selector 和标签这一层在 YAML 里不显眼，容易被跳过。
怎么补：按顺序走三步——先kubectl get endpoints，为空就是没匹配上或 Pod 没 Ready；再核对 Service 的 selector 与 Pod 的 labels 是否逐字一致，包括大小写和多余空格；最后才看端口映射和 kube-proxy。这个顺序能把大部分问题挡在前两步。
易漏点：kubectl logs报 "a container name must be specified"。
为什么漏：平时用的都是单容器 Pod，命令不带-c也没问题，换成多容器 Pod 后同一个命令直接失败。
怎么补：先用kubectl describe pod看容器列表，再用logs -c指定。同时确认日志到底写去了哪里——写标准输出的 logs 能看到，写文件的只能靠挂载卷带出来或者在容器里 exec 进去看。
6. 调度、存储与安全：三块内容的复习清单与查漏方式
调度这块的核心是 kube-scheduler 根据调度算法为新创建的 Pod 选节点，可以放在同一个节点，也可以分散到不同节点。它做判断的硬依据之一就是 requests——这也是上一章说 requests 写错会连带出问题的原因。复习时按三问过一遍：谁决定（scheduler）、依据什么（资源请求、标签、亲和性与污点容忍）、失败看哪（describe 里的 Events，Pending 加 Insufficient 基本就是资源不够）。
存储这块按生命周期从短到长记：emptyDir 随 Pod 消失，hostPath 跟着节点走，持久卷独立于 Pod 存在，靠 PVC 申请、PV 提供。梳理下来会发现，存储的考点不在怎么创建，而在"Pod 重建后数据还在不在"这条分界线上，判断标准就是看它挂的是哪一种卷。
安全这块落在入口与边界：apiserver 是所有请求的唯一入口，认证、授权、准入依次过；ServiceAccount 给 Pod 内的进程一个访问 apiserver 的身份，Secret 存敏感配置，Namespace 画逻辑边界，RBAC 决定谁能在哪个范围对什么资源做什么动作。最容易忽略的是"Pod 里的进程默认就带一个 ServiceAccount"，权限给大了，边界就形同虚设。
| 模块 | 必答问题 | 检查动作 |
|---|---|---|
| 调度 | Pod 为什么停在 Pending | kubectl describe pod看 Events 与资源请求 |
| 存储 | Pod 重建后数据还在吗 | 确认挂的是 emptyDir、hostPath 还是 PVC |
| 安全 | 谁用哪个身份访问 apiserver | kubectl get sa,rolebinding -n 命名空间 |
查漏的方式很土但有效：拿一张白纸写下六个章节名，每章下面强制写出三个"如果……会怎样"的问题，写不出来的地方就是没吃透的地方，回头对着课件那一节补。我自己的习惯是每次改完 YAML 先跑一遍kubectl apply --dry-run=client -f过语法，再真正 apply，最后一定kubectl get endpoints确认服务真的接上了——这个习惯是被一次"YAML 提交成功、服务从头到尾没通"的经历逼出来的。希望帮到你。
本文还有配套的精品资源，点击获取
