Kubernetes 面试题
本页只放 Kubernetes 面试标准回答、项目话术、常见追问和知识点跳转。API Server、etcd、Controller、Scheduler、Pod、Deployment、Service、Ingress、探针和可观测性原理放在知识点页。
使用方式
mermaid
flowchart TD
A["面试页：回答对象和链路"] --> B["知识点页：理解控制面原理"]
B --> C["项目页：部署、发布、扩缩容、排障"]高频问题
| 面试题 | 标准回答 | 原理知识点 |
|---|---|---|
| Kubernetes 是什么 | K8s 是容器编排平台，用来管理容器化应用的部署、扩缩容、服务发现、滚动更新、故障恢复和配置密钥等能力。 | 架构原理 |
| 有 Docker 为什么还需要 K8s | Docker 解决单个容器打包和运行；K8s 解决多服务、多副本、多节点环境下的编排、调度、自愈、服务发现和发布治理。 | 架构原理 |
| 什么是声明式部署 | 声明式部署是告诉系统期望状态，例如副本数、镜像、端口和配置。K8s 控制器会持续对比实际状态和期望状态，并把实际状态调整过去。 | 架构原理、工作负载 |
| Pod 是什么 | Pod 是 K8s 最小调度单位，一个 Pod 可以包含一个或多个共享网络、存储和生命周期的容器。多数业务场景是一个 Pod 一个主容器。 | 工作负载 |
| 为什么 Pod 是最小调度单位 | 因为有些容器需要共享网络、Volume 和生命周期，例如业务容器加 sidecar。K8s 把它们作为一个整体调度更合理。 | 工作负载 |
| Deployment 做什么 | Deployment管理发布策略和ReplicaSet；每个ReplicaSet对应一个Pod Template版本并维持该版本副本。模板改变时Deployment创建新ReplicaSet并扩新缩旧，不会原地修改旧Pod。 | Deployment控制器链 |
| Service 做什么 | Service提供稳定DNS、ClusterIP和端口映射；EndpointSlice Controller根据Selector维护Pod IP、目标端口和Ready条件，节点iptables/IPVS/eBPF等数据面再把新连接转发到后端。Service不保存固定Pod IP，也不直接判断业务数据库是否健康。 | Service与EndpointSlice全过程 |
| Ingress 做什么 | Ingress只是声明Host、Path、TLS和Backend的API对象，本身不监听或转发；匹配IngressClass的Controller观察Ingress、Service、EndpointSlice和Secret，生成代理或云LB配置，Controller数据面才真正处理请求。 | Ingress与Controller |
| Service 和 Ingress 区别 | Service主要提供四层稳定地址、服务发现和Pod后端转发；Ingress是七层HTTP/HTTPS路由声明，需要Ingress Controller按Host、Path和TLS配置真实代理。外部请求常先到Ingress Controller，再由它访问Service/Endpoint。 | Service数据面、Ingress |
| ClusterIP为什么没有进程监听也能访问 | ClusterIP通常是Service CIDR中的虚拟地址，不一定配置在网卡，也没有每个VIP对应的用户态监听进程。节点数据面匹配VIP和Port，在iptables、IPVS或eBPF中选择Endpoint并DNAT/转发到PodIP。 | ClusterIP与kube-proxy |
| Service如何负载均衡 | 常见实现是在新连接上选择Endpoint，Conntrack让同一连接保持映射。它不是每个HTTP请求严格轮询；HTTP Keep-Alive、HTTP/2和gRPC长连接会让大量请求固定到一个Pod，扩容不会迁移已有连接。 | 连接级负载原理 |
| ClusterIP、NodePort、LoadBalancer有什么区别 | ClusterIP提供集群内VIP；NodePort在NodeIP暴露端口；LoadBalancer由云控制器或LB实现创建外部入口。NodePort不会自动开放安全组，LoadBalancer对象存在也不代表外部LB、健康检查和路由已经完成。 | Service类型对比 |
| externalTrafficPolicy的Cluster和Local区别 | Cluster可转到集群任意健康Endpoint，可达性好但可能跨节点和SNAT；Local只用入口Node本地Endpoint，常可保留源IP，但无本地后端的Node不能接流量，必须配合外部LB健康检查和均匀Pod分布。 | externalTrafficPolicy原理 |
| NetworkPolicy为什么配置了还不通 | 通信通常需要源Pod Egress允许、目标Pod Ingress允许、DNS和中间CNI可达、应用端口监听。策略按所有适用规则的允许并集生效，还要检查Namespace/Pod Label、目标Pod端口、NAT后的IP和CNI是否真正支持策略。 | NetworkPolicy隔离原理 |
| 为什么Egress默认拒绝后域名全失败 | 使用域名访问依赖DNS，Egress默认拒绝会同时阻断到CoreDNS/NodeLocal DNS的UDP/TCP 53。必须按集群实际DNS Pod/地址放行，并继续单独放行业务目标；只放数据库端口但忘记DNS会先在解析阶段失败。 | DNS最小放行 |
| IngressClass有什么作用 | IngressClass用spec.controller标识由哪类Controller处理，Ingress通过ingressClassName显式引用。多Controller集群常区分公网、内网和隔离入口；Class写错会无人接管或错误暴露，旧class Annotation兼容性取决于Controller版本。 | IngressClass原理 |
| Ingress的Exact、Prefix和ImplementationSpecific区别 | Exact精确匹配完整路径；Prefix按斜杠分隔的路径元素匹配，不是任意字符串前缀；ImplementationSpecific由Controller定义，可能支持正则但可移植性差。多个匹配通常优先更长路径，同长度时Exact优先。 | PathType匹配 |
| Ingress 404怎么判断是谁返回 | 用正确Host和SNI请求，结合响应特征、Controller Access Log和应用日志。Controller没有上游时查Class、Host、Path和默认后端；有upstream_status=404且应用收到请求时，查Rewrite、Context Path和应用Route。 | 404证据链 |
| Ingress 502、503、504怎么区分 | 502常见于连接拒绝/重置、协议或上游响应错误；503常见于无Ready Endpoint或入口/应用主动不可用；504常见于连接或响应超时。但状态码也可能由应用返回，必须结合upstream地址、状态、分段耗时、Endpoint和Trace。 | 入口5xx排查 |
| TLS Secret更新后为什么仍是旧证书 | 检查Secret ResourceVersion、证书和私钥，再看Controller是否Watch并成功热加载、多个Controller副本是否一致；确认更外层CDN/LB是否实际终止TLS，最后使用带正确SNI的openssl/curl从真实入口握手。 | 证书更新排查 |
| Ingress和Gateway API有什么区别 | Ingress提供相对基础Host/Path/TLS路由，高级能力大量依赖Annotation；Gateway API通过GatewayClass、Gateway、HTTPRoute等资源分离基础设施与应用角色并表达更丰富路由。两者都需要Controller实现，也都不等于Spring Cloud Gateway业务网关。 | Ingress与Gateway API |
| 一次部署流程怎么走 | kubectl把Deployment提交给API Server，请求经过认证、授权、准入、校验并写入etcd；Deployment Controller创建ReplicaSet，ReplicaSet Controller创建Pod；Scheduler过滤、评分并绑定Node；kubelet经CRI创建Sandbox和容器、经CNI配置网络、经CSI挂载存储，执行探针并写回状态。 | 从API请求到Pod运行全过程 |
| API Server请求经过哪些阶段 | 客户端先验证服务端TLS，API Server认证调用者身份，再授权其资源动作，随后执行Mutating Admission、结构校验和Validating Admission，完成版本转换并持久化到etcd。401通常是认证失败，403通常是已认证但无权限。 | API请求全过程 |
| Controller为什么使用Informer | Informer先List建立本地缓存，再Watch增量变化，把对象Key放进限速队列，由Worker按最新状态Reconcile。这样减少轮询压力并支持合并和退避；Watch可能重复或重连，因此Reconcile必须幂等。 | List-Watch与控制循环 |
| Scheduler如何选择Node | Scheduler先按资源Request、Taint/Toleration、Affinity、存储拓扑等硬约束过滤，再按资源分布和软偏好评分，最终绑定节点。它主要依据Request而不是实时CPU使用率，失败原因应看FailedScheduling Event。 | Scheduler全过程 |
| CRI、CNI、CSI有什么区别 | CRI是kubelet管理Sandbox、镜像和容器的运行时接口；CNI负责给Pod网络命名空间配置网卡、IP和路由；CSI负责存储供应、附加和挂载。镜像、网络和Volume故障要分别沿对应边界排查。 | CRI、CNI与CSI |
| Pod Running为什么不代表可用 | Running只是Pod Phase的粗粒度状态，不代表Readiness成功。容器可能已运行但数据库未连接、缓存未预热，此时应保持NotReady并不进入Service就绪端点；还需业务Smoke和版本指标证明端到端可用。 | Phase、State与Condition |
| API Server或Scheduler故障后业务会立即停吗 | 不一定。已经运行的容器和现有数据面可能短时继续服务，但API变更、调度、扩容、重建和状态交换会受影响。Scheduler故障主要让新Pod无法绑定Node；控制面长期异常仍会削弱恢复能力。 | 组件故障矩阵 |
| 滚动更新是什么 | Pod Template改变后Deployment创建新ReplicaSet，按maxSurge扩新副本；新Pod通过Readiness并满足minReadySeconds后，再按maxUnavailable缩旧副本。新Pod不Available时旧副本可能被保留，progressDeadline超时只标记失败，不自动回滚。 | 滚动更新全过程 |
| maxSurge和maxUnavailable怎样计算 | maxSurge限制滚动期间可额外创建的副本，百分比向上取整；maxUnavailable限制可用副本最多减少多少，百分比向下取整。replicas=3且两者25%时分别为1和0；Terminating Pod仍可能让实际资源峰值更高。 | 滚动容量计算 |
| Pod优雅终止经历什么 | 删除后宽限期开始，kubelet执行preStop，再向主进程发送SIGTERM；应用停止接新请求并处理在途工作，超时才SIGKILL。Endpoint更新和进程信号不是全局原子顺序，preStop也占用宽限时间，因此应用必须实现Drain。 | 优雅终止全过程 |
| rollout undo能撤销什么 | 它把历史Pod Template重新设为当前期望并发起新一轮更新，不能自动撤销数据库DDL/DML、ConfigMap/Secret、Service/Ingress、已发送消息和外部支付等副作用。生产回滚需要兼容迁移和补偿。 | 回滚边界 |
| StatefulSet和Deployment区别 | Deployment管理可替换无状态副本；StatefulSet按Ordinal提供稳定名称、DNS语义和独立PVC，并支持有序创建更新。StatefulSet不会自动实现数据库复制、选主、Quorum、备份或故障转移。 | StatefulSet原理 |
| DaemonSet是否保证每个Node都有Pod | 它为每个符合NodeSelector/Affinity、Taint/Toleration等条件的Node维持一个Pod；不匹配、资源不足或节点异常仍会缺失。节点Agent常使用hostPath等高权限能力，必须最小挂载、只读和最小RBAC。 | DaemonSet节点覆盖 |
| Job为什么必须幂等 | 节点故障、重试和成功状态写回延迟可能让同一业务单元再次执行。使用稳定runId/shardId、数据库唯一键、条件更新、外部幂等键和原子结果发布；不能依赖平台严格恰好一次。 | Job完成与幂等 |
| CronJob三种并发策略是什么 | Allow允许并行，Forbid在上一Job未完成时跳过本次，Replace尝试替换旧Job。它们都不能撤销旧任务外部副作用，也不是跨集群全局锁；还要处理时区、missed schedule、startingDeadline和业务幂等。 | CronJob并发与错过调度 |
| startup、readiness和liveness区别 | startup判断本次容器是否完成启动，成功前门控另外两种探针，失败达阈值会重启；readiness决定是否作为Service正常新流量后端，失败不重启；liveness判断是否只能靠重启恢复，失败达阈值由kubelet重启该容器，通常不迁移Pod。 | 三种探针状态机 |
| Readiness失败后流量怎样摘除 | kubelet把Container/Pod Ready Condition写回API Server，EndpointSlice Controller更新端点Ready条件，节点和入口数据面再异步同步。过程不是原子的，已有Keep-Alive/gRPC/WebSocket连接不会自动迁移，直连PodIP也不受Service选择。 | Readiness到Endpoint全过程 |
| 为什么Liveness不应检查数据库 | 数据库是共享外部依赖，重启应用通常无法修复；若所有Pod把数据库加入Liveness，会同时重启并制造冷启动和连接风暴，进一步压垮数据库。Liveness只检查重启当前容器大概率可恢复的本地不可恢复状态。 | Liveness契约 |
| HTTP、TCP、gRPC、Exec Probe区别 | HTTP验证Pod内HTTP路径，TCP只验证端口可连接，gRPC调用标准Health协议，Exec在容器内执行命令看退出码。它们通常只覆盖Node到Pod/容器内部路径，不能证明Service、Ingress、TLS和完整业务；Exec还有进程资源开销。 | 探测方式对比 |
| initialDelay为什么不能替代startupProbe | initialDelay是固定等待：启动快也必须等，启动比固定值慢仍会被Liveness误杀；startupProbe按实际成功结束启动保护，在有界窗口内适应快慢启动，成功后再启用Readiness/Liveness。 | 启动窗口设计 |
| Probe成功为什么用户仍可能访问失败 | HTTP/TCP/gRPC Probe通常由kubelet从Node直接访问Pod IP，不经过Service ClusterIP、CoreDNS、Ingress、公网DNS、LB和完整TLS，也不证明关键业务交易成功；还需Service/Ingress排查、外部合成监控和发布Smoke。 | Probe盲区 |
| ConfigMap 和 Secret 区别 | ConfigMap保存非敏感配置，Secret表达密码、Token和证书等敏感小数据。Secret的Base64不是加密，仍需TLS、etcd静态加密/KMS、RBAC、节点安全、审计和外部密钥系统；两者都可通过env或Volume注入，但生效机制不同。 | ConfigMap与Secret边界 |
| 为什么修改ConfigMap后环境变量不变 | kubelet只在创建容器时解析ConfigMap/Secret并把值传给进程初始环境；进程环境是启动快照，后续对象变化不会远程修改运行中进程。需要滚动重建Pod，或改用文件/配置客户端并实现安全热加载。 | 环境变量生命周期 |
| ConfigMap Volume怎样更新 | kubelet检测新ResourceVersion后准备完整新版本目录，再原子切换..data符号链接。重新按路径open通常看到新内容，但更新有传播延迟；subPath绑定旧inode不会跟随，长期打开的FD和应用缓存也可能继续使用旧配置。 | 投射卷更新全过程 |
| Secret开启etcd加密后是否绝对安全 | 不是。静态加密主要保护etcd磁盘和备份，不防API读取权限、可创建Pod挂载Secret的人、exec权限、被攻陷Node/Pod、应用日志、Heap Dump和进程内存。加密只是Secret完整生命周期的一层。 | 静态加密边界 |
| 不能get Secret就一定读不到吗 | 不一定。能在Namespace创建Pod、修改Deployment或exec进入已挂载Secret的Pod，也可能间接取得明文；list/watch权限通常还能批量持续读取。Namespace工作负载写权限本身接近高权限，需要RBAC和Admission联合限制。 | 间接Secret权限 |
| 怎样零停机轮换数据库密码 | 先创建可并存的新数据库用户/Key和新版本Secret，让金丝雀、再全量新Pod验证；等待旧连接排空和旧凭据使用归零后撤销旧凭据，最后过回滚窗口再清理旧Secret。直接覆盖单一密码会让旧Pod立即失败。 | 凭据轮换流程 |
| ConfigMap变化怎样触发Deployment更新 | Deployment只观察Pod Template，同名ConfigMap内容变化不会自动生成ReplicaSet。可创建不可变版本名并修改引用，或把稳定内容Hash/版本ID写入Template Annotation；Secret低熵裸Hash还需防字典猜测。 | Checksum与版本化对象 |
| PV、PVC和StorageClass什么关系 | PVC是Namespace内应用对容量、AccessMode、VolumeMode和Class的申请；PV是集群级底层卷表示；StorageClass定义Provisioner、供应参数、Reclaim、扩容和绑定模式。动态供应时External Provisioner调用CSI创建真实卷和PV，再与PVC绑定。 | PV/PVC/StorageClass |
| PVC Bound后为什么Pod仍ContainerCreating | Bound只说明PVC与PV绑定。块盘还可能需要ControllerPublish附加Node、NodeStage准备设备/文件系统、NodePublish挂到Pod路径，再处理权限；任一步都可FailedAttach/FailedMount，应查VolumeAttachment、Event和CSI日志。 | Attach/Mount全过程 |
| RWO和RWOP区别 | RWO主要是单Node读写，同一Node多个Pod在某些场景仍可挂载；RWOP才表达集群范围单Pod读写，并要求CSI和Kubernetes版本支持。AccessMode不是应用并发锁，底层强制能力也依Driver。 | AccessMode准确语义 |
| Immediate和WaitForFirstConsumer区别 | Immediate在PVC创建时立即供应，拓扑卷可能落在与Pod约束冲突的Zone；WaitForFirstConsumer等待引用PVC的Pod，让Scheduler把CPU、Affinity和存储拓扑一起决策，再在选定Zone供应，未有消费者时PVC Pending可能正常。 | WFFC调度原理 |
| Delete和Retain回收策略区别 | Delete通常在PVC删除后由Provisioner删除PV和底层卷；Retain保留底层数据并使PV进入Released，需要人工恢复或清理。两者都不是备份：Delete要防误删，Retain要防孤儿盘、费用和数据泄露。 | ReclaimPolicy |
| 存储快照为什么不等于备份 | 快照可能与源卷同存储系统/账号、可被同凭据删除，并且通常只有Crash Consistent。备份应独立故障域、不可变/防删除、具备数据库一致性或PITR，并通过真实恢复演练验证RPO/RTO。 | 快照与备份边界 |
| Multi-Attach怎么排查 | 先确认旧Pod/Node是否仍运行并完成Fencing，再检查VolumeAttachment、云盘真实附加和CSI日志；安全卸载后按厂商Runbook Detach并在同拓扑重建。不能直接强制Detach仍在写的数据库卷，否则可能脑裂或损坏。 | Multi-Attach Runbook |
| K8s 怎么排查生产问题 | 先确认用户影响、时间窗、集群、Namespace、版本和最近变更，再用业务SLI定位异常版本。未调度查Scheduler Event，节点准备失败查Runtime/CNI/CSI，运行后异常查ContainerStatus、当前与previous日志、探针和资源，Ready但访问失败查EndpointSlice、Service、Ingress和Trace。止损前保留现场，修复后用同一SLI验证。 | 生产排查总流程 |
| 日志、指标、Trace和Event有什么区别 | 指标回答数量、趋势和影响范围；日志记录某时刻代码/组件输出；Trace展示单次请求的跨服务耗时；Event记录K8s组件的调度、镜像、探针和挂载判断。Object Status和Profile再补充当前收敛状态与运行时热点，必须相互验证。 | 六类证据边界 |
kubectl top和Prometheus有什么区别 | kubectl top通常读取Metrics Server提供的近期CPU/内存Resource Metrics，适合快速看当前值，不保存完整历史。Prometheus周期抓取并保存时间序列，可查询Rate、Histogram和告警；kube-state-metrics则把K8s对象状态转成指标。 | Metrics数据链路 |
| CrashLoopBackOff怎么排查 | 它表示容器反复失败后kubelet进入重启退避，不是根因。先看describe Event和ContainerStatus的lastState、ExitCode、Reason，再用logs --previous读取上一次崩溃日志，结合Command、配置、依赖、探针、权限和OOM证据判断。 | CrashLoopBackOff证据链 |
| OOMKilled等于Java Heap OOM吗 | 不等于。OOMKilled说明容器进程被内存控制/OOM机制终止；容器总内存还包括Heap、Metaspace、Direct Buffer、线程栈和Native。必须结合容器历史指标、JVM内存区、GC、线程数、Heap Dump或NMT判断。 | OOMKilled与Java OOM |
| Pod Ready但Service返回503怎么查 | 先检查Pod Label与Service Selector、EndpointSlice地址和Ready条件、targetPort、应用监听地址，再看NetworkPolicy、Ingress Backend和Controller日志，最后区分503究竟由Ingress、Service Mesh还是应用返回。Readiness配置错误也会产生假阳性。 | Ready但503排查 |
项目话术
text
在医疗数据采集平台里，采集服务、资产服务、字典服务、权限服务可以容器化后部署到 K8s。无状态服务用 Deployment 管副本和滚动更新，Service 提供内部稳定访问，Ingress 或网关暴露外部入口，ConfigMap 管普通配置，Secret 管敏感信息，readinessProbe 保证实例真正就绪后再接流量。常见追问
| 追问 | 回答方向 | 跳转 |
|---|---|---|
| Pod 一直重启怎么查 | 先保留现场，读取ContainerStatus的当前和上次状态、退出码和Reason，再看Event与logs --previous；区分应用主动退出、liveness误杀、OOMKilled、权限、配置和依赖失败。 | CrashLoopBackOff排查、探针 |
| Service 访问不到 Pod 怎么查 | 先验证DNS，再核对Service selector/port/targetPort；检查Pod Label、Ready和EndpointSlice地址/端口；从同一客户端分别直连PodIP和Service，PodIP失败查应用监听/Policy/CNI，PodIP成功而Service失败查节点Service数据面和Conntrack。 | 客户端到Pod验证顺序 |
| 发布为什么要配置 readinessProbe | 新Pod只有Readiness成功并满足minReadySeconds后才成为Available并进入正常后端；失败时可保留旧ReplicaSet，避免坏版本接流量。Readiness应表达能否接新请求，但不能把所有可降级依赖都无脑加入。 | Readiness与滚动更新 |
| Helm 解决什么问题 | Helm把一组Kubernetes资源组织成版本化Chart，按Values渲染并以Release/Revision管理安装升级历史。Helm主要是客户端模板和发布工具，不是另一套Controller；资源提交后仍由Kubernetes Controller运行，Release默认保存在Namespace Secret。 | Helm架构 |
| Helm Values优先级和合并规则 | Chart默认值最低，父Chart可覆盖依赖，其后多个-f按顺序后者覆盖，--set类最高；Map通常递归合并，List通常整体替换。--set会推断类型，Digest/账号等用--set-string，复用旧Values可能阻止新安全默认生效。 | Values全过程 |
--wait和--atomic区别 | wait在timeout内等待部分Kubernetes资源Ready/Complete，但不证明Ingress、业务和外部依赖；atomic在Install失败时卸载或Upgrade失败时尝试Rollback，并通常启用wait。atomic不能撤销数据库、Hook外部副作用、消息、CRD和新数据格式。 | wait与atomic边界 |
| Helm Rollback能回滚什么 | 它读取历史Revision中的Chart、Values和Manifest，把Kubernetes对象调整回历史期望，并产生新的Revision；不能撤销数据库DDL/DML、Hook副作用、外部Secret、CRD Schema和已写数据，旧API/镜像/Schema失效时自身也会失败。 | Rollback全过程 |
| Helm为什么不自动升级或删除CRD | CRD定义所有Custom Resource的Schema和生命周期，错误升级会拒绝/破坏对象，删除可能级联删除业务数据。Helm对crds/采用保守策略：Install先创建，但Upgrade/Uninstall不自动管理完整生命周期，需要独立转换、迁移和恢复Runbook。 | CRD特殊生命周期 |
| Helm Release Secret有什么风险 | 每个Revision默认把Chart、Values、Manifest、Hook和状态编码保存在Namespace Secret；密码明文放Values或渲染清单时会进入历史。需要最小RBAC、脱敏CI输出、existingSecret/外部Secret以及history-max。 | Release存储与安全 |
| pending-upgrade怎么处理 | 先确认是否仍有发布进程，查看status/history、Hook Job、Kubernetes资源和API事件，保存证据后按真实状态修复或rollback，并对Release加发布锁。不要先删除最新Release Secret，手工改内部记录会制造孤儿和历史不一致。 | Pending Runbook |
面试回答模板
text
K8s 我会围绕期望状态回答。开发者提交 YAML 后，API Server 接收并写入 etcd，Controller 持续对比期望状态和实际状态，Scheduler 为 Pod 选择节点，kubelet 在节点上启动容器。业务服务通常用 Deployment 管副本和滚动更新，用 Service 提供稳定访问，用 Ingress 暴露外部入口，用探针控制接流量和自愈。本章小结
K8s 面试页负责帮你组织回答。为什么 K8s 是声明式、为什么 Pod 是最小调度单位、为什么 Service 能稳定访问、为什么探针影响发布质量，都要进入知识点页理解。