K8S 高频面试题

SunnyFan大约 21 分钟约 6410 字

K8S 高频面试题

简介

Kubernetes（简称 K8S）是当前最主流的容器编排平台，负责自动化部署、扩展和管理容器化应用。随着云原生技术的普及，K8S 已成为后端开发和运维工程师的必备技能。本文整理了 Kubernetes 面试中的高频问题，涵盖 Pod、Service、Deployment、Ingress、PVC 以及集群架构等核心知识点，帮助候选人系统性地准备 K8S 相关面试。这些问题不仅考察基础概念，更关注在真实生产环境中的运维经验和故障排查能力。

特点

覆盖 K8S 核心资源对象和集群架构
从基础概念到进阶场景逐步深入
结合生产运维经验的实用面试回答
包含网络、存储、调度等多维度知识点

Pod 相关

1. 什么是 Pod？为什么 K8S 不直接管理容器？

Pod 是 Kubernetes 中最小的可部署计算单元，一个 Pod 中包含一个或多个紧密关联的容器，它们共享网络命名空间（同一个 IP 地址和端口空间）、存储卷以及运行规约。

K8S 不直接管理容器而是引入 Pod 层的原因：

容器协作需求：某些容器需要紧密协作（如主应用容器和 Sidecar 日志收集容器、Istio 的 Envoy 代理容器），它们需要共享网络和存储。在同一个 Pod 中的容器可以通过 localhost 直接通信，共享同一个生命周期。

调度和管理统一：Pod 提供了一个统一的调度和管理单位，简化了编排逻辑。K8S 调度器以 Pod 为最小调度单位，而不是单独的容器。

生命周期管理：通过 Pod 可以管理容器的生命周期，包括 Init Container（初始化容器，在主容器启动前执行）、PostStart Hook、PreStop Hook（优雅终止）等高级特性。

存储共享：同一 Pod 中的容器可以挂载相同的 Volume，实现数据共享。例如主容器产生日志，Sidecar 容器负责收集和转发日志。

2. Pod 的生命周期和状态有哪些？

Pod 的生命周期包括以下状态：

Pending：已创建但容器尚未启动，正在调度（等待调度器分配节点）或拉取镜像。常见原因：集群资源不足、镜像拉取失败、节点选择器不匹配。

Running：Pod 已调度到节点且至少一个容器运行中。注意 Running 不代表应用已就绪（可能还在初始化中）。

Succeeded：所有容器成功执行并退出（适用于一次性任务，如批处理作业）。

Failed：至少一个容器以非零状态退出。需要查看容器日志和事件排查原因。

Unknown：无法获取 Pod 状态，通常是与节点通信失败。可能原因：节点宕机、网络分区、kubelet 异常。

Pod 中每个容器还有自己的状态：Waiting（等待某个条件，如等待容器镜像拉取、等待存储挂载）、Running（正在执行）、Terminated（已退出，包含退出码和退出原因）。

Pod 还包含 Init Container 阶段，所有初始化容器按顺序成功执行后，主容器才会启动。Init Container 常用于：等待依赖服务就绪、初始化配置文件、数据库迁移等。

3. Pod 的健康检查机制是怎样的？

Kubernetes 提供三种探针（Probe）机制来监控容器的健康状态：

Liveness Probe（存活探针）：检测容器是否在运行，如果检测失败则 kubelet 会重启容器。适用于检测死锁、无限循环等"活着但不健康"的状态。注意：不要把 Liveness 配置得太激进，否则可能导致频繁重启。

Readiness Probe（就绪探针）：检测容器是否准备好接受流量，检测失败的 Pod 会从 Service 的 Endpoints 中移除。适用于应用启动较慢、需要加载大量数据或预热缓存的场景。

Startup Probe（启动探针）：检测容器是否已启动完成，优先级高于其他探针。适用于启动时间较长的应用（如 JVM 应用），可以给应用足够的启动时间，避免被 Liveness Probe 误杀。

每种探针支持三种检测方式：

HTTP GET：发送 HTTP 请求检查状态码（200-399 为成功）
TCP Socket：尝试建立 TCP 连接，连接成功为健康
Exec：在容器内执行命令检查返回码（返回 0 为成功）

探针配置的关键参数：initialDelaySeconds（首次检测延迟）、periodSeconds（检测间隔）、timeoutSeconds（超时时间）、failureThreshold（连续失败多少次判定为不健康）、successThreshold（连续成功多少次判定为健康）。

