简介这份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先搞懂它到底在忙什么你可能听过「K8s」这个词但第一次打开官方文档就被一堆名词劝退。别慌我换个说法把 Kubernetes 想象成一个「集装箱码头调度中心」。以前你手动把一个个应用搬上服务器就像用人力把货物一件件扛上船累且容易出错。Kubernetes 干的事就是帮你把应用打包成标准「集装箱」容器然后自动决定哪个箱子放哪条船、船满了怎么加船、船坏了怎么换船。它由 Google 在 2014 年开源全称 Kubernetes因为首尾字母 K 和 s 之间有 8 个字母所以简称 K8s。它的目标很朴素让部署容器化应用变得简单高效。这份课件就是带你从零认识这个调度中心适合完全没碰过容器编排、但想弄明白 K8s 到底能解决什么问题的朋友。2. 为什么要学 K8s从手动搬砖到自动调度2.1 没有 K8s 的世界有多累假设你开发了一个 Java 应用一开始只有一台服务器。你手动把程序传上去启动跑起来没问题。但用户多了一台扛不住你得再买一台然后手动把同样的程序再传一遍还得在前面加个负载均衡器让它知道请求该发给谁。这还没完——某天凌晨两点程序崩了你得爬起来重启。如果程序需要升级你得先停掉旧的再启动新的中间服务就断了。这些事做一次两次还行天天做就是折磨。K8s 把这些重复劳动全接了过去。你只需要告诉它「我要这个应用跑 3 份用这个镜像对外暴露 80 端口。」剩下的它来安排在哪台机器上跑、怎么让它们互相发现、挂了怎么自动拉起来、升级时怎么一个接一个换而不中断服务。这就是「容器化应用程序的部署、扩展和管理」这句话的真实含义。2.2 一个集群里都有谁在干活K8s 集群分两种角色Master 节点和 Node 节点。Master 是大脑Node 是干活的工人。大脑里有几个关键组件你不需要背但得知道它们各自管什么。kube-apiserver集群的统一入口。你敲的每一条 kubectl 命令最终都是发给它。它负责接收请求、校验、然后决定是存起来还是交给别人处理。kube-controller-manager后台大管家。比如你要求「始终有 3 个副本在跑」它就盯着少一个就补一个。kube-scheduler调度员。新创建的应用该放到哪个 Node 上由它根据资源情况来挑。Etcd集群的账本。所有状态数据比如有哪些应用、各自什么状态都记在这里。Node 节点上也有几个角色kubeletMaster 派在 Node 上的监工负责真正把容器创建出来、挂载存储、汇报状态。kube-proxy网络代理负责让外部请求能正确转发到容器里。docker 或 rocket容器引擎真正运行容器的底层工具。这些名字第一次看确实头大但你可以先记住一句话apiserver 收命令controller-manager 保状态scheduler 挑机器etcd 记台账kubelet 干活kube-proxy 管网络。后面动手时再回头对照自然就熟了。2.3 最小单元不是容器而是 Pod这是新手最容易卡住的地方。在 K8s 里它不直接管单个容器而是管一个叫Pod的东西。Pod 是最小部署单元你可以把它看成「一个或一组亲密容器的集合」。这些容器共享同一个网络命名空间意味着它们可以用localhost互相通信就像住在同一间宿舍里。为什么要有 Pod 这层抽象因为有些应用天生需要紧密协作。比如 nginx 和 php 需要频繁通过本地文件或 socket 通信把它们塞进同一个 Pod网络和存储共享就变得非常自然。Pod 是短暂的——它可能因为各种原因被销毁和重建所以不要把重要数据只放在 Pod 里。围绕 Pod还有几个你必须先认识的概念Controllers控制器管理 Pod 的「包工头」。Deployment 管无状态应用StatefulSet 管有状态应用DaemonSet 保证每个节点跑一个Job 跑一次性任务Cronjob 跑定时任务。Service给一组 Pod 一个固定的访问入口防止 Pod 重建后 IP 变了就失联。Label贴在资源上的标签用来筛选和关联对象。Namespace把对象在逻辑上分开比如开发环境和生产环境各用一个。这些概念现在有个印象就行下一章我们直接动手在动手中理解它们。3. 第一个例子从零跑起一个应用3.1 先确认你的集群能说话假设你已经有一个可用的 K8s 集群不管是单节点测试环境还是多节点集群第一步是确认kubectl能正常和集群通信。打开终端输入# 查看集群整体信息确认 apiserver 地址和核心服务状态 kubectl cluster-info如果返回类似Kubernetes control plane is running at https://...的信息说明连接正常。如果报错通常是配置文件~/.kube/config没配好或者集群没启动。这是新手第一道坎先解决它再往下走。接着看看集群里有哪些节点# 查看所有节点及其状态Ready 表示节点健康 kubectl get nodes你应该能看到节点列表状态是Ready。如果节点是NotReady可能是容器引擎或网络插件没装好先排查这个。3.2 用一条命令部署你的第一个应用现在我们来部署一个简单的 Java 应用。别担心你不需要自己写代码用现成的镜像就行# 创建一个名为 web 的 Deployment使用指定的 Java 应用镜像 kubectl create deployment web --imagelizhenliang/java-demo这条命令做了几件事创建了一个 Deployment 对象名字叫web它会确保有一个 Pod 在运行Pod 里的容器使用lizhenliang/java-demo这个镜像。执行完后查看一下# 查看 Deployment 和 Pod 的状态 kubectl get deploy,pods你会看到 Deployment 的READY是1/1Pod 的状态是Running。如果 Pod 状态是ContainerCreating稍等几秒再刷新如果是ImagePullBackOff说明镜像拉取失败检查网络或镜像名。3.3 把它暴露给外部访问Pod 有了但外部还访问不到。我们需要创建一个 Service# 为 web 这个 Deployment 创建一个 NodePort 类型的 Service kubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb参数解释一下--port80是 Service 自己的端口--target-port80是容器里应用实际监听的端口--typeNodePort表示在每个节点上开一个随机端口让外部可以通过「节点 IP:端口」访问。--nameweb是给这个 Service 起个名字。查看 Service# 查看 Service 列表注意 PORT(S) 列会显示类似 80:31234/TCP kubectl get svc31234就是 K8s 自动分配的节点端口。用浏览器访问http://任意节点IP:31234应该能看到应用页面。到这里你已经完成了一次完整的部署和暴露流程。3.4 用 YAML 文件描述你的应用命令行虽然快但实际工作中更常用 YAML 文件因为可以版本化管理、重复使用。下面是一个 Deployment 的 YAML 示例apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 # 期望运行 3 个副本 selector: matchLabels: app: nginx # 选择带有 appnginx 标签的 Pod template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15 ports: - containerPort: 80 # 容器暴露的端口几个关键字段apiVersion是 API 版本kind是资源类型metadata放元数据spec是期望状态。replicas: 3告诉 K8s 我要 3 个副本。selector和template.metadata.labels必须匹配否则 Deployment 不知道管哪些 Pod。保存为nginx-deployment.yaml然后执行# 根据 YAML 文件创建资源 kubectl apply -f nginx-deployment.yaml查看结果# 查看 Deployment 和 Pod应该看到 3 个 Pod 在运行 kubectl get deploy,pods3.5 升级、扩缩容和回滚应用不是部署完就一劳永逸。升级镜像# 将 web Deployment 中的容器镜像更新为新版本 kubectl set image deployment/web nginxnginx:1.16查看升级进度# 实时查看滚动更新状态 kubectl rollout status deployment/web弹性伸缩# 手动调整副本数为 10 kubectl scale deployment web --replicas10如果升级后发现有问题回滚# 查看历史版本 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/web这些命令现在不用全记住知道有这些能力就行。真正用起来时回来查一下即可。4. 避坑指南新手最容易翻车的五个地方4.1 Pod 一直处于 Pending 状态现象kubectl get pods显示 Pod 状态是Pending迟迟不变成Running。原因通常是调度器找不到合适的节点。可能是节点资源不足CPU 或内存不够也可能是节点有污点Taint而 Pod 没有对应的容忍Toleration。解决先用kubectl describe pod Pod名称查看事件列表最后几行会写明原因。如果是资源不足减少副本数或清理节点资源如果是污点问题给 Pod 加上对应的容忍配置。4.2 镜像拉取失败 ImagePullBackOff现象Pod 状态显示ImagePullBackOff或ErrImagePull。原因镜像名字写错了、镜像仓库需要认证、或者节点无法访问镜像仓库。解决检查镜像名和标签是否正确。如果是私有仓库需要创建imagePullSecrets并在 Pod 中引用。先手动在节点上docker pull一下那个镜像确认网络和认证没问题。4.3 Service 创建了但访问不通现象kubectl get svc能看到 Service但浏览器访问节点 IP 加端口没反应。原因可能是targetPort写错了或者 Pod 本身没准备好也可能是防火墙挡住了 NodePort 端口。解决先确认 Pod 是Running且READY是1/1。然后检查 Service 的Endpointskubectl get endpoints Service名称如果为空说明 Service 的标签选择器没匹配到任何 Pod。最后检查节点防火墙是否放行了 NodePort 范围。4.4 资源限制没设导致节点被压垮现象某个应用突然占用大量 CPU 或内存把整个节点拖慢其他 Pod 也受影响。原因创建 Pod 时没有设置资源申请和限制。解决在容器配置里加上resources.requests和resources.limits。例如resources: requests: memory: 64Mi cpu: 250m limits: memory: 128Mi cpu: 500mrequests是调度依据limits是硬上限。养成习惯每个容器都设。4.5 直接删 Pod 而不是改 Deployment现象手动删掉一个 Pod结果它又自动回来了。原因Pod 是由 Deployment 管理的Deployment 发现副本数不够立刻补了一个新的。解决这不是故障是正常行为。如果你想彻底移除应该删 Deployment 而不是 Pod。如果想临时调试可以用kubectl delete pod删掉让它重建但要知道它会回来。5. 下一步学什么从能跑到能管5.1 先把监控和日志用起来应用跑起来只是开始你还得知道它健不健康。K8s 提供了一些基础命令# 查看集群整体状态 kubectl cluster-info # 查看某个资源的详细信息排查问题时最有用 kubectl describe pod Pod名称 # 实时监听 Pod 状态变化 kubectl get pod Pod名称 --watch资源利用率方面需要部署 Metrics-server 配合 cAdvisor。装好后可以# 查看节点资源消耗 kubectl top node node名称 # 查看 Pod 资源消耗 kubectl top pod Pod名称日志分两层组件日志和应用日志。组件日志如果由 systemd 管理用journalctl -u kubelet查看如果是容器方式运行用kubectl logs kube-proxy-xxxxx -n kube-system。应用日志直接# 查看容器标准输出 kubectl logs Pod名称 # 持续跟踪日志 kubectl logs -f Pod名称 # 如果 Pod 里有多个容器指定容器名 kubectl logs -f Pod名称 -c 容器名称5.2 接着补调度、存储和安全这份课件还覆盖了调度、存储和集群安全。调度解决的是「Pod 放到哪」的问题比如指定节点、亲和性、污点与容忍。存储解决的是「数据放哪」的问题比如 emptyDir、hostPath、PV 和 PVC。安全解决的是「谁能做什么」的问题比如 ServiceAccount、Role、RoleBinding。入门阶段不用一头扎进去建议按这个顺序推进阶段重点目标第一周Pod、Deployment、Service能部署和暴露一个应用第二周配置管理、存储卷能让应用读配置、写数据第三周监控与日志能排查常见故障第四周调度与安全能控制 Pod 位置和权限5.3 我踩过的一个坑刚开始学的时候我总觉得 YAML 写起来太麻烦能命令行搞定就命令行。结果有一次升级完忘了当时用了哪些参数回滚时手忙脚乱。从那以后我每次创建资源都强制自己写 YAML 文件哪怕只是测试。文件放在版本控制里改了什么、什么时候改的一目了然。这个习惯帮我省下了很多「后悔药」。希望这份课件能帮你迈出第一步。别急着一次学完先把第一个例子跑通再慢慢往外扩。K8s 的东西多但常用的就那么几个用多了自然就熟了。希望帮到你。本文还有配套的精品资源点击获取