ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

K8s运维面试150题:从Pod Pending到CoreDNS重启的排查实战

2026/10/2 19:43:56 拓冰建站 浏览量
K8s运维面试150题:从Pod Pending到CoreDNS重启的排查实战 简介这份资源是面向中高级运维工程师及Kubernetes运维岗位求职者的面试专题资料围绕k8s容器运维技术整理了约150道常见面试题覆盖Pod、ReplicaSet、Deployment、DaemonSet、StatefulSet、Service、Ingress、ConfigMap、Secret、ServiceAccount等核心资源类型并延伸至健康检查、认证方式、证书种类、节点组件、高可用架构、镜像下载策略、故障重启策略、PV访问模式与PV/PVC关联等高频考点适合用于系统梳理知识体系与面试前查漏补缺。资源包内含1个docx文档压缩包约723KB以问答形式组织便于按专题快速检索与背诵。目前已有288人学习内容兼顾概念辨析与实战场景能帮助读者深入理解k8s底层机制提升面试通过率为冲击高薪运维职位提供有力支撑。1. 从一道 pending 题说起这份 150 题到底值不值得刷上周帮一个朋友复盘面试他被问到「pod 一直 pending 怎么排查」答了句「资源不够吧」面试官追问还有呢就卡住了。其实这道题在这份 150 题里排在第 30 题答案列了三种原因资源不足、nodeAffinity 硬策略没匹配上、节点有污点没配容忍。三种场景对应三种完全不同的修法只答一种就是没做过。这份资源是一套 k8s 运维面试专题150 道题覆盖资源对象、健康检查、认证、组件、高可用、存储、网络、调度、监控、故障排查。它不是那种「什么是 pod」的入门科普而是从运维视角出发把每个知识点落到「怎么配、怎么查、出错看哪」。适合两类人一是准备中高级运维或 k8s 运维岗面试的二是日常运维中遇到问题想快速定位的。下面我按「资源是什么 → 怎么用 → 坑在哪」的顺序把它拆开讲透。2. 资源对象与控制器从 Pod 到 StatefulSet 的选型逻辑2.1 为什么 Pod 是最小单元而不是容器k8s 不直接管容器管的是 Pod。一个 Pod 里可以跑一个或多个容器它们共享网络命名空间和存储卷。常见做法是一个 Pod 一个容器但有些场景必须多容器比如 sidecar 做日志收集、init 容器做初始化。Pod 里的容器共享 IP互相用 localhost 通信这是它和直接跑 docker 最大的区别。面试里常问「pod 中两个容器怎么共享数据」答案是用 emptyDir。在 yaml 里定义一个 emptyDir 卷两个容器同时挂载到各自路径数据就通了。注意 emptyDir 随 Pod 生命周期存在Pod 删了数据就没了别拿它当持久化存储。2.2 RS、Deployment、DaemonSet、StatefulSet 怎么选这四个控制器是面试高频。ReplicaSet 维护副本数但更新 Pod 要手动删旧的。Deployment 是 RS 的升级版改 yaml 里的镜像版本会自动滚动更新还能回滚。DaemonSet 保证每个节点跑一个 Pod监控和日志收集常用。StatefulSet 管有状态服务比如 mysql 主从Pod 有固定名字和顺序启动。选型逻辑很简单无状态服务用 Deployment每个节点都要跑的用 DaemonSet有状态或需要固定网络标识的用 StatefulSet。RS 现在基本不单独用了都被 Deployment 管着。apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deploy spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.20 ports: - containerPort: 80这段 yaml 定义一个 3 副本的 Deployment。replicas控制副本数selector.matchLabels必须和template.metadata.labels对上否则创建报错。改image版本再 apply就会触发滚动更新旧 Pod 逐个替换服务不中断。2.3 Service 和 Ingress 的分工Service 通过 label 匹配后端 Pod做四层负载均衡。四种类型ClusterIP 只能集群内访问NodePort 对外暴露节点端口LoadBalancer 依赖云厂商ExternalName 做外部服务映射。Ingress 是七层通过域名分流需要配合 Ingress Controller 用。常见做法是内部服务用 ClusterIP对外暴露用 Ingress 加域名。Ingress Controller 本质是个 nginx但配置不是手动改的而是通过 Ingress 资源的 yaml 动态生成。面试问「Ingress 和 Ingress Controller 区别」就答Ingress 是规则Controller 是执行规则的组件。3. 健康检查、认证与组件把集群跑起来的关键配置3.1 存活检查和就绪检查别搞反livenessProbe 检测失败会重启容器readinessProbe 检测失败只是把 Pod 从 Service 后端摘掉不重启。很多人配反了导致服务还没启动完就被反复重启。正确做法livenessProbe 的initialDelaySeconds设大一点给应用启动留时间readinessProbe 可以设小一点快速摘除不健康实例。三种探针方式httpGet 看状态码 2xxtcpSocket 看端口通不通exec 看命令退出码是不是 0。httpGet 最常用exec 适合复杂检查。livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5initialDelaySeconds是容器启动后等多久开始探测periodSeconds是探测间隔。liveness 设 30 秒是给应用启动时间readiness 设 5 秒是尽快确认就绪。这两个参数配错要么服务起不来就被杀要么流量打到没准备好的 Pod 上。3.2 认证和证书体系k8s 认证方式两种x509 证书加 role/rolebinding服务账号加 role/rolebinding。证书三类etcd 集群内部通信、apiserver 到 etcd、其他组件到 apiserver。面试问「客户端访问 k8s 资源经过几关」答认证通过、授权通过、资源限制。ServiceAccount 是给 Pod 用的身份绑定 Role 或 ClusterRole 控制权限。常见坑是默认 ServiceAccount 权限太大生产环境要按最小权限原则单独建。3.3 各节点组件的作用Master 节点跑 apiserver、controller-manager、scheduler。apiserver 是集群入口所有请求都走它。controller-manager 维护集群状态scheduler 决定 Pod 调度到哪个节点。Node 节点跑 kubelet 和 kube-proxy。kubelet 负责创建管理 Podkube-proxy 实现 Service 的负载均衡。公共组件有 etcd、网络插件、CoreDNS。面试问「pod 创建流程」按这个顺序答kubectl 发请求给 apiserverapiserver 写入 etcdscheduler 监听到新 Pod 开始调度kubelet 监听到分配给自己的 Pod 调用容器运行时创建。4. 存储、网络与调度生产环境最容易翻车的三块4.1 PV 和 PVC 的绑定逻辑PV 是持久化存储卷PVC 是对存储的描述。绑定顺序Pod 关联 PVCPVC 按容量和访问模式匹配 PVPV 关联底层存储。PV 三种访问模式ReadWriteOnce 单节点读写ReadWriteMany 多节点读写ReadOnlyMany 多节点只读。常见坑是 PVC 一直 pending原因通常是 PV 容量不够或访问模式不匹配。排查用kubectl describe pvc看事件会提示找不到匹配的 PV。4.2 网络插件选型和排查flannel 提供 IP 但不能配网络策略calico 既能提供 IP 也能配策略cannel 是两者结合。性能上 calico 和 flannel 差不多。flannel 的 vxlan 模式是叠加网络host-gw 模式用宿主机当网关。Pod 网络不通排查顺序先看网络插件 Pod 是不是 Running再看日志然后检查 Pod 网段和宿主机网段有没有重合。访问 Service IP 超时先检查宿主机net.ipv4.ip_forward是不是 1。# 检查 ipv4 转发 cat /proc/sys/net/ipv4/ip_forward # 如果为 0修改配置 echo net.ipv4.ip_forward1 /etc/sysctl.conf sysctl -pip_forward为 0 时宿主机不转发数据包Pod 访问外部或 Service 就会超时。这个参数在 kubelet 启动时通常会自动设置但有些系统重启后失效需要写进 sysctl.conf 持久化。4.3 调度机制和节点选择器调度分预选和优选。预选过滤掉资源不够、标签不匹配的节点优选从剩下的里挑最合适的。三种节点选择器nodeSelector 简单匹配标签nodeAffinity 支持软硬策略nodeName 直接指定节点跳过调度器。污点和容忍配合使用节点打污点Pod 配容忍才能调度上去。常见场景是给专用节点打污点只让特定服务跑。面试问「节点 not ready 原因」答网络插件没装、资源不足、kubelet 异常用kubectl describe node看详情。5. 避坑与排查那些面试官爱追问的故障场景5.1 Pod 一直 Pending现象kubectl get pod显示 Pendingdescribe 看到「0/3 nodes are available」。原因有三种节点资源不足yaml 里 request 的内存 CPU 超过节点剩余nodeAffinity 硬策略配了标签但节点没打节点有污点但 Pod 没配容忍。解决资源不足就调小 request 或加节点亲和性不匹配就去掉硬策略或给节点打标签污点问题就加 tolerations 或删污点。5.2 Pod 处于 Running 但服务不正常现象Pod 状态 Running但访问报错或超时。原因可能是端口配错应用监听端口和 containerPort 不一致依赖服务挂了比如数据库连不上环境变量配错内存 OOM 但进程没退出处于僵死状态。解决先kubectl logs看应用日志再kubectl exec进容器curl localhost:端口测本地通不通然后检查 Service 的 targetPort 和 containerPort 对不对。5.3 CoreDNS 频繁重启现象CoreDNS Pod 反复重启集群内域名解析时好时坏。原因资源不够被 OOM kill配置有语法错误上游 DNS 不可达版本有已知 bug。解决先看kubectl logs和kubectl describe pod确认重启原因资源不够就加 memory limit配置问题就检查 Corefile版本问题就升级。5.4 节点断电恢复后 Pod 起不来现象节点断电重启后上面的 Pod 无法调度。原因节点断电后 k8s 自动打了不可调度污点恢复后污点没自动消失或者主机名变了导致连不上集群。解决kubectl describe node看有没有污点有就删掉检查主机名改回来重启 kubelet。5.5 token 过期后加不了节点现象kubeadm join报 token 过期。原因kubeadm 初始化的 token 默认 24 小时过期。解决在 master 上kubeadm token create生成新 token再用openssl命令获取 ca 证书 hash然后在新节点上用新 token 和 hash 加入。# 在 master 生成新 token kubeadm token create # 获取 hash openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2/dev/null | openssl dgst -sha256 -hex | sed s/^.* // # 在新节点加入 kubeadm join --token 新token --discovery-token-ca-cert-hash sha256:hash master-ip:6443token 是加入集群的凭证hash 用来验证 master 的 ca 证书。两个都对才能加入成功。常见错误是只换了 token 没换 hash或者 master IP 写错。6. 从面试题到生产把 150 题用成排查手册刷题不是背答案是把每道题变成排查思路。我自己的习惯是遇到故障先想这题在 150 题里对应哪道然后按答案里的排查顺序走一遍。比如 Pod 起不来先看状态是 Pending 还是 RunningPending 查调度Running 查应用。这套题里第 30 题、43 题、53 题基本覆盖了 80% 的 Pod 故障场景。再比如监控这块第 42 题把 Prometheus、alertmanager、node_exporter、grafana 的部署方式和作用讲得很清楚。生产环境按这个搭node_exporter 用 DaemonSet 跑Prometheus 用 Deploymentgrafana 配数据源指向 Prometheusalertmanager 配钉钉告警。这套组合能覆盖宿主机和容器的基本监控。最后说个验证方法拿这套题当 checklist对着自己的集群逐条过。比如第 40 题问 Service 代理模式就去查自己集群是 iptables 还是 ipvs第 47 题问网络插件就确认用的是 flannel 还是 calico。过一遍下来集群的配置和短板就清楚了。从那以后我每次面试前都会把这 150 题过一遍不是背是看每道题的排查思路能不能对上自己踩过的坑。希望帮到你。本文还有配套的精品资源点击获取