第九部分算力平台与综合实战

本部分结合职位要求中的"算力平台运行环境保障"和"AI Agent 平台运维"，讲解算力平台架构、Agent 任务调度、资源池管理，并通过综合项目实战巩固所学知识。

第 33 章算力平台架构

33.1 什么是算力平台

算力平台是提供计算资源（CPU、GPU、内存）的统一平台，支持运行各种计算任务，如：

AI 模型训练
模型推理服务
大数据处理
Agent 任务执行
批量计算任务

33.2 算力平台典型架构

┌─────────────────────────────────────────────────────────────┐
│                       任务调度层                             │
│              （Kubernetes + 自定义调度器/队列）               │
├─────────────────────────────────────────────────────────────┤
│                       资源管理层                             │
│         （CPU 池 / 内存池 / GPU 池 /  spot 实例池）           │
├─────────────────────────────────────────────────────────────┤
│                       容器运行层                             │
│                  （Kubernetes + CRI）                        │
├─────────────────────────────────────────────────────────────┤
│                       基础设施层                             │
│           （公有云 / 私有云 / 裸金属 / 混合云）               │
└─────────────────────────────────────────────────────────────┘

33.3 Agent 任务特点

大量并发：可能有成千上万个 Agent 同时运行
生命周期短：任务快速启动和结束
资源需求多样：有的需要大量 CPU，有的需要大量内存
失败可重试：任务通常支持重试
优先级不同：有实时任务和离线任务

33.4 资源池类型

资源池	特点	适用任务
CPU 型	高 CPU、普通内存	计算密集型
内存型	大内存	数据缓存、分析
GPU 型	高性能显卡	AI 训练/推理
Spot 型	成本低但可能被回收	可中断的离线任务

33.5 K8s 中的资源池实现

通过节点标签（Label）和节点选择器（Node Selector）实现：

yaml

# 给节点打标签
kubectl label node node-1 workload-type=cpu-intensive
kubectl label node node-2 workload-type=memory-intensive

# Pod 选择特定资源池
spec:
  nodeSelector:
    workload-type: cpu-intensive

33.6 本章练习

画一个你理解的算力平台架构图。
列出 Agent 任务的 3 个特点和对应的运维挑战。
使用 Node Label 和 Pod 的 nodeSelector 将 Pod 调度到指定节点。

第 34 章 Agent 任务调度与资源池管理

34.1 任务调度挑战

大量短生命周期任务导致调度压力大
资源碎片化
任务优先级和抢占
公平调度（多租户）
失败重试和幂等性

34.2 常用调度策略

基于节点的调度

yaml

spec:
  nodeSelector:
    workload-type: cpu
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "agent"
    effect: "NoSchedule"

亲和性和反亲和性

yaml

# Pod 亲和性：尽量和某些 Pod 运行在一起
spec:
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - cache
          topologyKey: kubernetes.io/hostname

# Pod 反亲和性：避免同类型 Pod 在同一节点
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - agent-worker
          topologyKey: kubernetes.io/hostname

34.3 优先级和抢占

yaml

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "High priority for critical agent tasks"

yaml

spec:
  priorityClassName: high-priority

34.4 任务队列设计

常见任务队列组件：

组件	特点
Redis	轻量，适合简单队列
RabbitMQ	功能丰富
Kafka	高吞吐，适合大量任务
Argo Workflows	K8s 原生工作流引擎
Airflow	复杂 DAG 调度

34.5 Argo Workflows 简介

Argo Workflows 是 K8s 原生工作流引擎，适合批量任务调度。

yaml

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: agent-task-
spec:
  entrypoint: main
  templates:
  - name: main
    steps:
    - - name: process
        template: process-task
        withItems:
        - task1
        - task2
        - task3
  - name: process-task
    inputs:
      parameters:
      - name: task
    container:
      image: agent-processor:latest
      command: [python, process.py]
      args: ["{{inputs.parameters.task}}"]
      resources:
        requests:
          cpu: "500m"
          memory: "1Gi"

34.6 资源不足处理

当资源不足时：

任务进入队列等待
触发 Cluster Autoscaler 扩容
低优先级任务被抢占
任务设置超时和重试
监控排队时间告警

34.7 本章实验

实验 34-1：创建资源池和任务调度

bash

# 1. 创建不同资源池标签
kubectl label node minikube workload-type=cpu-intensive

# 2. 创建 CPU 型任务
kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: cpu-task
spec:
  template:
    spec:
      nodeSelector:
        workload-type: cpu-intensive
      containers:
      - name: worker
        image: busybox:1.36
        command: ["sh", "-c", "echo 'CPU task running'; sleep 30"]
        resources:
          requests:
            cpu: "500m"
            memory: "256Mi"
      restartPolicy: Never
EOF

