2. 对比题#

考察对两个相似概念的区分能力，每题含对比表格 + 关键差异说明 + 适用场景推荐。

题目 1：Pod vs Container#

问题： Pod 和 Container 在 K8s 中分别处于什么层次？两者的关系是什么？

参考答案：

关键差异： Pod 提供了比容器更高层级的抽象——Pod 内多容器共享网络和存储，适合需要紧密协作的容器组（如主容器 + sidecar）。K8s 以 Pod 而非容器为调度单元，解决了容器组需要共同调度、共享资源的场景。Pod 也是探针（Probe）、资源限制（QoS）、调度约束的应用层。

适用场景推荐： 单容器场景依然需要 Pod 包裹（K8s 不能直接调度裸容器）；多容器协作场景（日志 sidecar、Service Mesh sidecar、Init Container）是 Pod 设计的核心价值。

题目 2：Deployment vs StatefulSet#

问题： Deployment 和 StatefulSet 的核心区别是什么？何时应该选择 StatefulSet？

参考答案：

关键差异： StatefulSet 保证了 Pod 的"稳定性"——即使 Pod 被重新调度到其他节点，其名称、存储（重新绑定同一 PVC）和 DNS 名称不变。Deployment 的 Pod 是完全等价的，任意替换不影响服务。

适用场景推荐： 需要固定网络身份的服务（Kafka broker 需要持久化的 Broker ID 和地址）、需要独占存储的数据库（MySQL 主从、MongoDB 副本集）、需要有序扩缩容的集群（Etcd 集群）应使用 StatefulSet。普通无状态 API/Web 服务使用 Deployment。

题目 3：ClusterIP vs NodePort vs LoadBalancer#

问题： 三种 Service 类型的区别、访问方式及生产选型建议。

参考答案：

关键差异： NodePort 是 LoadBalancer 的基础（LoadBalancer 内部包含 NodePort 机制）。三者存在包含/递进关系。

适用场景推荐：

• ClusterIP：集群内微服务间通信（主要场景，占 90% 以上）
• NodePort：快速测试外部访问（生产不推荐，端口管理混乱、安全性差）
• LoadBalancer：生产环境对外暴露服务（配合云厂商 NLB/ALB，支持 TLS 终止、健康检查）
• 对外暴露标准做法：Ingress（单入口多服务路由）或 LoadBalancer + ExternalDNS

Service 的职责与四种类型（含 ExternalName、Headless）见概念篇 题2；"为何要有 ClusterIP 这层间接、而非直连 Pod"见设计理念篇 题4。本题聚焦三种类型的横向对比。

题目 4：Ingress vs Service#

问题： Ingress 和 Service 有什么区别？何时用 Ingress 替代直接暴露 Service？

参考答案：

关键差异： Service 是 L4 流量入口，只做端口转发不做内容检查。Ingress 是 L7 入口，根据 HTTP 请求的 Host 头和 URL Path 路由到不同 Service，还能提供 TLS 终止、重写、限流等高级中间件能力。

适用场景推荐：

• Service：集群内部微服务间通信、非 HTTP 协议（gRPC、TCP 代理）
• Ingress：对外暴露 HTTP 应用、需要 SSL/TLS 终止、需要基于路径/域名的多服务路由
• 两者配合使用：外部流量 → Ingress Controller → Service → Pod

题目 5：ConfigMap vs Secret#

问题： ConfigMap 和 Secret 的区别是什么？为什么不能把敏感数据放在 ConfigMap 中？

参考答案：

关键差异：

1. Secret 以 Volume 挂载时通过 tmpfs 存储在内存中，不落磁盘
2. Secret 应配合 etcd 加密、RBAC 严格管控、外部密钥管理（Vault/ESO）使用
3. ConfigMap 可直接入 Git 做版本管理，Secret 必须加密后才能入 Git

适用场景推荐：

• ConfigMap：应用配置（端口、日志级别、Feature Flag）、启动参数、Nginx/Apache 配置
• Secret：数据库密码、API Key、TLS 私钥、镜像仓库认证凭据、OAuth Client Secret

题目 6：PV vs PVC#

问题： PV 和 PVC 各自的职责是什么？为什么需要分成两个对象？

