简介这份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 --imagelizhenliang/java-demo这行命令做了几件事创建一个名为 web 的 Deployment使用 lizhenliang/java-demo 镜像。K8s 会自动拉取镜像并启动一个 Pod。接着查看结果kubectl get deploy,pods你会看到 Deployment 的期望副本数是 1当前可用也是 1Pod 状态是 Running。如果 Pod 卡在 ContainerCreating通常是镜像还在下载等一会儿再查。现在应用跑起来了但只能在集群内部访问。要让外部能访问需要创建一个 Servicekubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb参数解释一下--port80 是 Service 对外暴露的端口--target-port80 是容器实际监听的端口--typeNodePort 表示在每个节点上开一个随机端口来转发流量--nameweb 是 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 --replicas5这就是弹性伸缩的基本操作。升级镜像也很简单kubectl set image deployment/nginx-deployment nginxnginx: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: 500mcpu 的 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 --imagelizhenliang/java-demo这行命令做了几件事创建一个名为 web 的 Deployment使用 lizhenliang/java-demo 镜像。K8s 会自动拉取镜像并启动一个 Pod。接着查看结果kubectl get deploy,pods你会看到 Deployment 的期望副本数是 1当前可用也是 1Pod 状态是 Running。如果 Pod 卡在 ContainerCreating通常是镜像还在下载等一会儿再查。现在应用跑起来了但只能在集群内部访问。要让外部能访问需要创建一个 Servicekubectl expose deployment web --port80 --typeNodePort --target-port80 --nameweb参数解释一下--port80 是 Service 对外暴露的端口--target-port80 是容器实际监听的端口--typeNodePort 表示在每个节点上开一个随机端口来转发流量--nameweb 是 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 --replicas5这就是弹性伸缩的基本操作。升级镜像也很简单kubectl set image deployment/nginx-deployment nginxnginx: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: 500mcpu 的 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 的门推开剩下的路边跑边学最快。本文还有配套的精品资源点击获取
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化