简介：这份Kubernetes课件面向容器编排初学者与运维开发人员，系统梳理k8s基础知识点，帮助读者建立从集群架构到应用管理的完整认知。内容涵盖k8s基本概念、集群架构与核心组件（如kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等）、Pod与Controllers、Service、Label、NameSpaces等对象模型，并延伸至监控与日志管理、应用程序生命周期管理、调度、存储、集群安全等模块，目录结构清晰，便于按章节循序渐进学习。资源包为1个pptx文件，压缩包约1.25MB，以幻灯片形式呈现，适合课堂分享、自学梳理与知识速查。目前已有2191人学习下载，可作为k8s入门阶段的框架性参考资料，帮助读者快速把握核心概念与常用命令，为后续深入实践打下基础。1. 零基础搞懂 Kubernetes：它到底能帮你解决什么麻烦你有没有遇到过这种情况：在自己电脑上跑得好好的程序，发给同事却怎么都启动不了；或者线上服务器突然崩了，你手忙脚乱登上去重启，重启完发现数据丢了一半。更头疼的是，业务一忙，一台机器扛不住，你得手动再开一台，把程序复制过去，改配置、调网络，折腾半天。这些事，Kubernetes（简称 K8s）就是专门来帮你摆平的。你可以把 K8s 想象成一个“集装箱码头调度系统”。你的程序被打包成一个个标准集装箱（容器），K8s 负责把这些箱子搬到合适的货轮（服务器）上，箱子翻了它自动扶正，货轮不够它自动加派，码头哪里堵了它帮你疏通。它不关心箱子里装的是什么，只保证箱子按你的要求运行。这份课件就是带你从零认识这个调度系统，把基本概念、监控日志、应用管理、调度存储和安全这些核心模块串起来，让你看完敢自己动手跑一个例子。2. 先弄明白 K8s 的骨架：集群里谁在干活2.1 一个集群就像一家公司，角色分工很明确刚接触 K8s 的人最容易晕在“组件”这个词上。其实你不需要背，只要记住一家公司怎么运转就行。K8s 集群分两种角色：控制平面（Master）和工作节点（Node）。控制平面是管理层，工作节点是干活的人。控制平面里有几个核心成员。kube-apiserver 是前台接待，所有指令——不管是创建还是查询——都得先经过它，它再决定把信息交给谁。kube-controller-manager 是后台主管，专门盯着“期望状态”和“实际状态”是否一致，比如你要求跑 3 个副本，它发现只有 2 个，就会立刻补上。kube-scheduler 是调度员，新任务来了，它根据资源空闲情况决定放到哪个节点上。etcd 是公司的档案柜，所有集群状态数据都存这里，它是分布式的键值存储，挂了整个集群就失忆了。工作节点上也有三个关键角色。kubelet 是节点上的监工，负责管理本机容器的生命周期，创建容器、挂载数据卷、上报状态都归它管。kube-proxy 是网络代理，维护节点上的网络规则，让外部请求能正确转发到容器。docker 或 rocket 是容器引擎，真正运行容器的地方。提示：入门阶段不用纠结每个组件的源码实现，先记住“apiserver 是入口，etcd 是数据库，scheduler 管分配，kubelet 管执行”这条主线就够了。2.2 最小部署单元 Pod：为什么不是直接跑容器你可能会问：既然有容器了，为什么还要搞一个 Pod？直接跑容器不行吗？这里就是 K8s 设计上比较巧妙的地方。Pod 是最小部署单元，它是一组容器的集合，这些容器共享网络命名空间和存储卷。什么意思呢？比如你的应用需要一个 Nginx 和一个 PHP 紧密配合，它们之间要通过 127.0.0.1 通信，还要频繁读写同一份文件。如果把它们放在两个独立的容器里，网络和存储都要额外配置，很麻烦。Pod 让它们像住在同一间公寓里，共享同一个 IP 和端口空间，直接用 localhost 就能互相访问，文件也能通过挂载的卷共享。Pod 是短暂的，这句话很重要。Pod 随时可能被销毁和重建，重建后 IP 会变。所以你不能依赖 Pod 的 IP 做长期通信，这就引出了 Service 的概念。Service 给一组 Pod 提供一个固定的访问入口，防止 Pod 失联。Label 是标签，用来给资源打标记，Service 就是通过 Label 来筛选它要代理哪些 Pod 的。Namespace 则是逻辑隔离，把不同团队或不同环境的资源分开，互不干扰。2.3 控制器：让应用按你的期望运行光有 Pod 还不够，因为 Pod 挂了不会自动恢复。控制器就是来管这件事的。Deployment 用于无状态应用部署，比如 Web 服务，它保证你指定数量的 Pod 副本始终在运行，支持滚动升级和回滚。StatefulSet 用于有状态应用，比如数据库，它给每个 Pod 稳定的网络标识和存储。DaemonSet 确保每个节点上都跑一个 Pod，适合日志收集或监控代理。Job 是一次性任务，Cronjob 是定时任务。入门的话，先把 Deployment 用熟，因为大部分无状态服务都用它。你只需要写一个 YAML 文件，告诉 K8s“我要 3 个 nginx 副本”，Deployment 就会帮你维持这个状态。3. 第一个例子：从零跑起来一个应用3.1 动手前先确认环境能通这份课件默认你已经有一个可用的 K8s 集群。如果你还没有，入门阶段建议先用 Minikube 或 Kind 在本地搭一个单节点集群，这样不用担心搞坏线上环境。装好之后，打开终端，输入下面这行命令确认集群状态：kubectl cluster-info这个命令会返回 apiserver 的地址和核心服务信息。如果能看到类似“Kubernetes control plane is running at ...”的输出，说明你的 kubectl 已经能正常和集群通信了。如果报错，先检查 kubectl 是否安装、配置文件是否指向了正确的集群。接下来查看节点状态：kubectl get nodes你会看到节点名称和状态，Ready 表示节点健康。入门阶段一个节点就够了。3.2 用命令行部署第一个应用K8s 支持命令行和 YAML 文件两种方式创建资源。新手先用命令行感受一下，因为反馈快、不容易被 YAML 缩进搞晕。我们部署一个简单的 Java 应用：kubectl create deployment web --image=lizhenliang/java-demo这行命令做了几件事：创建一个名为 web 的 Deployment，使用 lizhenliang/java-demo 镜像。K8s 会自动拉取镜像并启动一个 Pod。接着查看结果：kubectl get deploy,pods你会看到 Deployment 的期望副本数是 1，当前可用也是 1，Pod 状态是 Running。如果 Pod 卡在 ContainerCreating，通常是镜像还在下载，等一会儿再查。现在应用跑起来了，但只能在集群内部访问。要让外部能访问，需要创建一个 Service：kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web参数解释一下：--port=80 是 Service 对外暴露的端口，--target-port=80 是容器实际监听的端口，--type=NodePort 表示在每个节点上开一个随机端口来转发流量，--name=web 是 Service 的名字。执行完再查一下：kubectl get service你会看到 web 这个 Service 有一个 ClusterIP 和一个 NodePort。用节点 IP 加上 NodePort 就能在浏览器里访问你的应用了。3.3 用 YAML 文件管理资源：更规范的做法命令行适合快速测试，但真正管理应用时，YAML 文件才是主流。因为 YAML 可以版本控制、可以复用、可以描述复杂配置。下面是一个 Deployment 的 YAML 示例：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 版本，apps/v1 是 Deployment 的稳定版本。kind 是资源类型。metadata 里写名字和命名空间。spec 是资源规格，replicas: 3 表示要 3 个副本。selector 是标签选择器，告诉 Deployment 管理哪些 Pod。template 是 Pod 模板，里面定义了容器名称、镜像和端口。保存为 nginx-deployment.yaml，然后执行：kubectl apply -f nginx-deployment.yaml再用 kubectl get pods 查看，你会看到 3 个 nginx Pod 在运行。如果只想临时改一下副本数，可以用：kubectl scale deployment nginx-deployment --replicas=5这就是弹性伸缩的基本操作。升级镜像也很简单：kubectl set image deployment/nginx-deployment nginx=nginx:1.16K8s 会逐个替换 Pod，实现滚动升级。如果新版本有问题，可以回滚：kubectl rollout undo deployment/nginx-deployment注意：入门阶段最容易犯的错是 YAML 缩进不对。建议用支持 YAML 语法高亮的编辑器，缩进统一用两个空格，不要用 Tab。4. 避坑指南：新手最容易翻车的五个地方4.1 Pod 一直处于 Pending 状态现象：kubectl get pods 看到 Pod 状态是 Pending，迟迟不变成 Running。原因：通常是资源不足，比如节点 CPU 或内存不够调度器分配；也可能是没有匹配的节点，比如你指定了 nodeSelector 但节点没有对应标签。解决：先用 kubectl describe pod <Pod名称> 查看 Events 部分，里面会写清楚为什么调度失败。如果是资源不足，可以删掉一些不用的 Pod 或者给节点加资源。如果是标签问题，检查 nodeSelector 配置。4.2 镜像拉取失败 ImagePullBackOff现象：Pod 状态显示 ImagePullBackOff 或 ErrImagePull。原因：镜像名称写错、镜像不存在、或者私有仓库需要认证但没配置 secret。解决：先确认镜像名和标签是否正确。如果是私有仓库，需要创建 docker-registry 类型的 Secret，并在 Pod 的 imagePullSecrets 里引用。课件里提到了 imagePullPolicy 的三个值：IfNotPresent 是默认值，本地没有才拉取；Always 是每次创建都重新拉；Never 是永远不主动拉。入门时用默认的 IfNotPresent 就行。4.3 Service 创建了但访问不通现象：kubectl get service 能看到 Service，但浏览器访问节点 IP 加 NodePort 没反应。原因：可能是 Pod 的 labels 和 Service 的 selector 不匹配，导致 Service 找不到后端 Pod；也可能是防火墙或安全组没放行 NodePort 端口。解决：用 kubectl describe service <Service名称> 查看 Endpoints，如果 Endpoints 是空的，说明 selector 没匹配到 Pod。检查 Pod 的 labels 是否和 Service 的 selector 一致。如果是云服务器，检查安全组规则。4.4 日志查看命令用不对现象：kubectl logs <Pod名称> 报错，说找不到容器或 Pod。原因：一个 Pod 里可能有多个容器，不指定容器名时默认查第一个，但有时第一个不是你要看的。另外 Pod 如果已经销毁，日志就查不到了。解决：先用 kubectl get pods 确认 Pod 名称和状态。如果 Pod 里有多个容器，用 -c 指定容器名，比如 kubectl logs -f <Pod名称> -c <容器名称>。如果要实时看日志，加 -f 参数。对于已经销毁的 Pod，需要提前配置日志收集系统，把日志持久化。4.5 资源限制没设导致节点被压垮现象：某个应用突然占用大量 CPU 或内存，导致节点上其他 Pod 被驱逐。原因：创建 Pod 时没有设置 resources.requests 和 resources.limits，容器可以无限制使用节点资源。解决：在 YAML 里给每个容器加上资源配额。requests 是调度时保证分配的量，limits 是容器能使用的最大值。比如：resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"cpu 的 250m 表示 0.25 个 CPU 核心，memory 的 Mi 是 Mebibyte。入门时先给一个保守的值，观察实际用量后再调整。5. 下一步学什么：从能跑到能管好5.1 先把监控和日志用起来应用跑起来之后，你肯定想知道它消耗了多少资源、有没有报错。K8s 本身不提供完整的监控方案，但社区有成熟的组合：Metrics-server 加 cAdvisor。Metrics-server 收集资源指标，cAdvisor 负责容器级别的数据采集。装好之后，你可以用：kubectl top node kubectl top pod这两个命令分别查看节点和 Pod 的 CPU、内存消耗。日志方面，kubectl logs 是最直接的入口，但生产环境建议上 EFK 或 Loki 这类日志聚合系统，不然 Pod 一销毁日志就丢了。5.2 理解调度和存储的基本玩法调度决定了 Pod 去哪个节点。入门阶段先了解 nodeSelector 和 affinity 的区别：nodeSelector 是硬性条件，必须满足；affinity 更灵活，支持软性偏好。存储方面，先搞懂 Volume 的几种类型：emptyDir 是临时目录，Pod 删了就没了；hostPath 是挂载宿主机目录，适合单节点测试；PersistentVolume 和 PersistentVolumeClaim 是生产环境用的持久化存储抽象。5.3 安全不是选修课集群安全包括几个层面：API 访问控制、网络策略、Pod 安全策略。入门时至少要知道 ServiceAccount 是干什么的——它给 Pod 提供一个身份，让 Pod 能安全地访问 API。还有 Secret 用来存密码和密钥，不要硬编码在镜像里。5.4 我踩过的一个坑刚开始学的时候，我觉得 YAML 写起来太麻烦，能命令行搞定就绝不用文件。结果有一次线上要改一个 Deployment 的镜像版本，我直接 kubectl set image 改了，但忘了记录改成了什么版本。后来要回滚，发现 rollout history 里只有版本号没有具体镜像信息，折腾了半天才找回来。从那以后我每次改任何资源，都强制先写 YAML 文件，apply 之前先 diff 一下，确认无误再执行。这个习惯帮我省了很多后悔药。希望这份课件能帮你把 K8s 的门推开，剩下的路，边跑边学最快。本文还有配套的精品资源，点击获取
简介：这份Kubernetes课件面向容器编排初学者与运维开发人员，系统梳理k8s基础知识点，帮助读者建立从集群架构到应用管理的完整认知。内容涵盖k8s基本概念、集群架构与核心组件（如kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等）、Pod与Controllers、Service、Label、NameSpaces等对象模型，并延伸至监控与日志管理、应用程序生命周期管理、调度、存储、集群安全等模块，目录结构清晰，便于按章节循序渐进学习。资源包为1个pptx文件，压缩包约1.25MB，以幻灯片形式呈现，适合课堂分享、自学梳理与知识速查。目前已有2191人学习下载，可作为k8s入门阶段的框架性参考资料，帮助读者快速把握核心概念与常用命令，为后续深入实践打下基础。1. 零基础搞懂 Kubernetes：它到底能帮你解决什么麻烦你有没有遇到过这种情况：在自己电脑上跑得好好的程序，发给同事却怎么都启动不了；或者线上服务器突然崩了，你手忙脚乱登上去重启，重启完发现数据丢了一半。更头疼的是，业务一忙，一台机器扛不住，你得手动再开一台，把程序复制过去，改配置、调网络，折腾半天。这些事，Kubernetes（简称 K8s）就是专门来帮你摆平的。你可以把 K8s 想象成一个“集装箱码头调度系统”。你的程序被打包成一个个标准集装箱（容器），K8s 负责把这些箱子搬到合适的货轮（服务器）上，箱子翻了它自动扶正，货轮不够它自动加派，码头哪里堵了它帮你疏通。它不关心箱子里装的是什么，只保证箱子按你的要求运行。这份课件就是带你从零认识这个调度系统，把基本概念、监控日志、应用管理、调度存储和安全这些核心模块串起来，让你看完敢自己动手跑一个例子。2. 先弄明白 K8s 的骨架：集群里谁在干活2.1 一个集群就像一家公司，角色分工很明确刚接触 K8s 的人最容易晕在“组件”这个词上。其实你不需要背，只要记住一家公司怎么运转就行。K8s 集群分两种角色：控制平面（Master）和工作节点（Node）。控制平面是管理层，工作节点是干活的人。控制平面里有几个核心成员。kube-apiserver 是前台接待，所有指令——不管是创建还是查询——都得先经过它，它再决定把信息交给谁。kube-controller-manager 是后台主管，专门盯着“期望状态”和“实际状态”是否一致，比如你要求跑 3 个副本，它发现只有 2 个，就会立刻补上。kube-scheduler 是调度员，新任务来了，它根据资源空闲情况决定放到哪个节点上。etcd 是公司的档案柜，所有集群状态数据都存这里，它是分布式的键值存储，挂了整个集群就失忆了。工作节点上也有三个关键角色。kubelet 是节点上的监工，负责管理本机容器的生命周期，创建容器、挂载数据卷、上报状态都归它管。kube-proxy 是网络代理，维护节点上的网络规则，让外部请求能正确转发到容器。docker 或 rocket 是容器引擎，真正运行容器的地方。提示：入门阶段不用纠结每个组件的源码实现，先记住“apiserver 是入口，etcd 是数据库，scheduler 管分配，kubelet 管执行”这条主线就够了。2.2 最小部署单元 Pod：为什么不是直接跑容器你可能会问：既然有容器了，为什么还要搞一个 Pod？直接跑容器不行吗？这里就是 K8s 设计上比较巧妙的地方。Pod 是最小部署单元，它是一组容器的集合，这些容器共享网络命名空间和存储卷。什么意思呢？比如你的应用需要一个 Nginx 和一个 PHP 紧密配合，它们之间要通过 127.0.0.1 通信，还要频繁读写同一份文件。如果把它们放在两个独立的容器里，网络和存储都要额外配置，很麻烦。Pod 让它们像住在同一间公寓里，共享同一个 IP 和端口空间，直接用 localhost 就能互相访问，文件也能通过挂载的卷共享。Pod 是短暂的，这句话很重要。Pod 随时可能被销毁和重建，重建后 IP 会变。所以你不能依赖 Pod 的 IP 做长期通信，这就引出了 Service 的概念。Service 给一组 Pod 提供一个固定的访问入口，防止 Pod 失联。Label 是标签，用来给资源打标记，Service 就是通过 Label 来筛选它要代理哪些 Pod 的。Namespace 则是逻辑隔离，把不同团队或不同环境的资源分开，互不干扰。2.3 控制器：让应用按你的期望运行光有 Pod 还不够，因为 Pod 挂了不会自动恢复。控制器就是来管这件事的。Deployment 用于无状态应用部署，比如 Web 服务，它保证你指定数量的 Pod 副本始终在运行，支持滚动升级和回滚。StatefulSet 用于有状态应用，比如数据库，它给每个 Pod 稳定的网络标识和存储。DaemonSet 确保每个节点上都跑一个 Pod，适合日志收集或监控代理。Job 是一次性任务，Cronjob 是定时任务。入门的话，先把 Deployment 用熟，因为大部分无状态服务都用它。你只需要写一个 YAML 文件，告诉 K8s“我要 3 个 nginx 副本”，Deployment 就会帮你维持这个状态。3. 第一个例子：从零跑起来一个应用3.1 动手前先确认环境能通这份课件默认你已经有一个可用的 K8s 集群。如果你还没有，入门阶段建议先用 Minikube 或 Kind 在本地搭一个单节点集群，这样不用担心搞坏线上环境。装好之后，打开终端，输入下面这行命令确认集群状态：kubectl cluster-info这个命令会返回 apiserver 的地址和核心服务信息。如果能看到类似“Kubernetes control plane is running at ...”的输出，说明你的 kubectl 已经能正常和集群通信了。如果报错，先检查 kubectl 是否安装、配置文件是否指向了正确的集群。接下来查看节点状态：kubectl get nodes你会看到节点名称和状态，Ready 表示节点健康。入门阶段一个节点就够了。3.2 用命令行部署第一个应用K8s 支持命令行和 YAML 文件两种方式创建资源。新手先用命令行感受一下，因为反馈快、不容易被 YAML 缩进搞晕。我们部署一个简单的 Java 应用：kubectl create deployment web --image=lizhenliang/java-demo这行命令做了几件事：创建一个名为 web 的 Deployment，使用 lizhenliang/java-demo 镜像。K8s 会自动拉取镜像并启动一个 Pod。接着查看结果：kubectl get deploy,pods你会看到 Deployment 的期望副本数是 1，当前可用也是 1，Pod 状态是 Running。如果 Pod 卡在 ContainerCreating，通常是镜像还在下载，等一会儿再查。现在应用跑起来了，但只能在集群内部访问。要让外部能访问，需要创建一个 Service：kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web参数解释一下：--port=80 是 Service 对外暴露的端口，--target-port=80 是容器实际监听的端口，--type=NodePort 表示在每个节点上开一个随机端口来转发流量，--name=web 是 Service 的名字。执行完再查一下：kubectl get service你会看到 web 这个 Service 有一个 ClusterIP 和一个 NodePort。用节点 IP 加上 NodePort 就能在浏览器里访问你的应用了。3.3 用 YAML 文件管理资源：更规范的做法命令行适合快速测试，但真正管理应用时，YAML 文件才是主流。因为 YAML 可以版本控制、可以复用、可以描述复杂配置。下面是一个 Deployment 的 YAML 示例：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 版本，apps/v1 是 Deployment 的稳定版本。kind 是资源类型。metadata 里写名字和命名空间。spec 是资源规格，replicas: 3 表示要 3 个副本。selector 是标签选择器，告诉 Deployment 管理哪些 Pod。template 是 Pod 模板，里面定义了容器名称、镜像和端口。保存为 nginx-deployment.yaml，然后执行：kubectl apply -f nginx-deployment.yaml再用 kubectl get pods 查看，你会看到 3 个 nginx Pod 在运行。如果只想临时改一下副本数，可以用：kubectl scale deployment nginx-deployment --replicas=5这就是弹性伸缩的基本操作。升级镜像也很简单：kubectl set image deployment/nginx-deployment nginx=nginx:1.16K8s 会逐个替换 Pod，实现滚动升级。如果新版本有问题，可以回滚：kubectl rollout undo deployment/nginx-deployment注意：入门阶段最容易犯的错是 YAML 缩进不对。建议用支持 YAML 语法高亮的编辑器，缩进统一用两个空格，不要用 Tab。4. 避坑指南：新手最容易翻车的五个地方4.1 Pod 一直处于 Pending 状态现象：kubectl get pods 看到 Pod 状态是 Pending，迟迟不变成 Running。原因：通常是资源不足，比如节点 CPU 或内存不够调度器分配；也可能是没有匹配的节点，比如你指定了 nodeSelector 但节点没有对应标签。解决：先用 kubectl describe pod <Pod名称> 查看 Events 部分，里面会写清楚为什么调度失败。如果是资源不足，可以删掉一些不用的 Pod 或者给节点加资源。如果是标签问题，检查 nodeSelector 配置。4.2 镜像拉取失败 ImagePullBackOff现象：Pod 状态显示 ImagePullBackOff 或 ErrImagePull。原因：镜像名称写错、镜像不存在、或者私有仓库需要认证但没配置 secret。解决：先确认镜像名和标签是否正确。如果是私有仓库，需要创建 docker-registry 类型的 Secret，并在 Pod 的 imagePullSecrets 里引用。课件里提到了 imagePullPolicy 的三个值：IfNotPresent 是默认值，本地没有才拉取；Always 是每次创建都重新拉；Never 是永远不主动拉。入门时用默认的 IfNotPresent 就行。4.3 Service 创建了但访问不通现象：kubectl get service 能看到 Service，但浏览器访问节点 IP 加 NodePort 没反应。原因：可能是 Pod 的 labels 和 Service 的 selector 不匹配，导致 Service 找不到后端 Pod；也可能是防火墙或安全组没放行 NodePort 端口。解决：用 kubectl describe service <Service名称> 查看 Endpoints，如果 Endpoints 是空的，说明 selector 没匹配到 Pod。检查 Pod 的 labels 是否和 Service 的 selector 一致。如果是云服务器，检查安全组规则。4.4 日志查看命令用不对现象：kubectl logs <Pod名称> 报错，说找不到容器或 Pod。原因：一个 Pod 里可能有多个容器，不指定容器名时默认查第一个，但有时第一个不是你要看的。另外 Pod 如果已经销毁，日志就查不到了。解决：先用 kubectl get pods 确认 Pod 名称和状态。如果 Pod 里有多个容器，用 -c 指定容器名，比如 kubectl logs -f <Pod名称> -c <容器名称>。如果要实时看日志，加 -f 参数。对于已经销毁的 Pod，需要提前配置日志收集系统，把日志持久化。4.5 资源限制没设导致节点被压垮现象：某个应用突然占用大量 CPU 或内存，导致节点上其他 Pod 被驱逐。原因：创建 Pod 时没有设置 resources.requests 和 resources.limits，容器可以无限制使用节点资源。解决：在 YAML 里给每个容器加上资源配额。requests 是调度时保证分配的量，limits 是容器能使用的最大值。比如：resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"cpu 的 250m 表示 0.25 个 CPU 核心，memory 的 Mi 是 Mebibyte。入门时先给一个保守的值，观察实际用量后再调整。5. 下一步学什么：从能跑到能管好5.1 先把监控和日志用起来应用跑起来之后，你肯定想知道它消耗了多少资源、有没有报错。K8s 本身不提供完整的监控方案，但社区有成熟的组合：Metrics-server 加 cAdvisor。Metrics-server 收集资源指标，cAdvisor 负责容器级别的数据采集。装好之后，你可以用：kubectl top node kubectl top pod这两个命令分别查看节点和 Pod 的 CPU、内存消耗。日志方面，kubectl logs 是最直接的入口，但生产环境建议上 EFK 或 Loki 这类日志聚合系统，不然 Pod 一销毁日志就丢了。5.2 理解调度和存储的基本玩法调度决定了 Pod 去哪个节点。入门阶段先了解 nodeSelector 和 affinity 的区别：nodeSelector 是硬性条件，必须满足；affinity 更灵活，支持软性偏好。存储方面，先搞懂 Volume 的几种类型：emptyDir 是临时目录，Pod 删了就没了；hostPath 是挂载宿主机目录，适合单节点测试；PersistentVolume 和 PersistentVolumeClaim 是生产环境用的持久化存储抽象。5.3 安全不是选修课集群安全包括几个层面：API 访问控制、网络策略、Pod 安全策略。入门时至少要知道 ServiceAccount 是干什么的——它给 Pod 提供一个身份，让 Pod 能安全地访问 API。还有 Secret 用来存密码和密钥，不要硬编码在镜像里。5.4 我踩过的一个坑刚开始学的时候，我觉得 YAML 写起来太麻烦，能命令行搞定就绝不用文件。结果有一次线上要改一个 Deployment 的镜像版本，我直接 kubectl set image 改了，但忘了记录改成了什么版本。后来要回滚，发现 rollout history 里只有版本号没有具体镜像信息，折腾了半天才找回来。从那以后我每次改任何资源，都强制先写 YAML 文件，apply 之前先 diff 一下，确认无误再执行。这个习惯帮我省了很多后悔药。希望这份课件能帮你把 K8s 的门推开，剩下的路，边跑边学最快。本文还有配套的精品资源，点击获取