3. 环境准备与基础搭建：云环境与本地集群

本章是整条推理链路落地的物理基础。无论选择公有云托管集群还是本地 Minikube 开发环境，都需要完成 Kubernetes 集群的初始化、命令行工具链的安装以及多租户命名空间的规划。以下内容按照“集群选型 → 工具安装 → 空间规划”的顺序展开，确保后续章节的模型部署、服务暴露与监控链路能够无缝衔接。

3.1 集群环境选型对比

根据团队规模、预算与运维能力，推荐以下三种主流方案。生产环境优先选择 AWS EKS 或 GCP GKE；个人实验或离线开发场景使用 Minikube。

3.2 集群搭建快速指南

3.2.1 Minikube（本地开发环境）

Minikube 是本地搭建单节点 Kubernetes 集群的最快方式，适合课程实验与模型调试。

# 安装 Minikube（Linux / macOS）
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# 启动集群（指定 Docker 驱动，分配 8 GB 内存）
minikube start --driver=docker --memory=8192 --cpus=4

# 验证集群状态
kubectl cluster-info
kubectl get nodes

3.2.2 AWS EKS（生产环境）

使用 eksctl 工具快速创建生产级集群，自动配置 VPC、IAM 与节点组。

# 安装 eksctl
curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin

# 创建集群（含 GPU 节点组）
eksctl create cluster \
  --name aml-inference-cluster \
  --region us-west-2 \
  --nodegroup-name gpu-workers \
  --node-type p3.2xlarge \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 4 \
  --with-oidc \
  --managed

3.2.3 GCP GKE（生产环境）

使用 gcloud 命令创建 Autopilot 或 Standard 集群，自动管理控制面与节点。

# 安装 gcloud 并配置项目
gcloud auth login
gcloud config set project your-project-id

# 创建 GKE Standard 集群（含 GPU 节点池）
gcloud container clusters create aml-inference-cluster \
  --region us-central1 \
  --node-locations us-central1-a \
  --machine-type n1-standard-4 \
  --num-nodes 2 \
  --accelerator type=nvidia-tesla-t4,count=1 \
  --enable-autoscaling --min-nodes 1 --max-nodes 4

3.3 命令行工具链安装

集群就绪后，必须安装 kubectl 与 helm 两个核心工具。kubectl 负责与 API Server 交互，helm 负责打包部署推理 Chart。

# 安装 kubectl（以 v1.28.0 为例）
curl -LO "https://dl.k8s.io/release/v1.28.0/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# 安装 helm
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

# 配置 kubectl 上下文（以 Minikube 为例）
kubectl config use-context minikube

3.4 命名空间规划与多租户隔离

在推理链路中，合理的命名空间规划可以隔离不同模型、不同环境（开发/预发/生产）以及不同团队的资源。推荐采用“环境 + 模型域”的二维命名策略。

3.4.1 命名空间设计原则

• 环境隔离： 每个环境（dev / staging / prod）使用独立命名空间，避免误操作影响生产流量。
• 模型域隔离： 同一环境下，不同模型域（如 NLP / CV / 推荐）使用不同命名空间，便于资源配额管理。
• 共享服务： 监控、日志、Ingress Controller 等基础设施组件统一部署在 infra 或 monitoring 命名空间。

3.4.2 推荐命名空间清单

# 创建命名空间
kubectl create namespace aml-dev-nlp
kubectl create namespace aml-dev-cv
kubectl create namespace aml-staging
kubectl create namespace aml-prod
kubectl create namespace infra

# 为命名空间设置资源配额（以 aml-dev-nlp 为例）
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-nlp-quota
  namespace: aml-dev-nlp
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    requests.nvidia.com/gpu: 0
EOF

3.5 环境架构总览

下图展示了本章搭建的完整环境拓扑：本地或云集群作为底座，kubectl/helm 作为控制工具，命名空间按环境与模型域划分，为后续模型部署与推理链路做好准备。

3.6 环境验证清单

完成上述步骤后，执行以下命令确认环境就绪。所有检查项通过后，即可进入下一章“模型镜像构建与推送”。

# 1. 检查集群节点状态
kubectl get nodes -o wide

# 2. 检查命名空间列表
kubectl get namespaces

# 3. 检查命名空间资源配额
kubectl get resourcequota -n aml-dev-nlp

# 4. 检查 Helm 是否可正常添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 5. 检查 GPU 节点可调度（如有 GPU）
kubectl describe nodes | grep -i nvidia