1. 项目概述从零构建一个高可用AI服务环境最近在折腾一个AI相关的项目发现很多朋友在部署和运行一些开源模型时常常被环境依赖、服务管理、资源调度这些问题搞得焦头烂额。今天我想分享的就是如何系统性地搭建一个我称之为“HAIS”的环境。HAIS你可以把它理解为一个高可用、可扩展的AI服务基础架构。它不是一个具体的软件而是一套方法论和工具集的组合目标是把模型部署、服务编排、监控运维这些脏活累活标准化、自动化让你能更专注于模型本身的应用和调优。简单来说搭建HAIS环境就是为了解决以下几个核心痛点第一环境隔离与复现难题。今天在A机器上跑通的模型明天换到B机器可能就报各种奇怪的依赖错误。第二服务高可用与弹性伸缩。自己写的Python脚本挂掉就全停了无法应对线上流量波动。第三资源管理与成本控制。GPU资源昂贵如何让多个模型服务共享资源并清晰监控其消耗第四标准化部署与运维。从开发到测试再到生产如何建立一套统一的发布流程如果你正在或计划将AI模型无论是Stable Diffusion这类图像生成模型还是LLaMA、ChatGLM这类大语言模型用于实际业务、对外提供服务或者仅仅是希望自己的研究环境更加稳定和高效那么搭建一套HAIS环境会是一个非常值得的前期投入。它就像给你的AI项目盖一个坚固、设施齐全的“房子”而不是在露天里“打地铺”。2. HAIS环境的核心架构设计思路搭建HAIS环境首先得想清楚我们需要一个什么样的架构。这个架构不是凭空想象而是针对前面提到的痛点一层层构建解决方案。我的设计思路主要围绕四个核心层级展开基础设施层、容器化与编排层、服务网关与治理层、以及监控运维层。2.1 分层解耦清晰定义每一层的职责基础设施层是地基主要包括物理机或云服务器、GPU资源、网络和存储。这一层的目标是提供稳定、高性能的计算资源。对于AI服务GPU无疑是核心。我们的设计需要考虑GPU的共享如使用NVIDIA MIG或通过容器虚拟化、远程访问比如NVLink或高速网络、以及存储高速SSD用于模型加载对象存储或网络存储用于持久化数据。容器化与编排层是承重墙也是HAIS的“灵魂”。我们使用Docker将每一个AI模型及其复杂的依赖Python版本、CUDA、各种pip包打包成一个独立的、可移植的镜像。这样环境隔离和复现问题就基本解决了。但仅有Docker还不够我们需要KubernetesK8s这样的容器编排系统。K8s负责管理这些容器化模型的“一生”在哪个节点启动、如何分配GPU资源、挂了如何自动重启、流量大了如何自动增加副本弹性伸缩。它将我们从手动管理一堆服务器和进程的苦海中解放出来。服务网关与治理层是门窗和管道负责对内外通信。AI模型通常通过HTTP API如RESTful或gRPC提供服务。我们不可能让用户直接访问K8s集群内部的某个Pod容器实例的IP和端口。这就需要引入Ingress Controller如Nginx Ingress作为入口网关统一管理外部访问的域名、路由、SSL证书卸载和负载均衡。同时我们还需要服务网格如Istio或API网关如Kong来管理服务间的发现、熔断、限流、认证等高级功能确保服务的稳定性和安全性。监控运维层是房子的水电表和警报系统。没有监控服务就是在“裸奔”。我们需要一套完整的可观测性体系使用Prometheus收集集群、节点、容器、GPU以及自定义应用如模型推理延迟的指标使用Grafana进行可视化展示和告警面板定制使用Loki或ELK Stack收集和查询容器日志使用Jaeger进行分布式链路追踪定位一次推理请求慢到底卡在哪个环节。这套体系能让我们快速发现问题、定位瓶颈、评估资源使用效率。2.2 技术选型背后的逻辑为什么是它们在具体选型上我遵循“主流、稳定、社区活跃”的原则。Docker和Kubernetes几乎是容器化和编排的事实标准拥有最庞大的生态和最多的实践经验遇到问题容易找到解决方案。在K8s发行版上对于生产环境我倾向于使用经过商业验证的发行版如Rancher RKE2或Red Hat OpenShift它们提供了额外的安全加固和简化运维工具。对于学习和测试Minikube或Kind足矣。在GPU支持方面关键在于安装NVIDIA的容器运行时nvidia-container-toolkit和在K8s中部署nvidia-device-plugin。这个插件会让K8s能够识别节点上的GPU资源并像分配CPU和内存一样通过limits.nvidia.com/gpu来分配GPU给Pod使用。这是实现AI模型在K8s中调度GPU的基础。对于服务网关Nginx Ingress Controller足够成熟和强大能满足大部分场景。如果业务需要更复杂的API管理、鉴权、流控策略可以再叠加Kong或APISIX。监控栈的经典组合PrometheusGrafanaLoki被称为“PLG”栈部署相对简单功能全面是云原生监控的标配。注意技术选型没有绝对的对错只有是否适合当前团队和业务场景。对于小团队或初期项目切勿过度设计。例如一开始可以不用服务网格Istio它的复杂性可能超过带来的收益。先从核心的K8sIngress监控做起随着业务复杂度的提升再逐步引入新组件。3. 基础环境与Kubernetes集群部署实操理论讲完我们进入实战环节。假设我们从一个纯净的Ubuntu 22.04 LTS服务器开始这台服务器至少有一块NVIDIA GPU已安装好官方驱动。3.1 前置条件准备与依赖安装首先我们需要配置一些基础环境和安装必要的依赖。# 1. 更新系统并安装基础工具 sudo apt-get update sudo apt-get upgrade -y sudo apt-get install -y curl wget gnupg2 software-properties-common apt-transport-https ca-certificates # 2. 安装Docker # 卸载旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 设置Docker仓库 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 将当前用户加入docker组避免每次sudo sudo usermod -aG docker $USER newgrp docker # 刷新组权限或重新登录 # 配置Docker守护进程使用systemd作为cgroup驱动K8s要求 sudo cat EOF | sudo tee /etc/docker/daemon.json { exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m }, storage-driver: overlay2 } EOF sudo systemctl restart docker sudo systemctl enable docker # 3. 安装NVIDIA容器运行时关键步骤 distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker # 测试nvidia-smi在容器内是否可用 docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi如果最后一条命令能成功输出GPU信息说明Docker的GPU支持已就绪。3.2 使用RKE2部署生产级Kubernetes集群这里我选择RKE2因为它是Rancher推出的一个完全符合K8s标准的发行版轻量且安全特别适合边缘和AI场景。# 1. 下载并安装RKE2作为server节点同时也是agent curl -sfL https://get.rke2.io | sudo sh - # 2. 创建RKE2配置文件 sudo mkdir -p /etc/rancher/rke2/ sudo cat EOF | sudo tee /etc/rancher/rke2/config.yaml write-kubeconfig-mode: 0644 tls-san: - 你的服务器IP或域名 node-ip: 你的服务器IP cni: cilium # 也可以使用calicocilium功能更强大 EOF # 3. 启动并启用RKE2服务 sudo systemctl enable rke2-server.service sudo systemctl start rke2-server.service # 4. 等待启动完成约1-2分钟然后检查状态并配置kubectl sudo systemctl status rke2-server.service sudo cp /etc/rancher/rke2/rke2.yaml ~/.kube/config sudo chown $(id -u):$(id -g) ~/.kube/config export KUBECONFIG~/.kube/config echo export KUBECONFIG~/.kube/config ~/.bashrc # 5. 验证集群 kubectl get nodes kubectl get pods -A如果看到节点状态为Ready并且kube-system命名空间下的核心Pod都在运行说明单节点的K8s集群已经部署成功。对于生产环境你还需要添加worker节点过程类似但安装的是rke2-agent并指向server节点的地址。3.3 部署NVIDIA Device Plugin与GPU资源验证K8s集群起来了但它还不知道我们有GPU。接下来部署NVIDIA Device Plugin。# 1. 添加NVIDIA Helm仓库Helm是K8s的包管理器需提前安装 curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash helm repo add nvdp https://nvidia.github.io/k8s-device-plugin helm repo update # 2. 部署NVIDIA Device Plugin helm upgrade -i nvdp nvdp/nvidia-device-plugin \ --namespace nvidia-device-plugin \ --create-namespace \ --set runtimeClassNamenvidia \ --version 0.14.5 # 使用一个稳定的版本 # 3. 验证插件运行和资源发现 kubectl get pods -n nvidia-device-plugin kubectl describe node 你的节点名 | grep -A 10 -B 5 Capacity在describe node的输出中你应该能在Capacity和Allocatable部分看到nvidia.com/gpu: 1假设你有一块GPU。这表明K8s已经识别到了GPU资源。现在我们可以创建一个测试Pod来验证GPU是否可用# gpu-test-pod.yaml apiVersion: v1 kind: Pod metadata: name: gpu-test-pod spec: restartPolicy: Never containers: - name: cuda-container image: nvidia/cuda:11.8.0-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1 # 申请1个GPUkubectl apply -f gpu-test-pod.yaml kubectl logs gpu-test-pod如果日志成功打印出GPU信息恭喜你一个支持GPU调度的K8s集群已经搭建完成。这是HAIS环境最核心的基础。4. AI模型容器化与Kubernetes部署实战有了能调度GPU的K8s集群下一步就是把我们的AI模型打包、部署上去。我们以一个典型的PyTorch模型部署为例假设我们有一个简单的文本分类模型它提供一个HTTP API。4.1 构建高效且安全的模型推理镜像Dockerfile的编写至关重要它决定了镜像的大小、安全性和构建速度。一个常见的误区是直接使用python:3.9这样的基础镜像然后无脑pip install这会导致镜像臃肿可能超过几个GB且包含大量不必要的系统工具。# 使用官方精简的Python运行时镜像作为基础 FROM python:3.9-slim-bullseye AS builder # 安装编译依赖仅构建阶段需要 RUN apt-get update apt-get install -y --no-install-recommends \ gcc \ g \ rm -rf /var/lib/apt/lists/* # 设置工作目录和Python环境 WORKDIR /app ENV PYTHONUNBUFFERED1 \ PYTHONDONTWRITEBYTECODE1 \ PIP_NO_CACHE_DIR1 \ PIP_DISABLE_PIP_VERSION_CHECK1 # 复制依赖文件并安装 COPY requirements.txt . # 使用清华PyPI镜像加速并精确锁定版本 RUN pip install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt # ---- 第二阶段运行阶段 ---- FROM python:3.9-slim-bullseye AS runtime # 安装运行时最小依赖如可能需要libgomp1等 RUN apt-get update apt-get install -y --no-install-recommends \ libgomp1 \ rm -rf /var/lib/apt/lists/* WORKDIR /app ENV PYTHONUNBUFFERED1 \ PYTHONDONTWRITEBYTECODE1 # 从构建阶段复制已安装的Python包 COPY --frombuilder /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages COPY --frombuilder /usr/local/bin /usr/local/bin # 复制应用代码 COPY . . # 创建一个非root用户运行应用增强安全性 RUN useradd -m -u 1000 appuser chown -R appuser:appuser /app USER appuser # 暴露端口假设你的模型服务运行在8080端口 EXPOSE 8080 # 启动命令使用Gunicorn作为WSGI服务器比直接python run.py更稳定 CMD [gunicorn, --bind, 0.0.0.0:8080, --workers, 2, --threads, 4, --timeout, 120, app:app]这个Dockerfile采用了多阶段构建最终运行镜像只包含运行时必需的库体积会小很多。requirements.txt里应该精确指定依赖版本例如torch2.1.0 --index-url https://download.pytorch.org/whl/cu118。4.2 编写Kubernetes部署清单Deployment与Service镜像构建并推送到镜像仓库如Docker Hub、Harbor后我们需要编写K8s的部署文件。一个完整的部署通常包括Deployment和Service。# model-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: text-classifier namespace: ai-services # 建议为AI服务创建独立的命名空间 spec: replicas: 2 # 启动两个副本实现高可用 selector: matchLabels: app: text-classifier template: metadata: labels: app: text-classifier spec: # 节点选择器可以指定带有GPU标签的节点 # nodeSelector: # accelerator: nvidia-gpu containers: - name: classifier image: your-registry/your-username/text-classifier:v1.0.0 ports: - containerPort: 8080 resources: limits: cpu: 2 memory: 4Gi nvidia.com/gpu: 1 # 申请1块GPU requests: cpu: 1 memory: 2Gi nvidia.com/gpu: 1 env: - name: MODEL_PATH value: /app/models/bert-base-uncased - name: LOG_LEVEL value: INFO # 健康检查对服务稳定性至关重要 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 # 给模型加载留出时间 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 # 将模型文件挂载为卷避免打包进镜像导致镜像过大 volumeMounts: - name: model-storage mountPath: /app/models readOnly: true volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc # 需要提前创建PVC关联到实际的存储 --- apiVersion: v1 kind: Service metadata: name: text-classifier-service namespace: ai-services spec: selector: app: text-classifier ports: - port: 80 # Service对集群内暴露的端口 targetPort: 8080 # 容器端口 type: ClusterIP # 集群内部访问应用这个配置kubectl apply -f model-deployment.yaml -n ai-services。Deployment确保了始终有2个Pod在运行K8s会自动处理故障恢复。Service为这组Pod提供了一个稳定的内部域名text-classifier-service.ai-services.svc.cluster.local和负载均衡。4.3 配置Ingress实现外部访问ClusterIP类型的Service只能在集群内部访问。要让外部用户能访问我们的模型API需要配置Ingress。# model-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: text-classifier-ingress namespace: ai-services annotations: nginx.ingress.kubernetes.io/proxy-body-size: 50m # 允许上传大文件如图片 nginx.ingress.kubernetes.io/proxy-read-timeout: 300 # 长超时适应模型推理时间 nginx.ingress.kubernetes.io/proxy-send-timeout: 300 cert-manager.io/cluster-issuer: letsencrypt-prod # 自动申请SSL证书如果安装了cert-manager spec: ingressClassName: nginx tls: - hosts: - ai.yourdomain.com secretName: text-classifier-tls rules: - host: ai.yourdomain.com http: paths: - path: /classify pathType: Prefix backend: service: name: text-classifier-service port: number: 80应用后外部用户就可以通过https://ai.yourdomain.com/classify访问你的模型服务了。你需要确保DNS将ai.yourdomain.com解析到了你的K8s集群Ingress Controller的公网IP上。实操心得模型第一次加载可能非常慢尤其是大模型initialDelaySeconds一定要设置得足够长否则健康检查会在模型加载完之前就判定Pod不健康并不断重启陷入死循环。另外GPU内存VRAM是稀缺资源在resources.limits中设置nvidia.com/gpu可以防止单个Pod占用所有GPU但要注意K8s的GPU调度是“全有或全无”它无法像CPU和内存那样按小数份额共享。如果你的模型只用了半张显卡的显存可以考虑使用NVIDIA的MIG多实例GPU技术或通过时间片轮转的方式在应用层实现共享。5. 可观测性建设监控、日志与告警服务跑起来不是终点我们需要知道它跑得怎么样。可观测性体系是HAIS环境的“眼睛”。5.1 部署Prometheus与Grafana监控栈使用Helm可以一键部署完整的监控栈。这里我们使用Prometheus社区提供的kube-prometheus-stack它包含了Prometheus、Grafana以及大量预置的监控规则和面板。# 添加Prometheus社区仓库 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 创建监控专用的命名空间 kubectl create namespace monitoring # 安装kube-prometheus-stack helm upgrade -i kube-prometheus-stack prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValuesfalse \ --set grafana.adminPassword你的强密码 \ --set grafana.service.typeLoadBalancer # 方便外部访问Grafana UI安装完成后你可以通过kubectl get svc -n monitoring找到Grafana的LoadBalancer类型Service的外部IP用admin和上面设置的密码登录。里面已经预置了Kubernetes集群、节点、Pod等丰富的监控面板。5.2 监控GPU与自定义模型指标预置面板可能没有GPU监控。我们需要部署NVIDIA DCGM Exporter来暴露GPU指标并让Prometheus采集。# 部署DCGM Exporter helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm upgrade -i dcgm-exporter gpu-helm-charts/dcgm-exporter \ --namespace monitoring \ --set serviceMonitor.enabledtrue # 自动创建ServiceMonitor让Prometheus发现并采集稍等片刻在Grafana中导入Dashboard ID12239这是一个社区维护的NVIDIA DCGM Exporter仪表板你就能看到每块GPU的利用率、显存使用、温度、功耗等详细信息了。对于自定义的业务指标比如模型推理的延迟model_inference_latency_seconds、请求量model_requests_total、错误率model_errors_total你需要在模型应用代码中使用Prometheus的客户端库如Python的prometheus_client来暴露这些指标。然后在Pod的annotations中添加注解让Prometheus自动抓取# 在Deployment的Pod模板中添加 metadata: annotations: prometheus.io/scrape: true prometheus.io/port: 8080 # 你的指标暴露端口 prometheus.io/path: /metrics # 你的指标端点路径5.3 集中式日志收集与链路追踪日志方面我推荐使用Loki因为它设计上就是为容器日志而生比ELK更轻量查询语法类似PromQL和Grafana集成无缝。# 添加Grafana仓库Loki和Tempo也在其中 helm repo add grafana https://grafana.github.io/helm-charts helm repo update # 安装Loki用于日志 helm upgrade -i loki grafana/loki-stack \ --namespace monitoring \ --set fluent-bit.enabledtrue \ --set promtail.enabledfalse # 我们使用Fluent Bit作为日志收集端 # 安装Tempo用于分布式追踪可选但对于复杂调用链很有用 helm upgrade -i tempo grafana/tempo \ --namespace monitoring \ --set serviceMonitor.enabledtrue在你的应用代码中需要集成OpenTelemetry SDK来生成追踪数据并发送到Tempo。同时确保应用日志输出到标准输出stdoutFluent Bit会自动收集所有容器的stdout/stderr日志并发送给Loki。在Grafana中配置数据源为Loki和Tempo你就可以在“Explore”页面中先用Loki查询特定的错误日志然后一键跳转到这条日志对应的完整分布式追踪链路Tempo极大提升了排障效率。6. 高级主题与生产环境考量基础环境搭建和监控都完成后我们可以考虑一些更高级的特性让HAIS环境更加强大和自动化。6.1 实现模型的自动伸缩HPAKubernetes的Horizontal Pod Autoscaler可以根据CPU、内存甚至自定义指标如QPS自动调整Pod的副本数。对于AI服务我们更关心的是GPU利用率和请求排队长度。首先需要安装Prometheus Adapter将Prometheus中的自定义指标转换成K8s HPA能识别的格式。helm upgrade -i prometheus-adapter prometheus-community/prometheus-adapter \ --namespace monitoring \ --set prometheus.urlhttp://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local \ --set prometheus.port9090 \ -f custom-metrics-config.yaml # 需要自定义配置告诉adapter如何查询你的业务指标假设我们暴露了一个名为http_requests_per_second的指标。配置好Adapter后就可以创建基于该指标的HPAapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: text-classifier-hpa namespace: ai-services spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: text-classifier minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100 # 当每个Pod平均每秒处理100个请求时触发扩容6.2 使用GitOps实现持续部署手动kubectl apply容易出错且难以审计。GitOps以Git作为唯一事实来源是更先进的做法。我们使用Argo CD它会持续监控Git仓库中的YAML文件并自动同步到K8s集群确保集群状态与Git声明的一致。# 安装Argo CD kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # 获取初始密码并通过端口转发访问UI kubectl get pods -n argocd -l app.kubernetes.io/nameargocd-server -o name | cut -d/ -f 2 kubectl port-forward svc/argocd-server -n argocd 8080:443 # 访问 https://localhost:8080 用户名为 admin密码为上一步获取的密码在Argo CD中创建一个Application指向存放你所有K8s YAML清单的Git仓库。之后你只需要向Git仓库提交代码和配置Argo CD就会自动部署实现了基础设施即代码IaC和持续部署。6.3 安全加固与多租户隔离生产环境必须考虑安全。Pod安全策略PSP/ Pod安全准入PSA限制Pod能以特权模式运行、能访问哪些主机资源等。在新版K8s中PSP已被PSA取代。网络策略使用Calico或Cilium的网络策略控制Pod之间的网络流量。例如禁止监控命名空间的Pod访问AI服务命名空间的Pod。服务网格如Istio提供细粒度的流量管理、mTLS加密通信、基于角色的访问控制RBAC。这对于有多团队、多模型服务的复杂场景非常有用可以实现模型A只能被服务B调用并且调用链路全程加密。资源配额ResourceQuota和限制范围LimitRange在命名空间级别限制总资源使用量并设置默认的资源请求和限制防止某个服务耗尽整个集群资源。7. 常见问题排查与运维技巧实录在实际搭建和运维中我踩过不少坑这里记录一些典型问题和解决方法。7.1 GPU相关故障排查问题1Pod调度失败提示0/1 nodes are available: 1 Insufficient nvidia.com/gpu。排查首先确认节点是否有GPUkubectl describe node node-name | grep nvidia.com/gpu。解决如果看不到GPU资源检查nvidia-device-pluginPod是否正常运行日志是否有错误。常见原因是Docker的运行时未配置为nvidia或者节点未安装NVIDIA驱动。确保/etc/docker/daemon.json中配置了default-runtime: nvidia不推荐建议使用运行时类或者Pod spec中指定了runtimeClassName: nvidia。问题2Pod内运行nvidia-smi报错Failed to initialize NVML: Driver/library version mismatch。排查这通常是主机NVIDIA驱动版本与容器内CUDA驱动库版本不兼容。解决确保你使用的CUDA基础镜像版本如nvidia/cuda:11.8.0-base与主机安装的NVIDIA驱动版本兼容。参考NVIDIA官方兼容性矩阵。通常主机驱动版本需要高于容器内CUDA所需的最低驱动版本。7.2 服务与网络问题问题3通过Ingress访问服务超时或返回502。排查链检查Ingress资源状态kubectl get ingress -n ai-services。检查对应的Service是否存在且Endpoints正确kubectl describe svc text-classifier-service -n ai-services。查看Endpoints列表是否与健康的Pod IP对应。检查Pod是否就绪readinessProbe通过且正在运行。进入Nginx Ingress Controller的Pod内部用curl直接访问Service的ClusterIP和端口判断是Ingress问题还是Service/ Pod问题。解决根据排查链定位。常见原因是readinessProbe配置不当Pod未就绪就被加入Endpoints或者Service的selector与Pod的label不匹配。问题4模型服务内存泄漏Pod不断被OOMKill。排查查看Pod描述信息确认终止原因为OOMKilled。使用kubectl top pod监控Pod内存使用趋势。检查应用日志看是否有异常对象未释放。解决优化应用代码避免内存泄漏。合理设置Pod的resources.limits.memory和resources.requests.memory。对于Python服务可以设置--preload减少Gunicorn worker的内存复制或者考虑使用异步框架。对于加载大模型确保只在进程启动时加载一次而不是每次请求都加载。7.3 存储与数据持久化问题5模型文件过大几十GB镜像构建和拉取缓慢且更新模型需要重新构建整个镜像。解决绝对不要将大模型文件打包进Docker镜像。应该使用持久化存储卷。对于云环境使用云提供商块存储如AWS EBS GCP Persistent Disk或文件存储如AWS EFS GCP Filestore创建PersistentVolumePV和PersistentVolumeClaimPVC。对于本地环境可以使用NFS、Ceph RBD或Longhorn等分布式存储方案。在Deployment中挂载PVC到容器的模型目录。更新模型时只需替换存储卷中的文件然后重启Pod或使用滚动更新策略即可无需重新构建镜像。问题6多个Pod需要共享访问同一份模型文件只读。解决使用支持ReadOnlyMany或ReadWriteMany访问模式的存储。云上的文件存储如AWS EFS通常支持。在PVC中指定accessModes: [“ReadOnlyMany”]然后多个Pod可以同时挂载同一个PVC进行读取。搭建一套完整的HAIS环境确实涉及不少组件和配置但一旦搭建完成它将为你后续所有AI项目的部署、运维和迭代提供巨大的便利性和稳定性保障。从手动运维到自动化、可观测的云原生架构这个转变带来的效率提升和风险降低是值得投入的。最重要的是理解每一层组件的作用和相互联系这样在出现问题时你才能像一名经验丰富的运维工程师一样快速定位并解决。