简介：这份资源是面向中高级运维工程师及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 看状态码 2xx，tcpSocket 看端口通不通，exec 看命令退出码是不是 0。httpGet 最常用，exec 适合复杂检查。

livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5

initialDelaySeconds是容器启动后等多久开始探测，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 负责创建管理 Pod，kube-proxy 实现 Service 的负载均衡。公共组件有 etcd、网络插件、CoreDNS。

面试问「pod 创建流程」，按这个顺序答：kubectl 发请求给 apiserver，apiserver 写入 etcd，scheduler 监听到新 Pod 开始调度，kubelet 监听到分配给自己的 Pod 调用容器运行时创建。

4. 存储、网络与调度：生产环境最容易翻车的三块

4.1 PV 和 PVC 的绑定逻辑

PV 是持久化存储卷，PVC 是对存储的描述。绑定顺序：Pod 关联 PVC，PVC 按容量和访问模式匹配 PV，PV 关联底层存储。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_forward=1" >> /etc/sysctl.conf sysctl -p

ip_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显示 Pending，describe 看到「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>:6443

token 是加入集群的凭证，hash 用来验证 master 的 ca 证书。两个都对才能加入成功。常见错误是只换了 token 没换 hash，或者 master IP 写错。

6. 从面试题到生产：把 150 题用成排查手册

刷题不是背答案，是把每道题变成排查思路。我自己的习惯是：遇到故障先想这题在 150 题里对应哪道，然后按答案里的排查顺序走一遍。比如 Pod 起不来，先看状态是 Pending 还是 Running，Pending 查调度，Running 查应用。这套题里第 30 题、43 题、53 题基本覆盖了 80% 的 Pod 故障场景。

再比如监控这块，第 42 题把 Prometheus、alertmanager、node_exporter、grafana 的部署方式和作用讲得很清楚。生产环境按这个搭，node_exporter 用 DaemonSet 跑，Prometheus 用 Deployment，grafana 配数据源指向 Prometheus，alertmanager 配钉钉告警。这套组合能覆盖宿主机和容器的基本监控。

最后说个验证方法：拿这套题当 checklist，对着自己的集群逐条过。比如第 40 题问 Service 代理模式，就去查自己集群是 iptables 还是 ipvs；第 47 题问网络插件，就确认用的是 flannel 还是 calico。过一遍下来，集群的配置和短板就清楚了。

从那以后我每次面试前都会把这 150 题过一遍，不是背，是看每道题的排查思路能不能对上自己踩过的坑。希望帮到你。

本文还有配套的精品资源，点击获取