4. Pod 的调度策略有哪些？

Kubernetes 的 Pod 调度策略包括：

nodeSelector：通过标签选择器将 Pod 调度到特定节点。例如 nodeSelector: {"disktype": "ssd"} 会将 Pod 调度到带有 disktype=ssd 标签的节点。

nodeAffinity：节点亲和性，支持硬亲和（required，必须满足）和软亲和（preferred，尽量满足）。比 nodeSelector 更灵活，支持操作符（In、NotIn、Exists、Gt、Lt 等）。

podAffinity/podAntiAffinity：Pod 亲和/反亲和，将 Pod 调度到与指定 Pod 相同或不同的拓扑域。例如将同一服务的多个副本分散到不同的可用区以提高可用性。

Taint 和 Toleration：污点和容忍机制。节点可以设置污点（Taint）排斥 Pod，Pod 可以设置容忍（Toleration）来接受特定污点。Master 节点默认有 node-role.kubernetes.io/master:NoSchedule 污点，防止普通 Pod 被调度到 Master 节点。

PriorityClass 和抢占：高优先级 Pod 可以驱逐低优先级 Pod 以获取资源。适用于关键业务场景。

Service 相关

5. Service 的作用是什么？有哪些类型？

Service 是 Kubernetes 中定义 Pod 访问方式的抽象资源，它为一组具有相同标签的 Pod 提供稳定的访问入口（ClusterIP）和负载均衡能力。

Service 通过标签选择器（selector）自动发现和关联后端 Pod，当 Pod 发生变化（扩缩容、重启）时自动更新 Endpoints，客户端无需关心后端 Pod 的变化。

Service 有四种类型：

ClusterIP（默认）：仅在集群内部可访问的虚拟 IP。适合内部微服务通信。

NodePort：在每个节点上开放一个端口（范围 30000-32767），外部可通过 节点IP:端口 访问。适合开发测试或简单的对外暴露。

LoadBalancer：在 NodePort 基础上请求云厂商创建外部负载均衡器（如 AWS ELB、阿里云 SLB）。适合云环境对外暴露服务。

ExternalName：将 Service 映射到外部 DNS 名称（如 mydb.example.com），适用于访问集群外部的服务。

6. kube-proxy 的工作模式有哪些？

kube-proxy 是运行在每个节点上的网络代理组件，负责实现 Service 的负载均衡。它有三种工作模式：

userspace 模式（早期方式）：在用户空间代理流量，请求先到 kube-proxy 进程再转发到后端 Pod，性能较差已淘汰。

iptables 模式（默认模式）：利用 iptables 规则实现 NAT 转发和负载均衡。数据包直接在内核空间转发，性能好。缺点是不支持会话保持后的实例变化感知（iptables 规则是随机选择的，不会感知后端 Pod 的负载情况）。

IPVS 模式：利用 Linux 内核 IPVS（IP Virtual Server）实现负载均衡，支持多种调度算法（轮询、最小连接、源地址哈希、最短期望延迟等），性能最优且功能最丰富。是大规模集群（节点数 > 1000）的推荐模式。

7. Headless Service 是什么？适用场景？

Headless Service 是将 clusterIP 设置为 None 的 Service，它不会分配 ClusterIP，也不会通过 kube-proxy 进行负载均衡。

DNS 查询 Headless Service 时会直接返回关联 Pod 的 IP 地址列表，而不是 Service 的虚拟 IP。

适用场景包括：StatefulSet 需要为每个 Pod 提供稳定的网络标识（如 pod-0.service.namespace.svc.cluster.local）；数据库集群（如 MySQL 主从、Redis 集群）需要客户端直接连接特定 Pod；服务发现场景下客户端需要知道所有后端实例地址以实现自定义负载均衡。

Deployment 相关

8. Deployment 的滚动更新策略是什么？

Deployment 支持两种更新策略：

RollingUpdate（默认，滚动更新）：逐步替换旧版本 Pod 为新版本 Pod，更新过程中始终保持一定数量的 Pod 可用。

通过两个参数控制更新节奏：

maxSurge（默认 25%）：更新过程中可以超出期望副本数的最大数量或比例。例如期望 10 个副本，maxSurge=25%，则更新过程中最多 12 个 Pod 运行。
maxUnavailable（默认 25%）：更新过程中允许不可用的最大数量或比例。例如期望 10 个副本，maxUnavailable=25%，则更新过程中至少保证 8 个 Pod 可用。