参考答案：

为什么分两层： K8s 将"存储供应"和"存储消费"解耦，遵循关注点分离原则。集群管理员负责定义可用的存储资源（PV/StorageClass），开发者只需声明存储需求（PVC）而无需关心底层存储的实现细节。这种模式使得开发者不需要知道 NFS 服务器地址、云磁盘 ID 等底层信息。

适用场景推荐： 理解这个分层模型后，PVC Pending 的排查思路就是：先看 StorageClass 是否存在和正确 → provisioner 是否健康 → 底层存储系统是否可用。

题目 7：emptyDir vs hostPath vs PVC#

问题： 三种存储卷类型的区别及各自适用场景。

参考答案：

适用场景推荐：

• emptyDir：临时缓存、同 Pod 内容器间共享数据、medium: Memory 用做高性能临时存储（如 AI 推理的临时张量缓存）
• hostPath：Log agent 读宿主机日志、监控 agent 访问宿主机指标（Docker socket/proc 文件系统）；生产环境慎用，Pod 需绑定到特定节点
• PVC：数据库数据文件、用户上传文件、模型文件等需要持久化的数据

题目 8：Liveness Probe vs Readiness Probe vs Startup Probe#

问题： 三种探针的功能区别、失败后果及配置要点。

参考答案：

关键差异：

• Startup Probe 解决了"慢启动应用被 Liveness 误杀"的问题。没有 Startup Probe 时只能用很长的 initialDelaySeconds，但每次重启后都要等这么久。
• Readiness 失败不会重启 Pod，只是停止向该 Pod 转发流量。这允许 Pod 在出现问题（如下游依赖不可用）时自我隔离。
• Liveness 不要检查数据库或 Redis 等外部依赖——如果外部系统故障，Liveness 失败会导致所有 Pod 被不断重启，引发雪崩。

适用场景推荐：

• 慢启动应用（JVM/Go 大依赖初始化）：三者都配
• 快速启动应用：只配 Readiness + Liveness，initialDelaySeconds 5-10s
• 批处理/Worker：可能只配 Liveness

题目 9：RWO vs RWX vs ROX#

问题： 三种存储访问模式的含义及其对 Pod 调度的影响。

参考答案：

关键差异：

• RWO 是最常见的模式（块存储类），如果 Deployment 有多个副本且分布在多个 Node 上，每个 Pod 需要各自的 PV/PVC
• ROX 适合需要多 Pod 共享只读数据的场景（如静态资源、配置文件）
• RWX 架构最灵活但存储系统要求高（需要支持并发写入的文件系统），成本通常高于 RWO

适用场景推荐：

• RWO：数据库数据卷、普通应用持久化
• ROX：静态资源 CDN 缓存层、共享配置目录
• RWX：多个 Pod 需要同时写同一文件系统的场景（如共享上传目录）

题目 10：Role vs ClusterRole#

问题： Role 和 ClusterRole 的区别是什么？什么场景下必须使用 ClusterRole？

参考答案：

必须使用 ClusterRole 的场景：

