从面试官视角拆解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优化方案矩阵维度常规配置优化配置效果对比副本数固定3副本基于HPA动态扩展(2-10)资源节省40%资源限制CPU:2 Memory:4GiCPU:4 Memory:8Gi Burstable QoS峰值吞吐量提升3倍调度策略默认调度PodAntiAffinity多可用区可用性从99.9%提升到99.99%# 生产级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: 11.2 滚动更新的暗礁与规避某金融系统在版本更新时出现长达5分钟的服务中断根本原因是同时更新所有Pod导致瞬时服务能力降为0新版本镜像存在启动顺序依赖需要先连接配置中心旧版本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%的延迟不同代理模式对比特性userspaceiptablesIPVS实现复杂度高中低性能差(10k req/s)良(50k req/s)优(100k req/s)会话保持不支持有限支持完整支持适用场景已废弃中小集群大型集群# 检查当前代理模式 kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode2.2 会话保持的代价某游戏公司使用默认的ClusterIP服务玩家频繁掉线。分析发现客户端长连接被随机分配到不同后端Pod玩家状态信息存储在Pod本地内存中服务端推送消息时连接已切换到其他Pod解决方案对比表方案实现方式优点缺点SessionAffinity基于客户端IP哈希简单易用移动端用户IP变化导致失效Redis集中存储会话数据外置真正无状态增加架构复杂度Service Mesh通过Envoy实现一致性哈希灵活可控学习成本高3. Ingress的进阶路由策略3.1 多Ingress控制器的共存困境某企业同时使用Nginx Ingress和ALB Ingress导致路由规则冲突某些路径被重复匹配监控指标分散难以统一观测TLS证书需要多份配置优雅解决方案通过IngressClass区分流量类型apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-alb spec: controller: ingress.k8s.aws/alb按域名分片.api.example.com走Nginx.web.example.com走ALB使用Gateway API统一抽象层3.2 金丝雀发布的精准控制传统方式修改Ingress注解实现流量切分存在两大问题无法基于请求内容如Header、Cookie路由比例调节需要频繁修改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: 1m4. 存储与网络的隐藏关卡4.1 PV扩容的陷阱当被问及如何扩展PV容量标准答案是修改PVC的storage字段但实际会遇到部分存储插件不支持在线扩容如AWSElasticBlockStore文件系统需要额外resize2fs操作有状态服务需要重建Pod才能生效安全扩容检查清单确认StorageClass支持allowVolumeExpansionallowVolumeExpansion: true检查PV的VolumeMode是否为FilesystemRaw block设备不支持扩容对于StatefulSet需要删除并让控制器重建Pod4.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工程师不是记住最多命令的人而是能说清楚每个参数为什么存在的人。