尧图网站建设 
简介这份资源是面向中高级运维工程师及Kubernetes运维岗位求职者的面试专题资料围绕k8s容器运维技术整理了约150道常见面试题帮助读者系统梳理核心概念、提升面试通过率。内容覆盖Pod、ReplicaSet、Deployment、DaemonSet、StatefulSet、Service、Ingress、ConfigMap、Secret、ServiceAccount等资源类型及区别并延伸至存活与就绪探针、X509证书与服务账号认证、etcd与apiserver证书体系、Master与Node各组件职责、高可用集群部署方式、镜像下载与Pod重启策略、PV访问模式与PVC关联顺序等高频考点。资源包为1个docx文档约723KB以问答形式组织便于按专题检索与背诵。目前已有288人学习。对于希望深入理解k8s架构、补齐知识盲区并冲刺高薪运维岗位的读者这份专题题库可作为面试前的集中复盘材料也可用于日常运维知识体系的查漏补缺。1. k8s 运维面试 150 题为什么背答案的人反而先挂面过几十个 k8s 运维岗的人我见过太多候选人把「Pod 生命周期」「Service 四种类型」背得滚瓜烂熟结果面试官一句「线上一个 Pod 一直 Pending你从哪一步开始查」就卡壳。k8s 面试题真正的分水岭不在记忆量而在你有没有一套从现象到根因的排查路径。这份 150 题的专题本质不是题库而是一张把 kubernetes 核心对象、调度链路、网络模型、存储挂载、故障排查串起来的能力地图。它适合两类人一是准备跳槽、想把零散知识缝成体系的运维工程师二是刚接手 k8s 集群、天天被 Pending、CrashLoopBackOff、Evicted 折磨的初中级同学。下面我不按题号讲而是按「面试官真正想听什么」把高频考点拆成能复现、能验证、能讲出边界的实战内容。你照着走一遍比刷三遍题库管用。2. 从 Pending 到 Running调度链路里的高频面试题怎么答面试里出现频率最高的场景题几乎都绕不开「Pod 起不来」。而 Pending 是其中最典型的一类它背后牵扯的是调度器、资源配额、污点容忍、亲和性这一整条链路。很多人只会答「资源不够」但面试官想听的是你如何一步步缩小范围。2.1 调度失败的四个检查层次一个 Pod 卡在 Pending我一般按下面顺序查从粗到细避免上来就翻 kubelet 日志。# 第一层看事件90% 的 Pending 原因直接写在 Events 里 kubectl describe pod pod-name -n namespace | tail -30 # 第二层看节点资源是否真的不够 kubectl describe nodes | grep -A5 Allocated resources # 第三层看是否有污点没容忍 kubectl get nodes -o custom-columnsNAME:.metadata.name,TAINTS:.spec.taints # 第四层看调度器日志多调度器或自定义调度器场景 kubectl logs -n kube-system -l componentkube-scheduler --tail50逻辑说明describe pod的 Events 区域会直接给出0/3 nodes are available: 3 Insufficient cpu这类信息这是最快的入口。第二层看的是节点已分配资源注意 requests 而非 limits 才影响调度。第三层污点检查常被忽略尤其是集群里有人手动打过NoSchedule。第四层只在默认调度器排查不出时才用。参数说明custom-columns是 kubectl 的通用输出技巧面试时能写出来是加分项。--tail50控制日志量生产环境调度器日志量很大别直接kubectl logs全量拉。2.2 资源 requests 与 limits 的面试陷阱面试官很爱问「requests 和 limits 有什么区别调度看哪个」标准答案是调度看 requests运行时限制看 limits。但真正拉开差距的是追问「如果 limits 设得比 requests 大很多会怎样」答案是节点会超卖。调度器只按 requests 累加假设节点 8 核三个 Pod 各 requests 2 核都能调度上去但每个 limits 设 4 核理论上峰值能到 12 核节点就会 CPU 争抢。这就是为什么生产环境我一般建议 requests 和 limits 的比值不要超过 2:1对延迟敏感的服务甚至设成相等。resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1Gi这段配置的含义是调度时按 0.5 核、512Mi 计算运行时最多用 1 核、1Gi。memory 超过 limits 会触发 OOMKilledCPU 超过 limits 只会被 throttle 不会杀进程这个区别是高频考点。2.3 污点、容忍与亲和性的组合题面试里常出这种题「如何让某个 Pod 只调度到带 GPU 的节点上」答案不是单一机制而是组合拳。常见做法是给 GPU 节点打污点Pod 配容忍再用 nodeAffinity 精确锁定。# 给 GPU 节点打污点 kubectl taint nodes gpu-node-1 dedicatedgpu:NoSchedule # 给节点打标签 kubectl label nodes gpu-node-1 hardwaregpuspec: tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: hardware operator: In values: - gpu逻辑说明污点保证别的 Pod 不会误调度上来容忍让目标 Pod 能上来nodeAffinity 再确保它只去 GPU 节点。三者缺一不可。面试时如果只答 nodeSelector会被追问「那普通 Pod 会不会也调度到 GPU 节点浪费资源」这时候污点就是答案。参数说明NoSchedule只影响新调度NoExecute还会驱逐已运行的 Pod生产环境驱逐要谨慎。requiredDuringSchedulingIgnoredDuringExecution是硬亲和不满足就不调度软亲和用preferred面试常考两者区别。3. 网络与 ServiceClusterIP、NodePort、ExternalIPs 到底怎么选网络是 k8s 面试的第二大战场尤其是 Service 类型选择和访问不通的排查。热词里出现的 externalIPs 就是一个容易被忽略但面试常问的点。3.1 四种 Service 类型的适用边界类型访问范围典型场景面试追问点ClusterIP集群内内部微服务互调默认类型DNS 解析格式NodePort集群外经节点 IP测试环境、简单暴露端口范围 30000-32767LoadBalancer云厂商 LB生产对外服务需要 cloud-controllerExternalNameDNS 别名访问外部服务不建代理只改 DNSExternalIPs 不是一种 Service 类型而是可以附加在 ClusterIP Service 上的字段让流量从指定节点 IP 的特定端口进来。它的坑在于流量不走 kube-proxy 的负载均衡逻辑那么干净且需要你自己保证那个 IP 在节点上可达。apiVersion: v1 kind: Service metadata: name: my-svc spec: type: ClusterIP externalIPs: - 192.168.1.100 ports: - port: 80 targetPort: 8080逻辑说明这个配置让 192.168.1.100:80 的流量转发到后端 Pod 的 8080。面试时如果被问「ExternalIPs 和 NodePort 区别」核心答法是NodePort 在所有节点开同一端口ExternalIPs 是你指定 IP且不占用 NodePort 端口段。参数说明port是 Service 暴露端口targetPort是容器端口nodePort不填则随机分配。这三个端口的区分是必考题。3.2 Service 访问不通的五步排查线上 Service 不通我一般按这个顺序走避免瞎猜。# 1. 确认 Endpoints 是否有后端 kubectl get endpoints svc-name -n ns # 2. 确认 Pod 的 readinessProbe 是否通过 kubectl get pods -n ns -o wide | grep app # 3. 从集群内测试 DNS 解析 kubectl run tmp --rm -it --imagebusybox -- nslookup svc-name.ns.svc.cluster.local # 4. 检查 kube-proxy 是否正常 kubectl get pods -n kube-system -l k8s-appkube-proxy # 5. 检查 NetworkPolicy 是否拦截 kubectl get networkpolicy -n ns逻辑说明Endpoints 为空是最常见原因通常是 selector 标签不匹配或 readinessProbe 失败。DNS 解析失败则查 CoreDNS。NetworkPolicy 是隐形杀手很多人忘了自己配过默认拒绝。参数说明nslookup的完整域名格式是service.namespace.svc.cluster.local面试时能完整写出来说明你真用过。3.3 Ingress 与 Service 的分工面试常问「有了 Service 为什么还要 Ingress」核心答法是Service 是四层Ingress 是七层。Service 的 NodePort 每个服务占一个端口服务多了端口管理混乱Ingress 用域名和路径做路由一个入口搞定所有 HTTP 服务。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80逻辑说明这个 Ingress 把 app.example.com/api 的流量转到 api-svc。pathType有 Prefix、Exact、ImplementationSpecific 三种Prefix 是前缀匹配最常用。参数说明Ingress 本身只是规则真正干活的是 Ingress Controller如 nginx-ingress。面试时如果只答 Ingress 不答 Controller会被认为理解不深。4. 存储、探针与 Operator中高级面试的分水岭到了中高级岗位面试官会往存储挂载、健康检查、Operator 模式这些方向深挖。这些点答得好不好直接决定你是 15k 还是 25k。4.1 PV、PVC 与 StorageClass 的绑定逻辑面试高频题「PVC 一直 Pending 是什么原因」核心是绑定三要素容量、访问模式、StorageClass 必须匹配。apiVersion: v1 kind: PersistentVolumeClaim metadata: name:>livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10逻辑说明startupProbe 成功前liveness 和 readiness 都不执行这是给慢启动应用的后悔药。没有 startupProbe 时慢启动应用容易被 liveness 误杀形成反复重启的玄学循环。参数说明initialDelaySeconds是首次探测延迟periodSeconds是探测间隔failureThreshold是失败几次判定不健康。liveness 失败会重启容器readiness 失败只是从 Endpoints 摘除这个区别是核心考点。4.3 Operator 模式面试怎么讲热词里出现 k8s 中 operator 案例这是中高级面试的加分项。Operator 本质是「CRD 自定义控制器」把运维知识编码进控制器里。面试答法先讲它解决什么问题——有状态应用如数据库的部署、扩缩、备份、故障恢复用声明式 API 表达。再讲核心组件CustomResourceDefinition 定义资源类型Controller 监听资源变化并调谐到期望状态。最后举一个具体例子比如 etcd-operator 如何自动处理节点故障时的成员重建。不要只背概念面试官会追问「Reconcile 循环是什么」「如何处理调谐失败」。答法是Reconcile 是控制器对比期望状态和实际状态并执行动作的循环失败时靠 requeue 重试要注意幂等性。5. 避坑与排查面试和线上都容易翻车的五个点这一章是我这些年踩过的血泪经验面试时能主动讲出来面试官会觉得你真干过活。5.1 Pod 反复重启但日志没报错现象Pod 状态 CrashLoopBackOff但kubectl logs看不到明显错误。原因容器主进程退出码非零但日志被缓冲没刷出来或者进程被 OOMKilled 而日志来不及写。解决先看kubectl describe pod的 Last State 和 Exit Code137 是 OOMKilled1 是应用错误。再看kubectl logs --previous拉上一次容器的日志。内存问题就调 limits应用问题就查启动脚本。5.2 节点 NotReady 但 kubelet 看着正常现象节点状态 NotReady但登上去看 kubelet 进程在跑。原因常见是容器运行时containerd/docker挂了或节点磁盘压力触发 Eviction或网络插件 Pod 异常导致节点网络不通。解决systemctl status containerd看运行时df -h看磁盘kubectl get pods -n kube-system -o wide看网络插件是否在该节点异常。磁盘压力是最常见的清理镜像和日志即可恢复。5.3 Service 能 ping 通但端口不通现象ClusterIP 能 ping 通但 telnet 端口不通。原因ping 走的是 ICMPService 的 ClusterIP 是虚拟 IP能 ping 通不代表端口转发正常。真正的问题可能是 Endpoints 为空或 kube-proxy 规则没下发。解决查 Endpoints查 kube-proxy 日志用iptables-save | grep svc-name看规则是否存在。规则缺失通常是 kube-proxy 异常或 iptables 模式配置问题。5.4 PVC 删除后 PV 一直 Terminating现象删除 PVC 后PV 卡在 Terminating 状态不释放。原因PV 的 reclaimPolicy 是 Retain或者有 Pod 还在挂载或者 finalizer 没被清理。解决确认没有 Pod 使用后手动编辑 PV 去掉 finalizers或改 reclaimPolicy 为 Delete。生产环境用 Retain 是保护数据但要有清理流程。5.5 滚动更新卡住不继续现象Deployment 滚动更新新 Pod 起不来旧 Pod 不销毁更新卡住。原因readinessProbe 一直失败或 maxUnavailable 设为 0 且新 Pod 无法就绪或资源不足新 Pod 调度不上。解决查新 Pod 的 Events 和探针配置查kubectl rollout status的输出必要时kubectl rollout undo回滚。maxSurge 和 maxUnavailable 的配置要匹配集群资源余量。6. 用一套自检脚本把 150 题变成肌肉记忆背题最大的问题是遗忘和脱节。我的做法是把高频考点写成一套集群自检脚本每次面试前跑一遍既复习又验证。下面这个脚本覆盖了调度、网络、存储、探针四大类你可以直接改成自己的版本。#!/bin/bash # k8s 集群健康自检 - 面试复习用 echo 1. 异常 Pod 扫描 kubectl get pods -A --field-selector status.phase!Running,status.phase!Succeeded echo 2. Pending Pod 及原因 for pod in $(kubectl get pods -A --field-selector status.phasePending -o jsonpath{range .items[*]}{.metadata.namespace}/{.metadata.name}{\n}{end}); do ns${pod%/*}; name${pod#*/} echo --- $pod --- kubectl describe pod $name -n $ns | grep -A3 Events: done echo 3. 节点资源与污点 kubectl describe nodes | grep -E Name:|Taints:|Allocated resources -A3 echo 4. 无 Endpoints 的 Service kubectl get svc -A -o json | python3 -c import json,sys datajson.load(sys.stdin) for svc in data[items]: nssvc[metadata][namespace]; namesvc[metadata][name] if svc[spec].get(selector): print(f{ns}/{name}) | while read svc; do ns${svc%/*}; name${svc#*/} ep$(kubectl get endpoints $name -n $ns -o jsonpath{.subsets}) [ -z $ep ] echo 无后端: $svc done echo 5. PVC 状态 kubectl get pvc -A | grep -v Bound echo 6. 最近重启的 Pod kubectl get pods -A -o json | python3 -c import json,sys datajson.load(sys.stdin) for p in data[items]: for cs in p[status].get(containerStatuses,[]): if cs[restartCount]3: print(f\{p[metadata][namespace]}/{p[metadata][name]} restarts{cs[restartCount]}\) 逻辑说明脚本按「异常 Pod → Pending 原因 → 节点资源 → Service 后端 → PVC → 重启次数」的顺序扫描正好对应面试里最常问的六类场景。每次跑完你对集群状态的敏感度会明显提升。参数说明--field-selector支持 status.phase 过滤但注意它不支持!组合多个值所以脚本里用了两次。Python 解析 JSON 是为了处理 kubectl 输出格式不固定的问题比 grep 可靠。我自己的习惯是每周跑一次这个脚本把输出和上周对比异常项就是复习重点。面试前再针对输出里的每一项口头讲一遍排查思路比刷题效率高得多。这套方法我用了三年从 15k 面到 30k靠的不是背了多少题而是每个现象都能讲出「我怎么查、为什么这么查、查不到怎么办」。希望帮到你。本文还有配套的精品资源点击获取 K8s运维面试150题：从Pending到Running的排查路径与实战解析
简介这份资源是面向中高级运维工程师及Kubernetes运维岗位求职者的面试专题资料围绕k8s容器运维技术整理了约150道常见面试题帮助读者系统梳理核心概念、提升面试通过率。内容覆盖Pod、ReplicaSet、Deployment、DaemonSet、StatefulSet、Service、Ingress、ConfigMap、Secret、ServiceAccount等资源类型及区别并延伸至存活与就绪探针、X509证书与服务账号认证、etcd与apiserver证书体系、Master与Node各组件职责、高可用集群部署方式、镜像下载与Pod重启策略、PV访问模式与PVC关联顺序等高频考点。资源包为1个docx文档约723KB以问答形式组织便于按专题检索与背诵。目前已有288人学习。对于希望深入理解k8s架构、补齐知识盲区并冲刺高薪运维岗位的读者这份专题题库可作为面试前的集中复盘材料也可用于日常运维知识体系的查漏补缺。1. k8s 运维面试 150 题为什么背答案的人反而先挂面过几十个 k8s 运维岗的人我见过太多候选人把「Pod 生命周期」「Service 四种类型」背得滚瓜烂熟结果面试官一句「线上一个 Pod 一直 Pending你从哪一步开始查」就卡壳。k8s 面试题真正的分水岭不在记忆量而在你有没有一套从现象到根因的排查路径。这份 150 题的专题本质不是题库而是一张把 kubernetes 核心对象、调度链路、网络模型、存储挂载、故障排查串起来的能力地图。它适合两类人一是准备跳槽、想把零散知识缝成体系的运维工程师二是刚接手 k8s 集群、天天被 Pending、CrashLoopBackOff、Evicted 折磨的初中级同学。下面我不按题号讲而是按「面试官真正想听什么」把高频考点拆成能复现、能验证、能讲出边界的实战内容。你照着走一遍比刷三遍题库管用。2. 从 Pending 到 Running调度链路里的高频面试题怎么答面试里出现频率最高的场景题几乎都绕不开「Pod 起不来」。而 Pending 是其中最典型的一类它背后牵扯的是调度器、资源配额、污点容忍、亲和性这一整条链路。很多人只会答「资源不够」但面试官想听的是你如何一步步缩小范围。2.1 调度失败的四个检查层次一个 Pod 卡在 Pending我一般按下面顺序查从粗到细避免上来就翻 kubelet 日志。# 第一层看事件90% 的 Pending 原因直接写在 Events 里 kubectl describe pod pod-name -n namespace | tail -30 # 第二层看节点资源是否真的不够 kubectl describe nodes | grep -A5 Allocated resources # 第三层看是否有污点没容忍 kubectl get nodes -o custom-columnsNAME:.metadata.name,TAINTS:.spec.taints # 第四层看调度器日志多调度器或自定义调度器场景 kubectl logs -n kube-system -l componentkube-scheduler --tail50逻辑说明describe pod的 Events 区域会直接给出0/3 nodes are available: 3 Insufficient cpu这类信息这是最快的入口。第二层看的是节点已分配资源注意 requests 而非 limits 才影响调度。第三层污点检查常被忽略尤其是集群里有人手动打过NoSchedule。第四层只在默认调度器排查不出时才用。参数说明custom-columns是 kubectl 的通用输出技巧面试时能写出来是加分项。--tail50控制日志量生产环境调度器日志量很大别直接kubectl logs全量拉。2.2 资源 requests 与 limits 的面试陷阱面试官很爱问「requests 和 limits 有什么区别调度看哪个」标准答案是调度看 requests运行时限制看 limits。但真正拉开差距的是追问「如果 limits 设得比 requests 大很多会怎样」答案是节点会超卖。调度器只按 requests 累加假设节点 8 核三个 Pod 各 requests 2 核都能调度上去但每个 limits 设 4 核理论上峰值能到 12 核节点就会 CPU 争抢。这就是为什么生产环境我一般建议 requests 和 limits 的比值不要超过 2:1对延迟敏感的服务甚至设成相等。resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1Gi这段配置的含义是调度时按 0.5 核、512Mi 计算运行时最多用 1 核、1Gi。memory 超过 limits 会触发 OOMKilledCPU 超过 limits 只会被 throttle 不会杀进程这个区别是高频考点。2.3 污点、容忍与亲和性的组合题面试里常出这种题「如何让某个 Pod 只调度到带 GPU 的节点上」答案不是单一机制而是组合拳。常见做法是给 GPU 节点打污点Pod 配容忍再用 nodeAffinity 精确锁定。# 给 GPU 节点打污点 kubectl taint nodes gpu-node-1 dedicatedgpu:NoSchedule # 给节点打标签 kubectl label nodes gpu-node-1 hardwaregpuspec: tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: hardware operator: In values: - gpu逻辑说明污点保证别的 Pod 不会误调度上来容忍让目标 Pod 能上来nodeAffinity 再确保它只去 GPU 节点。三者缺一不可。面试时如果只答 nodeSelector会被追问「那普通 Pod 会不会也调度到 GPU 节点浪费资源」这时候污点就是答案。参数说明NoSchedule只影响新调度NoExecute还会驱逐已运行的 Pod生产环境驱逐要谨慎。requiredDuringSchedulingIgnoredDuringExecution是硬亲和不满足就不调度软亲和用preferred面试常考两者区别。3. 网络与 ServiceClusterIP、NodePort、ExternalIPs 到底怎么选网络是 k8s 面试的第二大战场尤其是 Service 类型选择和访问不通的排查。热词里出现的 externalIPs 就是一个容易被忽略但面试常问的点。3.1 四种 Service 类型的适用边界类型访问范围典型场景面试追问点ClusterIP集群内内部微服务互调默认类型DNS 解析格式NodePort集群外经节点 IP测试环境、简单暴露端口范围 30000-32767LoadBalancer云厂商 LB生产对外服务需要 cloud-controllerExternalNameDNS 别名访问外部服务不建代理只改 DNSExternalIPs 不是一种 Service 类型而是可以附加在 ClusterIP Service 上的字段让流量从指定节点 IP 的特定端口进来。它的坑在于流量不走 kube-proxy 的负载均衡逻辑那么干净且需要你自己保证那个 IP 在节点上可达。apiVersion: v1 kind: Service metadata: name: my-svc spec: type: ClusterIP externalIPs: - 192.168.1.100 ports: - port: 80 targetPort: 8080逻辑说明这个配置让 192.168.1.100:80 的流量转发到后端 Pod 的 8080。面试时如果被问「ExternalIPs 和 NodePort 区别」核心答法是NodePort 在所有节点开同一端口ExternalIPs 是你指定 IP且不占用 NodePort 端口段。参数说明port是 Service 暴露端口targetPort是容器端口nodePort不填则随机分配。这三个端口的区分是必考题。3.2 Service 访问不通的五步排查线上 Service 不通我一般按这个顺序走避免瞎猜。# 1. 确认 Endpoints 是否有后端 kubectl get endpoints svc-name -n ns # 2. 确认 Pod 的 readinessProbe 是否通过 kubectl get pods -n ns -o wide | grep app # 3. 从集群内测试 DNS 解析 kubectl run tmp --rm -it --imagebusybox -- nslookup svc-name.ns.svc.cluster.local # 4. 检查 kube-proxy 是否正常 kubectl get pods -n kube-system -l k8s-appkube-proxy # 5. 检查 NetworkPolicy 是否拦截 kubectl get networkpolicy -n ns逻辑说明Endpoints 为空是最常见原因通常是 selector 标签不匹配或 readinessProbe 失败。DNS 解析失败则查 CoreDNS。NetworkPolicy 是隐形杀手很多人忘了自己配过默认拒绝。参数说明nslookup的完整域名格式是service.namespace.svc.cluster.local面试时能完整写出来说明你真用过。3.3 Ingress 与 Service 的分工面试常问「有了 Service 为什么还要 Ingress」核心答法是Service 是四层Ingress 是七层。Service 的 NodePort 每个服务占一个端口服务多了端口管理混乱Ingress 用域名和路径做路由一个入口搞定所有 HTTP 服务。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80逻辑说明这个 Ingress 把 app.example.com/api 的流量转到 api-svc。pathType有 Prefix、Exact、ImplementationSpecific 三种Prefix 是前缀匹配最常用。参数说明Ingress 本身只是规则真正干活的是 Ingress Controller如 nginx-ingress。面试时如果只答 Ingress 不答 Controller会被认为理解不深。4. 存储、探针与 Operator中高级面试的分水岭到了中高级岗位面试官会往存储挂载、健康检查、Operator 模式这些方向深挖。这些点答得好不好直接决定你是 15k 还是 25k。4.1 PV、PVC 与 StorageClass 的绑定逻辑面试高频题「PVC 一直 Pending 是什么原因」核心是绑定三要素容量、访问模式、StorageClass 必须匹配。apiVersion: v1 kind: PersistentVolumeClaim metadata: name:>livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10逻辑说明startupProbe 成功前liveness 和 readiness 都不执行这是给慢启动应用的后悔药。没有 startupProbe 时慢启动应用容易被 liveness 误杀形成反复重启的玄学循环。参数说明initialDelaySeconds是首次探测延迟periodSeconds是探测间隔failureThreshold是失败几次判定不健康。liveness 失败会重启容器readiness 失败只是从 Endpoints 摘除这个区别是核心考点。4.3 Operator 模式面试怎么讲热词里出现 k8s 中 operator 案例这是中高级面试的加分项。Operator 本质是「CRD 自定义控制器」把运维知识编码进控制器里。面试答法先讲它解决什么问题——有状态应用如数据库的部署、扩缩、备份、故障恢复用声明式 API 表达。再讲核心组件CustomResourceDefinition 定义资源类型Controller 监听资源变化并调谐到期望状态。最后举一个具体例子比如 etcd-operator 如何自动处理节点故障时的成员重建。不要只背概念面试官会追问「Reconcile 循环是什么」「如何处理调谐失败」。答法是Reconcile 是控制器对比期望状态和实际状态并执行动作的循环失败时靠 requeue 重试要注意幂等性。5. 避坑与排查面试和线上都容易翻车的五个点这一章是我这些年踩过的血泪经验面试时能主动讲出来面试官会觉得你真干过活。5.1 Pod 反复重启但日志没报错现象Pod 状态 CrashLoopBackOff但kubectl logs看不到明显错误。原因容器主进程退出码非零但日志被缓冲没刷出来或者进程被 OOMKilled 而日志来不及写。解决先看kubectl describe pod的 Last State 和 Exit Code137 是 OOMKilled1 是应用错误。再看kubectl logs --previous拉上一次容器的日志。内存问题就调 limits应用问题就查启动脚本。5.2 节点 NotReady 但 kubelet 看着正常现象节点状态 NotReady但登上去看 kubelet 进程在跑。原因常见是容器运行时containerd/docker挂了或节点磁盘压力触发 Eviction或网络插件 Pod 异常导致节点网络不通。解决systemctl status containerd看运行时df -h看磁盘kubectl get pods -n kube-system -o wide看网络插件是否在该节点异常。磁盘压力是最常见的清理镜像和日志即可恢复。5.3 Service 能 ping 通但端口不通现象ClusterIP 能 ping 通但 telnet 端口不通。原因ping 走的是 ICMPService 的 ClusterIP 是虚拟 IP能 ping 通不代表端口转发正常。真正的问题可能是 Endpoints 为空或 kube-proxy 规则没下发。解决查 Endpoints查 kube-proxy 日志用iptables-save | grep svc-name看规则是否存在。规则缺失通常是 kube-proxy 异常或 iptables 模式配置问题。5.4 PVC 删除后 PV 一直 Terminating现象删除 PVC 后PV 卡在 Terminating 状态不释放。原因PV 的 reclaimPolicy 是 Retain或者有 Pod 还在挂载或者 finalizer 没被清理。解决确认没有 Pod 使用后手动编辑 PV 去掉 finalizers或改 reclaimPolicy 为 Delete。生产环境用 Retain 是保护数据但要有清理流程。5.5 滚动更新卡住不继续现象Deployment 滚动更新新 Pod 起不来旧 Pod 不销毁更新卡住。原因readinessProbe 一直失败或 maxUnavailable 设为 0 且新 Pod 无法就绪或资源不足新 Pod 调度不上。解决查新 Pod 的 Events 和探针配置查kubectl rollout status的输出必要时kubectl rollout undo回滚。maxSurge 和 maxUnavailable 的配置要匹配集群资源余量。6. 用一套自检脚本把 150 题变成肌肉记忆背题最大的问题是遗忘和脱节。我的做法是把高频考点写成一套集群自检脚本每次面试前跑一遍既复习又验证。下面这个脚本覆盖了调度、网络、存储、探针四大类你可以直接改成自己的版本。#!/bin/bash # k8s 集群健康自检 - 面试复习用 echo 1. 异常 Pod 扫描 kubectl get pods -A --field-selector status.phase!Running,status.phase!Succeeded echo 2. Pending Pod 及原因 for pod in $(kubectl get pods -A --field-selector status.phasePending -o jsonpath{range .items[*]}{.metadata.namespace}/{.metadata.name}{\n}{end}); do ns${pod%/*}; name${pod#*/} echo --- $pod --- kubectl describe pod $name -n $ns | grep -A3 Events: done echo 3. 节点资源与污点 kubectl describe nodes | grep -E Name:|Taints:|Allocated resources -A3 echo 4. 无 Endpoints 的 Service kubectl get svc -A -o json | python3 -c import json,sys datajson.load(sys.stdin) for svc in data[items]: nssvc[metadata][namespace]; namesvc[metadata][name] if svc[spec].get(selector): print(f{ns}/{name}) | while read svc; do ns${svc%/*}; name${svc#*/} ep$(kubectl get endpoints $name -n $ns -o jsonpath{.subsets}) [ -z $ep ] echo 无后端: $svc done echo 5. PVC 状态 kubectl get pvc -A | grep -v Bound echo 6. 最近重启的 Pod kubectl get pods -A -o json | python3 -c import json,sys datajson.load(sys.stdin) for p in data[items]: for cs in p[status].get(containerStatuses,[]): if cs[restartCount]3: print(f\{p[metadata][namespace]}/{p[metadata][name]} restarts{cs[restartCount]}\) 逻辑说明脚本按「异常 Pod → Pending 原因 → 节点资源 → Service 后端 → PVC → 重启次数」的顺序扫描正好对应面试里最常问的六类场景。每次跑完你对集群状态的敏感度会明显提升。参数说明--field-selector支持 status.phase 过滤但注意它不支持!组合多个值所以脚本里用了两次。Python 解析 JSON 是为了处理 kubectl 输出格式不固定的问题比 grep 可靠。我自己的习惯是每周跑一次这个脚本把输出和上周对比异常项就是复习重点。面试前再针对输出里的每一项口头讲一遍排查思路比刷题效率高得多。这套方法我用了三年从 15k 面到 30k靠的不是背了多少题而是每个现象都能讲出「我怎么查、为什么这么查、查不到怎么办」。希望帮到你。本文还有配套的精品资源点击获取