# 3. 查看调度结果
kubectl get pods -o wide

34.8 本章练习

为集群节点添加不同资源池标签。
创建使用 nodeSelector 和 toleration 的任务。
安装 Argo Workflows，运行一个简单工作流。
设计一个任务排队和重试策略。

第 35 章综合运维项目实战

35.1 项目背景

假设你是一家 AI 公司的 K8s 运维工程师，公司有一个算力平台，运行大量 Agent 任务。你需要：

搭建一个 K8s 集群
部署一个 Web 应用
配置监控告警
配置日志收集
编写自动化脚本
建立故障响应机制

35.2 项目步骤

步骤 1：搭建 K8s 集群

bash

# 使用 minikube 或 kind
minikube start --driver=docker --nodes=3 --cpus=2 --memory=4096

# 或者使用 kubeadm 手动部署

步骤 2：部署应用

bash

# 创建命名空间
kubectl create namespace ai-platform

# 部署应用
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-api
  namespace: ai-platform
spec:
  replicas: 3
  selector:
    matchLabels:
      app: agent-api
  template:
    metadata:
      labels:
        app: agent-api
    spec:
      containers:
      - name: api
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"
EOF

# 暴露服务
kubectl expose deployment agent-api -n ai-platform --port=80 --type=ClusterIP

步骤 3：配置监控

bash

# 部署 Prometheus + Grafana
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

# 创建应用监控规则
kubectl apply -f - <<EOF
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: agent-api
  namespace: monitoring
  labels:
    release: prometheus
spec:
  namespaceSelector:
    matchNames:
    - ai-platform
  selector:
    matchLabels:
      app: agent-api
  endpoints:
  - port: 80
    interval: 15s
EOF

步骤 4：配置日志

bash

# 部署 Loki
helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true

# 在 Grafana 中添加 Loki 数据源

步骤 5：编写自动化脚本

bash

#!/bin/bash
# ai-platform-health-check.sh

NAMESPACE="ai-platform"
REPORT="/tmp/ai-platform-report-$(date +%Y%m%d-%H%M%S).log"

echo "===== AI 平台健康检查 $(date) =====" | tee -a "$REPORT"

echo "--- 应用 Pod 状态 ---" | tee -a "$REPORT"
kubectl get pods -n "$NAMESPACE" -o wide | tee -a "$REPORT"

echo "--- 服务状态 ---" | tee -a "$REPORT"
kubectl get svc -n "$NAMESPACE" | tee -a "$REPORT"

echo "--- 资源使用 ---" | tee -a "$REPORT"
kubectl top pods -n "$NAMESPACE" | tee -a "$REPORT"

echo "--- 异常事件 ---" | tee -a "$REPORT"
kubectl get events -n "$NAMESPACE" --field-selector type=Warning | tail -20 | tee -a "$REPORT"

echo "报告保存到: $REPORT"

步骤 6：建立告警

yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ai-platform-alerts
  namespace: monitoring
  labels:
    release: prometheus
spec:
  groups:
  - name: ai-platform
    rules:
    - alert: AgentAPIDown
      expr: up{namespace="ai-platform"} == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Agent API is down"

35.3 项目检查点

[ ] K8s 集群正常运行
[ ] 应用 Pod 3 副本运行正常
[ ] Service 可访问
[ ] Prometheus 能采集指标
[ ] Grafana 能看到仪表盘
[ ] Loki 能查询日志
[ ] 告警规则生效
[ ] 健康检查脚本可运行

35.4 本章练习

独立完成上述综合项目。
为应用添加 HPA。
为应用添加 Ingress。
使用 AI 工具辅助优化你的脚本和配置。

第 36 章 SRE 理念与职业发展

36.1 SRE 核心理念

SRE（Site Reliability Engineering，站点可靠性工程）是将软件工程方法应用于运维领域的实践。

核心原则：

拥抱风险：100% 可用性不现实，定义可接受的故障预算
服务水平目标（SLO）：定义服务的可靠性目标
错误预算：允许在一定时间内发生的故障量
减少琐事（Toil）：通过自动化减少重复劳动
分布式系统监控：基于用户视角的监控
自动化：一切可以自动化的都应该自动化

36.2 SLO、SLI、SLA

术语	全称	说明
SLI	Service Level Indicator	服务质量指标，如可用性、延迟
SLO	Service Level Objective	服务质量目标，如 99.9% 可用性
SLA	Service Level Agreement	服务等级协议，对用户的承诺

36.3 职业发展路径

初级运维工程师
    ↓
中级 K8s 运维工程师
    ↓
高级 K8s 运维/SRE 工程师
    ↓
运维架构师 / SRE 负责人
    ↓
技术总监 / CTO

36.4 持续学习建议

