Kubernetes 面试题精选

生成时间：2026-06-06 21:15 | 共 10 题

1. K8s 架构：Master 节点核心组件及其协作方式

难度：⭐⭐

标准答案：

Master 节点是 K8s 控制平面的核心，包含四个关键组件：

kube-apiserver：集群的统一入口，所有操作都通过 REST API 经由它处理，负责认证、授权、准入控制。
etcd：分布式键值存储，持久化集群所有状态数据（唯一的数据源）。
kube-scheduler：负责 Pod 调度，根据资源需求、亲和性、污点容忍等策略为 Pod 选择最优 Node。
kube-controller-manager：运行各类控制器（Deployment Controller、ReplicaSet Controller、Node Controller 等），通过观察-比较-执行循环（reconcile loop）持续驱动集群状态向期望状态收敛。

协作流程：用户通过 kubectl 提交 Deployment → apiserver 验证并写入 etcd → scheduler 监听到未调度的 Pod，计算目标 Node 并更新 Pod 的 nodeName → kubelet（Node 端）监听到新 Pod 分配到本机，调用容器运行时创建容器 → controller-manager 持续比对实际与期望副本数，触发扩缩容。

延伸思考： 如果 etcd 集群脑裂会发生什么？如何设计 etcd 的高可用拓扑（Stacked etcd vs External etcd）？

2. Pod 生命周期与探针机制

难度：⭐⭐

标准答案：

Pod 生命周期阶段（phase）：Pending → Running → Succeeded / Failed / Unknown。

Pod 内容器有三个生命周期回调（PostStart、PreStop）和三类探针：

startupProbe：启动探针，成功后才进行后续探针检查。解决慢启动应用的问题，避免在初始化阶段被 livenessProbe 误杀。
livenessProbe：存活探针，检测失败则 kubelet 重启容器。用于发现死锁等不可恢复的故障。
readinessProbe：就绪探针，检测失败则从 Service Endpoints 中摘除，不再接收流量。用于表示"活着但暂不能服务"的状态。

探针类型：httpGet、tcpSocket、exec、grpc。关键参数：initialDelaySeconds、periodSeconds、failureThreshold、successThreshold。

Pod 终止流程：Pod 收到删除请求 → terminationGracePeriodSeconds（默认 30s）倒计时 → 执行 PreStop hook → 发送 SIGTERM → 等待宽限期 → 发送 SIGKILL 强制终止。

延伸思考： 如何避免 Pod 在滚动更新时丢失正在处理的请求？preStop + readinessProbe 的配合策略是什么？

3. Deployment vs StatefulSet vs DaemonSet 的选型

难度：⭐⭐⭐

标准答案：

维度	Deployment	StatefulSet	DaemonSet
适用场景	无状态应用（Web、API）	有状态应用（数据库、ZK）	每个节点运行一个副本（日志采集、监控Agent）
Pod 标识	随机名，无序	有序编号（`pod-0`、`pod-1`），稳定网络标识	每节点一个，以节点名区分
存储	共享或临时存储	每个 Pod 独立 PVC，PVC 与 Pod 编号绑定，重建后重新挂载同一 PVC	通常使用 hostPath 或 host 网络
扩缩容	随机创建/删除	有序扩（从 0→N）、逆序缩（从 N→0）	自动随 Node 增减
更新策略	RollingUpdate / Recreate	RollingUpdate（有序）/ OnDelete	RollingUpdate / OnDelete
DNS	`svc-name.namespace.svc.cluster.local`（随机 Pod）	`pod-0.svc-name.namespace.svc.cluster.local`（可寻址单 Pod）	同 Deployment

核心区别：StatefulSet 保证 身份稳定性（名称+序号）、存储稳定性（PVC 跟随 Pod 序号）、有序性（部署/终止/升级严格有序）。

延伸思考： StatefulSet 的 Pod 删除后重建，其网络标识和存储能否保证完全一致？在什么场景下可能不一致？

4. Service 类型与服务发现机制

难度：⭐⭐

