05 Kubernetes 与 ACK 云原生

渐儿
3 阅读10分钟

面试官关注点：会写 YAML 只是起点。集群架构设计、节点排障、网络/存储 CSI 选型、Operator 能力、Istio 落地才是资深门槛。

一、Kubernetes 架构速览

1.1 控制面组件

  • kube-apiserver：唯一入口，认证/授权/准入控制、REST 服务、写 etcd
  • etcd：所有集群状态，强一致 KV，建议 3/5/7 节点奇数部署，SSD
  • kube-scheduler：Pod → Node 决策（过滤 + 打分）
  • kube-controller-manager：Deployment/RS/Node/Endpoint 等控制器
  • cloud-controller-manager：云厂商相关（SLB、路由、节点生命周期）

1.2 数据面组件

  • kubelet：节点上的代理，管理 Pod 生命周期
  • kube-proxy：Service 流量转发（iptables/ipvs/eBPF）
  • CRI（containerd）：容器运行时，1.24+ 废弃 dockershim
  • CNI：网络插件（Terway/Flannel/Calico/Cilium）
  • CSI：存储插件（各类盘/NAS/OSS）

1.3 典型请求链路

kubectl apply
→ apiserver 认证（Token/Cert）→ 授权（RBAC）→ 准入（Webhook）
→ 写 etcd
→ scheduler watch 到未调度 Pod → bind 到 Node
→ kubelet watch 到本节点 Pod → CRI 拉镜像、启容器 → CNI 配网络 → CSI 挂盘
→ 状态回写 apiserver → etcd

二、ACK 产品家族

产品定位
ACK 托管版 ProMaster 托管，Worker 自管（最主流）
ACK 专有版Master + Worker 自管（已不推荐）
ACK Serverless（ASK）无节点，Pod = ECI，按 Pod 计费
ACK Edge边缘节点纳管
ACK One多集群舰队管理
ACK Lingjun灵骏 AI 集群，RDMA + GPU

托管版 Pro 优势：SLA 99.95%、Master 高可用阿里云运维、ETCD 加密、审计日志默认开启。

三、集群架构设计

3.1 节点池规划

按业务特性拆节点池：

node-pool-system    # kube-system、CoreDNS、监控 Agent（污点隔离）
node-pool-general   # 通用业务
node-pool-gpu       # GPU 训练/推理（污点 + nodeSelector）
node-pool-spot      # Spot 实例，离线任务
node-pool-arm       # ARM 节点，成本优化

污点 + 亲和性组合：

  • 节点池打 taint dedicated=gpu:NoSchedule
  • Pod 写 tolerations + nodeSelector 精准调度

3.2 节点规格选型

  • 微服务密集：g 系列 32c64g / 32c128g，Pod 密度高
  • Java 应用：内存型 r 系列，堆够用
  • GPU 推理：gn7i（A10）
  • 大数据：d 系列本地盘
  • 单节点过大的坏处：故障半径大、调度粒度粗；过小则管理开销大，经验值 16c-64c

3.3 可用区拓扑

  • 多 AZ 节点池：每个 AZ 一个节点池，topologySpreadConstraints 强制 Pod 打散
  • etcd 跨 AZ：3 AZ 各 1 个节点（ACK 托管版已做好）
  • Ingress SLB：跨 AZ

四、网络深入

4.1 Terway 深度

  • 独占 ENI：Pod 独占一张弹性网卡（延迟最低，Pod 数受限）
  • 共享 ENI（辅助 IP）：一 ENI 多辅助 IP，一个 IP 对应一 Pod（主流）
  • Terway + IPvlan：内核级高性能
  • NetworkPolicy：支持 Calico 风格策略
  • Trunk ENI：一节点多 VSwitch / 安全组，支持 Pod 级细粒度网络隔离

4.2 Service 与 Ingress

  • ClusterIP：集群内 VIP，kube-proxy 转发
  • NodePort：每节点开端口，外部访问，不推荐生产
  • LoadBalancer：云厂商 LB 对接，ACK 自动创建 SLB/ALB/NLB
  • Headless Service：不分配 VIP，直接返回 Pod IP 列表（StatefulSet 场景）