跟踪 K8s 新版本特性
学习云原生基金会（CNCF）项目
参与开源社区
考取相关认证：CKA、CKAD、CKS
培养系统思维和编程能力
学习 AI 辅助工具

36.5 推荐认证

认证	说明
CKA	Certified Kubernetes Administrator
CKAD	Certified Kubernetes Application Developer
CKS	Certified Kubernetes Security Specialist
云厂商认证	阿里云 ACE、AWS SAA 等

36.6 面试准备

面试常见问题：

K8s 架构和核心组件
Pod 生命周期和探针
Service 类型和工作原理
存储和网络
故障排查思路
监控告警设计
自动化运维经验
SRE 理念

36.7 本章练习

为你负责的服务定义 SLO 和错误预算。
列出你想要获得的 1~2 个认证，并制定学习计划。
模拟一次面试，回答 5 个 K8s 常见问题。

附录：常用命令速查

Linux

bash

# 系统
free -h, df -h, du -sh, top, htop, ps aux

# 网络
ip a, ip route, ss -tlnp, curl, nc, dig

# 日志
journalctl -u service -f, tail -f /var/log/syslog

Docker

bash

docker ps, docker images, docker logs, docker exec, docker stats
docker build -t, docker run, docker compose up -d

Kubernetes

bash

kubectl get, describe, logs, exec, apply, delete
kubectl top, kubectl rollout, kubectl scale
kubeadm certs check-expiration

监控

bash

# Prometheus 查询
rate(http_requests_total[5m])
100 - avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100

# Loki 查询
{job="kubernetes-pods"} |= "error"

第九部分总结

完成本部分学习后，你应该能够：

理解算力平台和 Agent 任务调度架构
使用 K8s 实现资源池管理
独立完成 K8s 运维综合项目
理解 SRE 理念和职业发展路径
具备面试和实际工作的能力

恭喜你完成了整本教材的学习！

运维之路没有终点，保持好奇，持续实践，善用 AI，你一定能成为一名优秀的 K8s 运维工程师。

第九部分 算力平台与综合实战 ​

第 33 章 算力平台架构 ​

33.1 什么是算力平台 ​

33.2 算力平台典型架构 ​

33.3 Agent 任务特点 ​

33.4 资源池类型 ​

33.5 K8s 中的资源池实现 ​

33.6 本章练习 ​

第 34 章 Agent 任务调度与资源池管理 ​

34.1 任务调度挑战 ​

34.2 常用调度策略 ​

基于节点的调度 ​

亲和性和反亲和性 ​

34.3 优先级和抢占 ​

34.4 任务队列设计 ​

34.5 Argo Workflows 简介 ​

34.6 资源不足处理 ​

34.7 本章实验 ​

34.8 本章练习 ​

第 35 章 综合运维项目实战 ​

35.1 项目背景 ​

35.2 项目步骤 ​

步骤 1：搭建 K8s 集群 ​

步骤 2：部署应用 ​

步骤 3：配置监控 ​

步骤 4：配置日志 ​

步骤 5：编写自动化脚本 ​

步骤 6：建立告警 ​

35.3 项目检查点 ​

35.4 本章练习 ​

第 36 章 SRE 理念与职业发展 ​

36.1 SRE 核心理念 ​

36.2 SLO、SLI、SLA ​

36.3 职业发展路径 ​

36.4 持续学习建议 ​

36.5 推荐认证 ​

36.6 面试准备 ​

36.7 本章练习 ​

附录：常用命令速查 ​

Linux ​

Docker ​

Kubernetes ​

监控 ​

第九部分总结 ​

第九部分算力平台与综合实战

第 33 章算力平台架构

33.1 什么是算力平台

33.2 算力平台典型架构

33.3 Agent 任务特点

33.4 资源池类型

33.5 K8s 中的资源池实现

33.6 本章练习

第 34 章 Agent 任务调度与资源池管理

34.1 任务调度挑战

34.2 常用调度策略

基于节点的调度

亲和性和反亲和性

34.3 优先级和抢占

34.4 任务队列设计

34.5 Argo Workflows 简介

34.6 资源不足处理

34.7 本章实验

34.8 本章练习

第 35 章综合运维项目实战

35.1 项目背景

35.2 项目步骤

步骤 1：搭建 K8s 集群

步骤 2：部署应用

步骤 3：配置监控

步骤 4：配置日志

步骤 5：编写自动化脚本

步骤 6：建立告警

35.3 项目检查点

35.4 本章练习

第 36 章 SRE 理念与职业发展

36.1 SRE 核心理念

36.2 SLO、SLI、SLA

36.3 职业发展路径

36.4 持续学习建议

36.5 推荐认证

36.6 面试准备

36.7 本章练习

附录：常用命令速查

Linux

Docker

Kubernetes

监控

第九部分总结