📚 课程目录第2章 Kubernetes基础回顾

Kubernetes基础回顾：Pod、Deployment、Service、Namespace等核心概念

在深入理解Kubernetes（K8s）如何为AI服务提供自动扩缩容能力之前，必须先牢固掌握其最基础的对象模型。AI服务通常以无状态API推理、批处理任务或分布式训练等形式运行，这些形态在K8s中最终都映射为Pod及其上层控制器。本节将聚焦于Pod、Deployment、Service与Namespace四个核心概念，并说明它们如何构成AI服务弹性伸缩的“地基”。

核心原理：从Pod到Deployment的抽象层级

Pod是Kubernetes中可调度的最小计算单元，它封装了一个或多个紧密耦合的容器，并共享网络命名空间、存储卷和生命周期。对于AI推理服务而言，一个Pod通常包含一个运行模型推理的容器（如Triton或TorchServe），以及一个可选的Sidecar容器（用于日志采集或指标暴露）。Pod的IP地址是动态分配的，且Pod本身不具备自愈能力——一旦节点故障或进程崩溃，Pod便永久消失。

为了解决Pod的临时性问题，Deployment作为声明式控制器被引入。它负责维护一组Pod副本的期望状态，支持滚动更新、回滚和副本数调整。Deployment通过ReplicaSet管理Pod的创建与删除，其核心价值在于：当Pod意外终止时，控制器会自动创建新Pod以维持期望副本数。这正是水平Pod自动扩缩容（HPA）能够生效的前提——HPA只修改Deployment的replicas字段，而实际Pod的增删由控制器完成。

关键认知：Pod是“临时工人”，Deployment是“车间主任”。HPA与车间主任对话，而不是直接指挥工人。若绕过Deployment直接操作Pod，自动扩缩容将失去意义。

方法流程：Service如何将流量稳定送达动态Pod

由于Pod的IP会随重建而变化，Service提供了一组稳定的虚拟IP（ClusterIP）和DNS名称，作为访问后端Pod的固定入口。Service通过标签选择器（Label Selector）动态关联一组Pod，并利用iptables或IPVS规则将流量负载均衡到这些Pod上。当HPA扩容出新的Pod时，只要新Pod带有匹配的标签（如app=inference），Service会自动将其纳入负载均衡池，无需人工干预。

对于AI服务，通常还会使用Headless Service（设置clusterIP: None）来获得Pod的稳定DNS标识，便于分布式训练框架（如PyTorch Elastic）进行节点发现。此外，结合Ingress或Gateway API，可以将Service暴露到集群外部，实现HTTP/HTTPS流量的路由。

# 一个典型的AI推理服务定义（简化）
apiVersion: v1
kind: Service
metadata:
  name: model-svc
  namespace: ai-namespace
spec:
  selector:
    app: inference
  ports:
    - port: 80
      targetPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-deploy
  namespace: ai-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      containers:
        - name: triton
          image: nvcr.io/nvidia/tritonserver:23.10
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              cpu: 2
              memory: 4Gi

案例场景：AI推理服务的完整部署与访问链路

假设我们需要部署一个基于Triton的图像分类服务。整个流程如下：

创建Namespace：使用kubectl create namespace ai-namespace隔离环境，避免与其他团队资源冲突。
编写Deployment：定义容器镜像、资源请求（requests）与限制（limits）。资源请求是HPA计算CPU利用率的基准，必须合理设置。
创建Service：通过kubectl expose deployment inference-deploy --name=model-svc --port=80 --target-port=8000暴露服务。
配置HPA：执行kubectl autoscale deployment inference-deploy --cpu-percent=70 --min=2 --max=10，使副本数在2到10之间动态调整。
验证连通性：在集群内使用curl http://model-svc:80/v2/models检查模型列表。

当业务高峰到来时，HPA观察到CPU使用率超过70%，会将Deployment的replicas从3逐步提升至10。新Pod启动后，自动获得app=inference标签，Service立即将其加入端点列表。整个过程无需修改任何Service或Deployment的配置，体现了K8s声明式API的优雅之处。

误区与复盘：Namespace与资源隔离的边界

一个常见误区是认为Namespace提供了强隔离。实际上，Namespace仅提供逻辑隔离——它不限制Pod之间的网络通信（默认策略），也不提供资源配额。若AI团队与大数据团队共享集群，必须额外配置ResourceQuota和LimitRange，否则某个命名空间可能耗尽全部CPU，导致其他服务无法扩容。

核心对象	作用层级	对自动扩缩容的影响
Pod	计算单元	HPA监控其资源使用率；Pod规格中的requests决定扩缩容阈值
Deployment	控制器	HPA直接修改其replicas字段；滚动更新策略影响扩容速度
Service	网络抽象	自动发现新Pod；Headless模式用于分布式训练节点发现
Namespace	逻辑边界	配合ResourceQuota限制总资源，防止“吵闹邻居”影响扩容

排障提示：若HPA显示FailedGetResourceMetric，首先检查Pod是否定义了resources.requests.cpu。没有requests的Pod无法被HPA正确计算利用率，这是AI服务部署中最常见的配置遗漏。

另一个易被忽视的细节是：Deployment的strategy.rollingUpdate.maxSurge和maxUnavailable参数会影响扩容时的资源竞争。对于GPU推理服务，若节点GPU资源紧张，扩容可能因调度失败而长时间Pending。此时应结合Cluster Autoscaler（节点级扩容）与HPA（Pod级扩容）协同工作，才能实现端到端的弹性。