第十部分：面试题库与进阶路径

核心原理：

• vruntime = 实际运行时间 × 1024 / 进程权重
• 权重由 nice 值决定：weight = 1024 / (1.25 ^ nice)
• CFS 总是选择 vruntime 最小的进程运行
• 保证所有进程获得公平的 CPU 时间

示例：

# 进程A: nice=0, weight=1024
# 运行1ms后 vruntime = 1 × 1024 / 1024 = 1ms

# 进程B: nice=5, weight=335
# 运行1ms后 vruntime = 1 × 1024 / 335 = 3.06ms

面试加分点：

• 提到红黑树数据结构
• 提到 NUMA-aware 调度
• 提到 CPU throttling 问题

组件：

• G (Goroutine): 用户态协程
• M (Machine): 系统线程
• P (Processor): 逻辑处理器，数量 = GOMAXPROCS

调度流程：

1. 每个 M 必须绑定一个 P 才能执行 G
2. P 维护本地队列（最多256个G）
3. 全局队列作为后备
4. Work Stealing：空闲的 P 会从其他 P 偷取 G

关键优化：

• 避免频繁的系统调用切换
• 本地队列减少锁竞争
• 网络 I/O 使用 netpoller（epoll）

面试加分点：

• 提到系统调用时的 M 切换
• 提到 sysmon 监控线程
• 提到 spinning thread 机制

多级页表：

• x86_64: 4级页表（PGD → PUD → PMD → PTE）
• 页大小：默认 4KB，支持大页（2MB/1GB）

缺页中断处理：

1. 访问未映射的虚拟地址
2. CPU 触发 Page Fault
3. 内核分配物理页
4. 建立页表映射
5. 返回用户空间继续执行

内存分配路径：

malloc()
  → glibc ptmalloc
    → brk() [小于128KB]
    → mmap() [大于128KB]
      → 内核 buddy 系统
        → 物理页分配

面试加分点：

• TLB（Translation Lookaside Buffer）
• Copy-on-Write 机制
• Transparent Huge Pages（THP）

选择算法：

oom_score = (RSS + Swap) / 总内存 × 1000 + oom_score_adj

关键因素：

1. 内存使用量（RSS + Swap）
2. oom_score_adj 调整值（-1000 到 1000）
3. 特权进程（root）有轻微保护

查看和调整：

# 查看 OOM 分数
cat /proc/<pid>/oom_score

# 调整分数（需要 root）
echo -500 > /proc/<pid>/oom_score_adj

Kubernetes 中的应用：

• Guaranteed: oom_score_adj = -997
• Burstable: oom_score_adj = min(max(2, 1000 - memory_request/memory_limit × 1000), 999)
• BestEffort: oom_score_adj = 1000

面试加分点：

• 容器级 OOM vs 系统级 OOM
• cgroup memory.oom_control
• oom_kill_allocating_task 参数

接收路径：

网卡 → DMA → Ring Buffer → 硬中断 → 软中断（NET_RX_SOFTIRQ）
  → netif_receive_skb() → IP 层 → TCP 层 → Socket Buffer
  → 用户空间 recv()

发送路径：

用户空间 send() → Socket Buffer → TCP 层 → IP 层
  → 路由选择 → Netfilter（iptables） → 网卡驱动
  → DMA → 网卡发送

关键数据结构：

• sk_buff：网络数据包结构
• net_device：网络设备
• socket：套接字

面试加分点：

• GRO（Generic Receive Offload）
• TSO（TCP Segmentation Offload）
• XDP（eXpress Data Path）

5张表（优先级）：

1. raw：连接跟踪前
2. mangle：修改报文
3. nat：地址转换
4. filter：过滤
5. security：SELinux

5条链：

• PREROUTING：路由前
• INPUT：本地接收
• FORWARD：转发
• OUTPUT：本地发出
• POSTROUTING：路由后

数据包流向：

入站：
  PREROUTING (raw → mangle → nat)
  → 路由决策
  → INPUT (mangle → filter)
  → 本地进程

转发：
  PREROUTING (raw → mangle → nat)
  → 路由决策
  → FORWARD (mangle → filter)
  → POSTROUTING (mangle → nat)

出站：
  OUTPUT (raw → mangle → nat → filter)
  → 路由决策
  → POSTROUTING (mangle → nat)

面试加分点：

• conntrack 状态（NEW/ESTABLISHED/RELATED）
• SNAT vs DNAT
• iptables vs nftables

核心组件：

