在云原生环境中部署大数据平台，使用Kubernetes管理容器，如何优化资源调度和故障恢复？请举例说明。

1) 【一句话结论】

在Kubernetes中，通过合理配置资源请求与限制（控制资源分配）、设置Pod优先级与抢占（优化调度优先级）、部署健康检查（liveness/readiness）实现自愈、以及配置PodDisruptionBudget（保障高可用）等机制，可有效优化资源调度效率与故障恢复能力，确保大数据平台在云原生环境下的稳定运行。

2) 【原理/概念讲解】

老师解释：

• 资源请求（Requests）与限制（Limits）：每个容器需声明资源请求（如CPU 100m、内存256Mi），调度时确保节点有足够资源；限制是容器最大资源使用量，防止资源耗尽。类比：预订餐厅座位（请求）和座位最大容量（限制），避免超载。
• Pod优先级与抢占（Priority & Preemption）：为关键任务（如数据同步）设置高优先级（如1000），调度器优先分配资源；低优先级（如500）在资源紧张时被抢占。
• 健康检查（Liveness/Readiness）：liveness检查容器是否存活（失败则重启），readiness检查容器是否准备好服务（未就绪则不加入服务）。比如，大数据处理任务，liveness检查CPU使用率是否过高，readiness检查输出是否正确。
• 自愈机制（RestartPolicy）：默认Always，容器失败自动重启，结合健康检查确保故障后快速恢复。
• PodDisruptionBudget（PDB）：限制Pod被驱逐的数量，保障高可用。比如，大数据平台中，至少保持3个副本，PDB设置maxUnavailable=1，确保至少2个副本运行。

3) 【对比与适用场景】

概念	定义	特性	使用场景	注意点
资源请求（Requests）	容器声明所需的最小资源	调度时必须满足	确保Pod被调度到有足够资源的节点	过低会导致调度失败
资源限制（Limits）	容器可使用的最大资源	防止资源耗尽，触发OOMKILL	限制容器资源使用上限	过高可能导致资源浪费
Liveness探针	检查容器是否存活	失败则重启容器	防止容器僵死	频率不宜过高
Readiness探针	检查容器是否准备好服务	未准备好的Pod不加入服务	确保服务可用性	频率不宜过高

4) 【示例】

假设部署一个大数据处理Pod，配置资源请求/限制、健康检查及PDB：

apiVersion: v1
kind: Pod
metadata:
  name: bigdata-pod
spec:
  containers:
  - name: bigdata-container
    image: bigdata-image:1.0
    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "1Gi"
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
  restartPolicy: Always
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bigdata-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: bigdata
  template:
    metadata:
      labels:
        app: bigdata
    spec:
      containers:
      - name: bigdata-container
        image: bigdata-image:1.0
        resources:
          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: bigdata-service
spec:
  selector:
    app: bigdata
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: bigdata-pdb
spec:
  selector:
    matchLabels:
      app: bigdata
  minAvailable: 2

解释：Deployment有3个副本，每个Pod的容器设置了资源请求（100m CPU、256Mi内存）和限制（500m CPU、1Gi内存），通过liveness和readiness探针确保容器健康，PodDisruptionBudget保证至少2个副本运行，实现故障自愈。

5) 【面试口播版答案】

在云原生环境中部署大数据平台，优化资源调度和故障恢复的关键在于合理配置资源配额、健康检查和自愈机制。具体来说，通过为每个容器设置资源请求（确保调度时获得足够资源）和限制（防止资源耗尽），可以优化资源调度效率；利用Pod优先级与抢占机制，为关键任务（如数据同步）设置高优先级，确保资源优先分配；部署liveness和readiness健康检查，当容器异常时自动重启或从服务中移除，实现自愈；同时配置PodDisruptionBudget，限制Pod被驱逐的数量，保障高可用。例如，为大数据处理Pod设置资源请求和限制，结合健康检查，当节点故障时，Pod自动重启并重新加入服务，确保平台稳定运行。

6) 【追问清单】

• 问：资源请求和限制的具体配置原则是什么？比如如何根据实际负载估算？
  回答要点：资源请求应基于任务最小资源需求，限制为最大资源使用量，通常请求是限制的1/2-2/3，避免资源浪费或耗尽。
• 问：健康检查的liveness和readiness探针有什么区别？为什么都需要？
  回答要点：liveness检查容器是否存活（失败则重启），readiness检查容器是否准备好服务（未就绪则不加入服务），避免服务暴露未就绪的容器。
• 问：PodDisruptionBudget如何设置？比如副本数和maxUnavailable的关系？
  回答要点：minAvailable设置为至少保留的副本数，maxUnavailable为允许被驱逐的副本数，例如3个副本时，maxUnavailable设为1，确保至少2个副本运行。
• 问：如果节点资源不足，低优先级Pod会被抢占，如何避免关键任务被误抢占？
  回答要点：为关键任务设置高优先级（如1000），低优先级（如500），资源紧张时低优先级Pod被抢占，高优先级保留资源。
• 问：自愈机制中，restartPolicy的Always和OnFailure有什么区别？
  回答要点：Always表示容器失败自动重启；OnFailure表示只有非0退出码时才重启，可能用于需要手动干预的故障。

7) 【常见坑/雷区】

• 资源请求设置过高：导致Pod无法被调度，因为节点资源不足。
• 健康检查配置错误：比如liveness探针频率过高，频繁触发重启；或readiness探针未正确检查服务就绪状态，导致服务不可用。
• PodDisruptionBudget设置不当：minAvailable设置过小，导致高可用性不足；或maxUnavailable设置过大，无法有效保护Pod。
• 优先级设置错误：关键任务优先级低于低优先级任务，导致资源分配不合理。
• 忽略资源限制：容器超出限制导致OOMKILL，影响其他容器或系统稳定性。