简介这份「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 控制面四个组件入口、存储、决策与调节把控制面拆开看四个组件职责边界其实异常清晰复习时建议按请求进来—状态落盘—决定放哪—持续纠偏这条线记。组件核心职责复习时的记忆锚点kube-apiserver集群统一入口以 RESTful API 提供接口服务所有对象资源的增删改查和监听都经它处理唯一读写 etcd 的组件其它组件都围着它转kube-controller-manager处理集群常规后台任务一个资源对应一个控制器它负责管理这些控制器期望状态与实际状态的纠偏器kube-scheduler根据调度算法为新创建的 Pod 选择一个 Node只做决策不落地落地靠 kubeletetcd分布式键值存储保存集群状态数据如 Pod、Service 等对象信息全集群的唯一事实来源这张表最容易被背成四句孤立的话。串起来的逻辑是kubectl 的请求打到 apiserverapiserver 校验后把对象写进 etcdcontroller-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 都是常态。ControllersDeployment 管无状态应用部署StatefulSet 管有状态应用部署DaemonSet 管守护进程Job 管一次性任务Cronjob 管定时任务。选型判断只看一句这个应用需不需要固定的身份和存储。Service防止 Pod 失联定义一组 Pod 的访问策略。Pod 会换 IPService 提供稳定入口。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 --imagelizhenliang/java-demo # 确认 Deployment 与 Pod 都起来了 kubectl get deploy,pods # 暴露服务把 80 端口以 NodePort 方式发布转发到容器 80 kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb # 确认 Service 已创建并拿到端口 kubectl get serviceexpose那条命令里三个端口参数经常被搞混--port是 Service 自身暴露的端口--target-port是容器实际监听的端口--typeNodePort表示在每个节点上开一个高位端口对外。少写--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 模板模板里又有自己的metadataPod 元数据和specPod 规格最里层containers是容器配置。这里有个必须记住的约束spec.selector.matchLabels必须能匹配上template.metadata.labels两者对不上 apiserver 会直接拒绝创建。这个校验是好事它防止了一个 Deployment 管不住自己 Pod 的尴尬局面。4.2 升级、伸缩、回滚、删除的完整动作序列四个动作对应四组命令复习时建议按时间顺序理解它们在什么场景下用# 升级把 web 里的容器镜像换成新版本 kubectl set image deployment/web nginxnginx:1.15 kubectl rollout status deployment/web # 实时观察滚动升级进度 # 伸缩手动改副本数或配置自动扩缩容 kubectl scale deployment web --replicas10 kubectl autoscale deployment web --min10 --max15 --cpu-percent80 # 回滚先看历史版本再决定退到哪一版 kubectl rollout history deployment/web kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision2 # 删除Deployment 与 Service 分别删 kubectl delete deploy/web kubectl delete svc/webrollout status是升级时最该养成的习惯它会把进度打出来卡住时你能立刻发现而不是等用户报障。rollout history配合--to-revision精确回退到指定版本比起无脑undo一次退一版更可控。autoscale的三个参数里--cpu-percent80是触发阈值含义是平均 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有三个取值含义差异直接影响发布行为取值行为适用场景IfNotPresent默认值宿主机上不存在该镜像时才拉取大多数常规场景启动快Always每次创建 Pod 都重新拉取用固定 tag 或 latest 时保证拿到最新镜像Never永远不会主动拉取该镜像离线环境或预置镜像的节点有个细节很容易被绕过当镜像 tag 写成latest时默认策略会变成 Always。所以线上用latest标签既不可追溯又每次都拉镜像属于双重踩坑规范做法是用明确的版本号配合默认策略。私有仓库还需要imagePullSecrets指定凭据写法是在spec下引用一个已创建的 secret 名称。资源限制则分两类课件里的表述容易看反这里按作用记更稳limits是上限容器能使用的最大配置写spec.containers[].resources.limits.cpu和.memoryrequests是申请量调度器据此判断节点放不放得下。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: 500mcpu: 250m里的 m 是千分之一核250m 就是 0.25 核。这里最容易漏的是只写 limits 不写 requests此时 requests 默认等于 limits调度会按上限占位节点明明还有余量却调度不进去反过来只写 requests容器跑起来可以随意抢占 CPU一个失控进程能拖垮同节点其他 Pod。内存超 limits 会被 OOMKillCPU 超 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. 复习清单把六章内容压成一页可自查的表到这里整份课件的内容其实可以收敛成一张自检表。复习最怕的是看的时候都懂合上书什么都想不起来所以我习惯把每章压成几个能自己出题考自己的检查项答不上来就回去翻对应章节比通读第二遍效率高得多。章节自查问题答不上来的信号架构与组件一个 Pod 从被创建到容器跑起来经过哪几个组件、按什么顺序说不清 scheduler 和 kubelet 谁先谁后核心对象Deployment 的 selector 和 Pod 模板的 label 对不上会怎样以为会静默失败而不是被 apiserver 拒绝监控日志kubectl top报找不到 metrics API该查什么第一反应去查 RBAC 权限生命周期滚动升级卡住了用哪条命令看进度、哪条命令回退只会get pods反复刷镜像与资源内存超 limits 和 CPU 超 limits 后果一样吗以为都会导致重启调度存储安全Pod 漂移后 hostPath 里的日志还在不在认为挂到宿主机就永久保存了这张表的价值在于把知识点变成可验证的掌握度。整理这份清单时我最大的感受是k8s 的难点从来不是命令多而是每个命令背后都有一层对象模型和一组组件在支撑只记命令就等于只记了 API 表面。所以我的做法是每学一个命令都强制问一句它在改哪个对象、谁在监听这个对象答不出来就说明这块地图是缺的。另外补两个查漏补缺的具体做法。一是把课件里的 YAML 全部手敲一遍而不是复制敲的过程中必然会在volumeMounts和volumes名字、selector与labels对应这些地方卡住卡住的地方就是你的易漏点。二是给自己出故障题Pod 一直 Pending 该按什么顺序查、Service 访问不通先看哪一层、容器反复重启先看哪个字段能顺着架构图说出排查顺序比背十条命令更能说明你真的掌握了。从那以后我每次复习这套内容都强制走一遍对象—组件—命令三连问凡是答不上来的就标红回炉一轮下来薄的地方一目了然。这份课件的完整内容按基本概念、监控日志、生命周期、调度、存储、集群安全六块组织正好对应上面的自查表需要的可以拿去对着补。希望帮到你。本文还有配套的精品资源点击获取