简介：这份「Kubernetes课件分享」面向刚接触容器编排的开发者、运维人员与云计算学习者，围绕k8s基础入门与核心知识梳理展开，可帮助读者建立集群架构、资源对象与日常运维的整体认知。课件内容覆盖k8s基本概念、集群组件、Pod与Controller、Service、Label、Namespace，以及监控与日志、应用生命周期管理、调度、存储和集群安全等模块，既适合课堂讲解，也便于自学时按章查阅与复习。资源包内含1个pptx文件，压缩后约1.25MB，轻量便于传输和演示，可直接用于培训分享或学习笔记整理。目前已有2191人学习下载，说明其基础框架较受关注；通过目录化章节和命令示例，读者可快速定位kubectl常用操作、Deployment发布回滚伸缩等实践要点，形成后续深入实验与查漏补缺的参考线索。

1. 从一张架构图读懂 k8s：这份课件到底梳理了什么

很多人学 k8s 的第一个错觉，是把它当成一堆 kubectl 命令的集合，背完get、describe、logs就以为入门了。真到排查问题那天才发现，命令只是表皮，真正决定你能不能定位问题的是脑子里那张集群架构图：请求从哪进来、状态存在哪、谁在背后不断把实际状态拉回期望状态。这份课件最值得复习的地方，正是它先把 kube-apiserver、etcd、controller-manager、scheduler 和 Node 上的 kubelet、kube-proxy 摆成一张图，再往图里填 Pod、Controller、Service、Label、Namespace 这些对象。对正在系统学容器编排、或者准备把 k8s 基础过一遍的人来说，这份课件像一张提纲挈领的地图，六章内容从基本概念一路铺到监控日志、生命周期、调度、存储和集群安全，每一块都对应真实运维里绕不开的动作。复习时顺着这张地图走，比零散刷文章稳得多。

2. 集群架构与核心组件：控制面与节点各自在忙什么

Kubernetes 官方给它的定义很朴素：Google 在 2014 年开源的容器集群管理系统，简称 K8S，目标是让容器化应用的部署、扩展和管理变得简单高效。这句话里藏着一个关键判断——k8s 不是一个"运行容器"的东西，容器引擎才是；k8s 管的是"期望状态"，也就是你声明想要几个副本、什么镜像、暴露哪个端口，然后由集群里的一批组件持续把现实拉向声明。理解这一点，后面所有组件的行为都能推出来。

2.1 控制面四个组件：入口、存储、决策与调节

把控制面拆开看，四个组件职责边界其实异常清晰，复习时建议按"请求进来—状态落盘—决定放哪—持续纠偏"这条线记。

这张表最容易被背成四句孤立的话。串起来的逻辑是：kubectl 的请求打到 apiserver，apiserver 校验后把对象写进 etcd；controller-manager 里的各类控制器通过 apiserver 监听对象变化，发现某资源实际副本数不够就创建新的 Pod 对象；新 Pod 还没有归属节点，scheduler 介入挑一个 Node 并把绑定结果写回 apiserver；目标节点上的 kubelet 监听到"有活分给我了"，才开始真正创建容器。任何一个环节断了，现象都不一样——apiserver 挂了是所有操作都失败，etcd 挂了是集群"失忆"，scheduler 挂了是 Pod 一直 Pending。

2.2 节点侧三件套：kubelet、kube-proxy 与容器引擎

节点上的三个组件是把"声明"变成"现实"的最后一段路。kubelet 是 Master 在 Node 节点上的 Agent，管理本机运行容器的生命周期，包括创建容器、Pod 挂载数据卷、下载 secret、获取容器和节点状态等工作，它的一个核心动作是把每个 Pod 转换成一組容器。kube-proxy 在 Node 节点上实现 Pod 网络代理，维护网络规则和四层负载均衡。容器引擎（课件里写的是 docker 或 rocket）负责真正跑容器。

这里有个复习时特别值得停下来想的问题：为什么 Service 的 ClusterIP 能访问到一组 Pod，但节点上并没有一个"Service 进程"在监听？答案就在 kube-proxy——它维护的是转发规则，流量并不经过它本身。很多人第一次排查 Service 不通时，会去ps找一个叫 kube-proxy 的转发进程，找不到就怀疑组件没起来，这就是对"维护规则"和"代理流量"两种模式的混淆。梳理下来会发现，kube-proxy 属于典型的控制面思维落在数据面上：它写规则，内核执行。

2.3 五类核心对象：把"是什么"落到使用场景

课件把基本概念压缩成五组，每组都给了最短定义，复习时最好各配一个场景，否则定义记不住也用不上。