Ingress 选型：

  • Nginx Ingress：社区标准，ACK 默认可选
  • ALB Ingress：阿里云 ALB 直接做入口，与 IngressClass 集成
  • MSE 云原生网关：一体化（Ingress + 服务发现 + WAF + 限流）

4.3 kube-proxy 模式对比

模式原理性能故障排查
iptables大量 iptables 链O(n) 匹配，规模大时慢链太多难排查
IPVSLVS 内核级O(1) 哈希规则清晰
eBPF（Cilium）内核直通最快需工具链

生产建议：IPVS 或 Cilium。

4.4 CoreDNS 调优

  • 默认配置在大集群下可能成为瓶颈（大量 NXDOMAIN 查询）
  • NodeLocal DNSCache：每节点 Cache，减少跨节点流量
  • ndots:5 默认配置 → 多次查询，可调为 2
  • autopath 插件避免无意义 Search 查询

五、存储（CSI）

5.1 ACK CSI 支持

类型产品访问模式
块ESSD 云盘RWO（单 Pod）
文件NASRWX（多 Pod 共享）
文件CPFSRWX，高性能
对象OSS通过 ossfs/jindofs 挂载
本地Local PV节点本地盘

5.2 StatefulSet 存储

volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: [ReadWriteOnce]
    storageClassName: alicloud-disk-essd
    resources:
      requests:
        storage: 100Gi
  • 副本独立 PVC：每个副本自己的盘
  • Pod 重建盘保留：除非 persistentVolumeReclaimPolicy: Delete

5.3 动态扩容

  • StorageClass 设 allowVolumeExpansion: true
  • 改 PVC size → CSI 调 API 扩盘 → 节点重启或在线文件系统扩容

六、工作负载与调度

6.1 资源请求与限制

resources:
  requests:
    cpu: 500m        # 调度依据
    memory: 512Mi
  limits:
    cpu: 2           # CPU 超限节流，不杀
    memory: 1Gi      # 内存超限 OOMKill

QoS 等级：

  • Guaranteed：request = limit（关键业务）
  • Burstable：request < limit（普通）
  • BestEffort：无 request/limit（离线任务，优先被驱逐）

生产铁律：所有生产 Pod 必须显式设 request/limit，避免节点超卖引发连锁故障。

6.2 HPA / VPA / CA

工具维度
HPA水平扩副本，基于 CPU/内存/自定义指标（QPS、队列长度）
VPA垂直调 request/limit（改 Pod 需重建）
CA（Cluster Autoscaler）节点级扩容，Pending Pod 触发
ACK 虚节点Pod → ECI，瞬时弹性无节点等待
KEDA事件驱动扩缩，基于消息队列深度、Kafka lag 等

扩容速度：HPA 默认 15s 一次评估，CA 数分钟加节点；秒级峰值选虚节点 + 预留 buffer。

6.3 调度增强

  • 节点亲和性（nodeAffinity）：硬/软偏好
  • Pod 亲和/反亲和：同节点聚集或打散
  • topologySpreadConstraints：按 AZ/zone 均匀分布（强烈推荐）
  • PriorityClass：核心业务高优先级，抢占低优
  • Descheduler：定期重平衡已调度 Pod

6.4 PDB（PodDisruptionBudget）

apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2    # 或 maxUnavailable
  selector:
    matchLabels:
      app: web
  • 节点排水（drain）、节点升级时保底
  • 生产多副本工作负载必配

七、可观测与排障

7.1 集群健康检查

kubectl get componentstatuses     # 控制面组件（Deprecated，看 Pod）
kubectl get nodes -o wide         # 节点状态
kubectl top node                  # 节点资源使用
kubectl get events --sort-by='.lastTimestamp' -A

7.2 Pod 排障套路

kubectl describe pod <pod>        # Events 段看调度、镜像、健康检查失败原因
kubectl logs <pod> -c <container> --previous  # 看上一个挂掉的容器日志
kubectl exec -it <pod> -- sh      # 进容器排查
kubectl debug <pod> --image=busybox --target=<container>  # 临时调试容器

常见故障与原因：