1. kube-apiserver

   • 唯一与 etcd 交互的组件
   • 提供 RESTful API
   • 认证、授权、准入控制
   • 所有组件通信的枢纽

2. etcd

   • 分布式键值存储
   • 存储集群所有数据
   • 使用 Raft 协议保证一致性

3. kube-scheduler

   • 监听未调度的 Pod
   • Filter/Score/Bind 三阶段
   • 将 Pod 分配到合适的节点

4. kube-controller-manager

   • Node Controller：节点健康检查
   • Deployment Controller：副本管理
   • Service Controller：Endpoint 管理
   • 等 40+ 控制器

5. cloud-controller-manager

   • 与云平台交互
   • LoadBalancer 创建
   • Volume 挂载
   • Node 生命周期管理

面试加分点：

• Leader Election 机制
• Watch 机制原理
• Informer/Reflector 架构

详细流程：

1. 用户提交

   kubectl create -f pod.yaml
   

2. API Server 处理

   • 认证（Authentication）
   • 授权（Authorization）
   • 准入控制（Admission Control）
   • 写入 etcd

3. Scheduler 调度

   • Watch 到未调度 Pod
   • Filter：过滤不符合条件的节点
   • Score：给节点打分
   • Bind：绑定到最优节点

4. Kubelet 创建

   • Watch 到分配给自己的 Pod
   • 调用 CRI 创建容器
     • 创建 Sandbox（Pause 容器）
     • 创建业务容器
   • 调用 CNI 配置网络
   • 调用 CSI 挂载存储

5. 状态更新

   • Kubelet 持续上报状态
   • API Server 更新 etcd

时间线：

0s    - kubectl 提交
0.1s  - API Server 验证并存储
0.2s  - Scheduler 调度完成
0.3s  - Kubelet 开始创建
2s    - 镜像拉取（缓存命中时更快）
3s    - 容器启动
5s    - 健康检查通过
5.5s  - Pod Ready

面试加分点：

• InitContainer 执行时机
• Static Pod 的特殊性
• Pod Preemption 抢占机制

三大要求：

1. Pod 间直接通信

   • 任意两个 Pod 可以直接通过 IP 通信
   • 不需要 NAT
   • 跨节点也可以

2. Pod 与 Node 通信

   • Node 可以直接访问 Pod IP
   • Pod 可以直接访问 Node IP
   • 双向透明

3. Pod 看到的自己的 IP = 其他 Pod 看到的 IP

   • 不存在 IP 伪装
   • 避免端口冲突问题

实现方式：

• Overlay 网络（Flannel VXLAN）
• 路由方式（Calico BGP）
• Underlay 网络（Macvlan）

面试加分点：

• Service 的 ClusterIP 虚拟性
• Pod CIDR 与 Service CIDR 分配
• 网络策略的实现原理

工作流程：

1. Service 创建

   apiVersion: v1
   kind: Service
   metadata:
     name: web
   spec:
     clusterIP: 10.96.1.100
     ports:
     - port: 80
     selector:
       app: web
   

2. kube-proxy 生成 iptables 规则

   # DNAT 规则
   -A KUBE-SERVICES -d 10.96.1.100/32 -p tcp -m tcp --dport 80 \
     -j KUBE-SVC-XXXXX
   
   # 负载均衡规则（假设2个后端）
   -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.5 \
     -j KUBE-SEP-AAAA
   -A KUBE-SVC-XXXXX -j KUBE-SEP-BBBB
   
   # 后端 Pod 规则
   -A KUBE-SEP-AAAA -p tcp -m tcp \
     -j DNAT --to-destination 10.244.1.10:80
   -A KUBE-SEP-BBBB -p tcp -m tcp \
     -j DNAT --to-destination 10.244.2.20:80
   

3. 数据包流向

   客户端 → ClusterIP:80
     → iptables DNAT
     → 随机选择后端 Pod IP
     → Pod 处理请求
     → 响应原路返回（SNAT）
   

性能问题：

• 规则数量：O(Services × Endpoints)
• 更新时延：全量刷新
• 连接不平衡：概率负载均衡

IPVS 模式优势：

• 规则数量：O(Services + Endpoints)
• 更新增量式
• 负载均衡算法丰富（rr/lc/dh等）

面试加分点：

• Cilium eBPF 模式的革新
• SessionAffinity 的实现
• ExternalTrafficPolicy 的影响

三者关系：

PVC (用户需求)
  ↓ 匹配
PV (存储资源) ← 动态创建 ← StorageClass (存储模板)

静态供应流程：

