woshihlf的博客

本文涵盖了Kubernetes（k8s）的基础、进阶、插件、扩展以及相关容器知识的多个方面。基础部分包括API对象、Pod基础与进阶、资源调度和容器创建流程。进阶部分深入探讨了网络、存储、节点状态、Pod控制器更新策略等高级主题。插件部分介绍了Helm、Container-Runtime、CNI、CSI等工具的使用。扩展部分讨论了调度器扩展、Controller机制、API聚合层等高级功能。此外，还涉及了Docker的基本原理、网络模式、Cgroup等容器相关知识。文章内容持续更新，为读者提供了全面的Kub

CSI卷挂载冲突问题分析 问题现象：当同一Pod挂载多个具有相同CSI驱动和卷句柄的远程存储时，容器会卡在ContainerCreating状态，仅部分卷能成功挂载。 根本原因： CSI卷的唯一标识由驱动名称和卷句柄组合生成（格式：kubernetes.io/csi/<驱动名称>^<卷句柄>） 相同配置的CSI卷会生成相同的唯一卷名 系统内部desiredStateOfWorld数据结构会去重处理，仅保留一个卷条目 但校验阶段仍要求所有声明卷都挂载，导致无限等待 关键代码逻辑： 卷名

摘要：开源vGPU解决方案HAMi通过技术创新实现K8s集群中GPU资源共享，解决了原生NVIDIA Device Plugin独占式分配导致的资源利用率低问题。其核心组件包括改造的Device Plugin（支持设备复制与驱动替换）和自定义调度器（提供精细化的Spread/Binpack策略），通过libvgpu.so拦截CUDA API实现显存和算力限制。虽然存在软件隔离不完全和约5-10%性能损耗的局限，但HAMi为中小规模AI任务提供了高性价比的GPU共享方案，显著提升了资源利用率。（149字）

本文系统解析了 Kubernetes 服务发现与外部访问机制。首先介绍了 Kubernetes 内部服务域名的组成规则及其屏蔽 Pod IP 变化的核心作用。接着详细剖析了 Pod 的 DNS 配置原理，包括 /etc/resolv.conf 的搜索路径、DNS 服务器和 ndots 参数，以及通过 dnsPolicy 和 dnsConfig 自定义 DNS 的方法。最后对比了两种服务暴露方案：生产环境推荐的 Ingress Controller 实现外部域名到内部服务的映射，以及独立 Nginx 反向代理

摘要： Kubernetes Device Plugin 是连接容器与特殊硬件（如 GPU、FPGA）的关键机制。它通过设备发现与注册、资源分配调度以及容器资源注入三大功能，解决容器因隔离性无法直接访问硬件的问题。工作流程包括插件注册、资源上报和动态分配，使 Kubernetes 能像管理 CPU 一样调度特殊硬件。该机制为 AI、边缘计算等场景提供了标准化硬件访问方案，拓展了容器技术的应用边界。（150字）

摘要： Kubernetes 中 Pod 挂载存储卷需经历 Provision/Delete（创盘/删盘）、Attach/Detach（挂接/摘除）和 Mount/Unmount（挂载/卸载） 三阶段。动态卷供应流程中，用户创建 PVC 后，PersistentVolumeController 检测到未绑定 PVC 并触发 External Provisioner，后者通过 CSI 插件创建实际存储并生成 PV，最终完成 PV-PVC 绑定。静态场景（如手动创建 PV 或未关联 StorageClass）不

在Kubernetes中，Volume Snapshots（卷快照） 是一项关键的存储功能，用于创建持久卷（PV）的时间点副本。这一特性通过CSI（容器存储接口） 实现，并引入了一组新的API资源来管理快照生命周期。本文将详细讲解Kubernetes中的Volume Snapshots相关概念、工作原理及使用方法。Kubernetes通过以下CRD（自定义资源定义）管理卷快照：类似于，定义了创建快照的存储后端配置和删除策略。② 用户创建的快照请求，指向一个现有的PVC（PersistentVolumeC

状态初始化从 Pod 中收集卷信息，更新期望状态状态对比reconciler周期性比较期望状态和实际状态卸载操作：对不再需要的卷执行卸载挂载操作：对新增卷或需要更新的卷执行挂载状态更新：挂载/卸载成功后更新实际状态错误处理：处理挂载/卸载过程中的各种异常情况通过这种双缓存、周期性同步的机制，Kubernetes 确保了节点上卷的状态始终与期望状态一致。

简单来说，Kubebuilder 希望开发者像写普通 Go 程序一样编写 Operator，，目的是减少维护成本、提高可读性，同时保持灵活性。（如 CRD 生成），而非引入新的复杂度。Kubebuilder 的设计哲学强调。