1. 访问集群级资源：Node、PersistentVolume、Namespace、StorageClass、CRD
2. 访问非资源 URL：/healthz、/metrics、/api/*
3. 需要在所有 Namespace 中操作资源（如日志采集器需要读所有 Namespace 的 Pod）
4. 在某个 Namespace 中通过 RoleBinding 引用 ClusterRole 来复用其规则定义（授权范围会被降级到该 Namespace）——这一"复用但降权"机制的完整说明见题目 11

适用场景推荐：

• Role：团队 A 在 team-a Namespace 内管理自己的 Deployment
• ClusterRole：集群管理员管理所有 Namespace；监控系统读取全集群 Pod 状态
• 经验法则：如果操作范围不超过单个 Namespace，优先使用 Role

题目 11：RoleBinding vs ClusterRoleBinding#

问题： RoleBinding 和 ClusterRoleBinding 的差异以及交叉使用场景。

参考答案：

交叉使用场景（重要）： RoleBinding 可以引用 ClusterRole，这是复用 ClusterRole 定义、但限制权限范围的重要手段。例如：定义 ClusterRole pod-reader（对所有 Namespace 读 Pod），在 team-a Namespace 创建 RoleBinding 引用该 ClusterRole，效果是只允许在 team-a 内读 Pod，而非所有 Namespace。

适用场景推荐：

• RoleBinding + Role：团队内权限（如只在自己 Namespace 运行）
• ClusterRoleBinding + ClusterRole：集群管理员、系统组件的全局权限
• RoleBinding + ClusterRole：复用通用权限定义但限制范围（最常用的模式）

本题是"RoleBinding 引用 ClusterRole"机制的单一出处；其"为何要分 Role/ClusterRole 两级、这层复用降权为何精妙"的设计动因见设计理念篇 题5。

题目 12：Request vs Limit#

问题： CPU/内存的 requests 和 limits 在调度、运行时和驱逐中的不同作用。

参考答案：

关键差异：

1. CPU：超过 request 不触发 throttle，超过 limit 才 throttle。很多团队选择不设 CPU limits 以避免 CFS 带宽控制导致的 P99 延迟飙升
2. Memory：超过 request 不会被立即杀死（只要节点有足够内存），超过 limit 会触发 OOM Killer。Memory 的 limits 必须设置
3. 调度：Scheduler 只看 requests，Node 上所有 Pod 的 requests 总和不能超过 Node 的 Allocatable

适用场景推荐：

• Requests：基于长期监控的 P95 用量 * 1.3
• CPU Limits：通常不设（Perf敏感服务）；批处理可设
• Memory Limits：必须设（request * 1.5~2），防止内存泄漏影响整个节点

题目 13：HPA vs VPA#

问题： HPA 和 VPA 的不同扩缩维度、适用场景及能否共存。

参考答案：

能否共存： HPA 和 VPA 不要同时用相同的资源指标（如都管理 CPU），会导致两者冲突。但可以分工——VPA 只调 memory requests/limits（controlledResources: ["memory"]），HPA 按 CPU 或 QPS 扩缩副本数。

适用场景推荐：

• HPA：应对流量波动（Web 服务、API 网关）
• VPA Off 模式：分析生产资源使用，给出 requests 建议值（最安全的用法）
• VPA + HPA：VPA 管 memory（Off/Initial 模式），HPA 管 CPU 副本扩缩
• 注意：VPA Auto 模式会重启 Pod，生产环境不推荐直接使用

题目 14：iptables vs IPVS（kube-proxy 模式）#

问题： kube-proxy 的 iptables 和 IPVS 两种转发模式在性能和规模上有何差异？

参考答案：

关键差异： 在 1000 个 Service 的场景下，iptables 模式会产生数万条规则，每个新连接的 SYN 包需要遍历这些规则直到命中，导致数毫秒到数百毫秒的延迟；更痛的是规则全量同步慢。IPVS 用哈希查找直接定位后端；nftables 则用现代内核框架从根子上解决 iptables 的 O(n) 与同步慢问题，定位是"iptables 的官方现代替代"，长期看会成为默认。（各模式的完整定义、以及 userspace 模式于 1.26 移除的来龙去脉见概念篇 题14；转发链路机制见原理篇 题2。）

适用场景推荐：

• iptables：小集群（<200 Service）、需要成熟稳定和熟悉的调试手段
• IPVS：中大型集群（200+ Service）、需要多种 LB 算法、对连接延迟敏感
• nftables：内核/发行版够新、愿意跟进新特性，想要 iptables 的兼容语义但更好的规模表现
• 终极方案：Cilium（eBPF 替代 kube-proxy），完全在内核处理，延迟可降至微秒级

题目 15：Flannel vs Calico vs Cilium（CNI）#

问题： 三种主流 CNI 插件的架构差异和选型建议。

参考答案：

适用场景推荐：

• Flannel：简单场景、学习环境、不需要 NetworkPolicy 的小集群
• Calico：混合云/私有云场景需要 BGP 对等、稳定性优先的中大型集群
• Cilium：追求性能天花板、需要 L7 NetworkPolicy 和 Hubble 可观测性、新集群
• 托管 K8s（EKS/ACK）：通常使用厂商 CNI（AWS VPC CNI/Terway），不要替换

题目 16：Helm vs Kustomize#

问题： Helm 和 Kustomize 两种配置管理工具的设计理念和使用场景差异。

参考答案：

适用场景推荐：

• Helm：安装第三方软件（Prometheus、Ingress Controller、数据库）、复杂部署需要条件判断和循环
• Kustomize：自有应用的多环境管理、需要 patch 第三方配置的场景、GitOps 友好
• 混合使用：用 Helm 安装基础设施，用 Kustomize 管理自有应用配置

题目 17：ArgoCD vs FluxCD#

问题： 两种主流 GitOps 工具的架构差异和选型建议。

参考答案：

适用场景推荐：

• ArgoCD：中小规模集群、需要 Web UI 给开发团队自助查看部署状态、强依赖 ApplicationSet + PR preview 环境
• FluxCD：大规模跨云多集群（联邦式更安全）、重度 Helm 用户（真 release、rollback）、平台工程团队嵌入 IDP

题目 18：vCluster vs Capsule vs HNC（多租户）#

问题： 三种 K8s 多租户方案的隔离模型和各自优势。

参考答案：

适用场景推荐：

• vCluster：SaaS 平台多客户强隔离、客户需要自定义 CRD、不同客户可能需要不同 K8s 版本
• Capsule：企业内部平台多个业务团队共享集群、需要集中管控镜像仓库/IngressClass/StorageClass
• HNC：开发环境 Namespace 层级管理、项目树形结构（org → team → project → branch）

题目 19：Istio vs Cilium vs Linkerd（Service Mesh）#

问题： 三种 Service Mesh 方案的架构、性能和适用场景对比。

参考答案：

适用场景推荐：

• Istio：大规模组织有专职 SRE、需要完整 L7 控制（金丝雀/WASM 扩展/多集群）、已用 Envoy 生态
• Cilium SM：已用 Cilium CNI 的团队、性能敏感（低延迟/高吞吐）、需要 CNI+SM 一体化
• Linkerd：小团队、90% 需求是 mTLS + 基础可观测、追求运维最简体验

题目 20：PSP vs PSA（Pod 安全策略演进）#

问题： PSP 为什么被废弃？PSA 如何替代它？

参考答案：

关键差异： PSP 的问题在于使用门槛极高——创建 PSP 后还需要为 ServiceAccount 绑定 USE 权限，且 PSP 是集群级别的，需要 RBAC 来控制谁可以触发 PSP。PSA 采用 Namespace 标签方式，运维体验大幅简化：kubectl label ns production pod-security.kubernetes.io/enforce=restricted。

适用场景推荐：

• PSA：标准安全需求（禁止特权容器、非 root 运行、只读根文件系统）——三档预设覆盖 90% 场景
• OPA/Kyverno：PSA 预设不够的复杂场景（如限制镜像来源、限制 Ingress Host、注入 sidecar 策略）

题目 21：Sidecar 模式 vs Ambient 模式#

问题： Service Mesh 中 Sidecar 模式和 Ambient 模式的架构差异及各自优劣。

参考答案：

补充：K8s 原生 Sidecar（1.33 GA）改善了 Sidecar 模式的老痛点。 过去 Envoy sidecar 是普通容器，存在两大顺序问题：启动时业务容器可能早于 sidecar 就绪而丢流量；关停时 sidecar 可能先于业务容器退出，导致业务最后的请求发不出去（"代理先死"问题）。原生 sidecar 把它声明为 restartPolicy: Always 的 initContainer，由 kubelet 保证它先于业务容器启动、后于业务容器终止，正是这类问题的解法。这属于 K8s 层面的能力，与选不选 Ambient 是两码事。

适用场景推荐：

• Sidecar：成熟稳定、调试方便、中小规模集群（1000 Pod 以下）
• Ambient：大规模集群降低 sidecar 内存总开销、需要对 Pod 透明（不注入 sidecar 容器）、不需要重启 Pod 即可升级 mesh

题目 22：etcd 与其他分布式 KV 存储#

问题： etcd 相比 Redis、ZooKeeper、Consul 有哪些独特的设计优势？

参考答案：

关键差异： etcd 的核心优势是 Watch 机制的持久性和高效性（基于 HTTP/2 Server-Sent Stream），K8s 所有 Controller 都依赖这个 Watch 机制来监听资源变化。ZooKeeper 的 Watch 是一次性的（触发后需重新注册），在事件密集场景下容易丢失事件。Redis 并非强一致性系统（异步复制可能导致数据丢失），不适合作为分布式协调存储。

题目 23：Docker vs containerd#

问题： K8s 中 Docker 和 containerd 的角色差异，以及 K8s 为什么移除 Docker 支持。

参考答案：

K8s 移除 Docker 支持的原因： K8s v1.24 废弃 dockershim，原因是 Docker 不符合 CRI（Container Runtime Interface）规范，需要通过 dockershim 适配层转换。维护这一适配层增加了复杂度且不是必需的——containerd 已经是 CRI 兼容的，且 Docker 内部也使用 containerd。

迁移影响： 对用户几乎透明——容器镜像标准（OCI）不变，Dockerfile 和构建流程不变。唯一的改变是节点上不再用 docker 命令排障，改用 crictl（CRI 层通用）或 nerdctl（containerd 原生、命令行仿 docker）进行调试。

厘清一句常被说错的话： 不是"K8s 不再支持 Docker 镜像"，而是"K8s 不再把 Docker Engine 当作节点运行时"。当前主流的 CRI 运行时是 containerd（kubeadm/多数云厂商默认）和 CRI-O（Red Hat OpenShift 系默认，更精简、专为 K8s 而生）；二者都用 runc/crun 作为底层 OCI runtime。Docker 本身仍可用来构建镜像。

题目 24：Overlay vs Underlay 网络#

问题： 两种跨节点网络模型的原理、性能差异和适用场景。

参考答案：

适用场景推荐：

• Overlay：跨云/跨数据中心（网络不连续）、学习/测试环境、基础设施不提供路由互通能力
• Underlay：性能敏感场景（高频交易、AI 推理延迟敏感）、同一数据中心内（网络设备支持 BGP）、私有云

题目 25：声明式 vs 命令式#

问题： 声明式 API 和命令式 API 的核心差异，以及 K8s 为什么选择声明式。

参考答案：

K8s 选择声明式的原因（概要）： 持续调谐带来自愈能力、配置可版本化（IaC/GitOps）、把"如何达成目标"的复杂性封装进控制器。这几点设计动因（另含水平触发的可靠性、幂等性）以及"若改用命令式的后果"详见设计理念篇 题2；本题聚焦声明式与命令式的逐项对比。

题目 26：Gateway API vs Ingress#

问题： Gateway API 相比 Ingress 解决了什么问题？两者的角色模型和能力差异是什么？现在该用哪个？

参考答案：

关键差异： Ingress 最大的问题是表达力不足 + 靠 annotation 打补丁——想做金丝雀、限流、复杂改写只能写厂商私有 annotation，换个 Controller 就得推倒重来。Gateway API 用面向角色的多对象模型把"平台/运维/开发"权责分层，并把高级流量能力标准化为可移植的 API 字段。

现在该用哪个：

• 存量、简单的 HTTP 七层路由，Ingress 够用可继续维护
• 新项目、需要 TCP/UDP/gRPC、需要标准化流量拆分/多租户/跨 Namespace，直接上 Gateway API
• 迁移可借助官方 ingress2gateway 工具转换存量 Ingress 配置

题目 27：HPA vs KEDA#

问题： 原生 HPA 有哪些能力边界？KEDA 补齐了什么？两者是替代还是配合关系？

参考答案：

关键差异： 原生 HPA 面向"常驻服务按利用率弹性"，两个硬伤是接第三方指标要自己搭 metrics adapter、且缩不到 0。KEDA 用大量现成 Scaler 解决了前者，用"激活层 + 自动生成 HPA"解决了后者——闲时把消费者缩到 0、有消息进来再拉起，非常适合成本敏感的异步工作负载。

替代还是配合： 是配合，不是替代。KEDA 底层就是 HPA，只是替你把"事件源 → 指标 → HPA"这条链接好了。顺带补齐三者定位：HPA 改副本数（水平）、VPA 改单 Pod 的 requests/limits（垂直）、KEDA 让 HPA 能事件驱动并缩容到 0。