标准答案：

K8s Service 类型：

ClusterIP（默认）：分配集群内部 IP，仅集群内可达。适用于内部微服务通信。
NodePort：在 ClusterIP 基础上，在每个 Node 上开放一个端口（30000-32767）。外部通过 <NodeIP>:<NodePort> 访问。
LoadBalancer：在 NodePort 基础上，调用云厂商 API 创建外部负载均衡器（AWS ELB、GCP LB 等）。云环境专用。
ExternalName：返回 CNAME 记录，将 Service 映射到外部 DNS 名（如 my.database.aws.com）。不创建 Endpoints，纯 DNS 别名。
Headless Service（clusterIP: None）：不分配 VIP，DNS 直接返回 Pod IP 列表。用于 StatefulSet 的每个 Pod 独立寻址。

服务发现方式：

DNS 发现（推荐）：CoreDNS 为每个 Service 创建 <svc>.<ns>.svc.cluster.local A 记录，Headless Service 返回 Pod IP 列表。
环境变量：每个 Pod 启动时注入同命名空间下 Service 的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT。局限：仅能发现 Pod 启动前已存在的 Service。

延伸思考： 为什么推荐 DNS 发现而非环境变量？在 Service 扩缩容时，两种方式的实时性有何差异？

5. Ingress 控制器与流量管理

难度：⭐⭐⭐

标准答案：

Ingress 是 K8s 的 API 对象，定义七层（HTTP/HTTPS）路由规则，将外部流量按域名/路径路由到集群内 Service。Ingress Controller 是实际执行路由的组件（非 K8s 内置，需单独部署）。

主流 Ingress Controller：

NGINX Ingress Controller：最广泛使用，基于 NGINX，配置通过 Annotations 和 Ingress Resource。
Traefik：自动服务发现，原生支持 Let's Encrypt。
Kong：基于 NGINX + OpenResty，插件生态丰富（认证、限流等）。
Istio Gateway：服务网格场景，集成 mTLS 和可观测性。

核心配置示例：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts: [app.example.com]
      secretName: tls-secret
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

关键能力：TLS 终结、基于域名/路径的路由、负载均衡、会话亲和、速率限制。

延伸思考： Ingress 与 Gateway API 的关系是什么？Gateway API 是否会替代 Ingress？

6. ConfigMap 与 Secret 的安全最佳实践

难度：⭐⭐

标准答案：

ConfigMap：存储非敏感配置（环境变量、配置文件），以明文存储在 etcd 中。

Secret：存储敏感数据（密码、证书、Token），Base64 编码存储在 etcd 中。注意：Base64 不是加密，仅是编码。

安全最佳实践：

启用 etcd 加密：配置 EncryptionConfiguration，使用 AES-CBC / AES-GCM 加密 etcd 中的 Secret 数据。
RBAC 最小权限：限制 Secret 的读取权限，避免普通 ServiceAccount 访问非必要的 Secret。
外部密钥管理：使用 Vault、AWS Secrets Manager、Sealed Secrets 等方案，将密钥从 etcd 中移出。
镜像拉取 Secret：imagePullSecrets 用于私有镜像仓库认证，建议绑定到 ServiceAccount 而非逐个 Pod。
不可变 ConfigMap/Secret（immutable: true）：配置后不可修改，Kubelet 不再 watch 变化，降低 API Server 负载，提升安全隔离。

挂载方式：

环境变量：更新后需重启 Pod 才能生效。
Volume 挂载：更新后 Kubelet 自动同步到 Pod（延迟约 60s + kubelet 同步周期）。

延伸思考： 如何实现 Secret 的自动轮转（Rotation）？Pod 内应用如何感知 Secret 更新？

7. PV/PVC/StorageClass 与动态供给

难度：⭐⭐⭐

标准答案：

PV（PersistentVolume）：集群级资源，表示一块存储（NFS、EBS、Ceph 等），由管理员预创建或动态供给。
PVC（PersistentVolumeClaim）：命名空间级资源，用户对存储的"申请"，声明所需容量和访问模式。
StorageClass：定义存储"类别"和动态供给参数，关联 Provisioner（如 kubernetes.io/aws-ebs）。

