k8s 持久化存储解析：hostPath与NFS的应用与探索

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

一、前言

1、k8s为什么要有持久化存储

2、NFS简介

二、hostPath存储

1、hostPath工作原理

2、hostPath的定义

3、hostPath的优缺点分析

4、hostPath使用场景举例

三、NFS存储

1、NFS在Kubernetes中的应用

2、NFS的优缺点分析

一、前言

1、k8s为什么要有持久化存储

Kubernetes (k8s) 引入持久化存储是为了处理容器化应用在动态调度和生命周期管理过程中遇到的数据持久性问题。在Kubernetes中，Pod是应用实例的载体，它们具有短暂性，即Pod可以根据集群的健康状况、资源需求等因素被创建、销毁、重启或迁移到不同的节点。这就意味着，如果Pod内部的容器直接将数据写在其自身的存储空间中，一旦Pod被删除或重建，这些数据就会丢失。

持久化存储在Kubernetes中的核心作用包括：

数据持久性：允许容器在Pod被重新调度、重启或迁移时，保持对其存储数据的访问，即使Pod本身发生了变化，数据也不会丢失。
状态管理：对于状态型应用（如数据库服务MySQL、Redis等），需要确保在任何情况下都能访问和维护其关键状态数据。
资源共享：支持多容器间的共享存储，使得同一Pod内的多个容器或不同Pod间的容器能读取和修改相同的数据集。
应用可移植性：通过抽象出PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 对象，Kubernetes可以灵活地对接各种类型的存储系统（如云存储服务、网络存储、本地磁盘等），从而实现了跨不同基础设施环境的存储兼容性和可移植性。

2、NFS简介

NFS，即网络文件系统（Network File System），是一种用于在计算机系统之间共享文件和目录的协议。NFS最初由Sun公司开发，目前已经成为全球广泛使用的网络文件系统之一，无论是在企业内部网络还是在云计算环境中。

NFS允许远程计算机像访问本地文件一样访问和操作远程文件，从而方便了多台计算机之间的文件共享和协作。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。NFS不仅适用于Linux与Unix之间实现文件共享，也能实现Linux与Windows间的文件共享功能。

NFS服务器可以让PC将网络中的NFS服务器共享的目录挂载到本地端的文件系统中，这样，从本地端的系统来看，那个远程主机的目录就好像是自己的一个磁盘分区一样，使用上相当便利。

NFS的应用场景非常广泛，它可以用于办公环境，实现文件服务器的高可用性，保证数据的可靠传输和处理，提高工作效率；对于大型企业来说，NFS可以提供集中式的文件存储和管理，简化文件管理流程，降低运营成本。

二、hostPath存储

1、hostPath工作原理

HostPath的工作原理在于将宿主机的持久化存储挂载到Kubernetes集群上，使容器能够访问外部存储空间。具体来说，HostPath类型的存储卷是将工作节点上某个文件系统的目录或文件挂载到Pod中。这种挂载方式使得Pod能够独立于其生命周期访问这些存储资源，因此具有持久性。

在Kubernetes中，HostPath卷通过Volume抽象层将存储空间关联到容器，使容器可以直接访问宿主机上的文件系统。这意味着，当Pod被调度到某个节点上时，它会将宿主机上指定的目录或文件挂载到容器内部，使得容器可以像访问本地文件系统一样访问这些资源。

2、hostPath的定义

要使用hostPath在Kubernetes中创建一个Pod，我们可以编写一个YAML文件来定义这个Pod的配置。

以下是一个简单的示例，展示如何在YAML文件中使用hostPath卷：

yaml
apiVersion: v1  
kind: Pod  
metadata:  
  name: hostpath-example  
spec:  
  containers:  
  - name: mycontainer  
    image: nginx  
    volumeMounts:  
    - name: myvolume  
      mountPath: /data  
  volumes:  
  - name: myvolume  
    hostPath:  
      # 这里指定宿主机上的路径  
      path: /path/on/host  
      # 可选，指定hostPath卷的类型  
      # 默认为空字符串，表示任何类型的文件或目录都可以挂载  
      type: DirectoryOrCreate

在这个例子中，我们创建了一个名为hostpath-example的Pod，

它有一个容器mycontainer，这个容器使用了名为myvolume的卷，并将其挂载到容器的/data目录。

myvolume卷的类型是hostPath，它指定了宿主机上的/path/on/host路径作为存储源。

type字段是可选的，它指定了hostPath卷的类型。可用的类型包括：

DirectoryOrCreate：如果指定的路径不存在，则创建它作为目录。
Directory：如果指定的路径不存在，则不会创建。必须是一个已存在的目录。
FileOrCreate：如果指定的文件不存在，则创建它。
File：如果指定的文件不存在，则不会创建。必须是一个已存在的文件。
Socket：必须是已存在的UNIX套接字。
CharDevice：必须是已存在的字符设备。
BlockDevice：必须是已存在的块设备。

如果没有特定的类型需求，可以省略type字段，或者将其设置为空字符串。

保存这个YAML文件（例如，命名为hostpath-pod.yaml），然后使用kubectl命令行工具创建Pod：

kubectl apply -f hostpath-pod.yaml

之后，Pod将启动，并且容器内的/data目录将映射到宿主机上的/path/on/host目录。但要确保在宿主机上该路径是可访问的，并且Pod有足够的权限去读写这个路径。

3、hostPath的优缺点分析

优点：

直接访问宿主机文件系统：HostPath允许Pod直接访问宿主机上的文件系统，这使得某些需要直接操作宿主机文件或目录的场景变得可行。例如，当Pod需要访问Docker内部机制或特定的系统文件时，HostPath提供了这样的能力。
简单性和灵活性：相比其他复杂的存储解决方案，HostPath的配置和使用相对简单。同时，由于它直接关联到宿主机的文件系统，因此提供了较高的灵活性，可以根据需要挂载任何目录或文件。
特定场景下的实用性：在一些特定的应用场景下，如运行管理任务的系统级Pod资源，HostPath卷可以非常有用。这些Pod可能需要访问节点上的特定文件或目录来执行其任务。

缺点：

安全风险：HostPath卷允许容器直接访问宿主机的文件系统，这可能导致潜在的安全风险。如果Pod被恶意利用，攻击者可能通过访问HostPath卷来访问或修改宿主机上的敏感数据。
可靠性问题：宿主机上的文件或目录可能被容器意外修改或删除，这可能导致应用程序异常或数据丢失。特别是在多个容器或Pod共享同一个HostPath卷时，数据一致性和完整性的维护变得更加复杂。
可移植性问题：使用HostPath卷会使应用程序依赖于特定主机的文件系统结构。这意味着当应用程序需要迁移到另一个主机或集群时，可能需要重新配置HostPath卷的路径和权限，从而增加了迁移和部署的复杂性。
不适合大规模部署：由于HostPath卷是工作节点本地的存储空间，它不适合用于大规模部署或需要高可用性和持久性的场景。在大规模集群中，使用分布式存储系统或云提供商提供的存储服务通常更为合适。