简介面向容器与云原生入门学习者的 Kubernetes 课件围绕 k8s 基础知识点展开适合希望系统梳理集群架构、核心对象与日常运维命令的读者。压缩包内含 1 个 pptx 演示文稿约 1.25MB以分章幻灯片组织内容便于课堂讲授或自学时按目录推进。课件从 Kubernetes 的定位与集群组件讲起说明接口服务、控制器管理器、调度器、键值存储、节点代理与网络代理等角色职责并解释 Pod、控制器、服务、标签、命名空间等概念随后延伸到指标监控、资源用量查看、组件与应用日志定位以及部署控制器的创建、发布、升级、回滚和弹性伸缩。内容还串联调度、存储、集群安全等章节目录由浅入深能帮助读者建立从架构认识到命令实践的知识框架也适合作为面试复习、课堂汇报或整理学习笔记的提纲。目前已有 2191 人学习下载可作为入门梳理与后续实验的索引。1. 集群地图从 kubectl 到 kubelet 的一条控制链很多人第一次接触 k8s会以为 kubectl 是在直接指挥某台机器上的容器。实际不是kubectl 只把请求发给 kube-apiserverapiserver 校验后写进 etcdcontroller-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 选 PodLabel附加在资源上的键值对让对象之间可以关联、查询、筛选键值差一个字符关联就断Namespace对象的逻辑分区多团队多环境共用一个集群时的隔离是逻辑隔离不是网络隔离这张表读下来会发现一个规律越是被叫作基础概念的对象越不是孤立存在的。Pod 需要 Controller 来维持数量Controller 需要 Label 来选中 PodService 需要 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: {}两个容器共享同一个 emptyDirweb 写进去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 找 PodDeployment 靠 selector 管自己创建的 Pod节点靠标签参与调度。它本身不产生任何运行时行为但一旦对不上表现出来的是服务不通副本数不对这类看起来像网络或调度问题的现象。Namespace 则把对象逻辑分区kubectl 默认在 default 里操作跨命名空间必须显式指定同名对象可以在不同命名空间共存。# 给节点打标签为后续调度做准备 kubectl label node node-1 disktypessd # 按标签筛选 Pod并显示标签用来核对 selector 能不能命中 kubectl get pods -l appnginx --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 --imagejava-demo # 确认 Deployment 和 Pod 都起来了 kubectl get deploy,pods # 把 Deployment 暴露成 Service类型为 NodePort对外提供访问 kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb # 查看 Service 分配到的端口 kubectl get service web参数里最容易混淆的是两个端口--port是 Service 自己暴露的端口--target-port是容器实际监听的端口写反或写错的表现是 Service 存在、Endpoints 也有但访问就是不通。--typeNodePort会在每个节点上开一个高位端口适合临时验证正式对外一般换成别的类型或走入口层。--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 nginxnginx:1.15 # 观察滚动更新进度卡住时会停在某个副本数上 kubectl rollout status deployment/web # 查看历史版本确认要回退到哪一版 kubectl rollout history deployment/web # 回退到上一版或指定具体版本号 kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision2 # 手动扩到 10 个副本 kubectl scale deployment web --replicas10 # 基于 CPU 的自动伸缩副本在 10 到 15 之间浮动 kubectl autoscale deployment web --min10 --max15 --cpu-percent80 # 删除资源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: 500mrequests和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 托管日志进 journalctlkube-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 就是每次都检查实际上本地有镜像就直接用。怎么补固定版本用 IfNotPresentlatest 或需要强制更新用 Always离线环境用 Never。更重要的是升级时改 tag 而不是依赖策略镜像版本写死在 YAML 里回滚才有明确的落点。易漏点二requests 和 limits 只写一个或者两个数值写反。为什么漏两个字段名相近、在示例里经常并排出现抄的时候容易错行而且写错之后 Pod 照样能起来问题要等到资源紧张才暴露。怎么补requests 决定调度limits 决定运行时上限。内存 limits 给小了会被 OOMKillCPU 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 里的 EventsPending 加 Insufficient 基本就是资源不够。存储这块按生命周期从短到长记emptyDir 随 Pod 消失hostPath 跟着节点走持久卷独立于 Pod 存在靠 PVC 申请、PV 提供。梳理下来会发现存储的考点不在怎么创建而在Pod 重建后数据还在不在这条分界线上判断标准就是看它挂的是哪一种卷。安全这块落在入口与边界apiserver 是所有请求的唯一入口认证、授权、准入依次过ServiceAccount 给 Pod 内的进程一个访问 apiserver 的身份Secret 存敏感配置Namespace 画逻辑边界RBAC 决定谁能在哪个范围对什么资源做什么动作。最容易忽略的是Pod 里的进程默认就带一个 ServiceAccount权限给大了边界就形同虚设。模块必答问题检查动作调度Pod 为什么停在 Pendingkubectl describe pod看 Events 与资源请求存储Pod 重建后数据还在吗确认挂的是 emptyDir、hostPath 还是 PVC安全谁用哪个身份访问 apiserverkubectl get sa,rolebinding -n 命名空间查漏的方式很土但有效拿一张白纸写下六个章节名每章下面强制写出三个如果……会怎样的问题写不出来的地方就是没吃透的地方回头对着课件那一节补。我自己的习惯是每次改完 YAML 先跑一遍kubectl apply --dry-runclient -f过语法再真正 apply最后一定kubectl get endpoints确认服务真的接上了——这个习惯是被一次YAML 提交成功、服务从头到尾没通的经历逼出来的。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 12:40:48 · 阅读 1.2k K8s核心概念与排障复习地图：对象、生命周期、监控、调度、存储与安全
简介面向容器与云原生入门学习者的 Kubernetes 课件围绕 k8s 基础知识点展开适合希望系统梳理集群架构、核心对象与日常运维命令的读者。压缩包内含 1 个 pptx 演示文稿约 1.25MB以分章幻灯片组织内容便于课堂讲授或自学时按目录推进。课件从 Kubernetes 的定位与集群组件讲起说明接口服务、控制器管理器、调度器、键值存储、节点代理与网络代理等角色职责并解释 Pod、控制器、服务、标签、命名空间等概念随后延伸到指标监控、资源用量查看、组件与应用日志定位以及部署控制器的创建、发布、升级、回滚和弹性伸缩。内容还串联调度、存储、集群安全等章节目录由浅入深能帮助读者建立从架构认识到命令实践的知识框架也适合作为面试复习、课堂汇报或整理学习笔记的提纲。目前已有 2191 人学习下载可作为入门梳理与后续实验的索引。1. 集群地图从 kubectl 到 kubelet 的一条控制链很多人第一次接触 k8s会以为 kubectl 是在直接指挥某台机器上的容器。实际不是kubectl 只把请求发给 kube-apiserverapiserver 校验后写进 etcdcontroller-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 选 PodLabel附加在资源上的键值对让对象之间可以关联、查询、筛选键值差一个字符关联就断Namespace对象的逻辑分区多团队多环境共用一个集群时的隔离是逻辑隔离不是网络隔离这张表读下来会发现一个规律越是被叫作基础概念的对象越不是孤立存在的。Pod 需要 Controller 来维持数量Controller 需要 Label 来选中 PodService 需要 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: {}两个容器共享同一个 emptyDirweb 写进去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 找 PodDeployment 靠 selector 管自己创建的 Pod节点靠标签参与调度。它本身不产生任何运行时行为但一旦对不上表现出来的是服务不通副本数不对这类看起来像网络或调度问题的现象。Namespace 则把对象逻辑分区kubectl 默认在 default 里操作跨命名空间必须显式指定同名对象可以在不同命名空间共存。# 给节点打标签为后续调度做准备 kubectl label node node-1 disktypessd # 按标签筛选 Pod并显示标签用来核对 selector 能不能命中 kubectl get pods -l appnginx --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 --imagejava-demo # 确认 Deployment 和 Pod 都起来了 kubectl get deploy,pods # 把 Deployment 暴露成 Service类型为 NodePort对外提供访问 kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb # 查看 Service 分配到的端口 kubectl get service web参数里最容易混淆的是两个端口--port是 Service 自己暴露的端口--target-port是容器实际监听的端口写反或写错的表现是 Service 存在、Endpoints 也有但访问就是不通。--typeNodePort会在每个节点上开一个高位端口适合临时验证正式对外一般换成别的类型或走入口层。--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 nginxnginx:1.15 # 观察滚动更新进度卡住时会停在某个副本数上 kubectl rollout status deployment/web # 查看历史版本确认要回退到哪一版 kubectl rollout history deployment/web # 回退到上一版或指定具体版本号 kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision2 # 手动扩到 10 个副本 kubectl scale deployment web --replicas10 # 基于 CPU 的自动伸缩副本在 10 到 15 之间浮动 kubectl autoscale deployment web --min10 --max15 --cpu-percent80 # 删除资源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: 500mrequests和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 托管日志进 journalctlkube-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 就是每次都检查实际上本地有镜像就直接用。怎么补固定版本用 IfNotPresentlatest 或需要强制更新用 Always离线环境用 Never。更重要的是升级时改 tag 而不是依赖策略镜像版本写死在 YAML 里回滚才有明确的落点。易漏点二requests 和 limits 只写一个或者两个数值写反。为什么漏两个字段名相近、在示例里经常并排出现抄的时候容易错行而且写错之后 Pod 照样能起来问题要等到资源紧张才暴露。怎么补requests 决定调度limits 决定运行时上限。内存 limits 给小了会被 OOMKillCPU 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 里的 EventsPending 加 Insufficient 基本就是资源不够。存储这块按生命周期从短到长记emptyDir 随 Pod 消失hostPath 跟着节点走持久卷独立于 Pod 存在靠 PVC 申请、PV 提供。梳理下来会发现存储的考点不在怎么创建而在Pod 重建后数据还在不在这条分界线上判断标准就是看它挂的是哪一种卷。安全这块落在入口与边界apiserver 是所有请求的唯一入口认证、授权、准入依次过ServiceAccount 给 Pod 内的进程一个访问 apiserver 的身份Secret 存敏感配置Namespace 画逻辑边界RBAC 决定谁能在哪个范围对什么资源做什么动作。最容易忽略的是Pod 里的进程默认就带一个 ServiceAccount权限给大了边界就形同虚设。模块必答问题检查动作调度Pod 为什么停在 Pendingkubectl describe pod看 Events 与资源请求存储Pod 重建后数据还在吗确认挂的是 emptyDir、hostPath 还是 PVC安全谁用哪个身份访问 apiserverkubectl get sa,rolebinding -n 命名空间查漏的方式很土但有效拿一张白纸写下六个章节名每章下面强制写出三个如果……会怎样的问题写不出来的地方就是没吃透的地方回头对着课件那一节补。我自己的习惯是每次改完 YAML 先跑一遍kubectl apply --dry-runclient -f过语法再真正 apply最后一定kubectl get endpoints确认服务真的接上了——这个习惯是被一次YAML 提交成功、服务从头到尾没通的经历逼出来的。希望帮到你。本文还有配套的精品资源点击获取