📚 课程目录第4章容器基础与HPE ProLiant适配

4. 容器基础与HPE ProLiant适配

容器在HPE ProLiant上的落地，并不是把笔记本上的Docker命令原样搬过去。ProLiant作为企业级x86服务器，其价值在于可预测的算力、可管理的固件、可编排的存储与网络，以及可被容器直接调用的硬件加速能力。本节围绕三个层次展开：容器运行时（Runtime）、镜像（Image）与编排引擎（Orchestrator），并说明它们在ProLiant上如何安装、配置，以及如何把CPU指令集、SR-IOV网卡、NVMe与GPU等硬件能力暴露给容器。

一、运行时：从containerd到runc的调用链

在ProLiant上，推荐以containerd作为高层运行时，由它管理镜像、快照与容器生命周期，再通过runc调用Linux内核的namespace与cgroup完成隔离。安装通常来自HPE支持的OS仓库或Docker官方仓库。以RHEL 9 / Rocky 9为例，先确认内核与cgroup v2：

# 确认cgroup版本与内核
uname -r
mount | grep cgroup2

# 安装containerd
sudo dnf install -y containerd
sudo systemctl enable --now containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

# 关键：启用SystemdCgroup，避免与systemd资源管理冲突
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo ctr version

这里有两个ProLiant特有的注意点。第一，ProLiant的iLO与HPE Agentless Management会占用部分管理通道，容器运行时不需要也不应直接操作iLO，但应确保BIOS中VT-x/AMD-V、VT-d/AMD-Vi、SR-IOV与Above 4G Decoding已开启，否则后续设备直通会失败。第二，若使用HPE NSX或DPU卸载，需在运行时配置中保留对VFIO与vDPA的支持。

二、镜像：构建、分发与ProLiant上的本地缓存

镜像层是只读的，容器层可写。在ProLiant上，镜像仓库通常部署在本地NVMe或通过HPE Storage阵列提供。构建时建议使用多阶段构建，减小镜像体积并减少攻击面。例如一个基于UBI的Python服务：

FROM registry.access.redhat.com/ubi9/python-311 AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM registry.access.redhat.com/ubi9/python-311
WORKDIR /app
COPY --from=build /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY app.py .
CMD ["python","app.py"]

构建完成后，用podman build或docker build生成镜像，再推送到本地Harbor或Quay。ProLiant上建议把/var/lib/containerd放在NVMe RAID卷上，并设置data-root指向该路径，以获得更低的镜像解压与容器启动延迟。若使用HPE Alletra或MSA作为后端，可通过iSCSI或NVMe-oF挂载，但要注意多路径与队列深度，避免镜像拉取时出现I/O抖动。

三、编排引擎：Kubernetes在ProLiant上的安装与硬件加速

编排层推荐使用Kubernetes，配合containerd作为CRI。安装可用kubeadm，也可用HPE支持的Rancher RKE2或SUSE K3s。以kubeadm为例，先在所有节点安装kubelet、kubeadm、kubectl，并配置/etc/containerd/config.toml中的SystemdCgroup = true。初始化控制平面：

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
  --cri-socket=unix:///run/containerd/containerd.sock
mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

工作节点加入后，重点转向硬件加速。ProLiant常见的三类加速资源如下：

CPU指令集加速：在Pod中通过resources.limits请求cpu，并利用AVX-512或AMX进行推理与加解密。需在BIOS中启用对应指令集，并在kubelet中配置--cpu-manager-policy=static与--topology-manager-policy=single-numa-node，把关键Pod绑定到同一NUMA节点。
SR-IOV网卡加速：安装SR-IOV Network Device Plugin与Multus CNI，把ProLiant上的Intel E810或Mellanox ConnectX网卡的VF分配给Pod，获得接近线速的网络吞吐。
GPU/NVMe加速：安装NVIDIA GPU Operator或HPE的NVMe Device Plugin，把GPU或本地NVMe盘以扩展资源形式暴露给Pod。

下面这张图把“ProLiant硬件—运行时—镜像—编排—加速资源”的关系集中呈现，便于对照配置。

四、验证与排障：从Pod到硬件的可观测性

部署完成后，不要只看Pod是否Running。建议按以下顺序验证：

用kubectl get nodes -o wide确认节点Ready，并检查kubectl describe node中是否出现nvidia.com/gpu、sriovnetwork等扩展资源。
用kubectl exec进入Pod，执行lscpu | grep avx512确认指令集可见；执行ip link确认VF已注入。
用ctr -n k8s.io containers list查看containerd侧容器状态，与kubelet视图对照。
若Pod卡在ContainerCreating，优先检查CNI插件、Device Plugin日志与/var/log/pods；若启动慢，检查镜像拉取是否走本地Harbor、NVMe队列是否饱和。

在ProLiant上做容器化时，把“固件—内核—运行时—编排—设备插件”视为一条链：任何一层未对齐，硬件加速都不会真正生效。建议在BIOS变更后重启并重新验证SR-IOV VF数量与NUMA拓扑。

最后给出一个可直接参考的最小验证清单，用于确认ProLiant节点已具备容器与硬件加速能力：

检查项	命令/位置	期望结果
cgroup版本	`mount \| grep cgroup2`	存在cgroup2挂载
containerd状态	`systemctl status containerd`	active (running)
SystemdCgroup	`grep SystemdCgroup /etc/containerd/config.toml`	true
节点扩展资源	`kubectl describe node <node>`	出现GPU/SR-IOV/NVMe资源
Pod内指令集	`lscpu \| grep avx512`	列出avx512相关标志
VF注入	`ip link show`	可见VF接口

把上述运行时、镜像与编排三层在ProLiant上对齐后，容器才能真正获得企业级服务器的算力、网络与存储加速能力，而不是仅仅“跑起来”。