• Pod：最小部署单元，一组容器的集合，一个 Pod 中的容器共享网络命名空间，且 Pod 是短暂的。短暂这两个字分量很重，意味着不要把它当宠物养，重启、重建、换 IP 都是常态。
• Controllers：Deployment 管无状态应用部署，StatefulSet 管有状态应用部署，DaemonSet 管守护进程，Job 管一次性任务，Cronjob 管定时任务。选型判断只看一句：这个应用需不需要固定的身份和存储。
• Service：防止 Pod 失联，定义一组 Pod 的访问策略。Pod 会换 IP，Service 提供稳定入口。
• Label：附加到某个资源上的标签，用于关联对象、查询、筛选。它是 Service 选中 Pod、Deployment 管理 Pod 的纽带。
• Namespace：命名空间，将对象逻辑上分离。注意是逻辑隔离，不是网络隔离。

五组概念里最容易学成"名词解释"的是 Label。它的真正地位是 k8s 的"关系数据库外键"——Service 的 selector 和 Deployment 的 selector 都靠它匹配，一旦标签写错，Service 不会报错，只是后端为空，这是新手最常见的翻车现场之一。

3. 监控与日志：先能看见，才谈得上排障

集群跑起来只是开始，能不能看清它在干什么决定了你后续所有的排障效率。这一章的内容在课件里显得零散，但梳理下来其实是一条清晰的分层：集群整体状态、资源利用率、组件日志、应用日志，四层从上往下，范围逐级收窄。

3.1 集群与资源状态：从整体到单点的四级下钻

第一层看集群本身是否健康，第二层看谁在吃资源，第三层看具体对象的事件，第四层实时盯变化。

# 第一层：集群整体信息，确认 apiserver 可达、各组件地址正常 kubectl cluster-info # 需要更完整的组件与配置信息时再 dump，输出量大，排查疑难时用 kubectl cluster-info dump # 第二层：节点与 Pod 的资源消耗，前提是集群已部署 metrics-server kubectl top node <node name> kubectl top pod <pod name> # 第三层：查看对象的详细状态与事件，Pod 起不来时第一选择 kubectl describe <资源> <名称> # 第四层：持续观察某 Pod 的状态变化，适合盯启动过程 kubectl get pod <Pod 名称> --watch

几条命令背后的分工值得说清。cluster-info只回答"控制面还活着吗"，它不会告诉你业务有没有问题；describe输出的末尾那段 Events 才是排查 Pod 异常的金矿，ImagePullBackOff、CrashLoopBackOff、调度失败的原因几乎都写在那里；--watch适合在另开一个终端时守着，比如观察一次滚动升级过程中 Pod 的更替节奏。至于kubectl top，它依赖 Metrics-server + cAdvisor 这条链路采集数据，集群没装 Metrics-server 时命令会直接报错说找不到 metrics API，这不是权限问题，别往 RBAC 上查。

注意：kubectl top拿到的是瞬时采样值，不是历史曲线。做容量评估或事后复盘时它给不了依据，真正的历史数据要靠额外的监控体系留存。

3.2 两层日志：组件日志与应用日志别混着查

日志最容易出的错是"查错地方"。k8s 里的日志至少分两类，来源和管理方式完全不同。

组件日志指 kubelet、kube-proxy 这些集群自身进程的输出。用 systemd 管理的节点上，kubelet 日志走journalctl -u kubelet；以容器形式运行的组件（比如 kube-proxy）则用kubectl logs kube-proxy-btz4p -n kube-system查看；系统层面的信息还会落到/var/log/messages。这三条路径对应三种部署形态，复习时按"这个组件是被谁启动的"来判断该用哪条命令，比死记命令本身有用。

应用日志则是业务容器的标准输出，用kubectl logs系列命令获取：

# 查看 Pod 内容器的标准输出 kubectl logs <Pod 名称> # 持续跟踪输出，等价于 tail -f，调试时最常用 kubectl logs -f <Pod 名称> # Pod 内有多个容器时必须用 -c 指定，否则会提示需要明确容器 kubectl logs -f <Pod 名称> -c <容器名称>

-f和-c是两个高频参数：前者跟踪实时输出，后者在多容器 Pod 里指定目标容器。多容器场景在真实项目里很普遍，一个 Pod 里跑主应用加边车容器时，不加-c就会直接报错，这个报错信息其实很友好，照着改就行。

3.3 把日志落到宿主机：一个容易忽略的配置细节

容器标准输出适合看实时日志，但不适合长期留存，容器一重建日志就没了。课件给了一个把日志目录挂到宿主机的写法，思路很实用：

apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: web image: lizhenliang/nginx-php volumeMounts: - name: logs mountPath: /usr/local/nginx/logs # 容器内日志目录 volumes: - name: data hostPath: path: /tmp/logs # 宿主机上的落地目录 type: Directory

