简介这份Kubernetes课件面向容器编排初学者与运维开发人员系统梳理k8s基础知识点帮助读者建立从集群架构到应用管理的完整认知。内容涵盖k8s基本概念、集群架构与核心组件kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等、Pod与Controllers、Service、Label、NameSpaces并延伸至监控与日志管理、应用程序生命周期管理、调度、存储、集群安全等模块配合kubectl常用命令与YAML示例展开讲解。资源包为1个pptx文件大小约1.25MB以幻灯片形式呈现结构清晰、便于课堂分享与自学查阅。目前已有2191人学习下载适合需要快速入门k8s、梳理知识框架或准备技术分享的读者参考使用。1. Kubernetes 知识地图从集群架构到应用生命周期的完整梳理很多人学 Kubernetes 容易陷入一个误区上来就背kubectl命令结果遇到 Pod 起不来、Service 访问不通、滚动更新卡住完全不知道从哪查起。翻车几次之后才意识到K8s 不是命令的堆砌而是一套有明确分层和协作关系的系统。这份课件把内容分成六块基本概念、监控与日志、应用程序生命周期管理、调度、存储、集群安全。前两块解决“集群长什么样、怎么看它的状态”中间两块解决“应用怎么跑起来、怎么调度到合适节点”后两块解决“数据放哪、谁能访问”。如果你正在系统学 K8s或者复习备考建议按这个顺序走先建立组件与对象的对应关系再练排障命令最后补调度、存储和安全这些容易被跳过但考试和面试高频的模块。下面按模块拆解重点最后给一份可以照着查漏补缺的复习清单。2. 集群架构与核心对象组件分工和 Pod 设计模型2.1 控制平面与工作节点的组件职责K8s 集群分控制平面Master和工作节点Node两层。控制平面负责决策和存储集群状态工作节点负责实际运行容器。课件里列出的组件可以按“入口—决策—存储—执行”四条线来记。组件所在层核心职责复习抓手kube-apiserver控制平面集群统一入口RESTful API所有对象增删改查和监听都经它提交给 Etcd唯一直接读写 Etcd 的组件kube-controller-manager控制平面管理各类控制器一个资源对应一个控制器负责“期望状态”与“实际状态”的调和kube-scheduler控制平面根据调度算法为新 Pod 选择 Node只负责选节点不负责启动容器Etcd控制平面分布式键值存储保存集群状态数据集群的“唯一真相来源”kubelet工作节点Master 在 Node 上的 Agent管理本机容器生命周期把 Pod 转换成一组容器kube-proxy工作节点实现 Pod 网络代理维护网络规则和四层负载均衡负责 Service 的流量转发docker / rocket工作节点容器引擎运行容器真正跑容器的那一层梳理下来会发现排障时最该先看的是 kube-apiserver 和 Etcd 是否正常因为所有组件都通过 apiserver 协调。如果 apiserver 挂了kubectl 任何命令都会超时这时候看 kubelet 日志没有意义。2.2 Pod 为什么是最小部署单元Pod 是 K8s 里最小的部署单元但它本身是一个逻辑概念没有具体实体。课件里强调了一个关键设计Pod 为“亲密性应用”而存在。什么叫亲密性两个应用之间发生文件交互、需要通过 127.0.0.1 或 socket 通信典型组合是 nginx php、或者需要频繁调用。这些场景下把两个容器塞进同一个 Pod它们共享网络命名空间和存储卷通信效率最高。Pod 实现共享的机制是每个 Pod 先启动一个infra container基础容器其他容器加入这个网络命名空间于是看到的网络设备、IP 地址、Mac 地址完全一样。存储共享则通过挂载同一个卷实现。注意Pod 是短暂的。不要假设某个 Pod 会一直存在它的 IP 会变节点会漂移。这也是 Service 存在的理由——防止 Pod 失联给一组 Pod 定义稳定的访问策略。2.3 控制器、Service、Label 与 Namespace 的配合关系课件把 Controllers 分成五类Deployment 管无状态应用StatefulSet 管有状态应用DaemonSet 管守护进程Job 管一次性任务Cronjob 管定时任务。这五类不是随便选的复习时要能根据“应用有没有状态、要不要每个节点都跑、跑一次还是定时跑”三个问题快速定位。Service 解决的是 Pod IP 不固定、一组 Pod 需要统一访问入口的问题。Label 是附加到资源上的标签用于关联对象、查询和筛选。Service 通过 Label Selector 找到它要代理的那组 Pod。Namespace 把对象在逻辑上分离适合多团队或多环境共用集群的场景。这四者的关系可以这样串Deployment 创建并管理一组带 Label 的 PodService 通过 Label 选中这些 Pod 并提供稳定访问入口Namespace 把整套东西隔离在某个逻辑空间里。面试里常问“Service 怎么找到 Pod”答案就是 Label Selector不是 IP。3. 监控与日志集群状态查看和资源利用率排查3.1 集群整体状态与资源描述命令课件给出的命令分三组。第一组看集群整体kubectl cluster-info看集群基本信息kubectl cluster-info dump输出更多集群信息。第二组看单个资源详情kubectl describe 资源 名称这个命令在排障时用得最多Events 部分会告诉你 Pod 为什么调度失败、镜像为什么拉不下来。第三组是持续观察kubectl get pod Pod名称 --watch适合观察 Pod 状态变化过程。# 查看集群整体状态 kubectl cluster-info # 查看某个 Pod 的详细信息和事件 kubectl describe pod my-pod -n default # 持续观察 Pod 状态变化 kubectl get pod my-pod --watchdescribe的输出里重点看 Events 段落。常见事件包括 FailedScheduling调度失败通常是资源不够或节点选择器不匹配、ImagePullBackOff镜像拉取失败检查镜像名和 imagePullSecrets、CrashLoopBackOff容器反复重启看容器日志找原因。3.2 Metrics-server 与 cAdvisor 的资源监控课件提到 Metrics-server cAdvisor 监控集群资源消耗。cAdvisor 负责采集节点和容器的资源使用数据Metrics-server 聚合这些数据并通过 API 暴露出来。查看命令是kubectl top node node name和kubectl top pod pod name。这两个命令能返回数据的前提是 Metrics-server 已经部署且正常工作。如果执行kubectl top报错说 metrics API 不可用先检查 kube-system 命名空间下 metrics-server 的 Pod 是否 Running。这是复习时容易忽略的前置条件——命令本身很简单但环境没准备好就查不出东西。3.3 组件日志与应用日志的区分日志分两层。组件日志是 K8s 自身组件的日志比如 kubelet 用 systemd 管理时通过journalctl -u kubelet查看kube-proxy 以容器方式运行时通过kubectl logs kube-proxy-btz4p -n kube-system查看系统日志在/var/log/messages。应用日志是业务容器输出的日志通过kubectl logs Pod名称查看加-f持续跟踪加-c 容器名称指定 Pod 内某个容器。# 查看 kubelet 组件日志systemd 管理 journalctl -u kubelet # 查看 kube-proxy 容器日志 kubectl logs kube-proxy-btz4p -n kube-system # 查看应用容器标准输出持续跟踪 kubectl logs -f my-pod # 指定 Pod 内某个容器 kubectl logs -f my-pod -c web课件里还给了一个 Pod 配置示例把容器日志目录通过 hostPath 挂载到宿主机/tmp/logs方便集中收集。这种做法的思路是容器标准输出适合快速排查但长期存储和检索需要挂载到宿主机或用日志采集组件。apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: web image: nginx volumeMounts: - name: logs mountPath: /usr/local/nginx/logs volumes: - name: logs hostPath: path: /tmp/logs type: DirectoryvolumeMounts把容器内日志目录挂出来volumes定义宿主机路径。type: Directory表示宿主机上该目录必须已存在。复习时注意hostPath 适合单节点测试多节点场景下每个节点路径不同需要配合 DaemonSet 采集。4. 应用程序生命周期管理部署、升级、扩缩容与回滚4.1 命令行部署与 YAML 资源对象结构课件先用命令行演示部署 Java 应用kubectl create deployment web --imagelizhenliang/java-demo创建 Deployment然后kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb暴露为 Service。这两步是快速验证应用能否跑通的最短路径。但生产环境更推荐 YAML 文件。课件给出的 Deployment YAML 包含几个关键字段apiVersion指定 API 版本kind指定资源类型metadata放资源元数据spec放资源规格。spec下面replicas是副本数量selector是标签选择器template是 Pod 模板。Pod 模板里又有自己的metadata和specspec.containers定义容器配置。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这里最容易错的是selector.matchLabels和template.metadata.labels必须匹配。如果写得不一致Deployment 创建出来的 Pod 不会被它自己管理表现为kubectl get deploy显示副本数不对。这是血泪经验YAML 缩进错一行排查半小时。4.2 升级、弹性伸缩与回滚操作应用升级用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基于 CPU 使用率自动伸缩。回滚是生命周期管理里最该练熟的操作。kubectl rollout history deployment/web查看历史版本kubectl rollout undo deployment/web回滚到上一版kubectl rollout undo deployment/web --to-revision2回滚到指定版本。删除用kubectl delete deploy/web和kubectl delete svc/web。# 升级镜像 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复习时注意rollout undo默认回滚到上一个 revision但如果连续回滚多次revision 编号会变化。建议每次变更前用--record记录原因旧版本支持或者维护变更日志。4.3 镜像拉取策略与资源配额课件单独列了imagePullPolicy三个取值IfNotPresent是默认值宿主机不存在才拉取Always每次创建 Pod 都重新拉取Never永远不主动拉取。选择逻辑是开发环境用Always保证最新生产环境用IfNotPresent避免重复拉取离线环境用Never配合预加载镜像。资源配额分requests和limits。requests是调度依据K8s 根据它判断节点是否有足够资源limits是容器能使用的最大值超过会被限制或驱逐。课件示例里requests是 64Mi 内存和 250m CPUlimits是 128Mi 内存和 500m CPU。resources: requests: memory: 64Mi cpu: 250m limits: memory: 128Mi cpu: 500m这里容易漏的是limits必须大于等于requests否则创建报错。另外 CPU 单位m表示千分之一核250m 就是 0.25 核。内存单位 Mi 是二进制兆不要和 M 混用。5. 调度、存储与集群安全容易被跳过的三个模块5.1 调度器如何为 Pod 选节点kube-scheduler 的职责是根据调度算法为新创建的 Pod 选择一个 Node。课件强调“可以任意部署可以部署在同一个节点上也可以部署在不同的节点上”。这意味着调度器不保证均匀分布除非你配置了亲和性或反亲和性规则。调度过程分两步过滤和打分。过滤阶段排除不满足条件的节点比如资源不够、端口冲突、节点选择器不匹配。打分阶段对剩余节点排序选最高分。复习时要能说出影响调度的几个因素资源 requests、节点选择器 nodeSelector、亲和性与反亲和性、污点与容忍。5.2 存储卷与数据持久化思路课件在 Pod 配置示例里展示了 hostPath 卷的用法把宿主机目录挂载到容器内。这是最简单的存储方式但只适合单节点测试。多节点场景下Pod 漂移到另一个节点后hostPath 的数据就丢了。K8s 存储的完整体系包括 emptyDir临时目录Pod 删除即丢失、hostPath宿主机目录、PV 和 PVC持久卷和持久卷声明、StorageClass动态供给。复习时按“数据要不要持久、要不要跨节点、要不要动态创建”三个问题来选。课件没有展开 PV 和 PVC 的细节但这是调度和存储模块的衔接点建议补上。5.3 集群安全的基本层面课件把集群安全列为独立章节但正文没有展开。按 K8s 安全的标准分层至少包括认证谁在访问、授权能做什么、准入控制请求是否合规、网络策略Pod 之间能不能通、Secret 管理敏感信息怎么存。认证层面kube-apiserver 支持多种认证方式。授权层面RBAC 是最常用的通过 Role、ClusterRole、RoleBinding、ClusterRoleBinding 定义权限。Secret 用于存储密码、Token、证书等敏感数据Pod 通过 volume 或环境变量引用。课件里提到 kubelet 会“下载 secret”说明 Secret 是挂载到 Pod 里的。注意Secret 默认是 base64 编码不是加密。生产环境要开启 Etcd 加密或使用外部密钥管理。6. 易漏点与易错点复习时最容易翻车的五个地方6.1 易漏点一selector 与 labels 不匹配为什么漏YAML 写完后kubectl apply不报错但 Deployment 的 Pod 副本数始终是 0 或不对。很多人第一反应是查镜像、查资源忽略了 selector 和 template labels 的对应关系。怎么补创建 Deployment 后立刻执行kubectl get deploy和kubectl get pods --show-labels确认副本数和标签一致。如果副本数为 0先检查spec.selector.matchLabels是否等于spec.template.metadata.labels。6.2 易漏点二imagePullPolicy 与镜像标签的配合为什么漏用latest标签加IfNotPresent策略时如果宿主机已有旧镜像新 Pod 不会拉取最新版导致代码不生效。这个坑在开发环境特别常见。怎么补生产环境避免用latest用具体版本号。如果必须用latest把imagePullPolicy设为Always。离线环境用Never时确保所有节点已预加载目标镜像。6.3 易漏点三resources 的 requests 和 limits 写反为什么漏requests 和 limits 的语义容易记混。requests 是调度依据limits 是运行上限。写反了会导致 Pod 调度到资源不足的节点或者容器被意外限制。怎么补记住“requests 给调度器看limits 给内核看”。requests 小于等于 limits。CPU 单位用 m内存单位用 Mi。设置后通过kubectl describe pod查看实际分配。6.4 易漏点四rollout undo 后 revision 编号变化为什么漏执行kubectl rollout undo后以为 revision 编号不变再次回滚时选错版本。实际上每次回滚都会生成新的 revision。怎么补回滚前先kubectl rollout history deployment/web确认当前 revision 和目标 revision。回滚后用kubectl rollout status确认状态。重要变更前记录 revision 和对应镜像版本。6.5 易漏点五hostPath 在多节点场景下数据丢失为什么漏单节点测试时 hostPath 工作正常扩展到多节点后 Pod 漂移数据找不到。因为 hostPath 绑定的是具体节点的目录。怎么补多节点场景改用 PV 和 PVC或者用网络存储。如果必须用 hostPath配合 nodeSelector 把 Pod 固定到特定节点但这会牺牲调度灵活性。7. 复习清单从命令到排障的查漏补缺路径复习 K8s 最有效的方式不是从头背而是按“组件—对象—命令—排障”四条线交叉验证。下面这份清单可以逐项打勾哪一项卡住了就回到对应章节补。复习项自检问题对应章节集群架构能画出控制平面和工作节点的组件分工吗第 2 章核心对象Pod、Deployment、Service、Label、Namespace 的关系能串起来吗第 2 章监控命令kubectl describe的 Events 段落能读懂吗第 3 章日志排查组件日志和应用日志的查看方式能区分吗第 3 章生命周期升级、扩缩容、回滚的命令能默写吗第 4 章资源配额requests 和 limits 的区别能说清吗第 4 章调度因素影响 Pod 调度的因素能列出三个以上吗第 5 章存储选型hostPath、emptyDir、PV、PVC 的适用场景能区分吗第 5 章安全分层认证、授权、准入控制、Secret 管理能各说一句吗第 5 章易错点五个易漏点能复述并说出补法吗第 6 章排障时按固定顺序走先kubectl get pod看状态再kubectl describe pod看 Events然后kubectl logs看应用日志最后查组件日志和节点资源。这个顺序能覆盖大部分常见问题。# 排障四步 kubectl get pod -n default kubectl describe pod my-pod -n default kubectl logs my-pod -n default kubectl top node从那以后我每次部署新应用都强制走一遍“get → describe → logs → top”四步确认 Pod 状态、事件、日志和资源消耗都正常再继续下一步。这个习惯帮我省掉了很多事后回滚的麻烦。希望这份梳理能帮到你复习时少走弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/20 14:56:11 · 阅读 1.2k Kubernetes 知识地图：从集群架构到应用生命周期的完整梳理
简介这份Kubernetes课件面向容器编排初学者与运维开发人员系统梳理k8s基础知识点帮助读者建立从集群架构到应用管理的完整认知。内容涵盖k8s基本概念、集群架构与核心组件kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等、Pod与Controllers、Service、Label、NameSpaces并延伸至监控与日志管理、应用程序生命周期管理、调度、存储、集群安全等模块配合kubectl常用命令与YAML示例展开讲解。资源包为1个pptx文件大小约1.25MB以幻灯片形式呈现结构清晰、便于课堂分享与自学查阅。目前已有2191人学习下载适合需要快速入门k8s、梳理知识框架或准备技术分享的读者参考使用。1. Kubernetes 知识地图从集群架构到应用生命周期的完整梳理很多人学 Kubernetes 容易陷入一个误区上来就背kubectl命令结果遇到 Pod 起不来、Service 访问不通、滚动更新卡住完全不知道从哪查起。翻车几次之后才意识到K8s 不是命令的堆砌而是一套有明确分层和协作关系的系统。这份课件把内容分成六块基本概念、监控与日志、应用程序生命周期管理、调度、存储、集群安全。前两块解决“集群长什么样、怎么看它的状态”中间两块解决“应用怎么跑起来、怎么调度到合适节点”后两块解决“数据放哪、谁能访问”。如果你正在系统学 K8s或者复习备考建议按这个顺序走先建立组件与对象的对应关系再练排障命令最后补调度、存储和安全这些容易被跳过但考试和面试高频的模块。下面按模块拆解重点最后给一份可以照着查漏补缺的复习清单。2. 集群架构与核心对象组件分工和 Pod 设计模型2.1 控制平面与工作节点的组件职责K8s 集群分控制平面Master和工作节点Node两层。控制平面负责决策和存储集群状态工作节点负责实际运行容器。课件里列出的组件可以按“入口—决策—存储—执行”四条线来记。组件所在层核心职责复习抓手kube-apiserver控制平面集群统一入口RESTful API所有对象增删改查和监听都经它提交给 Etcd唯一直接读写 Etcd 的组件kube-controller-manager控制平面管理各类控制器一个资源对应一个控制器负责“期望状态”与“实际状态”的调和kube-scheduler控制平面根据调度算法为新 Pod 选择 Node只负责选节点不负责启动容器Etcd控制平面分布式键值存储保存集群状态数据集群的“唯一真相来源”kubelet工作节点Master 在 Node 上的 Agent管理本机容器生命周期把 Pod 转换成一组容器kube-proxy工作节点实现 Pod 网络代理维护网络规则和四层负载均衡负责 Service 的流量转发docker / rocket工作节点容器引擎运行容器真正跑容器的那一层梳理下来会发现排障时最该先看的是 kube-apiserver 和 Etcd 是否正常因为所有组件都通过 apiserver 协调。如果 apiserver 挂了kubectl 任何命令都会超时这时候看 kubelet 日志没有意义。2.2 Pod 为什么是最小部署单元Pod 是 K8s 里最小的部署单元但它本身是一个逻辑概念没有具体实体。课件里强调了一个关键设计Pod 为“亲密性应用”而存在。什么叫亲密性两个应用之间发生文件交互、需要通过 127.0.0.1 或 socket 通信典型组合是 nginx php、或者需要频繁调用。这些场景下把两个容器塞进同一个 Pod它们共享网络命名空间和存储卷通信效率最高。Pod 实现共享的机制是每个 Pod 先启动一个infra container基础容器其他容器加入这个网络命名空间于是看到的网络设备、IP 地址、Mac 地址完全一样。存储共享则通过挂载同一个卷实现。注意Pod 是短暂的。不要假设某个 Pod 会一直存在它的 IP 会变节点会漂移。这也是 Service 存在的理由——防止 Pod 失联给一组 Pod 定义稳定的访问策略。2.3 控制器、Service、Label 与 Namespace 的配合关系课件把 Controllers 分成五类Deployment 管无状态应用StatefulSet 管有状态应用DaemonSet 管守护进程Job 管一次性任务Cronjob 管定时任务。这五类不是随便选的复习时要能根据“应用有没有状态、要不要每个节点都跑、跑一次还是定时跑”三个问题快速定位。Service 解决的是 Pod IP 不固定、一组 Pod 需要统一访问入口的问题。Label 是附加到资源上的标签用于关联对象、查询和筛选。Service 通过 Label Selector 找到它要代理的那组 Pod。Namespace 把对象在逻辑上分离适合多团队或多环境共用集群的场景。这四者的关系可以这样串Deployment 创建并管理一组带 Label 的 PodService 通过 Label 选中这些 Pod 并提供稳定访问入口Namespace 把整套东西隔离在某个逻辑空间里。面试里常问“Service 怎么找到 Pod”答案就是 Label Selector不是 IP。3. 监控与日志集群状态查看和资源利用率排查3.1 集群整体状态与资源描述命令课件给出的命令分三组。第一组看集群整体kubectl cluster-info看集群基本信息kubectl cluster-info dump输出更多集群信息。第二组看单个资源详情kubectl describe 资源 名称这个命令在排障时用得最多Events 部分会告诉你 Pod 为什么调度失败、镜像为什么拉不下来。第三组是持续观察kubectl get pod Pod名称 --watch适合观察 Pod 状态变化过程。# 查看集群整体状态 kubectl cluster-info # 查看某个 Pod 的详细信息和事件 kubectl describe pod my-pod -n default # 持续观察 Pod 状态变化 kubectl get pod my-pod --watchdescribe的输出里重点看 Events 段落。常见事件包括 FailedScheduling调度失败通常是资源不够或节点选择器不匹配、ImagePullBackOff镜像拉取失败检查镜像名和 imagePullSecrets、CrashLoopBackOff容器反复重启看容器日志找原因。3.2 Metrics-server 与 cAdvisor 的资源监控课件提到 Metrics-server cAdvisor 监控集群资源消耗。cAdvisor 负责采集节点和容器的资源使用数据Metrics-server 聚合这些数据并通过 API 暴露出来。查看命令是kubectl top node node name和kubectl top pod pod name。这两个命令能返回数据的前提是 Metrics-server 已经部署且正常工作。如果执行kubectl top报错说 metrics API 不可用先检查 kube-system 命名空间下 metrics-server 的 Pod 是否 Running。这是复习时容易忽略的前置条件——命令本身很简单但环境没准备好就查不出东西。3.3 组件日志与应用日志的区分日志分两层。组件日志是 K8s 自身组件的日志比如 kubelet 用 systemd 管理时通过journalctl -u kubelet查看kube-proxy 以容器方式运行时通过kubectl logs kube-proxy-btz4p -n kube-system查看系统日志在/var/log/messages。应用日志是业务容器输出的日志通过kubectl logs Pod名称查看加-f持续跟踪加-c 容器名称指定 Pod 内某个容器。# 查看 kubelet 组件日志systemd 管理 journalctl -u kubelet # 查看 kube-proxy 容器日志 kubectl logs kube-proxy-btz4p -n kube-system # 查看应用容器标准输出持续跟踪 kubectl logs -f my-pod # 指定 Pod 内某个容器 kubectl logs -f my-pod -c web课件里还给了一个 Pod 配置示例把容器日志目录通过 hostPath 挂载到宿主机/tmp/logs方便集中收集。这种做法的思路是容器标准输出适合快速排查但长期存储和检索需要挂载到宿主机或用日志采集组件。apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: web image: nginx volumeMounts: - name: logs mountPath: /usr/local/nginx/logs volumes: - name: logs hostPath: path: /tmp/logs type: DirectoryvolumeMounts把容器内日志目录挂出来volumes定义宿主机路径。type: Directory表示宿主机上该目录必须已存在。复习时注意hostPath 适合单节点测试多节点场景下每个节点路径不同需要配合 DaemonSet 采集。4. 应用程序生命周期管理部署、升级、扩缩容与回滚4.1 命令行部署与 YAML 资源对象结构课件先用命令行演示部署 Java 应用kubectl create deployment web --imagelizhenliang/java-demo创建 Deployment然后kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb暴露为 Service。这两步是快速验证应用能否跑通的最短路径。但生产环境更推荐 YAML 文件。课件给出的 Deployment YAML 包含几个关键字段apiVersion指定 API 版本kind指定资源类型metadata放资源元数据spec放资源规格。spec下面replicas是副本数量selector是标签选择器template是 Pod 模板。Pod 模板里又有自己的metadata和specspec.containers定义容器配置。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这里最容易错的是selector.matchLabels和template.metadata.labels必须匹配。如果写得不一致Deployment 创建出来的 Pod 不会被它自己管理表现为kubectl get deploy显示副本数不对。这是血泪经验YAML 缩进错一行排查半小时。4.2 升级、弹性伸缩与回滚操作应用升级用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基于 CPU 使用率自动伸缩。回滚是生命周期管理里最该练熟的操作。kubectl rollout history deployment/web查看历史版本kubectl rollout undo deployment/web回滚到上一版kubectl rollout undo deployment/web --to-revision2回滚到指定版本。删除用kubectl delete deploy/web和kubectl delete svc/web。# 升级镜像 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复习时注意rollout undo默认回滚到上一个 revision但如果连续回滚多次revision 编号会变化。建议每次变更前用--record记录原因旧版本支持或者维护变更日志。4.3 镜像拉取策略与资源配额课件单独列了imagePullPolicy三个取值IfNotPresent是默认值宿主机不存在才拉取Always每次创建 Pod 都重新拉取Never永远不主动拉取。选择逻辑是开发环境用Always保证最新生产环境用IfNotPresent避免重复拉取离线环境用Never配合预加载镜像。资源配额分requests和limits。requests是调度依据K8s 根据它判断节点是否有足够资源limits是容器能使用的最大值超过会被限制或驱逐。课件示例里requests是 64Mi 内存和 250m CPUlimits是 128Mi 内存和 500m CPU。resources: requests: memory: 64Mi cpu: 250m limits: memory: 128Mi cpu: 500m这里容易漏的是limits必须大于等于requests否则创建报错。另外 CPU 单位m表示千分之一核250m 就是 0.25 核。内存单位 Mi 是二进制兆不要和 M 混用。5. 调度、存储与集群安全容易被跳过的三个模块5.1 调度器如何为 Pod 选节点kube-scheduler 的职责是根据调度算法为新创建的 Pod 选择一个 Node。课件强调“可以任意部署可以部署在同一个节点上也可以部署在不同的节点上”。这意味着调度器不保证均匀分布除非你配置了亲和性或反亲和性规则。调度过程分两步过滤和打分。过滤阶段排除不满足条件的节点比如资源不够、端口冲突、节点选择器不匹配。打分阶段对剩余节点排序选最高分。复习时要能说出影响调度的几个因素资源 requests、节点选择器 nodeSelector、亲和性与反亲和性、污点与容忍。5.2 存储卷与数据持久化思路课件在 Pod 配置示例里展示了 hostPath 卷的用法把宿主机目录挂载到容器内。这是最简单的存储方式但只适合单节点测试。多节点场景下Pod 漂移到另一个节点后hostPath 的数据就丢了。K8s 存储的完整体系包括 emptyDir临时目录Pod 删除即丢失、hostPath宿主机目录、PV 和 PVC持久卷和持久卷声明、StorageClass动态供给。复习时按“数据要不要持久、要不要跨节点、要不要动态创建”三个问题来选。课件没有展开 PV 和 PVC 的细节但这是调度和存储模块的衔接点建议补上。5.3 集群安全的基本层面课件把集群安全列为独立章节但正文没有展开。按 K8s 安全的标准分层至少包括认证谁在访问、授权能做什么、准入控制请求是否合规、网络策略Pod 之间能不能通、Secret 管理敏感信息怎么存。认证层面kube-apiserver 支持多种认证方式。授权层面RBAC 是最常用的通过 Role、ClusterRole、RoleBinding、ClusterRoleBinding 定义权限。Secret 用于存储密码、Token、证书等敏感数据Pod 通过 volume 或环境变量引用。课件里提到 kubelet 会“下载 secret”说明 Secret 是挂载到 Pod 里的。注意Secret 默认是 base64 编码不是加密。生产环境要开启 Etcd 加密或使用外部密钥管理。6. 易漏点与易错点复习时最容易翻车的五个地方6.1 易漏点一selector 与 labels 不匹配为什么漏YAML 写完后kubectl apply不报错但 Deployment 的 Pod 副本数始终是 0 或不对。很多人第一反应是查镜像、查资源忽略了 selector 和 template labels 的对应关系。怎么补创建 Deployment 后立刻执行kubectl get deploy和kubectl get pods --show-labels确认副本数和标签一致。如果副本数为 0先检查spec.selector.matchLabels是否等于spec.template.metadata.labels。6.2 易漏点二imagePullPolicy 与镜像标签的配合为什么漏用latest标签加IfNotPresent策略时如果宿主机已有旧镜像新 Pod 不会拉取最新版导致代码不生效。这个坑在开发环境特别常见。怎么补生产环境避免用latest用具体版本号。如果必须用latest把imagePullPolicy设为Always。离线环境用Never时确保所有节点已预加载目标镜像。6.3 易漏点三resources 的 requests 和 limits 写反为什么漏requests 和 limits 的语义容易记混。requests 是调度依据limits 是运行上限。写反了会导致 Pod 调度到资源不足的节点或者容器被意外限制。怎么补记住“requests 给调度器看limits 给内核看”。requests 小于等于 limits。CPU 单位用 m内存单位用 Mi。设置后通过kubectl describe pod查看实际分配。6.4 易漏点四rollout undo 后 revision 编号变化为什么漏执行kubectl rollout undo后以为 revision 编号不变再次回滚时选错版本。实际上每次回滚都会生成新的 revision。怎么补回滚前先kubectl rollout history deployment/web确认当前 revision 和目标 revision。回滚后用kubectl rollout status确认状态。重要变更前记录 revision 和对应镜像版本。6.5 易漏点五hostPath 在多节点场景下数据丢失为什么漏单节点测试时 hostPath 工作正常扩展到多节点后 Pod 漂移数据找不到。因为 hostPath 绑定的是具体节点的目录。怎么补多节点场景改用 PV 和 PVC或者用网络存储。如果必须用 hostPath配合 nodeSelector 把 Pod 固定到特定节点但这会牺牲调度灵活性。7. 复习清单从命令到排障的查漏补缺路径复习 K8s 最有效的方式不是从头背而是按“组件—对象—命令—排障”四条线交叉验证。下面这份清单可以逐项打勾哪一项卡住了就回到对应章节补。复习项自检问题对应章节集群架构能画出控制平面和工作节点的组件分工吗第 2 章核心对象Pod、Deployment、Service、Label、Namespace 的关系能串起来吗第 2 章监控命令kubectl describe的 Events 段落能读懂吗第 3 章日志排查组件日志和应用日志的查看方式能区分吗第 3 章生命周期升级、扩缩容、回滚的命令能默写吗第 4 章资源配额requests 和 limits 的区别能说清吗第 4 章调度因素影响 Pod 调度的因素能列出三个以上吗第 5 章存储选型hostPath、emptyDir、PV、PVC 的适用场景能区分吗第 5 章安全分层认证、授权、准入控制、Secret 管理能各说一句吗第 5 章易错点五个易漏点能复述并说出补法吗第 6 章排障时按固定顺序走先kubectl get pod看状态再kubectl describe pod看 Events然后kubectl logs看应用日志最后查组件日志和节点资源。这个顺序能覆盖大部分常见问题。# 排障四步 kubectl get pod -n default kubectl describe pod my-pod -n default kubectl logs my-pod -n default kubectl top node从那以后我每次部署新应用都强制走一遍“get → describe → logs → top”四步确认 Pod 状态、事件、日志和资源消耗都正常再继续下一步。这个习惯帮我省掉了很多事后回滚的麻烦。希望这份梳理能帮到你复习时少走弯路。本文还有配套的精品资源点击获取