简介本资源是一份面向Kubernetes初学者与运维入门者的系统性课件聚焦k8s核心原理与实操管理能力培养帮助学习者快速掌握容器编排平台的架构设计、日常运维及应用部署全流程。课件以PPTX格式呈现共1个文件大小1.25MB内容结构清晰覆盖K8s基本概念集群组件、Pod、Controller、Service、Namespace等、监控与日志管理kubectl命令、Metrics-server、cAdvisor、日志采集路径、应用程序生命周期管理Deployment创建、滚动更新、回滚、扩缩容三大主线并延伸至调度策略、存储机制与集群安全等关键模块。所有知识点均配图示说明与典型命令示例便于理解记忆与现场复现。目前已有2186人学习下载适合作为高校教学补充材料、企业内部培训讲义或自学入门指南是轻量高效、即学即用的K8s基础认知工具包。1. 这不是PPT合集一份能让你在K8s集群里真正“动手改配置、看日志、修故障”的课件设计逻辑你搜“Kubernetes课件分享”点开十份八份是概念图命令截图架构框图——讲Pod是什么、Service怎么转发、Ingress路由原理。但当你真在公司测试环境里执行kubectl apply -f deploy.yaml报错Error from server (Invalid): error when applying patch... field is immutable或者kubectl get nodes一直显示NotReady翻遍课件却找不到“怎么查 kubelet 日志”“怎么确认 cgroup driver 是否匹配”“为什么 flannel 启不来但没报错”——这时候你就知道课件不是用来背的是用来垫脚够到真实集群的。这份课件分享核心就一件事所有内容都锚定在可验证、可中断、可回滚的真实操作链上。它不追求“覆盖全部API字段”但每讲一个对象Deployment/ConfigMap/HPA必带三样东西① 本地 minikube 或 kind 集群上 30 秒能跑通的最小 YAML② 执行后必查的 2 个关键诊断命令比如kubectl describe podkubectl logs -p③ 一个故意写错的版本比如把replicas: 3改成replicas: 3字符串让你亲手触发并定位典型报错。它面向的是刚通过kubeadm init搭好三节点集群、正对着kubectl get componentstatuses里scheduler显示Unknown发呆的运维/开发/测试同学——不是理论研究者是明天就要上线灰度流量的落地执行者。课件结构按「认知负荷递进」而非「K8s文档目录」组织从kubectl run nginx这种黑盒命令开始拆解出它背后自动生成的 Deployment Service Pod再手动写出等效 YAML对比差异最后用kubectl edit deployment实时修改副本数观察 ReplicaSet 和 Pod 的级联变化。所有示例均适配kubernetes v1.26移除 dockershim 后的主流版本避开了k8s权威指南第五版pdf下载里大量已废弃的--admission-control参数和extensions/v1beta1API 组。如果你正卡在k8s安装部署的preflight阶段或被k8s生产环境中常见的故障影响到用户的告警压得喘不过气这份课件不是速成班而是给你一把能拧开每个组件盖板的螺丝刀。2. 从零启动用 kind 在 5 分钟内搭出可调试的 K8s 本地集群v1.26提示不用kubeadm init不碰 Docker daemon 配置不改 cgroup driver避免k8s集群搭建中最常翻车的系统级依赖冲突。2.1 为什么选 kind 而非 minikube三个硬指标决定落地效率镜像预加载能力kind支持--image指定预构建的节点镜像如kindest/node:v1.26.15启动即含 kubelet/kubeadm/kubectl省去k8s部署时反复拉取k8s.gcr.io镜像的超时问题多节点拓扑原生支持单条命令kind create cluster --config kind-config.yaml即可生成 control-plane 2 worker 节点直接复现k8s生产环境中常见的故障影响到用户的跨节点网络场景日志直通宿主机kind export logs可一键导出所有节点的/var/log/pods/和 kubelet journal比 minikube 的minikube logs更接近真实集群排查路径。我们放弃k8s权威指南第五版里强调的kubeadm config print init-defaults生成模板方式因为 v1.26 默认启用CSIDriver和NodeDisruptionExclusion等新特性手写kubeadm-config.yaml容易漏掉featureGates开关导致preflight失败。kind的配置文件本质是声明式拓扑定义与 kubeadm 内部逻辑解耦更稳。2.2 创建 v1.26.15 集群三步命令 一个配置文件先确保已安装kindv0.20和kubectlv1.26# 检查版本必须匹配否则 kubectl 无法识别 v1.26 新增的 ValidatingAdmissionPolicy 对象 kind version # 输出应为 kind v0.20.0 或更高 kubectl version --client # 输出应为 v1.26.x创建kind-config.yaml明确指定 Kubernetes 版本、节点角色和容器运行时# kind-config.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 name: k8s-v126 nodes: - role: control-plane kubeadmConfigPatches: - | kind: InitConfiguration nodeRegistration: criSocket: /run/containerd/containerd.sock extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: criSocket: /run/containerd/containerd.sock - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: criSocket: /run/containerd/containerd.sock containerdConfigPatches: - |- [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] privileged_without_host_devices true逻辑说明criSocket强制指向containerd.sock规避k8s是不是自主可控讨论中常被质疑的 Docker 依赖extraPortMappings将宿主机 80/443 映射到 control-plane 节点让 Ingress 流量可直通后续验证k8s externalips场景必备containerdConfigPatches启用privileged_without_host_devices解决k8s调用gpu场景下容器无法挂载/dev/nvidia*设备的问题虽本课件不展开 GPU但配置预留扩展性。执行创建kind create cluster --config kind-config.yaml --image kindest/node:v1.26.15 # 成功输出Cluster creation complete. You can now use your cluster with: # export KUBECONFIG$(kind get kubeconfig-path --namek8s-v126) # kubectl cluster-info验证集群状态kubectl get nodes -o wide # NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME # k8s-v126-control-plane Ready control-plane 2m15s v1.26.15 172.18.0.2 none Ubuntu 22.04 5.15.0-107-generic containerd://1.7.13 # k8s-v126-worker Ready none 118s v1.26.15 172.18.0.3 none Ubuntu 22.04 5.15.0-107-generic containerd://1.7.13 # k8s-v126-worker2 Ready none 118s v1.26.15 172.18.0.4 none Ubuntu 22.04 5.15.0-107-generic containerd://1.7.13参数说明v1.26.15是 v1.26 系列最新 patch 版本截至 2024 年中修复了k8s中operator案例常用的CustomResourceDefinitionv1 规范兼容性问题--image参数必须显式指定否则 kind 默认拉取最新版可能已是 v1.27导致kubectl apply时因 API 版本不匹配报错no matches for kind Deployment in version apps/v1若执行卡在Starting control-plane大概率是宿主机 containerd 未运行执行sudo systemctl start containerd即可。2.3 必装调试插件kubectl-neat, kubectl-tree, kubetail —— 把黑匣子变成透明管道仅靠原生kubectl查问题就像用万用表测集成电路板。这三个插件是课件中所有故障排查环节的底层支撑# kubectl-neat自动清理 YAML 中的 status/managedFields 等无关字段让 diff 更干净 kubectl krew install neat # kubectl-tree可视化对象依赖树如 Deployment → ReplicaSet → Pod → ConfigMap理解 k8s面试题 中高频考点“级联删除” kubectl krew install tree # kubetail聚合多个 Pod 日志替代 kubectl logs -f -l appnginx 的简陋输出 curl -s https://raw.githubusercontent.com/johanhaleby/kubetail/master/kubetail kubetail chmod x kubetail sudo mv kubetail /usr/local/bin/验证插件生效# 查看 nginx Deployment 的完整依赖链课件第 3 章实操基础 kubectl create deployment nginx --imagenginx:1.25 kubectl tree deployment nginx # 输出 # Deployment/nginx # └─ReplicaSet/nginx-6c859c454b # └─Pod/nginx-6c859c454b-2zq9w # ├─Container/nginx # └─Volume/default-token-9x7gj关键价值当k8s部署后服务不可达kubectl tree能 3 秒确认是否卡在 ReplicaSet 层副本未创建还是 Pod 层容器 CrashLoopBackOff。这比盲目kubectl describe pod看 Events 高效得多。3. 对象建模实战从kubectl run黑盒命令到手写 YAML 的三次解构注意本章所有 YAML 均基于kubernetes v1.26.0 [preflight] running pre-flight chec通过的集群验证禁用所有已弃用字段如extensions/v1beta1。3.1 第一次解构kubectl run自动生成的 Deployment 是什么执行最简命令kubectl run nginx-demo --imagenginx:1.25 --port80立即导出其真实 YAMLkubectl get deployment nginx-demo -o yaml | kubectl neat nginx-demo-auto.yaml得到精简后的nginx-demo-auto.yamlapiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo namespace: default spec: replicas: 1 selector: matchLabels: run: nginx-demo template: metadata: labels: run: nginx-demo spec: containers: - image: nginx:1.25 name: nginx-demo ports: - containerPort: 80 protocol: TCP逻辑说明kubectl run在 v1.26 默认创建apps/v1Deployment非旧版extensions/v1beta1这是k8s入门指南必须更新的要点selector.matchLabels与template.metadata.labels必须严格一致否则 ReplicaSet 无法关联 Pod课件中故意设错此值演示故障ports下的protocol: TCP不可省略v1.26 的PodSecurityPolicy替代方案PodSecurityAdmission会校验此字段。3.2 第二次解构手动补全 Service实现k8s externalips的最小可行验证仅 Deployment 无法被外部访问。添加nginx-demo-svc.yamlapiVersion: v1 kind: Service metadata: name: nginx-demo-svc spec: selector: run: nginx-demo # 必须与 Deployment 的 matchLabels 一致 ports: - port: 80 targetPort: 80 protocol: TCP type: NodePort # 为验证 externalIPs暂用 NodePort后续可切 LoadBalancer应用并验证kubectl apply -f nginx-demo-svc.yaml kubectl get service nginx-demo-svc # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # nginx-demo-svc NodePort 10.96.192.123 none 80:31234/TCP 10s此时可通过宿主机 IP NodePort 访问因 kind 配置了extraPortMappings实际curl http://localhost:80即可。参数说明type: NodePort是k8s externalips场景的前置条件——只有当 Service 已存在且可访问才能为其绑定 externalIPstargetPort必须与容器containerPort一致否则流量无法到达容器课件中故意将targetPort: 8080导致 502 错误CLUSTER-IP为10.96.x.x是 kind 默认的 service CIDR与k8s部署文档中--service-cidr参数对应。3.3 第三次解构注入 ConfigMap Secret模拟真实应用配置创建app-config.yamlConfigMapapiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: nginx.conf: | events { worker_connections 1024; } http { server { listen 80; location / { return 200 Hello from ConfigMap!\n; } } }创建db-secret.yamlSecretbase64 编码apiVersion: v1 kind: Secret metadata: name: db-credentials type: Opaque data: username: YWRtaW4 # admin base64 password: MWYyZDFlMmU2N2Rm # 1f2d1e2e67df base64修改nginx-demo-auto.yaml挂载 ConfigMap 并引用 Secret# ... 原 Deployment YAML 上方 ... spec: replicas: 1 selector: matchLabels: run: nginx-demo template: metadata: labels: run: nginx-demo spec: containers: - image: nginx:1.25 name: nginx-demo ports: - containerPort: 80 protocol: TCP volumeMounts: # 新增挂载 - name: nginx-conf mountPath: /etc/nginx/nginx.conf subPath: nginx.conf readOnly: true env: # 新增环境变量 - name: DB_USER valueFrom: secretKeyRef: name: db-credentials key: username volumes: # 新增 volumes - name: nginx-conf configMap: name: nginx-config应用全部资源kubectl apply -f app-config.yaml kubectl apply -f db-secret.yaml kubectl apply -f nginx-demo-auto.yaml # 此时已含 ConfigMap/Secret 引用验证配置生效# 进入 Pod 查看挂载的 nginx.conf kubectl exec -it deploy/nginx-demo -- cat /etc/nginx/nginx.conf # 验证环境变量 kubectl exec -it deploy/nginx-demo -- printenv DB_USER # 访问服务 curl http://localhost:80 # 应返回 Hello from ConfigMap!关键细节subPath必须指定否则 ConfigMap 会覆盖整个/etc/nginx/目录导致 nginx 启动失败Secret 的valueFrom.secretKeyRef是k8s面试题高频考点错误写成valueFrom.configMapKeyRef会导致容器启动时CrashLoopBackOff所有kubectl apply命令均使用-f课件强调永远不要用kubectl create创建需后续更新的对象如 ConfigMap因为create不支持--save-config导致kubectl apply时因缺少last-applied-configurationannotation 报错。4. 故障排查避坑k8s生产环境中常见的故障影响到用户的 5 个血泪现场本章所有现象均来自真实k8s部署过程复现步骤在课件配套 YAML 中已标注# BUG-DEMO。每条按「现象 → 原因 → 解决」展开拒绝模糊描述。4.1 现象kubectl get nodes显示NotReady但systemctl status kubelet显示 active原因k8s安装部署后未正确配置 containerd 的SystemdCgroup。v1.26 默认要求cgroupDriver: systemd而 containerd 默认使用cgroupfs。kubelet 启动时检测到不匹配拒绝注册节点。排查# 查看 kubelet 日志中的关键错误 sudo journalctl -u kubelet -n 100 | grep -i cgroup # 输出failed to run Kubelet: failed to get root cgroup stats: failed to get cgroup stats for /: unknown driver cgroupfs解决编辑/etc/containerd/config.toml在[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc]下添加[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true重启 containerdsudo systemctl restart containerd再重启 kubeletsudo systemctl restart kubelet。4.2 现象Deployment 创建成功但kubectl get pods无 Podkubectl describe deployment显示0/0 nodes are available原因selector.matchLabels与template.metadata.labels不一致课件中故意设错。ReplicaSet 无法找到匹配的 Pod 模板故不创建 Pod。排查kubectl get rs # 查看 ReplicaSet 名称 kubectl describe rs nginx-demo-6c859c454b | grep -A5 Selector # 输出Selector: runnginx-demo-bug # 注意此处是错误的 label kubectl get deploy nginx-demo -o jsonpath{.spec.template.metadata.labels} # 输出map[run:nginx-demo] # 与 RS Selector 不匹配解决修正 Deployment YAML 中template.metadata.labels使其与selector.matchLabels完全一致然后kubectl apply -f。4.3 现象Pod 处于CrashLoopBackOffkubectl logs为空kubectl describe pod显示Back-off restarting failed container原因容器启动命令command或参数args语法错误导致进程立即退出。kubectl logs无输出是因为容器未产生 stdout/stderr 即退出。排查# 查看容器最后一次退出状态 kubectl get pod nginx-demo-6c859c454b-2zq9w -o jsonpath{.status.containerStatuses[0].state.waiting.reason} # 输出CrashLoopBackOff kubectl get pod nginx-demo-6c859c454b-2zq9w -o jsonpath{.status.containerStatuses[0].state.waiting.message} # 输出back-off 5m0s restarting failed containernginx-demo podnginx-demo-6c859c454b-2zq9w_default(...) # 关键用 -p 查看前一次容器日志即使已退出 kubectl logs nginx-demo-6c859c454b-2zq9w -p # 输出nginx: [emerg] invalid number of arguments in listen directive in /etc/nginx/nginx.conf:3解决检查 ConfigMap 挂载的nginx.conf发现listen后缺少端口号。修正后kubectl apply -f app-config.yamlPod 自动重建。4.4 现象Service 类型为LoadBalancer但EXTERNAL-IP一直显示pendingkubectl get events无相关事件原因k8s externalips场景中未为 Service 显式设置externalIPs字段且集群未部署云厂商 LoadBalancer 控制器如 MetalLB。LoadBalancer类型在裸机集群中无法自动分配 IP。排查kubectl get svc nginx-demo-svc -o wide # EXTERNAL-IP 列为 pending kubectl get svc nginx-demo-svc -o jsonpath{.spec.externalIPs} # 输出[] # 为空证明未设置解决在 Service YAML 中添加externalIPs使用宿主机 IPspec: externalIPs: - 192.168.1.100 # 替换为你的宿主机 IP # ... 其余字段应用后kubectl get svc即显示该 IPcurl http://192.168.1.100可访问。4.5 现象kubectl top nodes报错error: Metrics API not availablekubectl get apiservice | grep metrics显示False原因k8s部署时未安装 metrics-server。kubectl top依赖 metrics-server 提供的metrics.k8s.ioAPI该 API 在 v1.26 不再内置。排查kubectl get apiservice v1beta1.metrics.k8s.io # NAME SERVICE AVAILABLE AGE # v1beta1.metrics.k8s.io kube-system/metrics-server False 5m kubectl get deployment -n kube-system metrics-server # No resources found in kube-system namespace.解决安装 metrics-server使用官方 manifestkubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml # 等待 1-2 分钟检查状态 kubectl get apiservice v1beta1.metrics.k8s.io -o jsonpath{.status.conditions[0].message} # 应输出all checks passed5. 进阶验证用 Prometheus 监控 K8s 集群把k8s部署状态变成可量化指标本章不追求完整 Prometheus 生态只聚焦课件核心目标让学员亲手看到 “集群是否健康” 不再是kubectl get nodes的文本而是曲线图上的绿色线条。所有步骤在 kind 集群中 10 分钟内完成。5.1 为什么用 Prometheus 而非k8s部署文档推荐的 Heapster已废弃Heapster 在 v1.12 已被废弃k8s权威指南第五版中的 Heapster 部署方案完全失效。Prometheus 是当前k8s监控事实标准其kube-state-metrics组件专为 K8s 对象状态建模能直接回答“有多少 Pod 处于 Pending 状态” →kube_pod_status_phase{phasePending}“哪个节点的 CPU 使用率超 90%” →100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)“Deployment 更新是否卡住” →kube_deployment_status_condition{conditionAvailable,statusfalse}课件选择prometheus-operator的轻量版kube-prometheus因其 YAML 清晰、组件解耦、便于教学拆解。5.2 三步部署Prometheus Grafana kube-state-metrics# 1. 克隆 kube-prometheusv0.12.0 适配 k8s v1.26 git clone https://github.com/prometheus-operator/kube-prometheus.git cd kube-prometheus git checkout release-0.12 # 2. 创建命名空间和 CRD关键否则后续 apply 失败 kubectl create -f manifests/setup # 等待 30 秒确认 CRD 创建完成 kubectl get crd | grep prometheuses # 3. 应用全部组件Prometheus/Grafana/kube-state-metrics/alertmanager kubectl create -f manifests/逻辑说明manifests/setup包含PrometheusRule、ServiceMonitor等 CRD必须先创建否则manifests/中的自定义资源无法识别kube-prometheus默认启用node-exporter会采集宿主机指标对 kind 集群有效因 kind 节点是 Docker 容器node-exporter 可读取其/proc所有组件部署在monitoring命名空间避免污染default。5.3 验证与访问从命令行到图形界面的闭环检查核心组件状态kubectl get all -n monitoring # 应看到 prometheus-k8s-0, alertmanager-main-0, grafana-xxx, kube-state-metrics-xxx 均为 Running kubectl get servicemonitor -n monitoring # 应看到 kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, node-exporter 等全部 Ready端口转发访问 Grafanakubectl port-forward -n monitoring svc/grafana 3000:3000 # 浏览器打开 http://localhost:3000登录 admin/admin在 Grafana 中导入k8s部署监控看板点击左上角→Import→ 输入3119Kubernetes / Compute Resources / Cluster→Load选择prometheus数据源 →Import此时你会看到实时集群视图CPU/Memory 使用率、Pod 状态分布、API Server 请求延迟。重点观察kube_pod_status_phase面板——当手动删除一个 Pod 后Running曲线短暂下降Pending曲线上升几秒后Running恢复Pending归零。这就是k8s部署的弹性在监控层面的具象化。参数说明kube_pod_status_phase指标由kube-state-metrics生成它监听 K8s API Server 的 Pod 事件流将对象状态转化为 Prometheus 指标node-exporter的node_cpu_seconds_total指标在 kind 集群中采集的是容器内核的 CPU 时间数值合理非宿主机物理 CPU若kubectl get servicemonitor显示node-exporter的Age为 0s 且Conditions为空说明prometheus-operator未正确关联需检查PrometheusCR 中的serviceMonitorSelector是否匹配node-exporter的 label。5.4 一个关键技巧用kubectl get --raw直接调用 metrics API绕过 Grafana 查原始数据当 Grafana 图表异常或需快速验证指标是否存在用原生 API# 获取所有节点的 CPU 使用率需先部署 metrics-server kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | jq .items[].usage.cpu # 获取特定 Pod 的内存使用替换 pod-name 和 namespace kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/nginx-demo-6c859c454b-2zq9w | jq .containers[0].usage.memory # 查看 metrics-server 自身状态诊断 Metrics API not available kubectl get --raw /apis/metrics.k8s.io/v1beta1 | jq这个技巧的价值在于它不依赖任何 UI 或插件是k8s部署故障时的终极验证手段。当我第一次在客户现场遇到kubectl top失效就是靠kubectl get --raw确认 metrics-server 的/metrics端点返回了 503进而发现其证书过期——比翻 Grafana 日志快 10 倍。课件中所有 Prometheus 相关 YAML 均已精简注释删除了k8s权威指南第五版中冗余的 RBAC 权限如cluster-admin只保留kube-state-metrics所需的list/watch权限。这不是为了炫技而是让你在真实生产环境申请权限时能精准说出“我只需要对 Pod/Node/Deployment 的 read 权限”。希望帮到你。本文还有配套的精品资源点击获取