这段 YAML 里mountPath是容器内视角的路径，hostPath.path是节点上的真实路径，两者通过volumeMounts和volumes里同名的logs/data关联起来——注意这里volumeMounts引用的名字是logs，而volumes里定义的卷名是data，名字对不上就不会挂载成功，这是抄配置时最容易带过去的错误。正确做法是让两边名字保持一致。另外hostPath属于节点本地存储，Pod 漂到别的节点就看不到旧日志，生产环境更适合用集中式日志方案，这一条在复习存储章节时要连起来看。

4. 应用生命周期：从部署到回滚的一条完整链路

这一章是整份课件里最"可操作"的部分，也是面试和实操都绕不开的。K8s 对应用的管理不是一次性动作，而是一条闭环：创建、发布、升级、伸缩、回滚、删除。把这条链路走顺，才算真的会用一个 Deployment。

4.1 命令行快速起步与 YAML 声明式管理

先用命令行走一遍，理解每个动作产生了什么对象：

# 创建 Deployment，指定名称与镜像 kubectl create deployment web --image=lizhenliang/java-demo # 确认 Deployment 与 Pod 都起来了 kubectl get deploy,pods # 暴露服务，把 80 端口以 NodePort 方式发布，转发到容器 80 kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web # 确认 Service 已创建并拿到端口 kubectl get service

expose那条命令里三个端口参数经常被搞混：--port是 Service 自身暴露的端口，--target-port是容器实际监听的端口，--type=NodePort表示在每个节点上开一个高位端口对外。少写--target-port时它默认与--port相同，如果应用监听的不是 80，流量就会打空，表现为 Service 有 ClusterIP 但访问不通。

命令行适合试手，真实管理走 YAML。课件给出的 Deployment 模板是标准四段结构：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15 ports: - containerPort: 80

四个顶层字段对应四类信息：apiVersion是 API 版本，kind是资源类型，metadata是资源元数据，spec是资源规格。往下replicas是副本数量，selector是标签选择器，template是 Pod 模板，模板里又有自己的metadata（Pod 元数据）和spec（Pod 规格），最里层containers是容器配置。这里有个必须记住的约束：spec.selector.matchLabels必须能匹配上template.metadata.labels，两者对不上 apiserver 会直接拒绝创建。这个校验是好事，它防止了一个 Deployment 管不住自己 Pod 的尴尬局面。

4.2 升级、伸缩、回滚、删除的完整动作序列

四个动作对应四组命令，复习时建议按时间顺序理解它们在什么场景下用：

# 升级：把 web 里的容器镜像换成新版本 kubectl set image deployment/web nginx=nginx:1.15 kubectl rollout status deployment/web # 实时观察滚动升级进度 # 伸缩：手动改副本数，或配置自动扩缩容 kubectl scale deployment web --replicas=10 kubectl autoscale deployment web --min=10 --max=15 --cpu-percent=80 # 回滚：先看历史版本，再决定退到哪一版 kubectl rollout history deployment/web kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision=2 # 删除：Deployment 与 Service 分别删 kubectl delete deploy/web kubectl delete svc/web

rollout status是升级时最该养成的习惯，它会把进度打出来，卡住时你能立刻发现而不是等用户报障。rollout history配合--to-revision精确回退到指定版本，比起无脑undo一次退一版更可控。autoscale的三个参数里，--cpu-percent=80是触发阈值，含义是平均 CPU 利用率超过 80% 就扩，低于阈值一段时间后缩。自动扩缩容需要 Metrics-server 提供数据，这一点和上一章的kubectl top是同一条依赖链。

4.3 Pod 的设计模型：为什么它不是一个"容器"

课件在这部分提了一个很好的问题：Pod 本身是一个逻辑概念，没有具体存在，那究竟怎么实现的？答案绕不开两个共享。

共享网络：每个 Pod 里会先启动一个 infra container 小容器（基础容器），然后让其他容器加入它的网络命名空间，于是所有容器看到的网络视图完全一样——相同的网络设备、IP 地址、MAC 地址，容器之间可以直接用 127.0.0.1 通信。共享存储：通过挂载同一份卷实现存储共享。

理解了机制，Pod 存在的意义就清楚了：它为"亲密性应用"而生。课件列了三种典型场景——两个应用之间发生文件交互、需要通过 127.0.0.1 或 socket 通信（经典组合是 nginx + php）、需要发生频繁调用。反过来说，如果两个服务之间没有这种强耦合，硬塞进一个 Pod 只会让扩容和故障隔离都变难，这是选型时最容易走偏的地方。

4.4 镜像拉取策略与资源限制：两个常被跳过的字段

imagePullPolicy有三个取值，含义差异直接影响发布行为：

有个细节很容易被绕过：当镜像 tag 写成latest时，默认策略会变成 Always。所以线上用latest标签既不可追溯又每次都拉镜像，属于双重踩坑，规范做法是用明确的版本号配合默认策略。私有仓库还需要imagePullSecrets指定凭据，写法是在spec下引用一个已创建的 secret 名称。