Recreate：先删除所有旧 Pod 再创建新 Pod。会导致短暂的服务中断，适用于不支持多版本并存的场景（如数据库 Schema 变更）。

9. 如何回滚 Deployment？

Kubernetes Deployment 默认保留历史版本（由 revisionHistoryLimit 控制，默认 10 个），支持随时回滚：

# 查看更新历史
kubectl rollout history deployment/myapp

# 查看特定版本的详细信息
kubectl rollout history deployment/myapp --revision=2

# 回滚到上一版本
kubectl rollout undo deployment/myapp

# 回滚到指定版本
kubectl rollout undo deployment/myapp --to-revision=2

# 查看回滚状态
kubectl rollout status deployment/myapp

10. Deployment 和 StatefulSet 的区别是什么？

对比项	Deployment	StatefulSet
Pod 名称	随机后缀（如 myapp-7b89f6d4-x2k9j）	有序编号（如 myapp-0, myapp-1）
调度顺序	并行创建和删除	有序创建（0->N）和逆序删除（N->0）
持久存储	Pod 重建后可能挂载不同 PVC	每个 Pod 绑定固定 PVC
网络标识	不稳定	通过 Headless Service 提供稳定 DNS
适用场景	无状态应用（Web、API）	有状态应用（数据库、消息队列）

StatefulSet 的核心价值在于为有状态应用提供稳定的网络标识和持久存储。例如 MySQL 主从集群中，mysql-0 始终是主节点，mysql-1 始终是从节点，Pod 重建后仍然绑定相同的 PVC 和网络标识。

Ingress 相关

11. Ingress 的作用是什么？

Ingress 是 Kubernetes 中管理集群外部 HTTP/HTTPS 访问的 API 对象，它提供基于域名的虚拟主机和基于 URL 路径的路由规则，将外部流量转发到集群内的 Service。

Ingress 可以配置 TLS 证书实现 HTTPS 终止、负载均衡策略以及会话亲和等功能。Ingress 本身只是规则定义，实际流量处理由 Ingress Controller 完成（如 Nginx Ingress Controller、Traefik、Kong 等）。

相当于集群的"智能网关"，将外部请求按照规则分发到不同的内部服务。例如 api.example.com 转发到 API Service，www.example.com 转发到 Web Service，api.example.com/v2 转发到 API v2 Service。

12. Ingress 和 Service 的 NodePort/LoadBalancer 有什么区别？

NodePort 在每个节点上开放一个端口（范围 30000-32767），适合临时测试或内部服务暴露。缺点是端口不固定且暴露的端口数量有限。

LoadBalancer 依赖云厂商的负载均衡服务，每个 Service 都会创建一个外部 LB，成本较高（每个 LB 都有费用）。

Ingress 提供"一个入口、多个服务"的模式，通过域名和路径路由到不同 Service，只需一个外部 IP 或 LB 即可暴露多个服务，支持 TLS 终止和七层路由，是生产环境暴露 HTTP 服务的推荐方式。

PVC 存储相关

13. PV 和 PVC 的关系是什么？

PV（PersistentVolume）是集群级别的存储资源，由管理员预先创建或通过 StorageClass 动态创建，代表一块实际的存储空间（如 NFS 卷、云盘等）。

PVC（PersistentVolumeClaim）是命名空间级别的存储声明，由用户创建，描述所需的存储大小和访问模式。

Kubernetes 通过绑定机制将 PVC 与匹配的 PV 关联。PVC 可以像使用本地存储一样使用持久存储，Pod 通过在 spec.volumes 中引用 PVC 来挂载持久化存储。PVC 的生命周期独立于 Pod，Pod 删除后 PVC 保留（除非设置了回收策略 Delete）。

14. StorageClass 的作用是什么？

StorageClass 为管理员提供了一种描述存储"类别"的方式，支持动态存储供给。

用户在 PVC 中指定 StorageClass 名称，Kubernetes 会自动调用对应的 Provisioner（如 AWS EBS CSI、NFS Provisioner 等）创建所需大小的 PV 并与 PVC 绑定。无需管理员手动预先创建 PV，大幅简化了存储管理流程。

StorageClass 定义了存储的类型（SSD/HDD）、回收策略（Retain/Delete）、绑定模式（Immediate/WaitForFirstConsumer）等参数。WaitForFirstConsumer 模式会延迟 PV 创建直到 Pod 被调度，确保 PV 在正确的节点/可用区上创建。