状态原因
Pending资源不足、PVC 没绑、节点亲和无匹配、污点不容忍
ImagePullBackOff镜像不存在、仓库认证失败、网络不通
CrashLoopBackOff应用启动失败、配置错误、探针失败
OOMKilled内存超 limit
Evicted节点压力驱逐（内存/磁盘）
Terminating 卡住finalizer 没清、存储卸载失败

7.3 节点问题诊断

# 节点 NotReady
systemctl status kubelet
journalctl -u kubelet -f
# 常见：证书过期、containerd 挂、磁盘满、网络插件异常

# 节点压力
kubectl describe node <node> | grep -A5 Conditions
# MemoryPressure / DiskPressure / PIDPressure

7.4 核心指标（配合 ARMS Prometheus）

  • apiserver QPS/延迟/错误率
  • etcd WAL sync duration、leader changes、DB size
  • scheduler e2e latency
  • kubelet PLEG duration（Pod 生命周期事件处理，>1s 告警）

八、Istio 服务网格

8.1 为什么用 Istio

  • 跨语言统一治理（Java/Go/Python 各自 SDK 维护成本高）
  • 流量管理：金丝雀、流量镜像、故障注入
  • 安全：mTLS 自动化
  • 可观测：自动埋点（但成本不低）

8.2 组件

  • istiod：控制面（原 Pilot + Citadel + Galley 合并）
  • Envoy Sidecar：数据面代理，拦截 Pod 流量
  • Gateway / VirtualService / DestinationRule：流量规则三件套

8.3 阿里云 ASM（服务网格）

  • 托管 Istio 控制面
  • 跨集群/跨 Region 统一网格
  • 与 ACK 深度集成

8.4 落地陷阱

  • 性能损耗：Envoy Sidecar 每调用多 1-2ms，P99 放大
  • 内存开销：Sidecar 几百 MB/Pod
  • 学习曲线陡：YAML 门槛高，开发不爱用
  • 建议：先在无状态微服务落地，避免把 DB/中间件 Pod 注入

8.5 替代：Dubbo + MSE / 应用级治理

  • 如果业务全 Java + Dubbo/Spring Cloud，MSE（微服务引擎）托管注册中心 + 配置 + 网关，成本更低

九、Serverless 与 ASK

9.1 ECI（弹性容器实例）

  • Pod 级 Serverless，秒级启动
  • 无节点管理，按 vCPU/GB/秒 计费
  • 不支持 DaemonSet、hostNetwork

9.2 ASK / ACK 虚节点模式

  • ASK：纯 Serverless 集群，无 Node
  • ACK + 虚节点：混合模式，部分工作负载跑 ECI，部分跑 ECS
  • KEDA + 虚节点：事件弹性的黄金组合

典型场景：

  • CI/CD 构建任务（Job）
  • 大促扩容兜底（超出节点池容量自动上 ECI）
  • Spark/Flink 临时任务

十、GitOps 与多集群

10.1 GitOps 工具链

  • ArgoCD：主流，多集群、ApplicationSet
  • Flux：CNCF 毕业，Helm/Kustomize 支持好
  • 原则：Git 是唯一事实来源，集群状态与 Git 持续对账

10.2 多集群方案

  • Karmada（CNCF，华为/阿里）：跨集群调度、联邦 API
  • ACK One：阿里云多集群管理平台，跨云/跨 Region 统一视角
  • Cluster API：声明式集群生命周期管理

十一、生产运维最佳实践

11.1 集群升级

  • 测试集群先行（至少预发一轮）
  • 先升控制面，再滚动升级节点池
  • 每次跨 1 个 Minor 版本（1.24 → 1.25，不要跳）
  • API 废弃检查：kubectl api-resources + pluto/kubent 工具扫描废弃 API
  • 关键应用打 PDB，升级期间不全挂

11.2 etcd 维护

  • 不要把 etcd 塞太大：> 8GB 开始有性能问题
  • 定期 defrag（ACK 托管自动）
  • 备份：托管版自动；自建必须定时 snapshot

11.3 镜像仓库（ACR）

  • 企业版：多地域复制、镜像签名、P2P 分发（海量节点加速）
  • 预热：大促前推镜像 + Preheater 预拉到节点
  • 扫描：集成漏洞扫描
  • 不可变：生产镜像 tag 禁止覆盖，用 digest 引用