绑定流程：

静态供给：管理员预先创建 PV → 用户创建 PVC → 控制器按容量和访问模式匹配绑定。
动态供给：用户创建 PVC（指定 storageClassName）→ StorageClass 对应的 Provisioner 自动创建 PV 并绑定。

访问模式（AccessModes）：

ReadWriteOnce（RWO）：单 Node 读写挂载（最常用，EBS 默认）。
ReadWriteMany（RWX）：多 Node 读写挂载（NFS、CephFS）。
ReadOnlyMany（ROX）：多 Node 只读挂载。

回收策略（Reclaim Policy）：

Retain：删除 PVC 后 PV 保留，需手动清理。
Delete：删除 PVC 后自动删除 PV 和底层存储。
Recycle（已废弃）：执行 rm -rf 后重新可用。

延伸思考： PVC 扩容（Volume Expansion）的条件和流程是什么？哪些存储驱动支持在线扩容？

8. HPA/VPA 自动伸缩策略

难度：⭐⭐⭐

标准答案：

HPA（Horizontal Pod Autoscaler）：水平伸缩，调整 Pod 副本数。

工作原理：

Metrics Server 或 Prometheus Adapter 采集指标。
HPA Controller 周期性计算目标副本数：desiredReplicas = ceil[currentReplicas × (currentMetric / targetMetric)]。
扩容即时生效，缩容有 5 分钟稳定窗口（--horizontal-pod-autoscaler-downscale-stabilization）。

指标类型：

Resource：CPU/Memory 利用率（需设置 resources.requests）。
Pods：自定义 Pod 指标（如消息队列深度）。
Object / External：外部指标（如 QPS、RabbitMQ 队列长度）。

VPA（Vertical Pod Autoscaler）：垂直伸缩，调整 Pod 的资源请求/限制。

组件：

Recommender：监控历史用量，推荐 requests 值。
Updater：驱逐偏离推荐值过大的 Pod。
Admission Controller：在 Pod 创建时注入推荐值。

VPA 模式：

Auto：自动应用推荐值（重建 Pod）。
Recreate：同 Auto，但重建行为更明确。
Initial：仅在 Pod 创建时应用推荐值，运行中不驱逐。
Off：仅推荐，不执行。

⚠ VPA 与 HPA 不能同时基于 CPU/Memory 伸缩同一工作负载，会互相冲突。建议：HPA 基于 CPU，VPA 基于 Memory；或 HPA 基于自定义指标，VPA 基于 Resource。

延伸思考： Cluster Autoscaler 与 HPA/VPA 如何联动？在突发流量场景下，三者如何协同保证 SLA？

9. 调度策略：nodeSelector、亲和性与污点容忍

难度：⭐⭐⭐

标准答案：

nodeSelector：最简单的调度约束，Pod 通过 nodeSelector 匹配 Node 的标签。硬约束，不满足则 Pod 无法调度。

Node Affinity（节点亲和性）：nodeSelector 的增强版。

requiredDuringSchedulingIgnoredDuringExecution：硬约束，必须满足。
preferredDuringSchedulingIgnoredDuringExecution：软约束，优先满足，不满足也可调度。
支持运算符：In、NotIn、Exists、DoesNotExist、Gt、Lt。

Pod Affinity/Anti-Affinity（Pod 亲和/反亲和）：

Pod Affinity：将 Pod 调度到已运行特定标签 Pod 的 Node（如前端与后端同节点降低延迟）。
Pod Anti-Affinity：避免调度到已运行特定标签 Pod 的 Node（如同一 Deployment 的副本分散到不同节点，实现高可用）。
拓扑域（topologyKey）：如 kubernetes.io/hostname（节点级）、topology.kubernetes.io/zone（可用区级）。

Taint 与 Tolerations（污点与容忍）：

