探索云原生

摘要：本文介绍了如何通过Scheduler Extender扩展Kubernetes调度器实现自定义调度策略。K8s默认调度器通过spec.schedulerName支持多调度器，自定义调度逻辑可满足GPU分配、资源均衡、地理调度等特殊需求。扩展方法主要包括：1）基于调度框架开发新调度器；2）通过Scheduler Extender以HTTP服务扩展原调度器。后者通过配置KubeSchedulerConfiguration的extenders字段，实现零侵入式扩展，支持filter、prioritize和b

本文分析了开源vGPU方案HAMi中的设备插件hami-device-plugin-nvidia实现原理。作为系列第一篇，重点解读了该插件的核心功能：与NVIDIA原生device-plugin不同，HAMi自定义实现是为了支持vGPU细粒度切分。文章从程序入口开始，介绍了基于CLI的启动命令配置，并指出分析device-plugin需要关注的三个关键环节：Register注册逻辑、ListAndWatch设备感知机制以及Allocate分配策略。后续将深入这些核心模块的实现细节，揭示HAMi如何通过定制设

Kubernetes 1.31 引入了 ImageVolume 新特性（Alpha阶段），允许将OCI镜像直接挂载为Volume，从而加速AI/ML场景中的模型权重等工件分发。该功能解决了传统PVC存储跨命名空间重复下载大模型的问题，提升效率。使用前需部署Kubernetes 1.31集群并启用ImageVolume特性门控，目前仅CRI-O运行时支持。通过简单的YAML配置即可将镜像挂载到Pod中访问文件内容，为AI工作负载提供了更灵活的存储方案。

本文介绍了一种开源的GPU虚拟化方案HAMi(Heterogeneous AI Computing Virtualization Middleware)。相比于传统的TimeSlicing方案，HAMi不仅支持GPU共享，还能对GPU核心和显存进行细粒度隔离与限制(1%级别)，确保各Pod获得相应资源。HAMi采用vCUDA方案，通过拦截CUDA/NVML API实现资源控制，当Pod使用超过申请量时会直接返回OOM。文章详细说明了HAMi的安装流程，包括先部署GPU Operator，再通过Helm添加r

本文介绍了GPU共享方案，特别是NVIDIA的Time Slicing技术，旨在通过超额订阅（oversubscription）实现多个Pod共享同一物理GPU，从而提升资源利用率。文章详细阐述了Time Slicing的配置步骤，包括创建Time Slicing配置、修改集群策略以启用Time Slicing，以及可选地为不同节点打上标签以应用不同策略。通过这种方式，可以在Kubernetes环境中实现GPU资源的共享，避免资源浪费。尽管Time Slicing方案存在内存和故障隔离的不足，但其简单易用的

本文主要分享如何使用 基于 Admission Webhook 实现自动修改 Pod DNSConfig，使其优先使用 NodeLocalDNS。more。

是一套 DNS 本地缓存解决方案。NodeLocal DNSCache 通过在集群节点上运行一个 DaemonSet 来提高集群 DNS 性能和可靠性。通过 dnsConfig 字段自定义Pod的dns配置，nameservers 中除了指定 NodeLocalDNS 之外还指定了 KubeDNS，这样即使 NodeLocalDNS 异常也不影响 Pod 中的 DNS 解析。

在 两篇文章中分别分享了在不同环境如何使用 GPU，以及在 k8s 中使用 GPU Operator 来加速部署。在 中则是分析了 Device Plugin 的实现原理。宿主机上的 GPU 是怎么能够被 K8s 中的 Pod 使用的。1）k8s 是如何感知到 GPU 的2）GPU 是如何分配给 Pod 的。

本文主要分析 k8s 中的 device-plugin 机制工作原理，并通过实现一个简单的 device-plugin 来加深理解。

上一篇文章GPU 使用指南：如何在裸机、Docker、K8s 等环境中使用 GPU分享了裸机、Docker 环境以及 K8s 环境中如何使用 GPU。整个流程还算比较简单，但是因为需要在节点上安装 GPU Driver、Container Toolkit 等组件，当集群规模较大时还是比较麻烦的。为了解决这个问题，NVIDIA 推出了。

仅以比较常见的 NVIDIA GPU 举例，系统为 Linux，对于其他厂家的 GPU 设备理论上流程都是一样的。省流：对于裸机环境，只需要安装对应的 GPU Driver 以及 CUDA Toolkit。对应 Docker 环境，需要额外安装 nvidia-container-toolkit 并配置 docker 使用 nvidia runtime。

所谓 Service，其实就是 Kubernetes 为 Pod 分配的、固定的、基于 iptables（或者 IPVS）的访问入口。而这些访问入口代理的 Pod 信息，则来自于 Etcd，由 kube-proxy 通过控制循环来维护。1）ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。2）NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。NodePort服务会路由到自动创建的ClusterIP服务。通过请求。

Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的，另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。metadata:spec:selector:ports:port: 80spec.selector 字段表明这个 Service 只代理携带了 app=hostnames 标签的 Pod。并且，这个 Service 的 80 端口，代理的是 Pod 的 9376 端口。

本文记录了使用 kubeadm 从头搭建一个使用 containerd 作为容器运行时的 Kubernetes 集群的过程。

使用 KubeClipper 一条命令快速创建 K8S 集群

本文主要介绍了 Kubernetes 中的Pure Layer 3）网络方案。其中的典型例子，莫过于 Flannel 的 host-gw 模式和 Calico 项目了。Kubernetes1. 概述除了前面讲述的隧道模式之外，Kubernetes 中还有一种纯三层（Pure Layer 3）网络方案

本文主要记录了 Kubernetes 集群网络方案之 Flannel 核心原理详解，包括其隧道方案中的两种：UDP 实现和 VXLAN 实现。1. 概述Docker 的默认配置下，不同宿主机上的容器通过 IP 地址进行互相访问是根本做不到的。为了解决这个容器跨主通信的问题，社区里才出现了那么多的容器网络方案。Fla

本文主要记录了如何使用 kubeadm 搭建 Kubernetes 集群。包括安装Kubeadm，初始化Master节点，配置Worker节点，安装网络插件等等。1. 概述本文主要记录了如何使用 kubeadm 搭建 Kubernetes 集群。大概有如下几个步骤：1）环境准备准备好3台机器（虚拟机、云服务器都行）修改必要