容器集群 k8s 从入门到精通：从零搭建可用集群与避坑指南-北京尧图网络

简介这份《容器集群k8s从入门到精通.pdf》面向希望系统掌握Kubernetes的开发者与运维人员从应用部署方式演变讲起逐步深入到集群架构与实战操作适合零基础入门到进阶提升的学习者。资源为单个PDF文档压缩包约4.22MB内容涵盖Kubernetes核心概念、组件原理与集群搭建流程结构完整、条理清晰。文档详细讲解了Master与Node的组件分工包括ApiServer、Scheduler、ControllerManager、Etcd、Kubelet与KubeProxy的职责并深入剖析Pod、Controller、Service、Label、NameSpace等核心对象。同时以部署Nginx服务为例串联各组件调用关系帮助读者理解请求从ApiServer到调度、再到容器启动的完整链路。第二章还给出基于CentOS7.5与kubeadm的一主两从集群环境搭建方案包含主机规划、网络配置与安装步骤便于对照实践。目前已有662人学习适合需要夯实云原生基础、掌握容器编排与自动化运维的读者参考。1. 容器集群 k8s 从入门到精通为什么你背完命令还是搭不出一个能用的集群很多人学 Kubernetes 的路径是这样的收藏一份《容器集群 k8s 从入门到精通.pdf》把kubectl get pods、kubectl describe、kubectl logs背得滚瓜烂熟面试也能聊几句 Pod、Service、Deployment 的关系。可真到要在一台干净机器上把集群拉起来、把业务跑通、把流量放进来的时候立刻卡住——镜像拉不动、Pod 一直 Pending、Service 访问不通、节点 NotReady报错信息翻来覆去就那么几行却不知道从哪下手。问题不在命令记得少而在于「从入门到精通」这条路上缺的是把概念串成一条可复现链路的能力。这份笔记不打算复述那本 PDF 的目录而是按一线搭集群的顺序把 k8s 的核心对象、最小可用集群的搭建、工作负载编排、网络与存储接入、以及排错方法讲成一条能照着走的路径。适合两类人刚接触容器编排、想亲手跑通一个集群的新手以及用过 k8s 但总在「能跑」和「跑稳」之间反复翻车的老手。读完你应该能独立完成一个单控制面加多工作节点的集群并把一个无状态服务完整暴露出去。2. 先把 k8s 的对象模型立住Pod、Deployment、Service 到底谁管谁学 k8s 最容易犯的错是把 Pod 当成「容器」来理解。Pod 是调度和生命周期的最小单位一个 Pod 里可以塞多个容器它们共享网络命名空间和存储卷。真正跑业务时你几乎不会直接创建 Pod而是通过 Deployment、StatefulSet 这类控制器来管理。理解这层「声明式控制器循环」的关系比记住任何一条命令都重要。2.1 声明式 API 与控制器循环k8s 的底层工作方式k8s 的核心不是「你命令它做什么」而是「你声明期望状态它自己想办法逼近」。你写一个 Deployment声明replicas: 3控制器就会持续对比「当前有几个 Pod」和「期望几个 Pod」少了就补多了就删。这个对比—调整的循环叫 reconcile loop是所有控制器的通用模式。这意味着两件事。第一你的 YAML 是「期望状态」不是「操作步骤」写错了不会报语法错而是集群一直达不到你要的状态。第二排错时要问的不是「我命令执行成功了吗」而是「当前状态和期望状态差在哪」。kubectl get看当前状态kubectl describe看事件和差异kubectl logs看容器内部这三条命令构成了排错的主干。下面是一个最小 Deployment 的声明注意它没有指定任何节点、任何 IP这些都由调度器和网络插件去填。apiVersion: apps/v1 kind: Deployment metadata: name: web-demo labels: app: web-demo spec: replicas: 3 # 期望副本数控制器会持续逼近这个值 selector: matchLabels: app: web-demo # 必须和 template 里的 labels 对上否则控制器找不到自己的 Pod template: metadata: labels: app: web-demo spec: containers: - name: web image: nginx:1.25-alpine # 用具体小版本别用 latest否则回滚时不知道回滚到哪 ports: - containerPort: 80 resources: requests: # 调度依据决定 Pod 被放到哪个节点 cpu: 100m memory: 128Mi limits: # 上限超了会被限流或 OOMKill cpu: 500m memory: 256Mi逻辑说明selector.matchLabels和template.metadata.labels必须一致这是新手最常见的「Deployment 创建成功但 Pod 数为 0」的原因。resources.requests决定调度limits决定运行时约束两者不设会让节点资源被超卖后期排查性能问题非常痛苦。参数上replicas按业务并发估cpu用m千分之一核为单位memory用Mi。2.2 Service 与 Endpoint流量是怎么找到 Pod 的Pod 的 IP 是临时的重建就变所以不能直接拿 Pod IP 对外。Service 提供稳定的虚拟 IP 和 DNS 名背后通过 selector 匹配一组 Pod自动维护 Endpoint 列表。理解 Service关键看三个字段type、selector、ports。apiVersion: v1 kind: Service metadata: name: web-demo-svc spec: type: ClusterIP # 集群内访问对外用 NodePort 或 LoadBalancer selector: app: web-demo # 匹配上面 Deployment 的 Pod 标签 ports: - name: http port: 80 # Service 暴露的端口 targetPort: 80 # 转发到容器里的端口必须和 containerPort 对上 protocol: TCP逻辑说明selector匹配的是 Pod 标签不是 Deployment 名字写错就得到一组空 Endpoint表现为「Service 存在但访问超时」。targetPort要和容器实际监听端口一致容器里 nginx 监听 80这里就写 80。验证方法很直接kubectl get endpoints web-demo-svc如果 ENDPOINTS 是none说明 selector 没匹配上任何 Pod回去查标签。2.3 命名空间与资源隔离别把所有东西堆在 default命名空间是逻辑隔离不是网络隔离。它的实际价值在于按团队或环境划分资源、配合 ResourceQuota 限制总量、配合 RBAC 控制权限。生产上至少分dev、staging、prod三个命名空间避免误操作把测试的东西删到生产。# 创建命名空间并设置资源配额 kubectl create namespace staging kubectl apply -f - EOF apiVersion: v1 kind: ResourceQuota metadata: name: staging-quota namespace: staging spec: hard: requests.cpu: 4 # 该命名空间所有 Pod 的 requests 总和上限 requests.memory: 8Gi limits.cpu: 8 limits.memory: 16Gi pods: 20 # 最多 20 个 Pod防止测试环境无限膨胀 EOF逻辑说明ResourceQuota 约束的是命名空间内所有 Pod 的 requests/limits 总和一旦超了新 Pod 会创建失败并报exceeded quota。这是防止某个团队把整个集群资源吃光的第一道闸。参数按团队实际配额给pods数量限制能有效拦住「循环创建 Pod」这类事故。3. 从零搭一个能用的集群kubeadm 初始化与节点加入概念立住之后动手环节。生产环境有托管方案但想真正「精通」必须自己用 kubeadm 走一遍。下面以三台机器为例一台控制面两台工作节点操作系统为常见 Linux 发行版容器运行时用 containerd。所有节点都要先做基础准备再初始化控制面最后加入工作节点。3.1 节点基础准备关交换、装运行时、配内核参数这一步做不干净后面 90% 的诡异问题都从这里来。交换分区必须关否则 kubelet 行为不可预测内核要开网桥转发否则 Pod 跨节点通信会断容器运行时用 containerd配置要指向正确的 cgroup 驱动。# 1. 关闭 swap并写入 fstab 防止重启后恢复 swapoff -a sed -i /swap/s/^/#/ /etc/fstab # 2. 加载内核模块并配置网络参数 cat /etc/modules-load.d/k8s.conf EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sysctl --system # 3. 安装并配置 containerd关键是 SystemdCgroup # 安装步骤按发行版包管理器执行这里只给配置 mkdir -p /etc/containerd containerd config default /etc/containerd/config.toml sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml systemctl restart containerd systemctl enable containerd逻辑说明net.bridge.bridge-nf-call-iptables1让网桥流量走 iptableskube-proxy 的 Service 规则才能生效漏了这条会出现「Pod 能 ping 通但 Service 访问不了」。SystemdCgroup true必须和 kubelet 的 cgroup 驱动一致不一致会导致节点反复 NotReady这是血泪经验里排第一的坑。参数上ip_forward1是跨节点转发的前提任何一条漏掉都要回头补。3.2 kubeadm init控制面初始化的关键参数控制面初始化只有一条命令但参数决定集群后续能不能扩展、Pod 网段会不会和主机网段冲突。# 安装 kubeadm、kubelet、kubectl 后执行初始化 kubeadm init \ --apiserver-advertise-address192.168.10.10 \ # 控制面节点内网 IP工作节点靠它连过来 --pod-network-cidr10.244.0.0/16 \ # Pod 网段必须和主机网段、Service 网段都不重叠 --service-cidr10.96.0.0/12 \ # Service 虚拟 IP 段 --kubernetes-version1.29.0 \ # 锁定版本避免各节点版本漂移 --control-plane-endpoint192.168.10.10 # 单控制面就填本机 IP多控制面填 VIP # 初始化成功后配置 kubectl mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config逻辑说明--pod-network-cidr是最容易翻车的参数如果和公司内网网段重叠Pod 会拿到和物理机冲突的 IP表现为随机丢包、部分节点不通。选之前先ip route看一眼现有网段。--kubernetes-version建议锁死集群里控制面和 kubelet 版本差超过一个小版本就可能出兼容问题。初始化完成后kubectl get nodes会看到控制面是 NotReady这是正常的因为还没装网络插件。3.3 安装网络插件并加入工作节点网络插件负责给 Pod 分配 IP、打通跨节点通信。常见选择有 Calico、Flannel、Cilium单机实验用 Flannel 最省事生产上 Calico 的策略能力更完整。这里以 Flannel 为例。# 安装 Flannel注意它的默认网段要和 --pod-network-cidr 一致 kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml # 等待网络插件 Pod 就绪 kubectl get pods -n kube-flannel -w # 在工作节点上执行 init 输出的 join 命令 kubeadm join 192.168.10.10:6443 \ --token token \ --discovery-token-ca-cert-hash sha256:hash逻辑说明Flannel 的 ConfigMap 里Network字段必须和--pod-network-cidr完全一致不一致会导致 Pod 拿到 IP 但跨节点不通。join 命令里的 token 默认 24 小时过期过期后用kubeadm token create --print-join-command重新生成。加入后在工作节点执行systemctl status kubelet如果一直重启先看journalctl -u kubelet -n 50多数是 cgroup 驱动或运行时 socket 路径不对。4. 工作负载编排进阶滚动更新、探针与 HPA 怎么配才不翻车集群能跑只是起点真正决定线上稳定性的是工作负载的编排策略。滚动更新配错会全量重启探针配错会反复杀健康 PodHPA 配错会在流量高峰时扩不出来。这一章把这三块的参数讲透。4.1 滚动更新maxSurge 与 maxUnavailable 的取舍Deployment 默认就是滚动更新但默认参数不一定适合你的业务。maxSurge控制更新时最多超出期望副本数多少maxUnavailable控制最多有多少副本不可用。两者不能同时为 0否则更新卡死。spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 每次最多多起 1 个新 Pod maxUnavailable: 0 # 保证更新期间可用副本数不减少 minReadySeconds: 10 # Pod 就绪后等 10 秒才算可用给探针留缓冲 progressDeadlineSeconds: 600 # 10 分钟没进展就标记失败避免无限卡住逻辑说明maxUnavailable: 0适合不能降容量的服务代价是更新期间需要额外资源起新 Pod。minReadySeconds很关键Pod 的 readiness 探针通过不代表业务真的能扛流量留几秒缓冲能过滤掉「刚启动就崩」的情况。progressDeadlineSeconds是后悔药更新卡住时能及时暴露而不是一直等。4.2 存活与就绪探针liveness 和 readiness 别用同一个接口这是新手最容易埋的雷。liveness 探针失败会重启容器readiness 探针失败只是把 Pod 从 Endpoint 摘掉。如果两者用同一个接口而这个接口依赖数据库数据库一抖动所有 Pod 会被集体重启雪崩。livenessProbe: httpGet: path: /healthz # 只检查进程本身不依赖外部依赖 port: 80 initialDelaySeconds: 15 # 给应用启动留时间太短会启动即被杀 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /readyz # 检查依赖是否就绪比如数据库连接 port: 80 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 2逻辑说明/healthz只返回进程存活/readyz才检查下游依赖。initialDelaySeconds要大于应用冷启动时间Java 应用常见要 30 秒以上设 5 秒会导致容器反复重启。failureThreshold乘以periodSeconds是容忍时间readiness 可以短一点快速摘流量liveness 要长一点避免误杀。4.3 HPA 自动扩缩容指标、阈值与冷却时间HPA 根据 CPU、内存或自定义指标调整副本数。配不好会出现「扩了又缩、缩了又扩」的抖动。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-demo-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-demo minReplicas: 2 # 下限保证基本可用性 maxReplicas: 10 # 上限防止把节点资源吃光 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 平均 CPU 超过 70% 就扩 behavior: scaleDown: stabilizationWindowSeconds: 300 # 缩容前观察 5 分钟避免抖动逻辑说明averageUtilization是相对 requests 的百分比所以 Deployment 里必须设requests.cpu否则 HPA 拿不到基准。stabilizationWindowSeconds是防抖关键缩容比扩容更需要保守因为缩容后马上来流量会来不及扩。minReplicas不要设 1单副本在滚动更新和节点故障时没有冗余。5. 避坑与排查集群从 NotReady 到 Service 不通的 5 个高频问题这一章是踩坑记录每条按「现象 → 原因 → 解决」写。这些问题我在不同环境反复遇到新手照着查能省大量时间。5.1 节点 NotReadycgroup 驱动不一致现象kubectl get nodes显示工作节点 NotReadyjournalctl -u kubelet里反复出现failed to run Kubelet: misconfiguration: kubelet cgroup driver: cgroupfs is different from docker cgroup driver: systemd。原因kubelet 和容器运行时的 cgroup 驱动不一致。containerd 默认配置里SystemdCgroup false而 kubelet 默认用 systemd。解决改 containerd 配置SystemdCgroup true重启 containerd 和 kubelet。或者反过来统一成 cgroupfs但推荐 systemd因为它是主流发行版的默认。5.2 Pod 一直 Pending资源不足或污点未容忍现象Pod 状态卡在 Pendingkubectl describe pod的 Events 里写0/3 nodes are available: 3 Insufficient cpu或node(s) had taint。原因要么节点可分配资源小于 Pod 的 requests要么控制面节点有NoSchedule污点而 Pod 没配 toleration。解决先kubectl describe node看 Allocatable 和已分配量确认是不是 requests 设太大。单节点实验环境可以去掉控制面污点kubectl taint nodes node-name node-role.kubernetes.io/control-plane-。生产上不要随便去污点应该加节点。5.3 Service 访问超时Endpoint 为空现象集群内curlService 的 ClusterIP 超时kubectl get endpoints显示none。原因Service 的 selector 和 Pod 标签不匹配或者 Pod 没通过 readiness 探针被排除在 Endpoint 之外。解决kubectl get pods --show-labels对比 Service 的 selector标签对不上就改。如果标签对但 Endpoint 还是空检查 readiness 探针kubectl describe pod看探针是否失败。5.4 镜像拉取失败ImagePullBackOff现象Pod 状态ImagePullBackOffEvents 里写failed to pull image或no such host。原因镜像名写错、私有仓库没配 imagePullSecrets、节点 DNS 解析不了仓库地址。解决先在节点上手动crictl pull image验证网络和镜像是否存在。私有仓库要创建 Secret 并在 Pod 的imagePullSecrets里引用。DNS 问题查节点的/etc/resolv.conf和 CoreDNS 是否正常。5.5 Pod 被 OOMKilledlimits 设太小或内存泄漏现象Pod 反复重启kubectl describe pod显示Last State: Terminated, Reason: OOMKilled。原因容器内存超过limits.memory被内核杀掉。可能是 limits 设太小也可能是应用内存泄漏。解决先看kubectl top pod的实际内存曲线如果稳定接近 limits调大 limits。如果持续增长不回落是应用问题加内存只是拖延。注意 requests 和 limits 差距不要太大否则节点会超卖。6. 把集群用稳的几个进阶习惯从能跑到跑得久集群搭起来、业务跑通之后真正拉开差距的是日常运维习惯。这里说几个我踩过坑之后固定下来的做法。第一所有 YAML 进版本控制用 GitOps 的方式管理。手动kubectl edit改的东西下次 apply 就被覆盖而且没人知道改了什么。把清单放仓库改动走合并请求集群状态和仓库状态对不上时能一眼看出来。第二给所有工作负载设 requests 和 limits哪怕估不准也要设一个初值没有 requests 的 Pod 会让调度器瞎猜节点资源分配变成玄学。第三用kubectl get events --sort-by.lastTimestamp养成看事件流的习惯很多问题在变成故障之前事件里已经有征兆。验证集群健康有一套固定动作我一般按这个顺序走检查项命令期望结果节点状态kubectl get nodes全部 Ready系统组件kubectl get pods -n kube-system全部 Running核心插件kubectl get pods -n kube-flannel全部 Running资源水位kubectl top nodesCPU/内存不超过 80%异常事件kubectl get events -A --field-selector typeWarning无持续新增再补一个具体技巧给关键 Deployment 配 PodDisruptionBudget防止节点维护时把副本一次性驱逐光。apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: web-demo-pdb spec: minAvailable: 2 # 任何时刻至少保留 2 个可用副本 selector: matchLabels: app: web-demo逻辑说明PDB 约束的是自愿驱逐比如节点排空维护不约束节点宕机这类非自愿中断。minAvailable要小于replicas等于的话节点永远排不空。这个对象平时不起眼真到集群升级、节点换硬件的时候它就是防止服务中断的那道保险。我自己最大的教训是早期觉得集群搭起来就完事YAML 随手改、资源不设限、探针随便填结果一次数据库抖动把所有 Pod 的 liveness 探针打挂服务整体重启了十几分钟。后来固定下来的习惯就是——liveness 只查进程、readiness 才查依赖所有清单进仓库改任何参数前先想清楚失败时会怎样。这套习惯比记住多少条命令都值钱。希望帮到你。本文还有配套的精品资源点击获取

容器集群 k8s 从入门到精通：从零搭建可用集群与避坑指南

相关推荐

PyInstaller 打包 Python 程序：Windows 下从参数到避坑的完整指南

OPNET 802.11 MAC源码解析：从进程模型到DCF退避与RTS门限调优

Python爬虫实战：宁波天气数据采集与存储全流程

更多资讯

Muse Gadgets：面向物理Agent的轻量级AI硬件设计与落地实践

51单片机流水灯实战：IO控制、延时精度与硬件驱动详解

EMC标准分类全解析：通用标准与产品族标准选用指南

八数码难题搜索算法进化：从BFS到双向BFS与A*启发式搜索

用Python圆周率计算进行CPU压力测试：多进程实现与监控

Qt QPainter绘图全面解析：从Basic Drawing示例到实战技巧

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？