平安科技一面面经（10.10）：K8s 核心组件、Pod 调度与 AI 底层架构优化

《面试题目》

1. 自我介绍。
2. 项目里用 Go 的时候，遇到过哪些问题？怎么优化的？
3. 有没有在全链路上做优化？包括前端、中间件、网络层、存储等等？
4. 说一下你对这个岗位的理解，以及你的优势。
5. 说一下 K8s 中核心的组件有哪些？
6. 部署一个 Pod 时，是怎么进行调度的？
7. 说一下 K8s 中 Pod 之间的通信方式有哪些？各自有哪些特点？
8. 针对 AI 底层架构，你在计算、存储和网络层上能想到哪些优化？
9. 收到 offer 后，最早什么时候可以提前入职？

（帖内提到：全程约 25 分钟结束，最后是反问环节。）

《参考解析》

Go 在项目里会遇到什么、怎么优化。 面试官问「用 Go 遇到过什么问题」，想听的是真实故障而不是语言特性罗列。高频的真实问题集中在这几类：一是 goroutine 泄漏——请求上下文取消后后台 goroutine 没有退出、channel 没人消费导致阻塞、循环里起 goroutine 却没有收敛机制，排查方式是看 goroutine 数与 pprof 的 goroutine dump；二是内存与 GC 压力——大对象频繁分配导致 GC 频率上升、[]byte 与字符串转换产生额外拷贝、切片没有预分配容量导致反复扩容，优化手段是对象池与缓冲区复用、预分配、减少逃逸；三是并发安全——map 并发读写 panic、误用共享变量，靠 -race 与最小化共享状态解决；四是锁与调度——全局锁导致串行、sync.Mutex 与 atomic/RWMutex 选择不当、channel 使用过量导致上下文切换；五是超时与重试——没有统一超时控制、重试放大流量形成雪崩，需要 context 传递超时、退避重试、熔断与限流。答题时最好给一条真实的排查链：现象（P99 升高 / 内存持续上涨）→ 观测工具（pprof、火焰图、metrics）→ 根因 → 改法与验证结果。

全链路优化怎么谈。 这道题的关键不是把每一层都讲一遍，而是展示你有「按瓶颈定位、分层优化」的方法。前端：减少请求数与体积、静态资源 CDN 与强缓存、首屏关键路径优化、接口聚合。网关与中间件：连接复用、超时与重试策略、限流削峰、无状态化以便水平扩容、缓存前置。应用层：慢接口拆分与异步化、批量代替循环单次调用、N+1 查询治理、池化（连接池、线程/协程池）与参数调优、序列化开销（避免大对象跨网络传输）。存储层：索引与慢查询治理、读写分离、分库分表、热点数据缓存、批量写入与顺序写。网络层：协议选择（gRPC 对比 JSON over HTTP）、压缩、就近接入、减少跨机房调用。收尾一定要落到「怎么量化」：给关键路径打点，看 P99、错误率、QPS、资源利用率，优化前后对比，避免「感觉快了」。全链路优化的另一个重点是分清「真正的瓶颈在哪一层」——很多时候上游的重试或下游的慢查询才是根因，盲目加缓存只会把问题掩盖成一致性问题。

K8s 核心组件与 Pod 调度。 控制面：kube-apiserver（唯一入口，负责认证、鉴权、准入、校验并持久化到 etcd）、etcd（集群唯一事实来源）、kube-scheduler（决定 Pod 落在哪个节点）、kube-controller-manager（各种控制循环：Deployment、ReplicaSet、Node、Endpoint 等）。数据面：kubelet（节点代理，负责 Pod 生命周期、探针、挂载、上报状态）、容器运行时（containerd/CRI-O）、kube-proxy 或 eBPF 实现（实现 Service 的负载均衡规则）、CNI 插件（Pod 网络）、CoreDNS（集群内服务发现）、CSI（存储）。调度流程分两步：先过滤（Filter/Predicates）——排除资源不足、亲和性不满足、污点不容忍、端口冲突、卷拓扑不匹配的节点；再打分（Score/Priorities）——按资源均衡、亲和性偏好、拓扑分布等维度排序，选出最优节点，最后绑定（Bind）写回 API Server。此外还有抢占（高优先级 Pod 驱逐低优先级）、调度框架的插件扩展点、以及未调度的常见原因排查（Pending：资源不足、污点、PVC 未绑定、镜像拉取失败不在调度阶段）。答题时把「过滤与打分」两个阶段说清楚，再补一句「调度只决定初始落点，运行期靠 kubelet 与控制器纠偏」，层次就很完整。

Pod 之间的通信方式。 K8s 的网络模型约定：每个 Pod 有独立 IP，Pod 内所有容器共享网络命名空间，因此同 Pod 内容器直接用 localhost 通信。跨 Pod 通信分几种情形：同一节点内，靠 CNI 创建的 veth pair 与网桥（或 eBPF 转发）二层直达；跨节点时，通常用 Overlay 封装（VXLAN/IPIP，靠隧道把包送到对端节点）或 Underlay 直通（BGP 宣告 Pod 网段，性能更好但要求网络设备配合）。服务发现与负载均衡层面：Service ClusterIP 由 kube-proxy 用 iptables/IPVS 规则或 eBPF 实现四层转发，NodePort 暴露到节点端口，LoadBalancer/Ingress 对外；Headless Service 直接返回 Pod IP 列表，供有状态服务自行管理连接。各自特点要能对比：iptables 规则随 Service 数量线性增长、大集群下更新慢；IPVS 用哈希表、规模大时更稳，支持更多调度算法；eBPF（Cilium 等）绕过 iptables、可观测性与性能更好，但依赖内核版本与运维成本。还要提安全与隔离：NetworkPolicy 控制 Pod 间的东西向流量，默认全通、需要显式收紧。顺带的考点是 DNS：集群内通过 Service 名解析，CoreDNS 负责，排查 DNS 超时也是常见运维问题。

AI 底层架构在计算、存储、网络上的优化空间。 计算层：提高 GPU 利用率是主线——用 MIG 或时间片切分把推理任务打满、提高 batch 与并发以摊薄权重加载、做算子融合与图优化、推理侧用量化（INT8/FP8）、蒸馏与投机解码降本，训练侧用混合精度、梯度累积、激活重计算换显存、ZeRO/并行策略（数据、张量、流水线并行）解决单卡放不下的问题；调度上用 gang scheduling 保证分布式任务要么全起要么不起，配合拓扑感知把同一个通信组调度到同一台机器或同一个交换机下。存储层：训练数据的读取往往是隐性瓶颈，要用高吞吐的并行文件系统或分布式缓存做数据本地性、预取与小文件合并，模型权重与 checkpoint 要有分层缓存（本地 NVMe → 共享存储 → 对象存储），并注意 checkpoint 的异步写与版本管理。网络层：分布式训练的瓶颈是集合通信，RDMA/RoCE 或 InfiniBand 能显著降低 CPU 开销与延迟，NCCL 的拓扑感知与 ring/tree 算法选择要看节点内 NVLink 与节点间带宽的收敛比；推理侧则是减少跨机房调用、就近接入与连接复用。回答这类开放题，加分点是先问清场景（训练还是推理、模型多大、延迟要求），再按「瓶颈在哪、怎么量化、收益与成本」给方案，而不是把所有技术名词堆一遍。