资源限制则分两类，课件里的表述容易看反，这里按作用记更稳：limits是上限，容器能使用的最大配置，写spec.containers[].resources.limits.cpu和.memory；requests是申请量，调度器据此判断节点放不放得下。

apiVersion: v1 kind: Pod metadata: name: web spec: containers: - name: java image: lizhenliang/java-demo resources: requests: # 调度依据：节点至少要留出这么多资源 memory: "64Mi" cpu: "250m" limits: # 运行上限：超过会被限流或终止 memory: "128Mi" cpu: "500m"

cpu: "250m"里的 m 是千分之一核，250m 就是 0.25 核。这里最容易漏的是"只写 limits 不写 requests"，此时 requests 默认等于 limits，调度会按上限占位，节点明明还有余量却调度不进去；反过来只写 requests，容器跑起来可以随意抢占 CPU，一个失控进程能拖垮同节点其他 Pod。内存超 limits 会被 OOMKill，CPU 超 limits 只是被限流，这两种后果的区别在排查时很关键——看到容器反复重启，先看是不是内存 limit 给小了。

5. 调度、存储与集群安全：三块最容易一起复习的内容

这三块在课件目录里各自独立，实际却互相咬合：调度决定 Pod 落在哪个节点，存储决定它落在那里能不能拿到数据，安全决定它有没有资格拿。分开背很容易忘，连起来理解反而记得住。

5.1 调度：默认行为的边界在哪

课件对 scheduler 的描述很克制——根据调度算法为新创建的 Pod 选择一个 Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上。这几句话点出了一个默认事实：调度器不关心你的业务是不是有状态，它只看资源够不够、约束满不满足。所以复习调度时，真正要记的不是算法细节，而是"默认调度不保证什么"：它不保证同一组 Pod 分散到不同节点，不保证有状态 Pod 每次回到原节点，也不保证高优先级业务优先拿到资源。这些要靠节点亲和、污点容忍、Pod 反亲和等约束去表达，属于需要主动声明的部分。

5.2 存储：从 Pod 短暂性倒推出来的需求

存储这一章的所有设计都能从第一章那句"Pod 是短暂的"推出来。Pod 重建后容器内文件系统丢失，所以需要卷；容器重建后卷要能延续，所以需要独立于 Pod 生命周期的存储；Pod 漂移到别的节点后数据还得在，所以hostPath只能算临时方案。复习时按这条推理链走一遍，比背卷类型清单有效得多。第 3 章那个hostPath的例子正好可以当作反面案例来对照：它能解决日志落地，但解决不了跨节点问题。

5.3 集群安全：先分清谁能做什么

集群安全最容易学成名词堆砌。一个可用的切入点是按"三个问题"过一遍：谁在请求（身份认证）、能做什么（授权）、能做多细（准入控制）。对应的记忆锚点是——认证解决"你是谁"，授权解决"你能干什么"，准入控制解决"你提交的这份配置合不合规"。课件把集群安全作为独立一章而不是附在组件后面，这个编排本身就是提示：安全是横切关注点，它不在某条请求链的某一环，而是贯穿每一环。复习时不要把它当最后一块补充知识，而应当作回看前面所有章节的一副眼镜。

6. 复习清单：把六章内容压成一页可自查的表

到这里，整份课件的内容其实可以收敛成一张自检表。复习最怕的是"看的时候都懂，合上书什么都想不起来"，所以我习惯把每章压成几个能自己出题考自己的检查项，答不上来就回去翻对应章节，比通读第二遍效率高得多。

这张表的价值在于把"知识点"变成"可验证的掌握度"。整理这份清单时，我最大的感受是：k8s 的难点从来不是命令多，而是每个命令背后都有一层对象模型和一组组件在支撑，只记命令就等于只记了 API 表面。所以我的做法是每学一个命令，都强制问一句"它在改哪个对象、谁在监听这个对象"，答不出来就说明这块地图是缺的。

另外补两个查漏补缺的具体做法。一是把课件里的 YAML 全部手敲一遍而不是复制，敲的过程中必然会在volumeMounts和volumes名字、selector与labels对应这些地方卡住，卡住的地方就是你的易漏点。二是给自己出"故障题"：Pod 一直 Pending 该按什么顺序查、Service 访问不通先看哪一层、容器反复重启先看哪个字段，能顺着架构图说出排查顺序，比背十条命令更能说明你真的掌握了。从那以后我每次复习这套内容，都强制走一遍"对象—组件—命令"三连问，凡是答不上来的就标红回炉，一轮下来薄的地方一目了然。这份课件的完整内容按基本概念、监控日志、生命周期、调度、存储、集群安全六块组织，正好对应上面的自查表，需要的可以拿去对着补。希望帮到你。

本文还有配套的精品资源，点击获取