KubeSphere 最佳实战：探索 (k8s)Kubernetes 持久化存储之 NFS 终极实战指南

转载：KubeSphere 最佳实战：探索 Kubernetes 持久化存储之 NFS 终极实战指南

今天分享的内容是 KubeSphere 最佳实战「2024」 系列文档中的 探索 Kubernetes 持久化存储之 NFS 终极实战指南。

在 Kubernetes 生态系统中，持久化存储扮演着至关重要的角色，它是支撑应用稳定运行的基石。对于那些选择自建 Kubernetes 集群的运维架构师而言，选择合适的后端持久化存储解决方案是一项至关重要的选型决策。后端持久化存储常见的解决方案有 Ceph、GlusterFS、NFS、hostPath，以及这两年新兴起的 Longhorn。当然，技术领域日新月异，还有其他优秀的解决方案我尚未了解。

今天，我将为大家分享，如何在 Kubernetes 集群中手动安装 Kubernetes NFS Subdir External Provisioner 插件。这是一个强大的工具，能够实现为 Kubernetes 集群提供自动化的基于 NFS 存储的持久化动态卷管理能力。通过实战演示，您将学会如何将 NFS 作为后端的持久化存储解决方案集成至 Kubernetes 集群。

本文核心内容概览：

NFS 持久化存储选型说明： 理解为什么选择 NFS 及其优缺点。
NFS 存储服务如何部署： 如何在openEuler 上部署配置 NFS 存储
手动安装 NFS Subdir External Provisioner：一步步指导如何安装、配置、卸载这一关键插件。
实战演示：创建测试资源，体验 NFS 作为持久化存储的效果。

实战服务器配置(架构1:1复刻小规模生产环境，配置略有不同)

主机名	IP	CPU	内存	系统盘	数据盘	用途
ksp-registry	192.168.9.90	4	8	40	200	Harbor 镜像仓库
ksp-control-1	192.168.9.91	4	8	40	100	KubeSphere/k8s-control-plane
ksp-control-2	192.168.9.92	4	8	40	100	KubeSphere/k8s-control-plane
ksp-control-3	192.168.9.93	4	8	40	100	KubeSphere/k8s-control-plane
ksp-worker-1	192.168.9.94	4	16	40	100	k8s-worker/CI
ksp-worker-2	192.168.9.95	4	16	40	100	k8s-worker
ksp-worker-3	192.168.9.96	4	16	40	100	k8s-worker
ksp-storage-1	192.168.9.97	4	8	40	300+	Ceph/Longhorn/NFS/ElasticSearch
ksp-storage-2	192.168.9.98	4	8	40	300+	Ceph/Longhorn/ElasticSearch
ksp-storage-3	192.168.9.99	4	8	40	300+	Ceph/Longhorn/ElasticSearch
ksp-gpu-worker-1	192.168.9.101	4	16	40	100	k8s-worker(GPU NVIDIA Tesla M40 24G)
ksp-gpu-worker-2	192.168.9.102	4	16	40	100	k8s-worker(GPU NVIDIA Tesla P100 16G)
ksp-gateway-1	192.168.9.103	2	4	40		自建应用服务代理网关/VIP：192.168.9.100
ksp-gateway-2	192.168.9.104	2	4	40		自建应用服务代理网关/VIP：192.168.9.100
ksp-mid	192.168.9.105	4	8	40	100	部署在 k8s 集群之外的服务节点（Gitlab 等）
合计	15	56	152	600	2000+

实战环境涉及软件版本信息

操作系统：openEuler 22.03 LTS SP3 x86_64
KubeSphere：v3.4.1
Kubernetes：v1.28.8
KubeKey: v3.1.1
Containerd：1.7.13
NVIDIA GPU Operator：v24.3.0
NVIDIA 显卡驱动：550.54.15
Kubernetes NFS Subdir External Provisioner：4.0.18

1. 前置条件

1.1 NFS 选型说明

本文介绍的内容可直接用于研发、测试环境，对于生产环境不建议使用 NFS 存储，主要原因如下：

单点故障，生产上使用第一要解决的就是 NFS 单点的问题，有解决方案但是很麻烦，本文不涉及
网络故障，要考虑 NFS 对网络的依赖度，网络波动造成的连接异常等问题
容量限制，无法限制实际的使用容量
存储的冗余，要考虑 NFS 底层磁盘是否有冗余备份
有些组件和应用不兼容 NFS 存储（比如 Promethues，未实际验证，只是在网上多次看到相关的说明）
性能优化（Pod 少的时候还可以，连接挂载点多了怎么优化是个问题）

虽然，我个人不建议在生产环境使用 NFS 作为 Kubernetes 的后端持久化存储。但是，在我做过的小调研中发现，生产环境使用 NFS 的比率还挺高。

这是为什么呢？我左思右想可能的原因有：

NFS 简单易维护
使用 NFS 的生产环境对于业务的中断和数据的丢失有一定的容忍度（或许对中断和数据丢失都有对应的应对方案）
成本低廉，降本增效（笑）。一台或两台存储就能搞定，比 Ceph、GlusterFS 动辄三台起步需要的资源少的太多了（但是也要考虑，因为存储导致集群故障从而导致业务故障的后果）

生产环境一定要使用 NFS？建议仔细考虑以下几点：

建议选择硬件厂商的商业集中式存储产品不要自建
存储网络一定要使用万兆网络，且有网卡冗余 bond 加持
自建的 NFS 存储数据盘一定要做 Raid，最好 Raid10
业务应用对存储 IO 能力要求高时，不要使用 NFS
是否需要 NFS 服务的高可用？如何实现？

1.2 安装 NFS 客户端

在安装 Kubernetes NFS Subdir External Provisioner 之前，Kubernetes 集群所有节点需要提前安装 NFS 客户端，否则部署过程会报错。不同操作系统 NFS 客户端的包名不同，CentOS 和 openEuler 中包名为 nfs-utils。