Cluster IP (10.233.50.2):External IP (显示为 ):服务暴露了多个端口，每种端口有不同的含义：Service Port (如9091/TCP):TargetPort (如9091/TCP):NodePort (如19650/TCP):当前服务暴露了4个端口组：每组格式为：通过Cluster IP:通过服务DNS名 (在同一个命名空间):集群外部连接通过NodePort (当外部IP未分配时):通过LoadBalancer IP (当外部IP分

抢占策略通过- 队列组内资源回收- 队列组内资源借用时的抢占- 集群队列内部的抢占如果不设置这些策略，默认都是不开启抢占功能。

ResourceFlavor 是 Kueue 中资源类型的抽象描述，它定义了计算节点的特性和约束条件，相当于为集群中的资源打上分类标签。metadata:spec:gpu-type: a100 # 匹配节点标签- key: gpu # 定义节点污点tolerations: # 自动添加的容忍度- key: gpu。

维度说明核心目标实现故障隔离和高可用性关键标签调度策略存储限制动态卷需与 Pod 同 Zone，分布式存储可跨 Zone网络优化优先同 Zone 流量路由（Service通过合理利用 Zone，可以显著提升 Kubernetes 集群的容灾能力和稳定性。

kubeconfig 是 Kubernetes 客户端（如。：在 Shell 提示符显示当前上下文。

组件作用与对方的关系TFJob运行 TensorFlow 分布式训练被Workload封装，受 Kueue 调度Workload管理作业的排队和资源分配持有TFJob的元数据，控制其何时执行。

为工作负载提供身份标识通过 RBAC 实现精细的访问控制支持安全的服务间通信管理外部资源访问凭证实现最小权限原则隔离不同工作负载提供可审计的服务身份增强集群整体安全性理解 ServiceAccount 与 Pod、Secret、RBAC 等组件的关系，对于设计安全的 Kubernetes 架构至关重要。随着 Kubernetes 的发展，ServiceAccount 机制也在不断改进，如 TokenRequest API 的引入，使得身份管理更加安全和灵活。

RoleBinding 是 Kubernetes RBAC 体系中的关键组件，它通过将角色与主体关联来实现细粒度的权限控制。实现最小权限原则隔离不同环境和工作负载提供审计跟踪能力支持多租户场景理解 RoleBinding 与 Role、ClusterRole、ServiceAccount 等资源的关系，是设计健壮的 Kubernetes 权限系统的基础。

定义：描述集群中可用的异构资源类型，通过标签/污点机制与物理节点建立映射关系核心功能：关键配置属性：版本兼容性：校验机制：2. ClusterQueue（集群队列）资源池化模型：定义跨命名空间的全局资源配额池，支持多级资源借用策略架构设计：高级配置参数：队列策略对比：资源借用规则：租户隔离机制：命名空间维度的虚拟队列，实现资源配额二次分配配置示例：运行特征：单元化设计：Kubernetes 原生 Job 的增强抽象，支持多框架集成优先级继承模型：是否Job/Pod PriorityClass是否

资源公平性成本效益和多租户隔离。其设计充分体现了Kubernetes原生组件的扩展哲学——在不颠覆现有体系的前提下，通过API扩展实现能力增强。对于正在构建AI训练平台或混合批处理系统的团队，Kueue提供了从资源配额、作业调度到成本优化的完整解决方案。随着v1版本的临近和生态集成的深化，Kueue有望成为云原生批处理的事实标准。

hostPath是Kubernetes中一个强大但需要谨慎使用的功能。它提供了直接访问宿主机文件系统的能力，适用于特定场景如日志收集、节点监控等。然而，由于其潜在的安全风险和可移植性限制，在生产环境中应谨慎评估是否真的需要hostPath，并始终遵循最小权限原则和安全最佳实践。

Headless Service 和 StatefulSet 共同为 Kubernetes 中的有状态工作负载提供了稳定的网络标识和发现机制。稳定的、可预测的 Pod 名称持久化存储有序部署和扩展需要直接 Pod 到 Pod 通信的场景。

spec:type: RollingUpdate # 或 OnDelete。

控制器类似strategy的字段更新行为适用场景Deployment滚动更新（RollingUpdate）或重建（Recreate）无状态服务（如 Web 应用）按序号分批更新，支持分区控制有状态服务（如数据库）DaemonSet按节点滚动更新节点级守护进程无直接替换 Pod，CronJob 依赖 concurrencyPolicy 控制并发批处理任务ReplicaSet无需通过 Deployment 控制一般不直接使用。

改的是Deployment的replicas，不影响PodTemplate。定义Deployment（包含PodTemplate）：改的是PodTemplate中的容器定义。

作用：控制更新期间允许不可用的Pod数量格式整数(如1)百分比字符串(如"25%")默认值：25%效果：保证服务的最低可用性。

命令，可打开 Minikube 的 Dashboard 界面，通过该界面能以可视化方式管理集群。此命令最好在新终端中运行并保持开启状态。Minikube 提供了一组内置插件，可按需启用、禁用和查看。消息，请等待一段时间后重试。

Helm 是 Kubernetes 的包管理工具，可帮助你更轻松地管理 Kubernetes 应用程序的部署。安装完成后，你就可以使用 Helm 来管理 Kubernetes 应用程序的部署和配置了。虽然启动过程提示成功，但你可以进一步确认集群组件是否正常运行。此命令会列出所有命名空间下的 Pod 信息，若 Pod 的状态为。然后就可以搜索和安装各种 Helm Chart 了。如果成功安装，该命令会显示 Helm 的版本信息。脚本会自动下载并安装最新版本的 Helm。，就表明它们已正常运行。

fieldsV1是 Kubernetes 的的一部分，用于记录字段的所有权信息。默认情况下，kubectl会隐藏，但通过查询时会包含它。你可以通过移除来生成与kubectl一致的 YAML 输出。

在 Kubernetes 中，是一种用于建立资源之间父子关系的机制。它允许一个资源（子资源）明确指定另一个资源（所有者资源）作为其拥有者。通过这种方式，Kubernetes 能够理解资源之间的依赖关系，并基于这些关系执行一些操作，比如级联删除和事件触发。例如，当你使用 Deployment 创建 Pod 时，Deployment 会先创建一个 ReplicaSet，然后 ReplicaSet 再创建 Pod。在这个过程中，Pod 的字段会指向 ReplicaSet，而 ReplicaSet 的。

Kubernetes控制器通过声明式管理控制循环和事件驱动三种机制，确保集群的实际状态与用户期望状态一致。声明式管理提供了用户友好的资源定义方式，控制循环确保了系统的最终一致性，而事件驱动则提高了系统的实时性和响应速度。这三种机制相互配合，构成了Kubernetes强大的自动化管理能力。

使用Kubernetes的自定义资源定义语言（CRD），定义一个自定义资源来描述您的应用程序。除了必备的TypeMeta、ObjectMeta，CRD中还应包含 资源规范Spec 和 资源状态Status 字段。使用 kubectl 或 编写yaml 创建CR的实例使用 kubectl 或 其他kubernetes客户端工具 管理CR。

List 操作是指从 API Server 获取某种类型资源的当前状态的完整列表。这个操作通常用于初始化资源的状态，以便后续的监控和管理。List 操作可以获取集群中某种类型的所有资源对象，比如所有的 Pods、Services、ConfigMaps 等。List 操作的特点全量获取：List 操作会返回指定资源类型的所有实例，包括每个实例的详细状态信息。这对于初始化和全面了解资源状态非常有用。一次性操作。

Kubebuilder 是一个用于构建 Kubernetes API 的框架，专注于通过自定义资源定义（CRD）扩展 Kubernetes 的功能。它类似于 Web 开发中的 Rails 或 Spring Boot，能够显著减少 Kubernetes API 开发的复杂性，帮助开发者遵循最佳实践。

Gatekeeper是Kubernetes社区精心维护的开源项目，本质上是一款基于约束的政策管理工具。在Kubernetes集群管理领域，它扮演着至关重要的角色。用户借助Gatekeeper，能够自定义一组严谨的政策规则，以此对Kubernetes集群内资源的创建和修改过程进行全方位的限制与管控。它通过与Kubernetes的API Server深度集成，达成了对集群资源变化的实时监控。一旦有资源状态发生改变，Gatekeeper便会依据事先设定好的政策规则，即刻展开验证与合规性检查。

Endpoint是Kubernetes中的一种资源，用于描述Service的实际访问点。它包含了提供服务的Pod的IP地址和端口信息。这些信息是Kubernetes实现服务发现和流量分发的关键依据，通过记录具体Pod的网络信息，让外部请求能够准确找到提供服务的实例。

扩展 Kubernetes Controller 的三种方式

Admission Controller 是 Kubernetes 中一个强大的扩展机制，允许用户在 API 请求被处理之前对请求进行验证、修改或拒绝。通过准入控制器，用户可以实现各种自定义的业务逻辑，例如资源配额控制、安全策略检查、自动化配置注入等。Kubernetes 提供了两种主要的准入控制器实现方式：Server-Side Admission 和 Webhook Admission。以下是这两种方式的详细介绍、实现细节、优缺点以及适用场景。

静态 Pod 是由 kubelet 直接管理的 Pod，其配置文件通常存于节点特定目录。kubelet 定时扫描这些配置文件，依其内容创建、更新或删除 Pod。与经 API 服务器管理的 Pod（如 Deployment、DaemonSet 等）不同，静态 Pod 不受 Kubernetes 控制面直接管控。

k8s之调度器详解（扩展调度器）

metadata:# name 必须匹配下面的 spec 字段：<plural>.<group>spec:# group 名用于 REST API 中的定义：/apis/<group>/<version># 列出自定义资源的所有 API 版本versions:- name: v1beta1 # 版本名称，比如 v1、v2beta1 等等served: true # 是否开启通过 REST APIs 访问 `/apis/<group>/<version>/...`