简介面向Kubernetes基础课程LFS258的学员这份压缩包提供课程实验所需基础设施的完整搭建材料帮助解决实验环境准备繁琐、步骤易错的问题。资源共包含11个文件以Terraform配置.tf采用HCL语法和Shell启动脚本.sh为核心可自动创建虚拟机、管理VPC与子网另配有关键步骤的PNG截图、README说明及密钥文件文件类型覆盖配置、脚本、文档与图片整体仅306KB轻量而实用。包内详细展示了GCP项目新建、服务账号创建及权限授予、访问密钥生成等操作细节并单独提供master与worker节点的启动脚本便于对照课程进度逐项复现。已有407人学习下载适合正在跟随LFS258课程动手实操、希望快速搭建云上Kubernetes实验环境的入门及进阶学习者。1. Kubernetes 基础知识 LFS258 资源别再只会 kubectl get pods 了Kubernetes 的知识点又多又碎很多人一上来就照着网上的 YAML 部署业务结果 Pod 为什么一直重启、Service 为什么忽通忽不通完全是一笔糊涂账。这份 LFS258 课程配套资源把 Kubernetes 基础知识的讲义、实验脚本和 YAML 模板整理成了完整主线从集群架构、Pod 调度、控制器到网络和存储一条线走下来。它适合两类人一类是刚接触容器编排、想按官方认证体系系统过一遍基础的新手另一类是平时 kubectl 敲得溜、但没深究过底层原理的从业者正好用资源里的实验补认知盲区。我照着这份资源把环境从零搭了一遍把选型、步骤和踩过的坑写成下面这篇文章新手能跟步骤走熟手可以跳过基础直接看避坑章节。2. 环境搭建minikube 单机与 kubeadm 多节点的选型和落地2.1 本地实验选 minikube驱动、内存和容器运行时LFS258 前几章的实验集中在 Pod、Deployment、Service 这些核心对象上单节点集群完全够用所以本地环境我首选 minikube。它的优势是初始化快、占用可控、销毁重来成本几乎为零适合跟着课程一节一节过。驱动方面我选了 docker 驱动条件是你的机器上已经装好了 Dockerminikube 会直接基于 docker 容器把整个控制平面跑起来不需要额外装虚拟化软件Windows 和 macOS 上尤其省事。minikube start \ --driverdocker \ --cpus4 \ --memory6144 \ --kubernetes-versionv1.29.0 \ --image-mirror-countrycn参数说明--cpus和--memory决定 Kubernetes 控制平面和业务 Pod 能拿到的资源我给了 4 核 6G跑课程里的实验基本不卡--kubernetes-version指定版本建议固定版本而不是用默认的 latest避免后面课程里的 YAML 与新版 API 不兼容--image-mirror-countrycn是 minikube 提供的镜像加速参数国内网络环境下能明显加快组件镜像拉取。初始化完成后kubectl get nodes能看到一个 Ready 的节点控制平面和业务 Pod 共用这一个 node这也是单节点环境需要记住的第一条边界默认情况下业务 Pod 会和控制面组件挤在同一台机器上资源紧张时表现和真实多节点集群有差异。这里要提醒一句minikube 默认会给节点打上node-role.kubernetes.io/control-plane相关标签但并不会给业务 Pod 加污点隔离所以调度行为和真实集群不完全一致。做资源限制相关的实验时注意观察kubectl describe node里的 Allocated resources 字段单节点上更容易出现资源不足导致 Pod Pending 的情况。课程里如果涉及多节点调度、污点容忍这类实验minikube 支持--nodes3参数拉起三节点但我个人建议直接跳去 kubeadm体验更接近生产。2.2 kubeadm 搭三节点集群初始化参数与 CNI 插件到了网络策略、持久化存储、多节点调度这些章节单节点就露馅了。我按资源里的指引用 kubeadm 搭了一套一主两从的三节点集群。前置条件是三台 Ubuntu 22.04 的机器虚拟机也行每台装好 containerd、kubeadm、kubelet、kubectl版本统一锁在 v1.29.0。这里有一个绕不开的坑containerd 默认的 Cgroup 驱动是 systemd 还是 cgroupfs必须和 kubelet 保持一致不然 kubelet 会报failed to run Kubelet的错。常见做法是在/etc/containerd/config.toml里把SystemdCgroup设为true然后重启 containerd。sudo kubeadm init \ --kubernetes-versionv1.29.0 \ --apiserver-advertise-address192.168.1.10 \ --pod-network-cidr10.244.0.0/16 \ --control-plane-endpoint192.168.1.10参数说明--apiserver-advertise-address是 API Server 对外通告的地址填主节点的内网 IP--pod-network-cidr是 Pod 网段这个 CIDR 必须和后面要装的 CNI 插件要求一致比如 Flannel 默认用 10.244.0.0/16Calico 默认用 192.168.0.0/16选哪个插件就用哪个网段混用会直接导致跨节点 Pod 互不通。初始化成功后按输出的提示执行三件事把 admin.conf 拷到~/.kube/config拿到管理权限、安装 CNI 插件、把 worker 节点用kubeadm join加进来。mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.ymlCNI 插件这块我的习惯是课程实验选 Flannel配置简单、跨节点通信稳定够用如果后面要测 NetworkPolicy再迁到 Calico。注意 Flannel 的 YAML 里默认镜像在 Docker Hub 上内网机器可能拉不动提前把镜像docker pull到各节点并docker tag成 YAML 里写的名字能省不少等待时间。装完等几十秒kubectl get nodes三台都 Ready再用kubectl get pods -n kube-system看 CoreDNS 是否 RunningCoreDNS 起不来往往是 CNI 网段冲突或镜像没拉全优先查这两个方向。2.3 集群健康检查kubectl get 之外还要看什么环境搭好只是开始排障的第一步是会用一系列检查命令把集群状态摸清楚。我一般按这个顺序走先看节点再看系统组件最后看事件。节点状态用kubectl get nodes -o wide能一次性看到节点 IP、内核版本、容器运行时版本系统组件用kubectl get pods -n kube-system关注 CoreDNS、etcd、kube-apiserver 这些关键 Pod 是不是 Running如果某个 Pod 状态不对kubectl describe pod xxx -n kube-system里的 Events 字段就是第一手线索。检查项命令重点看什么节点资源kubectl describe node nodeAllocated resources 是否接近上限组件状态kubectl get csscheduler/controller-manager 健康事件流kubectl get events --sort-by.lastTimestamp按时间倒序的错误事件etcd 健康kubectl exec -n kube-system etcd-node -- etcdctl endpoint health每个 etcd 成员是否 healthyAPI 可达kubectl cluster-info控制平面各端点是否返回正常这个表里的命令看起来基础但很多从业者卡在翻车现场时第一反应是重启而不是先看事件结果绕了一大圈。我的经验是任何异常先kubectl get events大部分问题在事件里已经有明确提示比翻日志快得多。另外kubectl get cs在较新的 Kubernetes 版本里默认会显示unhealthy别慌那是健康检查组件本身的已知行为不代表集群有问题对照kubectl get componentstatuses时要以实际 API 响应为准。3. 核心工作负载实战Pod、Deployment 与 Service 的编排关系3.1 Pod 与容器镜像、探针和资源限制Pod 是 Kubernetes 里最小的调度单元但很多新手把它和容器混为一谈。一个 Pod 可以装多个容器共享网络命名空间和存储卷典型场景是 sidecar 模式比如主容器跑 Nginxsidecar 容器负责收集日志或同步配置。课程实验里最常见的写法是单容器 Pod我建议在练习阶段就把探针和资源限制一起写进去养成习惯不然到后面做滚动更新实验时必翻车。apiVersion: v1 kind: Pod metadata: name: lfs258-web spec: containers: - name: web image: nginx:1.25 imagePullPolicy: IfNotPresent ports: - containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 80 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 250m memory: 256Mi逻辑说明livenessProbe决定容器要不要重启探测失败 kubelet 会杀掉容器按restartPolicy重启readinessProbe决定容器要不要接流量探测失败会把 Pod 从 Service 的 Endpoints 里摘掉但不会重启容器。这两个探针职责完全不同initialDelaySeconds是容器启动后等多久才开始探测periodSeconds是探测间隔Nginx 这类应用给 10 秒启动缓冲比较稳妥。resources里requests是调度依据limits是运行时上限只写 limits 不写 requests 在某些场景下会被系统按 limits 值填 requests导致调度判断失真这是资源管理里一个很隐蔽的坑。课程里会有kubectl exec进容器、kubectl logs -f看输出的练习组合起来就是排查 Pod 异常的完整手段。我的习惯是创建完 Pod 先kubectl get pod -o wide看它被调度到哪个节点再kubectl describe看事件最后才决定要不要看日志顺序反了容易在错误的方向上浪费时间。3.2 Deployment 滚动更新maxSurge 与 maxUnavailable 参数Deployment 是课程里最重要的控制器之一它负责声明期望的副本数并保证实际状态向期望状态收敛。手动删一个 PodDeployment 会立刻重建一个这是它的入门体验。真正有含金量的是滚动更新策略里面两个参数maxSurge和maxUnavailable决定了更新过程中的快慢和可用性边界。apiVersion: apps/v1 kind: Deployment metadata: name: lfs258-app spec: replicas: 3 selector: matchLabels: app: lfs258-app strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: lfs258-app spec: containers: - name: app image: nginx:1.25 readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 5逻辑说明maxSurge: 1表示更新过程中允许超出期望副本数最多 1 个maxUnavailable: 0表示不允许出现不可用副本。这两个值组合起来的效果是先额外起一个新版本 Pod等它 readiness 通过后再逐个下线旧版本 Pod整个过程中可用副本数始终不低于 3适合在线业务。反过来如果实验场景是批量离线任务可以设maxSurge: 0、maxUnavailable: 1先删旧再起新资源占用更省。kubectl set image deployment/lfs258-app appnginx:1.26 \ --record kubectl rollout status deployment/lfs258-app kubectl rollout history deployment/lfs258-app kubectl rollout undo deployment/lfs258-app命令说明--record会把触发命令记录到 revision 历史里方便回溯rollout status阻塞等待更新完成返回成功才说明新版本全部就绪rollout undo回滚到上一个版本是实验翻车后的后悔药。这里必须强调一点如果没配 readinessProbe滚动更新会直接跳过就绪检查旧 Pod 全删完才发现新 Pod 起不来业务直接断档。所以我在课程实验里反复确认任何 Deployment 只要对外提供服务readinessProbe 必须有这不是可选优化是保命配置。3.3 Service 三类型ClusterIP、NodePort 与 LoadBalancer 的选型Service 是 Pod 和外界的桥梁核心机制是 selector 匹配 Pod 标签然后把流量转发到后端的 Endpoints 上。课程实验里最常见的三种类型ClusterIP 只在集群内部可达NodePort 把端口暴露到每个节点上LoadBalancer 则依赖云厂商的负载均衡器。三者的选型逻辑其实很简单只给集群内其他组件访问用 ClusterIP要给集群外访问但条件有限用 NodePort生产环境有云厂商 LB 可用用 LoadBalancer。apiVersion: v1 kind: Service metadata: name: lfs258-svc spec: type: NodePort selector: app: lfs258-app ports: - port: 80 targetPort: 80 nodePort: 30080 protocol: TCP逻辑说明port是 Service 自己的端口集群内通过svc-name:port访问targetPort是后端 Pod 的容器端口nodePort是节点上暴露的端口默认范围是 30000-32767不写的话系统随机分配。selector 必须和 Pod 的 labels 完全匹配这是 Service 调不通时最高频的翻车点kubectl get endpoints能看到后端列表是否为空为空先查 selector。课程实验里还会测sessionAffinity: ClientIP这个参数让同一个客户端的请求固定打到同一个 Pod 上适合有本地会话状态的应用。另外提醒一句externalTrafficPolicy默认是 Cluster会经过二次转发导致客户端真实 IP 丢失要保留源 IP 就设成 Local但代价是流量可能倾斜到某些节点。这些参数看起来细理解了以后调试 Service 基本不用猜。4. 配置与存储ConfigMap、Secret 和 PV/PVC 的完整落地4.1 ConfigMap 与 Secret从 data 到挂载的完整链路配置和敏感信息的解耦是 Kubernetes 实验里逃不掉的一环。ConfigMap 存非敏感配置Secret 存敏感信息两者的使用方式几乎一样可以注入成环境变量也可以挂载成文件。课程实验里的典型场景是把 Nginx 的配置文件放进 ConfigMap把数据库密码放进 Secret。apiVersion: v1 kind: ConfigMap metadata: name: lfs258-config data: nginx.conf: | server { listen 80; location / { root /usr/share/nginx/html; } } --- apiVersion: v1 kind: Secret metadata: name: lfs258-secret type: Opaque stringData: db_password: S3cr3tPss逻辑说明data和stringData的区别是data里的值必须是 base64 编码后的stringData直接写明文kubectl 提交时会自动帮你编码。注意 Secret 的 base64 只是编码不是加密kubectl get secret -o yaml就能看到明文千万别把生产密码当实验密码这样玩。把配置注入 Pod 有两种方式env字段挂成环境变量volumes挂成文件。环境变量方式在 ConfigMap 更新后不会自动同步到已运行的容器文件挂载方式则会在 kubelet 同步周期内自动更新。spec: containers: - name: web image: nginx:1.25 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: lfs258-secret key: db_password volumeMounts: - name: config-vol mountPath: /etc/nginx/nginx.conf subPath: nginx.conf volumes: - name: config-vol configMap: name: lfs258-config逻辑说明secretKeyRef把 Secret 的某个 key 注入成环境变量subPath指定只挂载 ConfigMap 里的单个 key 作为文件这样不会覆盖整个/etc/nginx目录。这里有个隐蔽的坑使用subPath挂载的文件不会随 ConfigMap 更新而刷新因为 kubelet 把它当作普通文件处理了这也是网上很多人抱怨改了 ConfigMap 不生效的根本原因之一。4.2 PV/PVC 与 StorageClass动态供给的绑定流程持久化存储是 Kubernetes 里最容易让人绕晕的模块核心是 PV、PVC、StorageClass 三个对象的关系。PV 是管理员预先准备的存储资源PVC 是用户对存储的申请StorageClass 则负责按需动态创建 PV。课程实验会分别演示静态供给和动态供给两条链路静态供给先建 PV 再建 PVC动态供给只需要建 PVC 和 StorageClass。apiVersion: v1 kind: PersistentVolume metadata: name: lfs258-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/lfs258 --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: lfs258-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi逻辑说明accessModes有三种ReadWriteOnce 单节点读写、ReadOnlyMany 多节点只读、ReadWriteMany 多节点读写hostPath 类型只支持 RWO这也是实验中限制最多的参数persistentVolumeReclaimPolicy决定 PVC 释放后 PV 怎么处理Retain 保留数据但 PV 不可复用Delete 直接删掉底层存储Recycle 已废弃。PVC 绑定 PV 的规则是容量、访问模式都满足再看 StorageClass 是否匹配。实验里最容易踩的坑是 PVC 一直 Pending原因是没有任何 PV 满足条件或者 StorageClass 的动态供给没配好。kubectl get pvc的状态列会给你线索Pending 说明还没绑定Bound 说明绑定成功。验证持久化的标准动作是创建一个挂载 PVC 的 Pod写一个文件删掉 Pod再重建一个挂载同一个 PVC 的 Pod文件还在这就证明数据真的持久化了。动态供给场景下minikube 自带一个基于 hostPath 的 standard StorageClass可以直接体验kubectl get sc看到自动创建的 PV注意它的 reclaimPolicy 是 DeletePVC 一删数据就没了。5. 避坑与常见问题LFS258 实验里的五个翻车点5.1 现象Pod 一直卡在 Pending创建 Pod 后kubectl get pods一直显示 PendingEvents 里提示FailedScheduling。原因通常有两种一种是节点资源不足requests 加起来超过了节点可分配资源另一种是镜像拉取慢但这种情况一般显示 ContainerCreating 而不是 Pending。解决方法是先kubectl describe node看 Allocated resources再检查 Pod 有没有 nodeSelector 或资源 requests 设置得不合理把 requests 调小或者加节点问题基本解决。课程实验里最常见的是 requests 写得太高比如给 4Gi 内存但实验节点总共只有 6Gi还要跑系统组件自然调度不上去。5.2 现象NodePort 访问不通Service 类型是 NodePortkubectl get svc能看到端口但浏览器访问节点IP:30080不通。排查顺序要从外到内先看节点防火墙有没有放行 30080 端口很多虚拟机上ufw或安全组默认只放行 22 和常用端口再看kubectl get endpoints后端地址列表是否为空为空说明 selector 没匹配到 Pod最后看 kube-proxy 是否正常kubectl logs -n kube-system -l k8s-appkube-proxy里如果有报错检查--proxy-mode是 iptables 还是 ipvs两种模式对内核模块依赖不同。这个问题的解决往往就一两步但排查路径不对会浪费半小时。5.3 现象滚动更新卡住不前进Deployment 更新后rollout status一直等不到完成新版本 Pod 反复创建又反复被杀。根本原因多半是新版本 Pod 的 readinessProbe 没通过或者压根没配 readinessProbe导致新 Pod 永远进不了 Ready 状态maxUnavailable: 0时旧 Pod 一个都不会删更新就卡死了。解决方法是kubectl rollout undo先回滚再检查新版本的探针路径和端口是否正确用kubectl port-forward手动访问一下 Pod 的探针路径确认返回 200然后再触发更新。从那以后我每次写 Deployment 都强制先确认 readinessProbe 能通再谈更新策略。5.4 现象ConfigMap 改了文件没变费劲改了 ConfigMap进容器看文件还是旧的。原因有两个一个是 kubelet 的同步周期默认 1 分钟改完要等一会儿另一个更隐蔽使用subPath挂载的 ConfigMap 文件不会自动更新kubelet 只在挂载点变化时重新拉取内容。解决方法是如果必须用 subPath就接受要触发更新只能重建 Pod这一点或者在 ConfigMap 更新后主动kubectl rollout restart deployment强制重建。另外走环境变量注入的配置容器启动后不会变更新 ConfigMap 后重建 Pod 才能生效这是很多老手也会记混的细节。5.5 现象kubeadm 集群接近一年时突然不可用集群跑了大半年某天kubectl get nodes开始报证书过期或连接超时。原因是 kubeadm 默认签发的证书有效期只有一年控制平面和 kubelet 的证书到期后 API Server 的 TLS 握手失败。解决方法是赶在过期前执行kubeadm certs renew all然后重启 kube-apiserver、kube-controller-manager、kube-scheduler 这些静态 Pod再更新所有节点的 kubelet 证书配置。这里的关键教训是用 kubeadm 建的集群一定要把证书续期写进运维日历等它自己炸了再处理代价是整个集群不可用比任何业务故障都难收拾。6. 进阶技巧把 YAML 换成 HCL用 Terraform 统一管理 Kubernetes 资源6.1 为什么把 YAML 迁到 HCL学完基础课程后大多数人还是停留在kubectl apply -f的层面但生产环境里资源散落在各个 YAML 文件里谁也说不清线上实际跑的版本是什么。HCL 是 Terraform 使用的声明式语言配合 Kubernetes Provider可以把 namespace、Deployment、Service 这些资源全部纳入 IaC 管理获得terraform plan的变更预览和terraform apply的自动化应用状态文件里能看到每一次变更的痕迹。这是把课程基础升级成生产习惯的一条捷径。6.2 一个 HCL 管理 namespace 与 Deployment 的 Demoprovider kubernetes { config_path ~/.kube/config } resource kubernetes_namespace lfs258 { metadata { name lfs258-prod } } resource kubernetes_deployment web { metadata { name lfs258-web namespace kubernetes_namespace.lfs258.metadata[0].name } spec { replicas 2 selector { match_labels { app lfs258-web } } template { metadata { labels { app lfs258-web } } spec { container { name web image nginx:1.25 port { container_port 80 } } } } } }逻辑说明config_path指定 kubeconfig 路径让 Terraform 拿当前集群的凭证kubernetes_namespace和kubernetes_deployment是 provider 暴露的两个资源类型资源之间的依赖关系用引用表达式表达比如 deployment 里的 namespace 直接引用了上面创建的资源属性Terraform 会按依赖顺序创建。执行时先terraform init拉取 provider再terraform plan看变更计划最后terraform apply应用。这套方式的优势是所有 Kubernetes 资源像基础设施一样可评审、可回滚改坏了一个 label 也能在 plan 阶段发现。课程基础打得越扎实用这些工具的时候越能理解背后发生了什么。每次我在新集群上做任何操作前都会强制自己先跑一遍kubectl get events和terraform plan确认变更范围再动手。这个习惯让我少踩了无数个改了一行配置业务挂了半小时的坑。希望你也能顺着这份资源把基础夯实带着这个习惯去折腾更复杂的场景希望帮到你。本文还有配套的精品资源点击获取
简介面向Kubernetes基础课程LFS258的学员这份压缩包提供课程实验所需基础设施的完整搭建材料帮助解决实验环境准备繁琐、步骤易错的问题。资源共包含11个文件以Terraform配置.tf采用HCL语法和Shell启动脚本.sh为核心可自动创建虚拟机、管理VPC与子网另配有关键步骤的PNG截图、README说明及密钥文件文件类型覆盖配置、脚本、文档与图片整体仅306KB轻量而实用。包内详细展示了GCP项目新建、服务账号创建及权限授予、访问密钥生成等操作细节并单独提供master与worker节点的启动脚本便于对照课程进度逐项复现。已有407人学习下载适合正在跟随LFS258课程动手实操、希望快速搭建云上Kubernetes实验环境的入门及进阶学习者。1. Kubernetes 基础知识 LFS258 资源别再只会 kubectl get pods 了Kubernetes 的知识点又多又碎很多人一上来就照着网上的 YAML 部署业务结果 Pod 为什么一直重启、Service 为什么忽通忽不通完全是一笔糊涂账。这份 LFS258 课程配套资源把 Kubernetes 基础知识的讲义、实验脚本和 YAML 模板整理成了完整主线从集群架构、Pod 调度、控制器到网络和存储一条线走下来。它适合两类人一类是刚接触容器编排、想按官方认证体系系统过一遍基础的新手另一类是平时 kubectl 敲得溜、但没深究过底层原理的从业者正好用资源里的实验补认知盲区。我照着这份资源把环境从零搭了一遍把选型、步骤和踩过的坑写成下面这篇文章新手能跟步骤走熟手可以跳过基础直接看避坑章节。2. 环境搭建minikube 单机与 kubeadm 多节点的选型和落地2.1 本地实验选 minikube驱动、内存和容器运行时LFS258 前几章的实验集中在 Pod、Deployment、Service 这些核心对象上单节点集群完全够用所以本地环境我首选 minikube。它的优势是初始化快、占用可控、销毁重来成本几乎为零适合跟着课程一节一节过。驱动方面我选了 docker 驱动条件是你的机器上已经装好了 Dockerminikube 会直接基于 docker 容器把整个控制平面跑起来不需要额外装虚拟化软件Windows 和 macOS 上尤其省事。minikube start \ --driverdocker \ --cpus4 \ --memory6144 \ --kubernetes-versionv1.29.0 \ --image-mirror-countrycn参数说明--cpus和--memory决定 Kubernetes 控制平面和业务 Pod 能拿到的资源我给了 4 核 6G跑课程里的实验基本不卡--kubernetes-version指定版本建议固定版本而不是用默认的 latest避免后面课程里的 YAML 与新版 API 不兼容--image-mirror-countrycn是 minikube 提供的镜像加速参数国内网络环境下能明显加快组件镜像拉取。初始化完成后kubectl get nodes能看到一个 Ready 的节点控制平面和业务 Pod 共用这一个 node这也是单节点环境需要记住的第一条边界默认情况下业务 Pod 会和控制面组件挤在同一台机器上资源紧张时表现和真实多节点集群有差异。这里要提醒一句minikube 默认会给节点打上node-role.kubernetes.io/control-plane相关标签但并不会给业务 Pod 加污点隔离所以调度行为和真实集群不完全一致。做资源限制相关的实验时注意观察kubectl describe node里的 Allocated resources 字段单节点上更容易出现资源不足导致 Pod Pending 的情况。课程里如果涉及多节点调度、污点容忍这类实验minikube 支持--nodes3参数拉起三节点但我个人建议直接跳去 kubeadm体验更接近生产。2.2 kubeadm 搭三节点集群初始化参数与 CNI 插件到了网络策略、持久化存储、多节点调度这些章节单节点就露馅了。我按资源里的指引用 kubeadm 搭了一套一主两从的三节点集群。前置条件是三台 Ubuntu 22.04 的机器虚拟机也行每台装好 containerd、kubeadm、kubelet、kubectl版本统一锁在 v1.29.0。这里有一个绕不开的坑containerd 默认的 Cgroup 驱动是 systemd 还是 cgroupfs必须和 kubelet 保持一致不然 kubelet 会报failed to run Kubelet的错。常见做法是在/etc/containerd/config.toml里把SystemdCgroup设为true然后重启 containerd。sudo kubeadm init \ --kubernetes-versionv1.29.0 \ --apiserver-advertise-address192.168.1.10 \ --pod-network-cidr10.244.0.0/16 \ --control-plane-endpoint192.168.1.10参数说明--apiserver-advertise-address是 API Server 对外通告的地址填主节点的内网 IP--pod-network-cidr是 Pod 网段这个 CIDR 必须和后面要装的 CNI 插件要求一致比如 Flannel 默认用 10.244.0.0/16Calico 默认用 192.168.0.0/16选哪个插件就用哪个网段混用会直接导致跨节点 Pod 互不通。初始化成功后按输出的提示执行三件事把 admin.conf 拷到~/.kube/config拿到管理权限、安装 CNI 插件、把 worker 节点用kubeadm join加进来。mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.ymlCNI 插件这块我的习惯是课程实验选 Flannel配置简单、跨节点通信稳定够用如果后面要测 NetworkPolicy再迁到 Calico。注意 Flannel 的 YAML 里默认镜像在 Docker Hub 上内网机器可能拉不动提前把镜像docker pull到各节点并docker tag成 YAML 里写的名字能省不少等待时间。装完等几十秒kubectl get nodes三台都 Ready再用kubectl get pods -n kube-system看 CoreDNS 是否 RunningCoreDNS 起不来往往是 CNI 网段冲突或镜像没拉全优先查这两个方向。2.3 集群健康检查kubectl get 之外还要看什么环境搭好只是开始排障的第一步是会用一系列检查命令把集群状态摸清楚。我一般按这个顺序走先看节点再看系统组件最后看事件。节点状态用kubectl get nodes -o wide能一次性看到节点 IP、内核版本、容器运行时版本系统组件用kubectl get pods -n kube-system关注 CoreDNS、etcd、kube-apiserver 这些关键 Pod 是不是 Running如果某个 Pod 状态不对kubectl describe pod xxx -n kube-system里的 Events 字段就是第一手线索。检查项命令重点看什么节点资源kubectl describe node nodeAllocated resources 是否接近上限组件状态kubectl get csscheduler/controller-manager 健康事件流kubectl get events --sort-by.lastTimestamp按时间倒序的错误事件etcd 健康kubectl exec -n kube-system etcd-node -- etcdctl endpoint health每个 etcd 成员是否 healthyAPI 可达kubectl cluster-info控制平面各端点是否返回正常这个表里的命令看起来基础但很多从业者卡在翻车现场时第一反应是重启而不是先看事件结果绕了一大圈。我的经验是任何异常先kubectl get events大部分问题在事件里已经有明确提示比翻日志快得多。另外kubectl get cs在较新的 Kubernetes 版本里默认会显示unhealthy别慌那是健康检查组件本身的已知行为不代表集群有问题对照kubectl get componentstatuses时要以实际 API 响应为准。3. 核心工作负载实战Pod、Deployment 与 Service 的编排关系3.1 Pod 与容器镜像、探针和资源限制Pod 是 Kubernetes 里最小的调度单元但很多新手把它和容器混为一谈。一个 Pod 可以装多个容器共享网络命名空间和存储卷典型场景是 sidecar 模式比如主容器跑 Nginxsidecar 容器负责收集日志或同步配置。课程实验里最常见的写法是单容器 Pod我建议在练习阶段就把探针和资源限制一起写进去养成习惯不然到后面做滚动更新实验时必翻车。apiVersion: v1 kind: Pod metadata: name: lfs258-web spec: containers: - name: web image: nginx:1.25 imagePullPolicy: IfNotPresent ports: - containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 80 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 250m memory: 256Mi逻辑说明livenessProbe决定容器要不要重启探测失败 kubelet 会杀掉容器按restartPolicy重启readinessProbe决定容器要不要接流量探测失败会把 Pod 从 Service 的 Endpoints 里摘掉但不会重启容器。这两个探针职责完全不同initialDelaySeconds是容器启动后等多久才开始探测periodSeconds是探测间隔Nginx 这类应用给 10 秒启动缓冲比较稳妥。resources里requests是调度依据limits是运行时上限只写 limits 不写 requests 在某些场景下会被系统按 limits 值填 requests导致调度判断失真这是资源管理里一个很隐蔽的坑。课程里会有kubectl exec进容器、kubectl logs -f看输出的练习组合起来就是排查 Pod 异常的完整手段。我的习惯是创建完 Pod 先kubectl get pod -o wide看它被调度到哪个节点再kubectl describe看事件最后才决定要不要看日志顺序反了容易在错误的方向上浪费时间。3.2 Deployment 滚动更新maxSurge 与 maxUnavailable 参数Deployment 是课程里最重要的控制器之一它负责声明期望的副本数并保证实际状态向期望状态收敛。手动删一个 PodDeployment 会立刻重建一个这是它的入门体验。真正有含金量的是滚动更新策略里面两个参数maxSurge和maxUnavailable决定了更新过程中的快慢和可用性边界。apiVersion: apps/v1 kind: Deployment metadata: name: lfs258-app spec: replicas: 3 selector: matchLabels: app: lfs258-app strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: lfs258-app spec: containers: - name: app image: nginx:1.25 readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 5逻辑说明maxSurge: 1表示更新过程中允许超出期望副本数最多 1 个maxUnavailable: 0表示不允许出现不可用副本。这两个值组合起来的效果是先额外起一个新版本 Pod等它 readiness 通过后再逐个下线旧版本 Pod整个过程中可用副本数始终不低于 3适合在线业务。反过来如果实验场景是批量离线任务可以设maxSurge: 0、maxUnavailable: 1先删旧再起新资源占用更省。kubectl set image deployment/lfs258-app appnginx:1.26 \ --record kubectl rollout status deployment/lfs258-app kubectl rollout history deployment/lfs258-app kubectl rollout undo deployment/lfs258-app命令说明--record会把触发命令记录到 revision 历史里方便回溯rollout status阻塞等待更新完成返回成功才说明新版本全部就绪rollout undo回滚到上一个版本是实验翻车后的后悔药。这里必须强调一点如果没配 readinessProbe滚动更新会直接跳过就绪检查旧 Pod 全删完才发现新 Pod 起不来业务直接断档。所以我在课程实验里反复确认任何 Deployment 只要对外提供服务readinessProbe 必须有这不是可选优化是保命配置。3.3 Service 三类型ClusterIP、NodePort 与 LoadBalancer 的选型Service 是 Pod 和外界的桥梁核心机制是 selector 匹配 Pod 标签然后把流量转发到后端的 Endpoints 上。课程实验里最常见的三种类型ClusterIP 只在集群内部可达NodePort 把端口暴露到每个节点上LoadBalancer 则依赖云厂商的负载均衡器。三者的选型逻辑其实很简单只给集群内其他组件访问用 ClusterIP要给集群外访问但条件有限用 NodePort生产环境有云厂商 LB 可用用 LoadBalancer。apiVersion: v1 kind: Service metadata: name: lfs258-svc spec: type: NodePort selector: app: lfs258-app ports: - port: 80 targetPort: 80 nodePort: 30080 protocol: TCP逻辑说明port是 Service 自己的端口集群内通过svc-name:port访问targetPort是后端 Pod 的容器端口nodePort是节点上暴露的端口默认范围是 30000-32767不写的话系统随机分配。selector 必须和 Pod 的 labels 完全匹配这是 Service 调不通时最高频的翻车点kubectl get endpoints能看到后端列表是否为空为空先查 selector。课程实验里还会测sessionAffinity: ClientIP这个参数让同一个客户端的请求固定打到同一个 Pod 上适合有本地会话状态的应用。另外提醒一句externalTrafficPolicy默认是 Cluster会经过二次转发导致客户端真实 IP 丢失要保留源 IP 就设成 Local但代价是流量可能倾斜到某些节点。这些参数看起来细理解了以后调试 Service 基本不用猜。4. 配置与存储ConfigMap、Secret 和 PV/PVC 的完整落地4.1 ConfigMap 与 Secret从 data 到挂载的完整链路配置和敏感信息的解耦是 Kubernetes 实验里逃不掉的一环。ConfigMap 存非敏感配置Secret 存敏感信息两者的使用方式几乎一样可以注入成环境变量也可以挂载成文件。课程实验里的典型场景是把 Nginx 的配置文件放进 ConfigMap把数据库密码放进 Secret。apiVersion: v1 kind: ConfigMap metadata: name: lfs258-config data: nginx.conf: | server { listen 80; location / { root /usr/share/nginx/html; } } --- apiVersion: v1 kind: Secret metadata: name: lfs258-secret type: Opaque stringData: db_password: S3cr3tPss逻辑说明data和stringData的区别是data里的值必须是 base64 编码后的stringData直接写明文kubectl 提交时会自动帮你编码。注意 Secret 的 base64 只是编码不是加密kubectl get secret -o yaml就能看到明文千万别把生产密码当实验密码这样玩。把配置注入 Pod 有两种方式env字段挂成环境变量volumes挂成文件。环境变量方式在 ConfigMap 更新后不会自动同步到已运行的容器文件挂载方式则会在 kubelet 同步周期内自动更新。spec: containers: - name: web image: nginx:1.25 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: lfs258-secret key: db_password volumeMounts: - name: config-vol mountPath: /etc/nginx/nginx.conf subPath: nginx.conf volumes: - name: config-vol configMap: name: lfs258-config逻辑说明secretKeyRef把 Secret 的某个 key 注入成环境变量subPath指定只挂载 ConfigMap 里的单个 key 作为文件这样不会覆盖整个/etc/nginx目录。这里有个隐蔽的坑使用subPath挂载的文件不会随 ConfigMap 更新而刷新因为 kubelet 把它当作普通文件处理了这也是网上很多人抱怨改了 ConfigMap 不生效的根本原因之一。4.2 PV/PVC 与 StorageClass动态供给的绑定流程持久化存储是 Kubernetes 里最容易让人绕晕的模块核心是 PV、PVC、StorageClass 三个对象的关系。PV 是管理员预先准备的存储资源PVC 是用户对存储的申请StorageClass 则负责按需动态创建 PV。课程实验会分别演示静态供给和动态供给两条链路静态供给先建 PV 再建 PVC动态供给只需要建 PVC 和 StorageClass。apiVersion: v1 kind: PersistentVolume metadata: name: lfs258-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/lfs258 --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: lfs258-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi逻辑说明accessModes有三种ReadWriteOnce 单节点读写、ReadOnlyMany 多节点只读、ReadWriteMany 多节点读写hostPath 类型只支持 RWO这也是实验中限制最多的参数persistentVolumeReclaimPolicy决定 PVC 释放后 PV 怎么处理Retain 保留数据但 PV 不可复用Delete 直接删掉底层存储Recycle 已废弃。PVC 绑定 PV 的规则是容量、访问模式都满足再看 StorageClass 是否匹配。实验里最容易踩的坑是 PVC 一直 Pending原因是没有任何 PV 满足条件或者 StorageClass 的动态供给没配好。kubectl get pvc的状态列会给你线索Pending 说明还没绑定Bound 说明绑定成功。验证持久化的标准动作是创建一个挂载 PVC 的 Pod写一个文件删掉 Pod再重建一个挂载同一个 PVC 的 Pod文件还在这就证明数据真的持久化了。动态供给场景下minikube 自带一个基于 hostPath 的 standard StorageClass可以直接体验kubectl get sc看到自动创建的 PV注意它的 reclaimPolicy 是 DeletePVC 一删数据就没了。5. 避坑与常见问题LFS258 实验里的五个翻车点5.1 现象Pod 一直卡在 Pending创建 Pod 后kubectl get pods一直显示 PendingEvents 里提示FailedScheduling。原因通常有两种一种是节点资源不足requests 加起来超过了节点可分配资源另一种是镜像拉取慢但这种情况一般显示 ContainerCreating 而不是 Pending。解决方法是先kubectl describe node看 Allocated resources再检查 Pod 有没有 nodeSelector 或资源 requests 设置得不合理把 requests 调小或者加节点问题基本解决。课程实验里最常见的是 requests 写得太高比如给 4Gi 内存但实验节点总共只有 6Gi还要跑系统组件自然调度不上去。5.2 现象NodePort 访问不通Service 类型是 NodePortkubectl get svc能看到端口但浏览器访问节点IP:30080不通。排查顺序要从外到内先看节点防火墙有没有放行 30080 端口很多虚拟机上ufw或安全组默认只放行 22 和常用端口再看kubectl get endpoints后端地址列表是否为空为空说明 selector 没匹配到 Pod最后看 kube-proxy 是否正常kubectl logs -n kube-system -l k8s-appkube-proxy里如果有报错检查--proxy-mode是 iptables 还是 ipvs两种模式对内核模块依赖不同。这个问题的解决往往就一两步但排查路径不对会浪费半小时。5.3 现象滚动更新卡住不前进Deployment 更新后rollout status一直等不到完成新版本 Pod 反复创建又反复被杀。根本原因多半是新版本 Pod 的 readinessProbe 没通过或者压根没配 readinessProbe导致新 Pod 永远进不了 Ready 状态maxUnavailable: 0时旧 Pod 一个都不会删更新就卡死了。解决方法是kubectl rollout undo先回滚再检查新版本的探针路径和端口是否正确用kubectl port-forward手动访问一下 Pod 的探针路径确认返回 200然后再触发更新。从那以后我每次写 Deployment 都强制先确认 readinessProbe 能通再谈更新策略。5.4 现象ConfigMap 改了文件没变费劲改了 ConfigMap进容器看文件还是旧的。原因有两个一个是 kubelet 的同步周期默认 1 分钟改完要等一会儿另一个更隐蔽使用subPath挂载的 ConfigMap 文件不会自动更新kubelet 只在挂载点变化时重新拉取内容。解决方法是如果必须用 subPath就接受要触发更新只能重建 Pod这一点或者在 ConfigMap 更新后主动kubectl rollout restart deployment强制重建。另外走环境变量注入的配置容器启动后不会变更新 ConfigMap 后重建 Pod 才能生效这是很多老手也会记混的细节。5.5 现象kubeadm 集群接近一年时突然不可用集群跑了大半年某天kubectl get nodes开始报证书过期或连接超时。原因是 kubeadm 默认签发的证书有效期只有一年控制平面和 kubelet 的证书到期后 API Server 的 TLS 握手失败。解决方法是赶在过期前执行kubeadm certs renew all然后重启 kube-apiserver、kube-controller-manager、kube-scheduler 这些静态 Pod再更新所有节点的 kubelet 证书配置。这里的关键教训是用 kubeadm 建的集群一定要把证书续期写进运维日历等它自己炸了再处理代价是整个集群不可用比任何业务故障都难收拾。6. 进阶技巧把 YAML 换成 HCL用 Terraform 统一管理 Kubernetes 资源6.1 为什么把 YAML 迁到 HCL学完基础课程后大多数人还是停留在kubectl apply -f的层面但生产环境里资源散落在各个 YAML 文件里谁也说不清线上实际跑的版本是什么。HCL 是 Terraform 使用的声明式语言配合 Kubernetes Provider可以把 namespace、Deployment、Service 这些资源全部纳入 IaC 管理获得terraform plan的变更预览和terraform apply的自动化应用状态文件里能看到每一次变更的痕迹。这是把课程基础升级成生产习惯的一条捷径。6.2 一个 HCL 管理 namespace 与 Deployment 的 Demoprovider kubernetes { config_path ~/.kube/config } resource kubernetes_namespace lfs258 { metadata { name lfs258-prod } } resource kubernetes_deployment web { metadata { name lfs258-web namespace kubernetes_namespace.lfs258.metadata[0].name } spec { replicas 2 selector { match_labels { app lfs258-web } } template { metadata { labels { app lfs258-web } } spec { container { name web image nginx:1.25 port { container_port 80 } } } } } }逻辑说明config_path指定 kubeconfig 路径让 Terraform 拿当前集群的凭证kubernetes_namespace和kubernetes_deployment是 provider 暴露的两个资源类型资源之间的依赖关系用引用表达式表达比如 deployment 里的 namespace 直接引用了上面创建的资源属性Terraform 会按依赖顺序创建。执行时先terraform init拉取 provider再terraform plan看变更计划最后terraform apply应用。这套方式的优势是所有 Kubernetes 资源像基础设施一样可评审、可回滚改坏了一个 label 也能在 plan 阶段发现。课程基础打得越扎实用这些工具的时候越能理解背后发生了什么。每次我在新集群上做任何操作前都会强制自己先跑一遍kubectl get events和terraform plan确认变更范围再动手。这个习惯让我少踩了无数个改了一行配置业务挂了半小时的坑。希望你也能顺着这份资源把基础夯实带着这个习惯去折腾更复杂的场景希望帮到你。本文还有配套的精品资源点击获取
