跳到主要内容

4 篇博文 含有标签「Kubernetes」

Kubernetes 集群与运维相关

查看所有标签

K8s 上的 GPU 调度：从 Device Plugin 到 Kueue/Volcano 的推理集群资源管理

· 阅读需 9 分钟

推理集群的利用率为什么普遍只有 30%-50%？大多数时候不是模型不够强，而是调度层把 GPU 当成了「特别大号的 CPU」。这张卡该不该给、给多少、和谁共享、抢占了谁——每一步都决定你是多跑一倍任务，还是天天看着显存碎片和排队干瞪眼。

上一篇Linux VRAM overcommit 与显存超卖讲了单机层面的显存管理，这篇往上一层：K8s 集群里 GPU 是怎么被调度、切分和排队的。面向要搭推理集群的 SRE / 平台工程师，从 Device Plugin 讲到 Kueue、Volcano，附可直接抄的 YAML。

没有 docker daemon 的节点，怎么让 docker 命令照常工作？

· 阅读需 4 分钟

KubeKey 搭的 k8s 集群，节点上装的是 containerd + nerdctl，没有 docker daemon。平时操作没问题，但一旦要跑别人的脚本、CI 或者凭肌肉记忆敲 docker 命令时就傻眼了——docker: command not found。

这篇记录我写的一个 60 行 bash shim：把 docker 伪装成 nerdctl 的转发器，以及部署过程中踩到的一个 CentOS 7 专属的隐蔽坑。

Kubernetes 默认 StorageClass — OpenEBS 安装

· 阅读需 2 分钟

K8s 集群起来后第一个要配的就是默认 StorageClass。没有它，PVC 不会自动绑定 PV，有状态应用（数据库、缓存、日志）都跑不起来。

这篇文章记录在 CentOS 7 + containerd 集群上安装 OpenEBS 作为默认存储后端的过程。

为什么 OpenEBS​

OpenEBS 是一个 CNCF 沙箱项目，核心优势：

  • 轻量：不需要外部存储阵列，直接用节点的本地磁盘
  • CSI 驱动：原生支持 WaitForFirstConsumer 延迟绑定
  • 简单：一条 yaml 搞定，不依赖 Helm

安装​

kubectl apply -f https://openebs.github.io/charts/openebs-operator.yaml

这个 yaml 会创建：

  • openebs-hostpath — 基于节点本地路径的存储类
  • openebs-device — 基于块设备的存储类
  • openebs-localpv-provisioner — CSI provisioner
  • openebs-ndm — 节点磁盘管理器

设为默认​

K8s 集群可以有多个 StorageClass，但只有一个标记为默认：

kubectl patch storageclass openebs-hostpath \
  -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

验证：

kubectl get sc
# openebs-hostpath (default)   openebs.io/local   Delete   WaitForFirstConsumer   13s

看到 (default) 标记就对了。

验证 PVC 自动绑定​

cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
EOF

kubectl get pvc
# test-pvc   Bound   pvc-xxxx   1Gi   RWO   openebs-hostpath

注意事项​

  1. WaitForFirstConsumer：PV 延迟绑定到使用它的 Pod 所在节点，这是最优行为
  2. 回收策略：默认 Delete，PVC 删除后 PV 和本地数据也会被删除。如需保留数据，改 Retain
  3. 本地存储限制：节点宕机后 Pod 漂移，无法访问原节点的本地数据。生产建议配合分布式存储使用

参考​