15. PV 的访问模式（AccessModes）有哪些？

ReadWriteOnce（RWO）：单个节点以读写模式挂载，是最常用的模式。适用于大多数块存储（AWS EBS、GCE PD、Azure Disk）。
ReadOnlyMany（ROX）：多个节点以只读模式挂载。适用于共享只读数据（如静态文件、配置文件）。
ReadWriteMany（RWX）：多个节点以读写模式挂载，需要底层存储支持分布式文件系统（如 NFS、CephFS、GlusterFS）。

注意不同存储类型支持的访问模式不同，块存储通常只支持 RWO，文件存储通常支持 RWX。

集群架构

16. Kubernetes 集群的核心组件有哪些？

Kubernetes 集群分为 Control Plane（控制平面）和 Worker Node（工作节点）两部分。

控制平面组件：

kube-apiserver：集群的统一入口，所有操作通过 REST API 经由它处理，是唯一与 etcd 通信的组件
etcd：分布式键值存储，保存集群所有状态数据（使用 Raft 共识算法保证一致性）
kube-scheduler：根据资源需求和调度策略将 Pod 分配到合适的节点
kube-controller-manager：运行各种控制器（Deployment Controller、ReplicaSet Controller、Node Controller 等），负责集群状态的收敛

工作节点组件：

kubelet：管理节点上 Pod 的生命周期，与容器运行时交互
kube-proxy：实现 Service 的网络规则（iptables/IPVS）
Container Runtime：容器运行时，如 containerd、CRI-O（Docker 已被移除）

17. etcd 在 K8S 中的作用是什么？如何保证高可用？

etcd 是 Kubernetes 集群的后端存储，保存了集群的所有状态数据，包括 Pod、Service、ConfigMap、Secret 等所有资源对象的定义和状态。etcd 的性能直接影响整个集群的响应速度。

etcd 采用 Raft 共识算法保证数据一致性。为了保证高可用，etcd 集群通常部署奇数个节点（3、5 或 7 个），能容忍 (N-1)/2 个节点故障。3 节点集群容忍 1 个故障，5 节点容忍 2 个。

生产环境建议：

etcd 集群与 Kubernetes 控制平面分开部署
使用 SSD 存储（etcd 对磁盘 I/O 延迟非常敏感）
定期备份数据（etcdctl snapshot save）
监控关键指标：WAL fsync 延迟、DB 大小、Leader 变更频率

18. K8S 中 ConfigMap 和 Secret 的区别？

ConfigMap 用于存储非敏感的配置数据（如配置文件内容、环境变量），以明文形式存储在 etcd 中。

Secret 用于存储敏感数据（如密码、Token、证书），默认以 Base64 编码存储在 etcd 中（注意 Base64 不是加密，只是编码，任何人都可以解码）。

Secret 相比 ConfigMap 有额外的安全措施：可以配置 etcd 加密存储（EncryptionConfiguration）；Secret 的数据不会写入节点磁盘（通过 tmpfs 挂载，只存在于内存中）；Secret 有更严格的 RBAC 访问控制。

生产环境建议：启用 etcd 加密存储 Secret；配合外部密钥管理系统（如 HashiCorp Vault、AWS Secrets Manager）使用；定期轮换敏感凭证。

综合进阶

19. K8S 的网络模型是怎样的？CNI 是什么？

Kubernetes 的网络模型要求：每个 Pod 拥有独立的 IP 地址；同一个 Pod 内的容器共享网络命名空间；集群内所有 Pod 在一个扁平的网络空间中可以直接通信（无需 NAT）；Node 与 Pod 之间可以直接通信（无需 NAT）。

CNI（Container Network Interface）是 Kubernetes 的网络插件接口标准，负责为 Pod 分配 IP 地址并实现网络连通。

常见的 CNI 插件包括：Calico（支持 BGP 路由和网络策略，性能好但配置复杂）、Flannel（简单易用的 Overlay 网络，适合入门）、Cilium（基于 eBPF 的高性能网络方案，支持透明加密和可观测性，是新兴趋势）。

20. 什么是 HPA 和 VPA？如何实现自动伸缩？

HPA（Horizontal Pod Autoscaler）水平 Pod 自动伸缩器，根据 CPU 使用率、内存使用率或自定义指标自动增加或减少 Pod 副本数量。需要安装 Metrics Server 或 Prometheus Adapter 来提供指标数据。

