从面试官视角拆解K8s：那些藏在Deployment、Service和Ingress背后的真实生产考量

从面试官视角拆解K8s：那些藏在Deployment、Service和Ingress背后的真实生产考量

当面试官问"如何设计一个高可用的Kubernetes服务"时，候选人流畅地背出Deployment的YAML模板，却对背后的设计哲学一无所知——这正是大多数K8s面试的现状。本文将从生产视角揭示那些文档不会告诉你的实战经验，带你看透K8s核心组件背后的工程智慧。

1. Deployment的进阶生存法则

1.1 副本数设置的黄金分割点

在面试中常被问及"应该设置多少个副本"，标准答案是"至少2个确保高可用"，但真实场景要复杂得多。我们曾遇到一个典型案例：某电商设置3副本的订单服务，在流量高峰时仍出现服务降级。根本原因在于：

• 垂直扩展陷阱：每个Pod的CPU限制设置为2核，但实际业务峰值时需要4核处理能力
• 节点亲和性缺失：所有副本被调度到同一可用区，当该区域网络出现波动时整体不可用
• 就绪探针缺陷：应用启动需要45秒，但就绪探针在30秒超时，导致流量打到未就绪Pod

优化方案矩阵：

# 生产级Deployment片段示例 spec: replicas: 3 strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 15% template: spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["order-service"] topologyKey: "topology.kubernetes.io/zone" containers: - resources: requests: cpu: "2" memory: "4Gi" limits: cpu: "4" memory: "8Gi" readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 45 periodSeconds: 10 successThreshold: 1

1.2 滚动更新的暗礁与规避

某金融系统在版本更新时出现长达5分钟的服务中断，根本原因是：

1. 同时更新所有Pod导致瞬时服务能力降为0
2. 新版本镜像存在启动顺序依赖（需要先连接配置中心）
3. 旧版本Pod被立即终止，未处理完的请求被强制中断

解决方案工具箱：

• 分阶段发布：先更新20%的Pod，验证通过后再全量
• PreStop Hook：优雅终止旧Pod，等待30秒排水时间
• ReadinessGate：添加自定义就绪条件（如配置中心连接状态）

关键洞察：生产环境中maxUnavailable建议设置在15%-25%之间，maxSurge建议20%-30%。对于有状态服务，考虑使用StatefulSet的partition更新策略。

2. Service的流量治理艺术

2.1 ClusterIP的性能迷思

当被问及"Service如何实现负载均衡"，多数人会回答"通过kube-proxy的iptables规则"，但极少人知道：

• iptables模式在超过5000个Service时会出现明显性能下降
• IPVS模式支持多种调度算法（rr/wrr/lc等）但需要内核模块支持
• Headless Service配合客户端负载均衡可降低30%的延迟

不同代理模式对比：

# 检查当前代理模式 kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode

2.2 会话保持的代价

某游戏公司使用默认的ClusterIP服务，玩家频繁掉线。分析发现：

1. 客户端长连接被随机分配到不同后端Pod
2. 玩家状态信息存储在Pod本地内存中
3. 服务端推送消息时连接已切换到其他Pod

解决方案对比表：

3. Ingress的进阶路由策略

3.1 多Ingress控制器的共存困境

某企业同时使用Nginx Ingress和ALB Ingress，导致：

• 路由规则冲突，某些路径被重复匹配
• 监控指标分散，难以统一观测
• TLS证书需要多份配置

优雅解决方案：

1. 通过IngressClass区分流量类型：

   apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-alb spec: controller: ingress.k8s.aws/alb

2. 按域名分片：.api.example.com走Nginx，.web.example.com走ALB
3. 使用Gateway API统一抽象层

3.2 金丝雀发布的精准控制

传统方式修改Ingress注解实现流量切分存在两大问题：

1. 无法基于请求内容（如Header、Cookie）路由
2. 比例调节需要频繁修改YAML并重新加载

进阶方案示例：

apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: product-service spec: targetRef: apiVersion: apps/v1 kind: Deployment name: product-service service: port: 8080 analysis: interval: 1m threshold: 5 maxWeight: 50 stepWeight: 10 metrics: - name: request-success-rate thresholdRange: min: 99 interval: 1m - name: request-duration thresholdRange: max: 500 interval: 1m

4. 存储与网络的隐藏关卡

4.1 PV扩容的陷阱

当被问及"如何扩展PV容量"，标准答案是修改PVC的storage字段，但实际会遇到：

• 部分存储插件不支持在线扩容（如AWSElasticBlockStore）
• 文件系统需要额外resize2fs操作
• 有状态服务需要重建Pod才能生效

安全扩容检查清单：

1. 确认StorageClass支持allowVolumeExpansion

   allowVolumeExpansion: true

2. 检查PV的VolumeMode是否为Filesystem（Raw block设备不支持扩容）
3. 对于StatefulSet，需要删除并让控制器重建Pod

4.2 网络策略的性能代价

启用NetworkPolicy后某AI训练集群性能下降60%，根源在于：

• Calico的iptables实现每条规则需要线性匹配
• 超过500条规则时数据包处理延迟显著增加
• 频繁的Pod创建导致规则动态更新消耗CPU

优化策略：

• 使用Cilium的eBPF实现替代iptables
• 按命名空间划分安全域而非单个Pod
• 合并相似规则，减少规则总数

# 低效策略示例 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-isolation spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 5432 # 优化后策略 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: namespace-isolation spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: env: production

在K8s生产实践中，真正的挑战从来不是YAML语法，而是理解每个API对象背后的设计约束和工程权衡。那些看似简单的Deployment、Service配置项，实则是无数线上事故换来的经验结晶。记住：优秀的K8s工程师不是记住最多命令的人，而是能说清楚每个参数为什么存在的人。