1. 管理员手动创建 PV
2. 用户创建 PVC
3. 控制器自动绑定（根据容量、AccessMode、Label 匹配）
4. Pod 使用 PVC

动态供应流程：

1. 管理员创建 StorageClass
2. 用户创建 PVC（指定 storageClassName）
3. Provisioner 自动创建 PV
4. 自动绑定
5. Pod 使用 PVC

示例：

# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  iops: "3000"

---
# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

面试加分点：

• Reclaim Policy（Retain/Delete/Recycle）
• Volume Expansion 扩容
• CSI Driver 架构

排查步骤：

1. 查看 Pod 详情

   kubectl describe pod <pod-name>
   

2. 常见原因及解决方案：

原因1：资源不足

Events:
  Warning  FailedScheduling  pod has unbound immediate PersistentVolumeClaims

解决：

# 检查节点资源
kubectl top nodes
kubectl describe nodes

# 增加节点或降低资源请求

原因2：PVC 未绑定

Events:
  Warning  FailedScheduling  pod has unbound PersistentVolumeClaims

解决：

# 检查 PVC 状态
kubectl get pvc

# 检查 PV 是否可用
kubectl get pv

# 检查 StorageClass
kubectl get sc

原因3：节点亲和性不满足

Events:
  Warning  FailedScheduling  0/3 nodes are available: 3 node(s) didn't match node selector

解决：

# 检查节点标签
kubectl get nodes --show-labels

# 检查 Pod 的 nodeSelector/nodeAffinity
kubectl get pod <pod> -o yaml | grep -A10 nodeSelector

原因4：污点与容忍

Events:
  Warning  FailedScheduling  0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate

解决：

# 检查节点污点
kubectl describe nodes | grep Taints

# 添加容忍或移除污点
kubectl taint nodes <node> key=value:NoSchedule-

面试加分点：

• 提到 Scheduler 的 Filter 阶段
• 提到 Pod Priority 和 Preemption
• 能够快速定位问题根因

分析流程：

1. 确认 OOM 事件

   # 查看 Pod 事件
   kubectl describe pod <pod>
   
   # 查看容器退出码
   kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated}'
   
   # 退出码 137 = OOMKilled
   

2. 区分 OOM 类型

容器级 OOM（cgroup）：

# 查看内存限制
kubectl get pod <pod> -o yaml | grep -A5 resources

# 查看实际使用
kubectl top pod <pod>

节点级 OOM（系统）：

# 查看系统日志
dmesg | grep -i oom
journalctl -k | grep -i oom

# 查看节点内存
kubectl top nodes

3. 根因分析

原因1：内存泄漏

# 启用 pprof
kubectl port-forward <pod> 6060:6060

# 收集内存 profile
curl http://localhost:6060/debug/pprof/heap > heap.prof

# 分析
go tool pprof heap.prof

原因2：limits 设置过小

# 对比 requests 和 limits
kubectl get pod <pod> -o jsonpath='{.spec.containers[0].resources}'

# 查看历史使用峰值（需要监控系统）

原因3：突发流量

# 查看 QPS 趋势
# 检查是否有流量突增

4. 解决方案

临时方案：

# 增加 memory limits
kubectl set resources deployment <name> -c=<container> --limits=memory=2Gi

长期方案：

# 1. 修复内存泄漏（代码层面）
# 2. 合理设置资源
resources:
  requests:
    memory: 1Gi
  limits:
    memory: 2Gi  # limits = requests × 1.5~2

# 3. 启用 VPA 自动调整
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"

面试加分点：

• 提到 memory.oom_control
• 提到 oom_score_adj 优先级
• 提到监控告警的重要性

排查流程：

第1层：Pod 状态

# 检查 Pod 是否 Ready
kubectl get pods -o wide

# 检查 IP 是否分配
kubectl describe pod <pod> | grep IP

第2层：Pod 间连通性

# 测试 Pod IP 直连
kubectl exec <pod-a> -- ping <pod-b-ip>

# 如果不通：
# 1. 检查 CNI
kubectl get pods -n kube-system | grep -E 'calico|flannel|cilium'

# 2. 检查路由
kubectl exec <pod> -- ip route show

# 3. 检查 NetworkPolicy
kubectl get networkpolicy
kubectl describe networkpolicy <policy>

第3层：Service 访问

# 测试 Service
kubectl exec <pod> -- curl http://<service-name>

# 如果不通：
# 1. 检查 Service
kubectl get svc <service>
kubectl describe svc <service>