VPA（Vertical Pod Autoscaler）垂直 Pod 自动伸缩器，根据历史资源使用情况自动调整 Pod 的 CPU 和内存请求/限制。VPA 会重启 Pod 来应用新的资源设置。

Cluster Autoscaler 根据资源需求自动增减节点数量。当集群资源不足导致 Pod 处于 Pending 状态时，自动添加新节点；当节点利用率低时，自动移除空闲节点。

生产环境建议：HPA 最为常用，建议同时配置资源请求（requests）和限制（limits），HPA 基于 requests 的百分比进行扩缩容计算。注意 HPA 的扩容有冷却时间，避免频繁扩缩。

21. K8S 中如何实现滚动更新和灰度发布？

滚动更新（Rolling Update）是 Deployment 的默认更新策略，通过逐步替换旧 Pod 实现零停机更新。

灰度发布（Canary Release）是渐进式发布策略，先让少量流量到新版本，验证无误后逐步扩大：

# 方式 1：使用两个 Deployment + Service 权重
# 部署新版本 Deployment（如 myapp-v2）
kubectl apply -f myapp-v2-deployment.yaml

# 创建新版本的 Service（指向新版本 Pod）
kubectl apply -f myapp-v2-service.yaml

# 通过 Ingress 控制流量比例（Nginx Ingress）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-v2
                port:
                  number: 80

# 方式 2：使用 Argo Rollouts（更强大的灰度发布工具）
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
        - setWeight: 100

22. K8S 中如何管理敏感信息？

K8S 提供三种主要方式管理敏感信息：

Secret：存储密码、Token、证书等敏感数据，以 Base64 编码存储（非加密）。支持通过环境变量或 Volume 挂载到 Pod。

External Secrets Operator：从外部密钥管理系统（AWS Secrets Manager、HashiCorp Vault、Azure Key Vault）同步密钥到 K8S Secret。

Sealed Secrets：允许将 Secret 加密后提交到 Git 仓库，只有集群中的控制器能解密。

# 创建 Secret
kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password='MyP@ssw0rd'

# 在 Pod 中使用 Secret
# 方式 1：环境变量
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

# 方式 2：Volume 挂载
volumes:
  - name: secret-volume
    secret:
      secretName: db-secret
volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets
    readOnly: true

# 生产建议：
# 1. 启用 etcd 加密存储 Secret（EncryptionConfiguration）
# 2. 使用 RBAC 限制 Secret 访问权限
# 3. 定期轮换密钥（结合 CI/CD 自动化）
# 4. 使用 External Secrets Operator 集成专业密钥管理

23. K8S 中 Liveness Probe、Readiness Probe 和 Startup Probe 的区别？

探针	检测目标	失败后果	使用场景
Liveness	容器是否运行	重启容器	检测死锁、无限循环
Readiness	是否可以接收流量	从 Service 移除	等待应用预热、依赖初始化
Startup	是否启动完成	重启容器（优先级高于 Liveness）	启动时间长的应用

注意事项：

Liveness 不应依赖外部依赖（如数据库），否则外部故障会导致容器无限重启
Readiness 应该检查关键依赖是否可用
Startup Probe 用于 JVM 等启动慢的应用，设置较长的 failureThreshold，避免启动过程中被 Liveness 误杀

24. K8S 资源限制（Requests 和 Limits）有什么作用？

resources:
  requests:    # 调度器使用 requests 决定 Pod 调度到哪个节点
    cpu: "500m"        # 0.5 核 CPU
    memory: "256Mi"    # 256 MiB 内存
  limits:       # Pod 能使用的最大资源量
    cpu: "1000m"       # 1 核 CPU
    memory: "512Mi"    # 512 MiB 内存

CPU：可压缩资源，超过 limits 会被限流（throttle），不会终止 Pod。
Memory：不可压缩资源，超过 limits 会触发 OOMKill（容器被终止）。

最佳实践：

所有 Pod 必须设置 requests 和 limits
requests <= limits
CPU requests 和 limits 可以不等（允许超用）
Memory requests 和 limits 建议相等（避免 OOMKill）

25. K8S 中如何进行日志收集？

K8S 日志收集有三种主要方式：

方式 1：节点级日志代理（DaemonSet + Filebeat/Fluentd）