Taint：打在 Node 上，表示"排斥未经容忍的 Pod"。
- NoSchedule：仅影响调度，已运行 Pod 不受影响。
- PreferNoSchedule：尽量不调度，非强制。
- NoExecute：影响调度 + 驱逐已运行的不容忍 Pod。
Toleration：打在 Pod 上，表示"可以容忍特定 Taint"。

典型场景：Master 节点打 node-role.kubernetes.io/master:NoSchedule 污点，阻止普通 Pod 调度到 Master。

延伸思考： 如何实现"优先调度到 SSD 节点，SSD 满了再调度到 HDD 节点"的策略？nodeAffinity + Taint 的组合方案是什么？

10. 运维排障：kubectl 命令、日志与事件分析

难度：⭐⭐

标准答案：

排障五步法：

Step 1 — 资源状态检查

bash

kubectl get pods -A -o wide           # 查看所有命名空间 Pod 状态
kubectl describe pod <pod-name>        # 查看事件、调度信息、容器状态
kubectl get events --sort-by=.metadata.creationTimestamp   # 按时间排序查看事件

Step 2 — 容器日志分析

bash

kubectl logs <pod-name> [-c container]            # 当前日志
kubectl logs <pod-name> --previous                 # 上一次崩溃的日志（CrashLoopBackOff）
kubectl logs <pod-name> -f --tail=100              # 实时跟踪最后 100 行

Step 3 — 常见异常状态

ImagePullBackOff：镜像拉取失败 → 检查镜像名、imagePullSecrets、网络。
CrashLoopBackOff：容器启动后崩溃 → 查 --previous 日志，检查启动命令、配置、依赖。
Pending：无法调度 → describe pod 查看 Events，检查资源不足/亲和性/污点/PVC 未绑定。
OOMKilled：内存溢出 → 调大 resources.limits.memory，排查内存泄漏。
Terminating：卡在删除 → 检查 Finalizers、PreStop hook 是否阻塞。

Step 4 — 网络排障

bash

kubectl exec -it <pod> -- curl <svc-name>:<port>     # Pod 内测试 Service 连通性
kubectl run tmp --image=busybox --rm -it -- wget -qO- <url>   # 临时 Pod 测试外部连通
kubectl get endpoints <svc-name>                      # 检查 Service 是否关联到 Pod

Step 5 — 集群级诊断

bash

kubectl top nodes / kubectl top pods      # 资源使用率（需 Metrics Server）
kubectl get componentstatuses              # 组件健康状态
kubectl cluster-info dump                  # 集群诊断信息

延伸思考： 在大规模集群中，如何快速定位"某个 Service 请求延迟飙升"的根因？需要哪些可观测性组件（Prometheus + Grafana + Jaeger + Loki）配合？

🦐 阿虾出品 | Kubernetes 面试题自动生成 | 2026-06-06

Kubernetes 面试题精选 ​

1. K8s 架构：Master 节点核心组件及其协作方式 ​

2. Pod 生命周期与探针机制 ​

3. Deployment vs StatefulSet vs DaemonSet 的选型 ​

4. Service 类型与服务发现机制 ​

5. Ingress 控制器与流量管理 ​

6. ConfigMap 与 Secret 的安全最佳实践 ​

7. PV/PVC/StorageClass 与动态供给 ​

8. HPA/VPA 自动伸缩策略 ​

9. 调度策略：nodeSelector、亲和性与污点容忍 ​

10. 运维排障：kubectl 命令、日志与事件分析 ​

Kubernetes 面试题精选

1. K8s 架构：Master 节点核心组件及其协作方式

2. Pod 生命周期与探针机制

3. Deployment vs StatefulSet vs DaemonSet 的选型

4. Service 类型与服务发现机制

5. Ingress 控制器与流量管理

6. ConfigMap 与 Secret 的安全最佳实践

7. PV/PVC/StorageClass 与动态供给

8. HPA/VPA 自动伸缩策略

9. 调度策略：nodeSelector、亲和性与污点容忍

10. 运维排障：kubectl 命令、日志与事件分析