# 2. 检查 Endpoints
kubectl get endpoints <service>

# 3. 检查 kube-proxy
kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system <kube-proxy-pod>

第4层：DNS 解析

# 测试 DNS
kubectl exec <pod> -- nslookup kubernetes.default

# 如果失败：
# 1. 检查 CoreDNS
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system <coredns-pod>

# 2. 检查 DNS 配置
kubectl exec <pod> -- cat /etc/resolv.conf

第5层：外部访问

# 测试 Ingress
curl http://<ingress-host>

# 如果失败：
# 1. 检查 Ingress Controller
kubectl get pods -n ingress-nginx

# 2. 检查 Ingress 规则
kubectl get ingress
kubectl describe ingress <ingress>

# 3. 检查证书（HTTPS）
kubectl get secret <tls-secret>

高级排查：

# 抓包分析
kubectl exec <pod> -- tcpdump -i any -w /tmp/capture.pcap port 80

# 查看 iptables 规则
kubectl exec <pod> -- iptables-save | grep <service-name>

# 查看 conntrack 表
kubectl exec <pod> -- conntrack -L | grep <ip>

面试加分点：

• 分层排查思路清晰
• 了解每层的关键组件
• 能使用工具定位问题

整体架构：

                       ┌─────────────┐
Internet ──────────────►│   CDN       │
                       └──────┬──────┘
                              │
                       ┌────────────┐
                       │  WAF/DDoS   │
                       └──────┬──────┘
                              │
                       ┌─────────────┐
                       │  LoadBalancer│
                       │  (Layer 4)   │
                       └──────┬───────┘
                              │
              ┌───────────────┴───────────────┐
              │                               │
       ┌────────────┐               ┌─────────────┐
       │ Ingress     │               │  Ingress     │
       │ (NGINX)     │               │  (NGINX)     │
       └──────┬──────┘               └───────┬──────┘
              │                              │
    ┌─────────┴─────────────────────────────┴──────┐
    │                                                │
┌───────┐  ┌────────┐  ┌─────────┐  ┌──────────┐ │
│API GW  │  │  Auth  │  │Business │  │  Worker  │ │
│(50 pod)│  │(20 pod)│  │(100 pod)│  │ (30 pod) │ │
└───┬────┘  └────┬───┘  └────┬────┘  └─────┬────┘ │
    │            │           │              │      │
    └────────────┴───────────┴──────────────┘      │
                      │                             │
              ┌───────────────┐                    │
              │   Redis        │                    │
              │   (Cluster)    │                    │
              └───────┬────────┘                    │
                      │                             │
              ┌───────────────┐                    │
              │   MySQL        │                    │
              │   (Master+     │                    │
              │    Slaves)     │                    │
              └────────────────┘                    │

关键技术点：

1. 接入层

# Ingress 配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "1000"  # 限流
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-gateway
            port:
              number: 80

2. API Gateway 层

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 50
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
      containers:
      - name: gateway
        image: api-gateway:v1
        resources:
          requests:
            cpu: 2
            memory: 2Gi
        env:
        - name: GOMAXPROCS
          value: "2"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 50
  maxReplicas: 200
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

3. 缓存层

# Redis Cluster
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  replicas: 6  # 3 master + 3 slave
  template:
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        resources:
          requests:
            cpu: 2
            memory: 4Gi
          limits:
            memory: 4Gi
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: fast-ssd
      resources:
        requests:
          storage: 50Gi

4. 数据库层

# MySQL Master-Slave (使用 Operator)
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
  name: my-cluster
spec:
  replicas: 3  # 1 master + 2 slaves
  secretName: mysql-secret
  volumeSpec:
    persistentVolumeClaim:
      storageClassName: fast-ssd
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 500Gi
  podSpec:
    resources:
      requests:
        cpu: 4
        memory: 16Gi
      limits:
        memory: 16Gi

性能优化点：

1. 连接池：合理配置数据库连接池（max=100）
2. 缓存：热点数据缓存命中率 > 95%
3. 异步处理：消息队列解耦（Kafka/RabbitMQ）
4. 读写分离：MySQL Proxy 实现
5. 分库分表：Sharding-JDBC

容量规划：

• 单 Pod QPS: 200
• 需要 Pod 数: 100000 / 200 = 500 个
• 考虑冗余: 500 × 1.5 = 750 个
• 节点数（8C16G）: 750 / 10 = 75 个节点

面试加分点：

• 提到限流、降级、熔断
• 提到链路追踪（Jaeger）
• 提到灰度发布策略