K8s 中 Pod 的底层架构和容器组成整体架构分层先看大结构这张图分为2 大区域左侧Master Node控制平面​ —— 负责“发号施令”右侧Worker Node工作节点​ —— 负责“干活执行”二、 左侧Master Node控制平面组件控制平面的核心是“让集群按期望运行”所有指令都经过API Server。组件作用图中位置API Server​K8s 的唯一入口所有操作kubectl、控制器、调度器都找它中间矩形Controller-Manager​运行各种控制器Deployment、RS、Node 等保证“期望状态”“实际状态”左下Scheduler​调度 Pod根据资源、亲和性等选一个合适的 Worker Node右下etcd​分布式存储保存集群所有资源的状态Pod、Service、RS 等下方圆柱控制流逻辑箭头方向你用kubectl发请求 → 打到API Server​API Server → 存到etcd记录状态Controller-Manager​ 监听 API Server发现“实际状态≠期望状态” → 调谐比如重建 PodScheduler​ 监听 API Server发现新 Pod 没调度 → 选一个 Worker Node → 通知 API Server三、 右侧Worker Node工作节点组件工作节点的核心是“运行 Pod”所有容器都在这里跑。组件作用图中位置kubelet​每个 Worker Node 一个监听 API Server根据 PodSpec 拉镜像、启容器、汇报状态上方矩形kube-proxy​维护iptables/IPVS 规则实现 Service → Pod 流量转发上方矩形和 kubelet 并列pod​K8s 最小调度单位里面跑container容器红色框内docker或 containerd真正跑容器的容器运行时​红色框内pod 旁边运行流逻辑箭头方向API Server 收到 Scheduler 的调度结果 → 通知对应 Worker Node 的kubelet​kubelet​ → 调用docker​ → 拉镜像、启容器 → 形成pod里面包含 containerkube-proxy​ → 监听 API Server 的 Service 变化 → 写 iptables/IPVS 规则 → 让外部流量能访问到 Pod四、 图的“细节亮点”容易被忽略的点1. 红色框pod和docker的关系图中红色框内pod是逻辑概念K8s 的调度单位docker是实际运行环境容器运行时。一个pod里可以有多个 container比如 pause 业务容器 init 容器这些 container 都由docker启动。2. 箭头双向性API Server和etcd之间是双向箭头API Server → etcd写状态比如创建 Podetcd → API Server读状态比如查询 PodAPI Server和kubelet之间也是双向箭头API Server → kubelet下发 Pod 配置kubelet → API Server汇报容器状态Running、Failed 等3. 两个 Worker Node 的重复结构图中画了两个 Worker Node说明 K8s 是多节点集群每个节点都有kubeletkube-proxypoddocker。五、 结合“创建 Pod”的流程串联整张图我们拿“kubectl create -f pod.yaml”​ 来串一遍kubectl​ → 调用API ServerMaster 节点API Server​ → 把 Pod 对象写入etcd存状态Scheduler​ 监听 API Server → 发现新 Pod 没调度 → 选一个 Worker Node比如 Worker 1 → 通知 API ServerAPI Server​ → 通知 Worker 1 的kubelet​kubelet​ → 调用docker​ → 拉镜像、启容器 → 形成pod里面有 containerkubelet​ → 向 API Server 汇报“Pod 已 Running”kube-proxy​ → 监听 API Server如果 Pod 被 Service 关联 → 写 iptables 规则 → 让外部能访问一、Pod 内容器的类型必须掌握✅Pod 一组共享 Network / IPC / Volume 的容器集合1️⃣ pause 容器基础设施容器第一个启动作用创建Linux namespacenetwork / ipc / pid为业务容器提供共享网络栈同一个 IP / localhost共享存储卷特点不跑业务生命周期 Pod 生命周期一句话pause 容器是 Pod 的“地基”所有容器都站在它上面。2️⃣ init 容器InitContainer在业务容器之前串行执行作用初始化环境等待依赖服务就绪拉配置、改权限、预检查特点必须全部成功退出exit 0任何一个失败 → Pod 重启 / 卡住 常见场景等数据库 ready下载配置文件初始化数据库表3️⃣ 业务容器Container真正跑服务的并行启动受探针 重启策略管理✅启动顺序总结必考纯文本纯文本pause 容器 ↓ init 容器串行 ↓ 业务容器并行二、Pod 的三种类型重点区分类型是否受控制器管理是否自动重建典型场景自主式 Pod❌❌临时测试控制器 Pod✅✅99% 生产静态 Pod❌✅kubeletMaster 组件1️⃣ 自主式 Pod直接kubectl run或 YAML 创建挂了就挂了不会被重建面试坑自主式 Pod 不是“不能恢复”而是没有控制器帮你恢复2️⃣ 控制器管理的 Pod最常用Deployment / StatefulSet / DaemonSet / Job保证副本数、版本、滚动更新3️⃣ 静态 Pod由kubelet 直接管理文件路径/etc/kubernetes/manifests特点不走 apiserver不调度常用于kube-apiserverkube-controller-managerkube-scheduler面试高频静态 Pod 在kubectl get pods能看到但删不掉删了 kubelet 又拉起来三、ImagePullPolicy镜像拉取策略策略行为IfNotPresent本地有就用没有就拉Always每次都拉默认用于 latestNever只用本地不拉生产规范非 latest 镜像 →IfNotPresentlatest 镜像 →Always离线环境 →Never四、RestartPolicy容器重启策略策略说明Always只要退出就重启默认OnFailure非 0 才重启Never永不重启联系 Pod 类型Deployment → 几乎都是AlwaysJob / CronJob →OnFailure / Never五、Harbor 镜像推送bashbashdocker tag nginx:latest 192.168.110.141/ruoyi/nginx:ruoyi-vue docker login -u admin -pHarbor12345 192.168.110.141 docker push 192.168.110.141/ruoyi/nginx:ruoyi-vueK8s 使用yamlyamlimage: 192.168.110.141/ruoyi/nginx:ruoyi-vue imagePullSecrets: - name: harbor-secret六、Pod 资源限制Requests / Limitsyamlyamlresources: requests: cpu: 200m memory: 300Mi limits: cpu: 500m memory: 500Mi核心概念requests调度依据Node 是否有资源limits最大可用上限OOM 杀手依据面试必说requests 决定能不能调度limits 决定会不会被 kill七、K8s 驱逐机制Eviction1️⃣ 驱逐触发条件Node 资源不足memory.availablenodefs.availableimagefs.availablepid.available硬阈值示例yamlyamleviction-hard: memory.available 100Mi2️⃣ QoS 等级决定谁先死QoS说明Guaranteedrequests limits最后被杀Burstable有 requests / limits中间BestEffort无限制最先被杀✅驱逐优先级纯文本纯文本BestEffort → Burstable → Guaranteed八、容器健康检查三大探针1️⃣ 三种探针的区别必背探针作用失败后果startupProbe判断“是否启动完成”Pod 启动失败livenessProbe判断是否活着重启容器readinessProbe是否可接流量从 Service 摘除启动顺序纯文本纯文本startupProbe → livenessProbe readinessProbe2️⃣ 探测方式方式说明HTTPGet/health返回 200TCPSocket端口能连Exec执行命令返回 0MySQL 示例bashbashmysql -uroot -pabc123 -e show slave status\G | grep -c Yes九、一句话总结面试收尾Pod 由一个 pause 容器提供基础环境init 容器做初始化业务容器跑服务Pod 由控制器管理可实现自愈通过 requests / limits 限制资源依靠 startup / liveness / readiness 探针判断容器状态在资源不足时K8s 根据 QoS 等级进行驱逐保障集群稳定性。