随着人工智能（AI）和机器学习（ML）的快速发展，GPU 已成为 Kubernetes 中不可或缺的资源。然而，Kubernetes 最初设计的调度机制主要针对 CPU 和内存等常规资源，未对异构硬件（如 GPU）提供原生支持。

之前我用 Ollama 在本地跑大语言模型（可以参考《AI LLM 利器 Ollama 架构和对话处理流程解析》）。这次想再捣鼓点进阶操作，比如 fine-tuning。

我的想法是：既然有现成的大模型，为什么不自己整理些特定领域的数据集，给模型“加点料”呢？这样最后就能得到一个针对特定领域优化过的模型了。

Ollama 概述

Ollama 是一个快速运行 LLM（Large Language Models，大语言模型）的简便工具。通过 Ollama，用户无需复杂的环境配置，即可轻松与大语言模型对话互动。

在云原生环境中，为确保容器化应用的安全运行，Kubernetes 利用了 Linux 内核的三大安全机制：Seccomp、AppArmor 和 SELinux，并引入了 Pod 安全性标准与准入控制来增强 Pod 的安全性。

在 Kubernetes 中，kube-proxy 和 CNI 插件协同工作，确保集群内 Pod 之间的互联互通。

Kube-proxy & CNI

如上图所示，假设我们有一个类型为 ClusterIP 的 Service，它对应两个位于不同节点的 Pod。

本文将会以 CSI driver - NFS 为例，讲述 CSI 驱动的工作流程和原理。

CSI 概述

CSI 驱动通常分为两个部分：

• Controller plugin: 负责存储资源的管理，如卷的创建、删除、扩容、快照等。
• Node plugin: 处理节点级别的存储操作，负责在具体的节点上执行卷的挂载和卸载等任务。

OCI 简介

在容器化技术的演进中，OCI（Open Container Initiative）提供了一套标准化的规范，帮助统一容器的构建、分发和运行。OCI 规范包含三个部分：

kubectl 是与 Kubernetes 集群交互的命令行工具，用户通过它可以对集群资源进行操作和管理。你有没有想过，当我们执行一条 kubectl 命令之后，背后都发生了什么？

详细过程

kubectl -> kube-api-server

根据通信类型，我把 kubectl 命令分为两类：单向通信和双向通信。

DNS 简介

在互联网早期，随着连接设备数量的增加，IP 地址的管理与记忆变得越来越复杂。为了简化网络资源的访问，DNS（Domain Name System）应运而生。DNS 的核心作用是将用户可读的域名（如 www.example.com）解析为对应的 IP 地址（如 93.184.215.34），从而使用户无需记忆复杂的数字串，便能轻松访问全球各地的网络资源。

序言

网络是容器通信的基础，Kubernetes 本身并未提供开箱即用的网络互通功能，只提出了两点基本要求：

• pods can communicate with all other pods on any other node without NAT
• agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

至于如何实现这些通信能力，通常依赖于 CNI 插件来完成。