在每个节点部署一个日志收集代理（DaemonSet）
代理读取节点上所有容器的日志文件（/var/log/containers/）
发送到 Elasticsearch/Loki 等日志存储
优点：对应用无侵入，统一收集
缺点：占用节点资源

# Filebeat DaemonSet 示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  namespace: logging
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    spec:
      containers:
        - name: filebeat
          image: docker.elastic.co/beats/filebeat:8.12.0
          volumeMounts:
            - name: varlog
              mountPath: /var/log/containers
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
      volumes:
        - name: varlog
          hostPath:
            path: /var/log/containers
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers

方式 2：Sidecar 容器

每个业务 Pod 旁边运行一个日志收集容器
共享日志卷（emptyDir）
适合日志格式特殊或需要独立配置的场景
缺点：每个 Pod 都要额外运行一个容器，资源开销大

方式 3：应用直接输出日志

应用代码直接将日志发送到日志收集系统（如 Loki、Elasticsearch）
适合日志量小或日志格式标准的场景
缺点：与应用代码耦合

26. 什么是 K8S 的 ResourceQuota 和 LimitRange？

ResourceQuota：限制命名空间级别的资源总量，防止某个团队或项目占用过多资源。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"        # 该命名空间最多请求 10 核 CPU
    requests.memory: 20Gi     # 最多请求 20Gi 内存
    limits.cpu: "20"           # 最多使用 20 核 CPU
    limits.memory: 40Gi        # 最多使用 40Gi 内存
    pods: "50"                 # 最多 50 个 Pod
    services: "10"             # 最多 10 个 Service
    persistentvolumeclaims: "5" # 最多 5 个 PVC

LimitRange：限制单个 Pod 或容器的资源范围，防止设置过大或过小。

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
    - type: Container
      default:           # 默认 limits（未设置时自动填充）
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:    # 默认 requests（未设置时自动填充）
        cpu: "100m"
        memory: "128Mi"
      max:               # 最大值（不允许超过）
        cpu: "2"
        memory: "4Gi"
      min:               # 最小值（不允许低于）
        cpu: "50m"
        memory: "64Mi"

Liveness Probe 探测间隔应小于 limits 的资源耗尽时间

优点

全面覆盖 K8S 核心资源对象和集群架构知识
问题由浅入深，适合不同水平的候选人
包含对比表格，帮助理解容易混淆的概念
结合生产实践给出建议，提升面试回答质量

缺点

K8S 生态庞大，20 道题无法覆盖所有方向
缺少 Helm、Service Mesh 等周边工具的面试题
部分进阶问题需要实际集群操作经验才能深入理解
K8S 版本迭代较快，部分特性和 API 版本需关注最新变化

总结

Kubernetes 面试题涵盖了 Pod 管理、Service 网络、Deployment 部署、Ingress 网关、PVC 存储和集群架构等核心领域。掌握这些知识点是通过 K8S 面试的基础，建议在学习过程中结合实际集群操作加深理解，关注各组件之间的协作关系和数据流向，形成完整的云原生知识体系。

这组题真正考什么

面试官往往不只是考定义，而是在看你能否把基础概念放回真实场景。
这类题经常沿着基础概念、故障排查、生产实践往下追问。
高分答案通常有三层：结论、原理、项目中的真实案例。

60 秒答题模板

先用一句话给结论。
再补关键原理或底层机制。
最后说适用边界、常见坑或生产环境经验。

容易失分的点

只会背术语，不会结合实际场景举例。
回答太散，没有结构。
忽略版本差异和工程背景。

刷题建议

把答案拆成"定义、适用场景、风险点、实战例子"四段来复述。
回答时尽量补一个真实项目中的落地场景。
高频概念题建议自己再追问一层：底层原理、常见坑、性能代价。

高频追问

如果面试官继续追问底层实现，你能否解释运行机制或源码层面的关键点？
如果题目放到实际生产环境里，这个结论是否还成立？
是否存在版本差异、特殊边界条件需要主动说明？

复习重点

把每道题的关键词整理成自己的知识树，而不是只背原句。
对容易混淆的概念要做横向比较，例如机制差异、适用边界和性能代价。
复习时优先补"为什么"，其次才是"怎么用"和"记住什么术语"。

面试作答提醒

先给结论，再补原因和例子。
回答基础题时不要只说"能用"，最好补一句为什么这样选。
如果记不清细节，优先说出适用边界和排查思路。