LFS258实战指南：Kubernetes基础、集群搭建与排错避坑

简介这是一份配合Linux基金会LFS258《Kubernetes基础知识》课程的实验基础设施资源面向正在入门Kubernetes、希望动手搭建集群环境的开发者。资源共11个文件压缩包整体约306KB核心包括Terraform编排文件.tf、Shell初始化脚本.sh、README说明.md、操作步骤截图.png及SSH公钥.pub。借助HCL语言编写的Terraform配置可在GCP项目中自动创建服务账号、开启所需API并配置Compute Engine等权限省去大量手工操作脚本则负责master与worker节点的启动初始化缩短从零搭建环境的时间。目前已有407人学习下载适合作为LFS258课程实验的前置准备与配套参考。1. Kubernetes 基础知识的正确打开方式LFS258 这套资源到底解决什么问题学 Kubernetes 的人手里从来不缺教程缺的是把教程串成主线的那根绳。Kubernetes 生态里文档、博客、开源项目多到让人焦虑今天看 Pod明天看 Service后天又被网络策略打乱节奏最后连kubectl get pods的状态都懒得细看——这是大多数入门者的真实状态。LFS258 这类基础知识课程资源的价值恰恰在于它把 Kubernetes 的概念按依赖顺序整理成一条主线先讲清楚容器编排要解决什么问题再依次展开 API 对象、控制面协作、工作负载与配置体系最后落到一个能动手验证的集群环境上。这套资源适合两类人一类是从零开始学 Kubernetes、需要一个结构化学习路径的新手另一类是已经用过kubectl但知识体系凌乱、想扎实补一遍基础再考认证或做平台开发的从业者。它能帮你把“看过教程”变成“能讲清原理、能动手复现、能处理故障”。本文不打算复述课程内容而是以一个一线工程师的视角告诉你如何拆解、验证、实操这套资源涉及的所有关键基础以及最常见的 5 个翻车点。2. 先把 LFS258 的知识骨架立起来编排要解决什么、控制面与工作节点怎么协作2.1 理解 Kubernetes 的“声明式运维”逻辑别用管理物理机的思路去学Kubernetes 学习中最难跨过的一道坎不是语法不是 YAML而是思维方式的切换。传统运维习惯“命令式”操作我要启动一个进程命令执行它我要修改配置命令改掉它进程挂了命令重启它。但 Kubernetes 是完全相反的思路——你只需要声明“我想要什么状态”剩下的对齐过程由系统自动完成。这个差别是 LFS258 这类基础课一开始就强调的。举个最直观的例子你用kubectl run创建一个 Pod看起来像命令式操作但实际上它最终会生成一个 Deployment 对象里面声明了“我要 3 个副本、镜像版本是 v1.0、更新策略是滚动更新”。后续所有行为都围绕这个声明展开副本数不够了控制器会补镜像版本要升级控制器按策略滚动替换某个节点挂了控制器在别的节点上重建 Pod。这个“声明式”风格贯穿了 Kubernetes 的所有核心对象学的时候如果只记命令不记对象语义后面排障会非常吃力。判断自己有没有理解声明式逻辑有一个很实用的方法能不能不看资料回答“如果我把 Deployment 的副本数从 3 改成 5中间发生了什么”。答案是API Server 校验并存储新期望状态、控制器观察到期望与实际的偏差、控制器创建新的 Pod、调度器为新 Pod 绑定节点、节点上的 kubelet 拉镜像并启动容器。整个过程你只改了 YAML 里的一个数字但系统内部五个组件协作完成了一整套动作。LFS258 的基础章节反复训练的就是这种链路认知。2.2 API 对象是学习的核心线索Pod、控制器与 Service 的三角关系Kubernetes 的核心概念再多抓出主线索就能理清。这条线索是Pod 是运行单元控制器保证 Pod 数量和状态Service 负责把流量转给符合条件的 Pod。这三者的关系建议用一张三角图记在脑子里控制器管“有多少个”Pod 管“跑的是什么”Service 管“谁能访问到”。Pod 是最小的资源调度单位里面可以有一个或多个容器共享网络命名空间、存储卷和资源配额。理解 Pod 的关键在于它不是一个“大容器”而是一个“容器的宿主环境”。同一个 Pod 里的容器用 localhost 互相访问这是多容器 Pod 设计的基础也是日志采集 sidecar 模式的前提。控制器Deployment、StatefulSet、DaemonSet、Job是比 Pod 更高一层的抽象。学习时很容易混淆它们的使用场景Deployment 管无状态应用副本可以随时替换StatefulSet 管有状态应用每个副本有独立的网络标识和存储DaemonSet 保证每个节点上恰好跑一个实例比如日志采集器、节点监控组件Job 管一次性任务。判断该用哪个控制器只要问一个问题我的应用是永久服务、有状态服务、节点级服务还是一跑就退出的任务Service 解决的是 Pod IP 不稳定、不能直接作为访问入口的问题。因为 Pod 随时可能被重建IP 会变化Service 用标签选择器把一组 Pod 聚合成一个稳定的虚拟 IP 和 DNS 名称。生产环境里客户端访问的是 Service而不是某个 Pod。LFS258 在基础阶段不会要求你背所有 Service 类型但 ClusterIP、NodePort、LoadBalancer 三种模式的差异必须清楚——它们对应的分别是集群内部访问、节点端口访问、云平台负载均衡器接入。2.3 控制面与工作节点的协作机制etcd、kubelet 与调度器各干什么Kubernetes 集群分为控制面和工作节点两部分这个分区是整个系统的骨架。控制面由 API Server、etcd、调度器、控制器管理器组成工作节点上跑着 kubelet、容器运行时和 kube-proxy。学习时最容易犯的错是把这些组件当成一个个抽象名词去背而不是理解它们之间的数据流。其实只需要记住一条主线一切状态都通过 API Server 流转etcd 存储状态调度器决定放在哪kubelet 负责落实到节点上。API Server 是整个集群的唯一入口所有kubectl命令、控制器、调度器的读写都打到它身上。它做三件事认证鉴权、校验 YAML 格式与语义、把合法的对象写入 etcd。所以当你kubectl apply一个文件时如果格式有错在 API Server 这一层就会被拦下根本不会落到节点上。etcd 是分布式键值存储它保存集群的完整状态。节点挂了、Pod 被删了、配置改了etcd 里都有记录。这也意味着etcd 是唯一需要备份的组件其他组件都可以无状态地重建。做运维的人常说的“etcd 是集群的黑匣子”就是这个意思——想看断言发生了什么直接查 etcd 或通过 API Server 查对象状态这是最权威的信息源。调度器负责为新创建的 Pod 挑选一个合适的节点依据是资源请求值、节点亲和性、污点与容忍度。工作节点上的 kubelet 则是每个节点的“最后一公里执行者”它监听 API Server 分配给本节点的 Pod确保容器真的在运行然后不断上报节点和 Pod 的状态。如果 kubelet 挂了节点上的容器并不会立即停止但 API Server 会在一段时间后判定节点失联触发控制器在别处重建 Pod。学习 LFS258 时建议这样验证组件理解在实验环境里执行kubectl get events --sort-by.lastTimestamp查看事件流你能看到调度器“Successfully assigned”、kubelet“Pulled image”“Started container”这些事件它们对应了上面说的协作链路。把这些事件和时间戳对齐比反复读五遍组件说明更管用。3. 用本地环境跑通 Kubernetes 最小集群minikube 安装与验证命令3.1 选择本地集群工具先想清楚要验证什么再决定用 minikube 还是 kindLFS258 的动手实验需要一个本地集群环境常见选择有 minikube、kind、k3s。很多初学者随便装一个就开始跑结果后面发现工具特性干扰了对 Kubernetes 本身的理解。我建议先想清楚自己的目标是“模拟真实集群结构”还是“快速验证某几个对象”。目标不同选择完全不同。工具集群结构资源占用最适用的验证场景主要限制minikube单节点可启用多节点中基础命令、Pod/Service/ConfigMap、控制面行为默认使用虚拟机驱动启动偏慢kind单控制面 多工作节点中高多节点调度、节点故障、Ingress 规则基于容器网络行为与物理节点有差异k3s单节点压扁结构低资源受限环境的快速验证架构做了裁剪和标准集群有差异我一般用 minikube 作为 LFS258 学习的主环境原因有三个。第一它默认就是虚拟机里的单节点集群包括完整的控制面组件和真实集群行为最接近第二它内置了minikube start和minikube dashboard对新手最友好第三它支持--cpus、--memory、--kubernetes-version参数可以在资源受限时调节占用。kind 适合需要验证多节点行为的场景比如“节点下线后控制器何时在别的节点重建 Pod”但 kind 的节点本质是容器某些系统层面的行为如磁盘压力、PID 耗尽模拟不出来。k3s 适合资源极少的边缘环境但它的架构做了很多裁剪学习标准 Kubernetes 时容易产生误导。如果只是跟着 LFS258 做基础实验minikube 是起点kind 留到需要多节点时再切换。3.2 最小安装步骤minikube 启动、kubectl 对齐与集群健康检查本地环境搭建的第一步是先确认本机已经装好容器运行时和 kubectl。常见的做法是先检查现状docker version --format {{.Server.Version}} kubectl version --clientdocker version检查的是容器引擎是否可用kubectl version --client查看客户端版本。注意这里只查了客户端版本后面还要和服务端版本对齐版本差距过大会导致 API 兼容问题。很多新手在这里埋下第一个坑客户端 v1.28、服务端 v1.23然后发现某些字段在 apply 时被忽略或报错。接着启动 minikube。最常用、最不挑环境的方式是让 minikube 使用 Docker 驱动minikube start --driverdocker \ --cpus2 \ --memory2048 \ --kubernetes-version1.27.3--driverdocker表示让 minikube 的所有控制面组件以容器方式跑在你的 Docker 引擎里不需要额外安装虚拟机软件。--cpus2和--memory2048是给这个虚拟集群分配的资源如果电脑内存只有 8G建议把内存降到 1536如果本机资源充裕又想做稍微重一点的实验比如同时跑多个控制器可以给到 4GB。--kubernetes-version1.27.3务必指定否则 minikube 会默认用最新版本和 LFS258 课程环境或其他工具的参数会有出入。启动完成后第一件事不是立刻创建 Pod而是确认集群健康kubectl cluster-info kubectl get nodes kubectl get pods -Akubectl cluster-info输出集群控制面的地址如果这里就报The connection to the server ... was refused说明 API Server 没起来查docker ps看容器状态。kubectl get nodes查看节点状态正常应该是Ready如果一直NotReady多半是 kubelet 起不来或容器运行时配置有问题。kubectl get pods -A看所有命名空间的 Pod 状态重点看kube-system命名空间里的组件是否 Running——coredns 和 etcd 是常见的两个“启动慢”对象等 30 秒再看一般就绪。3.3 看懂 kubectl 输出从 get、describe 到 logs 的排错三联集群起来了接下来要养成一个习惯拿到任何异常状态按 get → describe → logs 的顺序查下去。这三条命令组成了 Kubernetes 排障的最小闭环LFS258 的实验里至少一半的任务是围绕这三条命令设计的。kubectl get回答“当前是什么状态”是最快的体检表kubectl get pods -o wide kubectl get deployment -o wide kubectl get svc-o wide会额外显示 Pod 所在的节点名和 Pod IP排查调度问题或网络问题时非常有用。get只能看到状态的最终结果但看不到状态变化的原因于是需要describe出场。kubectl describe回答“这个对象经历了什么”它会把对象的事件列表直接列出来kubectl describe pod pod-name输出里最关键的部分是最后的Events区域。这里能看到镜像拉取成功、容器启动、健康检查通过这些事件如果 Pod 一直PendingEvents 里通常会有0/1 nodes are available加上具体原因的调度失败信息。注意describe显示的是对象当前存在的事件历史Pod 重建后事件会清空所以要在异常发生后的短时间内查看。kubectl logs回答“容器内部在输出什么”用于排查应用本身的问题kubectl logs pod-name kubectl logs -f pod-name-f是持续跟随输出适合看启动日志或调试循环任务。如果 Pod 里有多个容器需要加-c container-name指定容器否则会报“需要指定容器名”。这三个命令配合使用的场景非常典型get看到 CrashLoopBackOff →describe看到 Liveness 探针失败 →logs看到应用报错端口未监听。这个排查链路是 LFS258 实验里默认要求掌握的能力。4. 把 LFS258 的核心工作负载概念落到实操上部署、暴露与配置的完整闭环4.1 用 Deployment 跑起你的第一个应用YAML 写法和滚动更新参数Deployment 是学习 Kubernetes 工作负载的第一个落脚点因为它是无状态应用部署的标准形态。不要用kubectl run随手创建一个 Pod 就以为完成了部署——Pod 不是部署单元Deployment 才是。LFS258 的实验里反复强调这一点因为直接创建 Pod 意味着你没有副本保障、没有滚动更新、没有故障自愈能力。先看一个最小可用的 Deployment YAML然后逐行拆解apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deploy labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80apiVersion: apps/v1是 Deployment 的正确 API 版本早期课程资料里的extensions/v1beta1在老集群上才有现在的标准环境用apps/v1。selector.matchLabels是整个 YAML 里最容易被忽略但最关键的字段它决定了 Deployment 控制哪些 Pod。template里的 Pod 标签必须和selector匹配否则控制器会创建 Pod 但无法关联它们行为变得不可预测。应用这个文件kubectl apply -f nginx-deployment.yaml kubectl rollout status deployment/nginx-deployapply是声明式操作重复执行不会重复创建而create会。rollout status会实时显示滚动更新的进度比如Waiting for rollout to finish: 2 of 3 updated replicas are available...等待结束会显示deployment nginx-deploy successfully rolled out。Deployment 的滚动更新策略在spec.strategy.rollingUpdate里配置两个参数必调参数默认值作用建议maxUnavailable25%更新期间最多允许多少副本不可用追求高可用就设 0maxSurge25%更新期间最多允许多少额外副本资源紧张时设 0实际使用时如果你在更新期间不希望任何流量损失把maxUnavailable设为 0、maxSurge设为 1意思是“先起一个新的确认可用后再停一个旧的”。反过来如果你希望更新迅速完成、能容忍短暂的部分不可用把maxSurge设为 0、maxUnavailable设为 50%。这两个参数是面试高频点也是生产环境真正会调的参数。4.2 用 Service 把 Pod 暴露给集群内外ClusterIP 与 NodePort 的选择Deployment 创建完成后Pod 虽在运行但集群内外都访问不到。Pod IP 是临时的Pod 重建就变而且 3 个副本有 3 个 IP客户端不知道该访问哪个。Service 解决了这两个问题提供稳定虚拟 IP、把流量负载均衡到多个 Pod。把上一节的 Deployment 暴露成 Servicekubectl expose deployment nginx-deploy \ --typeClusterIP \ --port80 \ --target-port80 \ --namenginx-svc--typeClusterIP表示只能在集群内部访问--port80是 Service 对外提供服务的端口--target-port80是后端 Pod 实际监听的端口。这两个端口经常被搞混客户端访问Service IP:80请求被转发到Pod IP:80如果容器监听的是 8080写--port80 --target-port8080才对。验证访问kubectl get svc nginx-svc kubectl run test-pod --imagebusybox --rm -it -- sh # 在临时 Pod 里执行 wget -O- http://nginx-svc:80临时 Pod 里用 Service DNS 名称访问是验证 ClusterIP Service 的最快方式。Service 名称就是集群内的域名前缀同命名空间下直接用服务名即可访问。如果要在集群外部访问最简单的方式是改用 NodePortkubectl expose deployment nginx-deploy \ --typeNodePort \ --port80 \ --target-port80 \ --namenginx-nodeport kubectl get svc nginx-nodeportNodePort 会在每个节点上开一个 30000-32767 之间的随机端口访问任意节点 IP:随机端口就能到达 Service。注意这个 NodePort 是全局性的所有节点都会监听同一个端口。LFS258 实验里用 NodePort 验证“集群外部入口”已经足够LoadBalancer 类型只有在上云后才有实际意义本地集群不支持。4.3 用 ConfigMap 和 Secret 解耦配置给应用注入参数的常见做法Deployment 和 Service 解决了“应用跑起来”的问题但应用还需要配置。生产环境里不可能把数据库地址、口令、开关参数写死在镜像里于是 Kubernetes 提供了 ConfigMap 和 Secret 两个配置注入对象。它们的作用本质相同——把配置从镜像中解耦出来但数据安全级别不同ConfigMap 存普通文本Secret 存敏感信息。创建 ConfigMap 的两种常见方式# 方式一从字面量创建 kubectl create configmap app-config \ --from-literalDB_HOSTmysql.svc.local \ --from-literalLOG_LEVELinfo # 方式二从文件创建 kubectl create configmap app-config-file \ --from-fileapp.properties--from-literal适合少量键值对--from-file适合整个配置文件。注意 ConfigMap 的键名必须符合 DNS 子域名规范不能有大写字母和特殊符号这是新手常犯的错。把 ConfigMap 引用进 Deployment修改上一节的 YAMLspec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 env: - name: LOG_LEVEL valueFrom: configMapKeyRef: name: app-config key: LOG_LEVELconfigMapKeyRef.name指定 ConfigMap 名称key指定要取哪个键。这样配置变更时只需要改 ConfigMap然后滚动重启应用不需要重新构建镜像。Secret 的创建方式类似只多一步编码处理kubectl create secret generic db-secret \ --from-literalDB_PASSWORDPssw0rd这是自动 base64 编码的最简写法但要注意 base64 只是编码不是加密kubectl get secret db-secret -o yaml任何人都能读到原文。真正的生产使用需要配合外部密钥管理方案LFS258 基础阶段不做展开但要有这个安全意识。Secret 使用的实际坑是更新 Secret 后已运行的 Pod 不会拿到新值必须重启或滚动更新应用才能生效。如果你改了 ConfigMap 或 Secret 后访问应用发现还是旧配置先跑一下kubectl rollout restart deployment/xxx这个行为可以理解为 Kubernetes 的“后悔药”。5. 自己搭环境最容易翻车的 5 个地方避坑排查清单5.1 坑一minikube 启动卡在 Starting the control plane现象执行minikube start后长时间停留在Starting the control plane最后报错退出minikube status显示host: Running但kubelet: Stopped。原因最常见的是镜像仓库连通性不佳控制面组件镜像拉取超时。其次是本机 Docker 资源不足minikube 容器启动了但内部组件起不来。很多时候这两个原因同时存在镜像一直拉不下来Docker 缓存爆掉kubelet 就没法初始化。解决先检查 Docker 磁盘占用清理无用镜像和悬空镜像然后带详细日志重新启动minikube start --driverdocker \ --cpus2 \ --memory2048 \ --kubernetes-version1.27.3 \ --v7--v7是 minikube 的详细日志级别启动失败时能看到具体是哪个镜像或哪个步骤超时。如果确认是镜像拉取问题给容器运行时配置镜像仓库加速地址或指定一个可用的镜像仓库再重试。5.2 坑二镜像拉不下来导致 Pod 一直 ImagePullBackOff现象kubectl get pods看到 Pod 状态在ImagePullBackOffdescribe里 Events 显示Failed to pull image或Back-off pulling image。原因Kubernetes 集群所在环境访问默认镜像仓库不稳定或者 YAML 里指定的镜像标签写错比如nginx:1.25写成nginx:v1.25或nginx:latest的某个不存在变体。还有一个隐蔽原因是镜像仓库对匿名拉取限流连续创建多个 Pod 时触发限流。解决先确认镜像标签存在且格式正确用docker pull在节点上手动拉一遍。然后修改 Deployment 的镜像地址为较稳定的镜像源。改好后执行kubectl rollout restart deployment/nginx-deploy让 Pod 重建。注意ImagePullBackOff有退避计时频繁删除重建不会缩短重试间隔反而可能踩到仓库限流。5.3 坑三kubectl 版本和集群版本差太远命令行为不一致现象kubectl apply一个 YAML 文件不报错但对象根本没创建或者输出版本差异告警某个字段在文档里有但本地集群就是不生效。原因kubectl 客户端版本和服务端 API Server 版本差距过大客户端默认走的是最新 API 发现机制老版本 API Server 不认识新字段。尤其是用新客户端访问老集群时未知字段会被静默丢弃这是最危险的情况——你以为配置生效了其实没有。解决养成先对齐版本再操作的习惯kubectl version --client kubectl version --server如果客户端和服务器版本差超过一个小版本要么升级集群要么换一个与集群版本匹配的 kubectl。Kubernetes 官方支持前后一个版本的兼容窗口超过这个窗口行为就无法保证。5.4 坑四Service 选型不对外部访问永远超时现象kubectl get svc有地址但在集群外curl http://192.168.49.2:31000一直超时或者 NodePort 能通但换成 ClusterIP 后外部访问失败。原因ClusterIP 类型的 Service 只具备集群内可达性集群外访问需要 NodePort 或 LoadBalancer。NodePort 的在节点 IP 上监听但 minikube 单节点环境访问的 IP 应该用minikube ip查出来的地址而不是localhost。另一个常见问题是 Service 的selector与 Pod 标签不匹配Service 后面没有 Endpoint请求被转到黑洞。解决先查kubectl get endpoints如果显示Endpoints: none说明标签选择器没匹配上然后确认 Service 端口和 Pod 容器端口是否对应最后用minikube service -n namespace service-name获取正确的访问地址。外部访问超时时按这个顺序排查 8 成能定位。5.5 坑五改了 YAML 没生效像在“玄学运维”现象修改了 Deployment 或 ConfigMap执行kubectl apply返回configured但应用行为完全没变日志和配置都是旧的。原因apply更新了对象的期望状态但控制器不一定会主动重启已经运行的 Pod。Deployment 只有在模板Pod 模板变更时才会触发滚动更新ConfigMap 和 Secret 的变更不会直接触发滚动更新必须手动重启。很多人误以为“改了配置就会自动拉起新 Pod”这是对声明式模型最常见的误解。解决写完apply后主动触发一次重启kubectl rollout restart deployment/nginx-deploy这个命令会生成一个新的修订版本让 Deployment 按滚动更新策略重建所有 Pod。重启后不要只看 Pod 是不是 Running要看新旧版本切换是否完整kubectl rollout status deployment/nginx-deploy kubectl get replicasets -l appnginx看到旧 ReplicaSet 的副本数为 0、新 ReplicaSet 的副本数等于期望值这次变更才算真正生效。6. 把 LFS258 的资源用到最后一步用 explain、dry-run 和故障演练验证自己的掌握度课程资源本身是有限的但 Kubernetes 自带的“活字典”其实就在手边。我在过完 LFS258 基础的实验要求后最高效的收尾方式是三件事用kubectl explain把每个核心对象的字段结构过一遍用--dry-runclient在不改动集群的前提下反复验证自己的 YAML 写法再人为制造一个故障并独立恢复。kubectl explain是理解 API 对象最权威的工具比任何博客都准确。查看任意对象的字段结构kubectl explain deployment.spec.template.spec.containers kubectl explain deployment.spec.strategy.rollingUpdate它会列出每个字段的类型、默认值、是否必填以及最下面一行提示You can also look up the field reference...。而且它是递归的从外层对象一直追到最底层字段比如从deployment追到container的resources字段链路一目了然。查一个普通对象所需的全部字段用kubectl explain deployment --recursive一次展开。这比背文档更接近“动词式学习”。--dry-runclient是 YAML 写法的后悔药kubectl apply -f nginx-deployment.yaml --dry-runclient kubectl apply -f nginx-deployment.yaml --dry-runclient -o yaml第一个命令只校验 YAML 格式和基本语义但不会影响集群加-o yaml后还能看到经过 API Server 默认值填充的完整对象结构——你可以看到哪些字段你没写但系统为你补了默认值这很有价值。注意--dry-runclient只做客户端本地校验如果确定要写测试集群可以用--dry-runserver让 API Server 做完整校验这是最接近“真实创建但不真正写入”的验证方式。故障演练则是检验理解深度的唯一标准。我做过的最后一个验证是在 minikube 节点上停止 kubelet观察 Kubernetes 如何反应。minikube ssh sudo systemctl stop kubelet然后在本地观察kubectl get nodes的变化——节点先是NotReady过一段时间后节点上的 Pod 被标记为Terminating控制面在别处重建 Pod。最后再把 kubelet 拉起来恢复节点。这一套演练把节点心跳、控制器重建、Pod 生命周期几个概念串成了一次真实经历比任何理论题都印象深刻。这是这套课程资源最值得投入的用法不是看完视频、记完笔记就算结束而是把每个核心对象都“弄坏一次、再恢复一次”。我当初就是在故障演练里误删了一个命名空间花了一整天才把服务恢复到原状从此记住了kubectl delete ns的危险和kubectl apply -f做恢复的意义——这套刻进肌肉记忆的成本比任何 PPT 都值。希望帮到你。本文还有配套的精品资源点击获取