11.4 权限治理

  • RAM 用户 + RBAC：禁止 root kubeconfig 下发
  • 命名空间隔离：业务 ns + ResourceQuota + LimitRange
  • OPA / Kyverno 策略引擎：禁止 hostNetwork、必须有 requests 等

十二、面试高频问答

Q1：一个 Pod 从 kubectl apply 到 Running 的完整流程？ A：见本文 1.3 节，能流利画出图是加分项。

Q2：Pod 一直 Pending 怎么排查？ A：

kubectl describe pod <pod>  # Events 最关键

依次排查：

  1. 资源不足（CPU/内存/GPU），看 FailedScheduling 事件
  2. PVC 未绑定
  3. 节点污点不容忍
  4. nodeSelector/affinity 无匹配
  5. PodTopologySpread 硬约束不满足
  6. CA 是否扩容失败（查 CA 日志）

Q3：Service 如何实现负载均衡？kube-proxy 的 iptables 和 IPVS 有什么区别？ A：见 4.3 节。补充：Service VIP 不可 ping 通，因为它只是 iptables/ipvs 规则的目标，不绑定到任何实体接口。

Q4：Deployment 滚动更新的参数？优雅下线怎么做？ A：

  • strategy.rollingUpdate.maxSurge / maxUnavailable
  • 优雅下线：
    1. terminationGracePeriodSeconds（默认 30s，Java 应用调大）
    2. preStop hook：sleep 10 等待 Endpoint 同步
    3. 应用收到 SIGTERM 后停止接新请求、处理完在途请求
    4. 配合 readiness 探针摘流
  • 坑：Pod 被 Terminating 时，Endpoint 摘除是异步的，前 ~5s 可能还有流量进来，所以 preStop sleep 是必须的

Q5：一个节点 NotReady 怎么处理？ A：

  1. 不要直接删 Pod，用 kubectl cordon 禁止新 Pod 调度
  2. kubectl drain <node> --ignore-daemonsets --delete-emptydir-data 排水
  3. 登录节点：kubelet/containerd/系统日志排查
  4. 常见原因：证书过期、磁盘满、OOM、网络、内核 bug
  5. 修复后 uncordon 回来，或直接换节点

Q6：HPA 基于自定义指标（如 QPS）怎么实现？ A：

  • 指标采集：Prometheus → prometheus-adapter → Custom Metrics API
  • HPA 引用：
metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 1000

Q7：Ingress 和 Service LoadBalancer 的区别？ A：

  • Service LB：4 层，每暴露一个服务就一个 SLB，成本高
  • Ingress：7 层，一个 SLB 后面复用多域名/路径路由
  • ALB Ingress：阿里云 ALB 直接做 Ingress 控制器，减少一跳 Nginx

Q8：etcd 为什么是瓶颈？怎么优化？ A：

  • 写放大：每次写走 Raft + fsync
  • 优化：
    • 专用 SSD
    • 限制大对象（单 key < 1MB）
    • 减少 watch 数量（CRD 爆炸的集群常见问题）
    • 定期 defrag
    • 拆分：events 单独 etcd 集群

Q9：K8s 网络 Pod 跨节点通信原理？ A（以 Terway ENI 模式为例）：

  • Pod IP 属于 VPC
  • 跨节点：走 VPC 路由（就是云 VPC 内部路由），不需要 Overlay
  • Flannel VXLAN 则封装一层 UDP 到对端节点解包

Q10：Istio 会带来什么问题？不用 Istio 怎么做灰度发布？ A：见 8.4。替代方案：

  • Nginx/ALB Ingress 的 Canary Annotation（按权重、Header、Cookie 分流）
  • 应用框架层（Spring Cloud / Dubbo）做元数据标签路由
  • MSE 云原生网关的金丝雀能力

十三、必看资源

  • Kubernetes 官方文档 kubernetes.io/docs
  • ACK 官方文档 help.aliyun.com/product/85222.html
  • 《Kubernetes in Action》Marko Luksa
  • 《Programming Kubernetes》Operator 模式
  • CNCF Landscape landscape.cncf.io
  • 阿里云 ACK 团队博客 / 知乎专栏
avatar
文章
阅读
粉丝