PV和PVC是什么

在 Kubernetes (k8s) 中，Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 是管理存储资源的两个重要概念。它们抽象了存储细节，允许用户在不了解底层存储细节的情况下使用存储资源。

Persistent Volume (PV)：

• PV 是集群中的一块网络存储，由管理员预先配置或由 Kubernetes 动态配置，可以是 NFS、iSCSI、云提供商的存储系统如 AWS EBS、GCP Persistent Disks、Azure Disk Storage 等。
• PV 是集群资源，与 Pod 生命周期独立，可以被不同 Pod 复用。
• PV 有多种访问模式，如 ReadWriteOnce（单节点读写）、ReadOnlyMany（多节点只读）和 ReadWriteMany（多节点读写）。
• PV 支持不同的存储类，允许定义不同的服务等级，比如 SSD 或常规硬盘。

Persistent Volume Claim (PVC)：

• PVC 是用户对 PV 的存储请求。用户在 PVC 中定义存储的大小和访问模式等需求，而不需要指定具体的 PV。
• 当 PVC 被创建时，Kubernetes 会从可用的 PV 中找到一个匹配用户需求的卷，并建立绑定，若无可用 PV，存储类动态配置可新建一个。
• PVC 会绑定到与其大小和访问模式条件相匹配的 PV（StorageClass 参数会用来选择动态创建 PV 的配置）。
• 当 Pod 被创建时，它可以引用 PVC。Kubernetes 会确保这个 PVC 绑定的 PV 被挂载到 Pod 指定的路径上。

使用 PV 和 PVC 的过程大体上分为以下几个步骤：

1. 管理员设置 Persistent Volumes：根据集群使用的实际存储系统创建一系列 PV。
2. 用户创建 Persistent Volume Claims：用户根据自己的需求创建 PVC，声明所需的存储空间大小以及访问模式。
3. 存储绑定：Kubernetes 寻找符合 PVC 条件的 PV，并建立绑定关系。如果环境支持动态存储配额，一个新的 PV 也可以根据 PVC 请求被创建出来。
4. 使用 Persistent Volume Claims：Pod 在定义中引用 PVC。Pod 被调度到节点上时，PV 会被挂载到相应的目录，让 Pod 能使用相关的存储资源。

利用 PV 和 PVC，Kubernetes 实现了存储的声明式管理，用户无须处理存储资源的具体创建和分配细节，从而大大简化了在容器化环境中管理持久性数据的复杂性。这种模式提高了存储资源的复用性和应用的可移植性。

PV/PVC和csi插件是什么关系

在 Kubernetes (k8s) 中，Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 是存储资源的API对象，而 Container Storage Interface (CSI) 是一个标准的接口，用于连接和管理存储解决方案。这三者在 Kubernetes 存储体系中关系密切，下面逐一解释它们之间的关系：

PV 和 PVC：

• PV 和 PVC 是 Kubernetes 存储管理中的两个基本概念。PV 代表集群中的一块存储资源，它对应于底层的物理或网络存储。PVC 则是用户对存储的请求，相当于一个声明，用户通过 PVC 来请求所需的存储资源。
• 用户创建 PVC 来声明所需的存储特性（如容量和访问模式），然后 Kubernetes 系统会自动将 PVC 和合适的 PV 绑定，或者动态创建一个新的 PV 来满足 PVC 的请求。

CSI：

• CSI 是一种标准化的接口规范，旨在定义如何在 Kubernetes 这类容器编排平台中对存储资源进行操作（比如创建卷、挂载卷、快照等）。
• CSI 使得存储提供商（如云平台或者存储系统厂商）可以开发一套插件，在不修改 Kubernetes 核心代码的情况下，使其存储产品和服务与 Kubernetes 兼容。
• 当 Kubernetes 要进行存储相关操作，如根据 PVC 动态创建一个新的 PV 时，会调用符合 CSI 规范的存储插件来实现这些操作。

PV/PVC 与 CSI 的关系：

• PV/PVC 是 Kubernetes 中表示和请求存储资源的机制，它们抽象了具体实现详情，而 CSI 是底层实现这些存储操作的一种途径。
• Kubernetes 控制器会监听 PVC 请求，根据提供的细节，通过 CSI 插件与具体的存储解决方案交互，动态地创建、配置和提供 PV 资源。
• 使用 CSI 插件，管理员无需手动创建 PV 资源，当有符合条件的 PVC 请求时，PV 可以自动、动态地被创建和绑定。

归纳来说，PV 和 PVC 定义了用户如何在 Kubernetes 中请求和使用持久存储，而 CSI 提供了一个标准化的方式，让存储供应商不需要修改 Kubernetes 核心代码，就能插入他们的存储解决方案，使其能响应来自 Kubernetes 的持久存储请求，这包括动态地创建、删除和管理 PVs。

默认csi插件和当前csi插件

Kubernetes 并没有所谓的"默认" CSI（Container Storage Interface）插件。相反，Kubernetes 提供了 CSI 标准，任何存储服务供应商都可以根据该标准编写自己的CSI插件，与 Kubernetes 集成，来提供存储资源。

CSI 是一个跨产业标准，允许存储提供商将他们的解决方案接入容器编排系统，比如 Kubernetes，而不需要修改容器编排系统本身的代码。这种插件式的架构使得用户可以根据需要安装和使用特定的 CSI 插件。

一些 Kubernetes 集群可能会预先安装或推荐使用某些特定的 CSI 插件，这通常取决于被使用的 Kubernetes 部署方式或云服务提供商。例如：

• 云服务商通常会为他们的存储解决方案提供自己的 CSI 加以集成，比如 AWS EBS CSI 驱动、Google Persistent Disk CSI 驱动、Azure Disk CSI 驱动等。
• Minikube，一个轻量级的 Kubernetes 环境，使用内建的 storage-provisioner 插件来模拟持久化存储功能，但技术上它不是一个传统意义上的CSI驱动。

如果你想在 Kubernetes 集群中使用某种持久存储解决方案，你需要查看存储服务供应商是否提供对应的 CSI 插件，并按照其说明进行安装和配置。通过 Kubernetes 的生态系统，你可以找到各种支持 CSI 的存储驱动，包括但不限于云服务、软件定义存储和传统存储系统。

在 Kubernetes (K8s) 集群中，你可以通过检查集群中运行的 Pod 和 CSI 相关的 Custom Resource Definitions (CRDs) 来查询当前使用的 CSI 插件。下面是一些步骤和命令，通过它们可以查看集群中部署的 CSI 插件：

1. 查看 CSI 相关的 Pods：
   使用 kubectl 命令查看所有命名空间的 Pods，并筛选出带有 CSI 组件的 Pods。

   kubectl get pods --all-namespaces -o wide | grep csi
   

   CSI 驱动通常会以 daemonset 和/or statefulset 的形式运行在集群中。它们通常命名包含 csi，例如 csi-attacher、csi-provisioner 等。

2. 查询 CSI 驱动的 DaemonSets 和 StatefulSets：

   kubectl get daemonset,statefulset --all-namespaces | grep csi
   

   此命令将列出所有命名空间中与 CSI 相关的 DaemonSet 和 StatefulSet 资源。

3. 查看 CSI 驱动的 CRDs：
   CSI 驱动可能会有关联的 CRDs：

   kubectl get crd | grep csi
   

   CSI 会注册一些自定义资源定义（CRDs），以便管理和操作存储功能。

4. 检查 StorageClasses：
   列出现有的 StorageClasses，并查看它们各自的 provisioner。

   kubectl get storageclass
   

   存储类的 provisioner 字段通常会指向一个 CSI 驱动程序，例如 kubernetes.io/aws-ebs 或自定义 CSI 驱动程序，例如 csi.storage.com。

5. 检查 CSI Drivers：

   Kubernetes 1.14 开始引入了 CSIDriver 对象，这是一个集群范围内的资源，可以列出和描述安装在 Kubernetes 集群上的 CSI 驱动程序：

   kubectl get csidriver
   

6. 检查 CSINode 信息：

   CSINode 对象提供了节点级别的 CSI 驱动信息。它可以帮你理解每个节点上都安装了哪些 CSI 驱动：

   kubectl get csinode
   

通过上述步骤，你可以获取到关于当前 Kubernetes 集群中正在使用 CSI 插件的详细信息。如果你正在使用特定的 Kubernetes 构建或云服务提供商，他们可能会默认启用一些特定的 CSI 插件，具体信息可以通过他们的官方文档获得。

hostpath.csi.k8s.io插件是什么

hostpath.csi.k8s.io 是一个 Kubernetes CSI（Container Storage Interface）驱动程序的示例实现，它提供了一种将宿主机上路径（目录）作为卷挂载到 Pod 中的方法。

简单来说，HostPath CSI 驱动程序允许你在 Kubernetes Pod 中使用宿主机（也就是跑 Pod 的机器）的文件系统。这个 CSI 驱动通常用于测试目的，并不是为生产环境设计的。它将宿主机上的一个文件或目录作为卷暴露给所指定的 Pod，从而使得在不同的 Pod 之间共享数据变得可能。

由于 hostPath 方式只能在单个节点上工作（因为数据只存在于那个节点上），它并不能提供跨节点的数据持久性和共享访问，这是在分布式系统和云原生环境中一个很重要的特性。因此，这个驱动程序通常仅在单机环境下或者在开发和测试时用于快速简便地访问本机文件。

简单来说，如果有一个 Pod 需要对本机文件系统有访问权，开发者可以使用 hostPath CSI 驱动程序为这个 Pod 创建一个 PV (Persistent Volume) 和 PVC (Persistent Volume Claim)，然后 Pod 可以挂载这个 PVC 来存储数据。

由于 hostPath 存储方式存在数据安全和隔离方面的问题，一般建议在生产环境使用更加稳定安全的存储解决方案，比如云存储服务（GCP 的 Persistent Disks、AWS 的 EBS、Azure 的 Disk Storage）或者专业的存储系统（如 NFS、Ceph、GlusterFS 等）。

完整的PV/PVC的使用范例

以下是一个使用 hostpath.csi.k8s.io 来创建 Persistent Volume (PV) 并由 Pod 使用的示例。

第一步： 安装 HostPath CSI 驱动器

如果还未安装 HostPath CSI 驱动器，需要根据 Kubernetes 的官方指南进行安装。可以通过部署驱动器的 YAML 文件来安装，通常来说这些文件可以在 Kubernetes 的官方 GitHub 仓库的 CSI 驱动器示例目录中找到。

第二步： 创建 PersistentVolume 资源

创建一个名为 pv-hostpath.yaml 的文件，描述如下的 PersistentVolume：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: hostpath
  csi:
    driver: hostpath.csi.k8s.io
    volumeHandle: hostpath-vol
    nodePublishSecretRef:
      name: hostpath-secret
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: hostpath.csi.k8s.io

在这个配置中，我们定义了一个容量为 1Gi 的 PV，使用 HostPath CSI 驱动，并指定了一个 nodePublishSecretRef，你需要确保这个 secret 存在或者移除这一行。

使用 kubectl 创建 PV：

kubectl apply -f pv-hostpath.yaml

第三步： 创建 PersistentVolumeClaim 资源

创建一个名为 pvc-hostpath.yaml 的文件，描述如下的 PersistentVolumeClaim：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-hostpath
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: hostpath

在这个配置中，我们定义了一个匹配刚才 PV 配置（同样容量和访问模式）的 PVC。

使用 kubectl 创建 PVC：

kubectl apply -f pvc-hostpath.yaml

第四步： 创建一个使用这个 PVC 的 Pod

创建一个名为 pod-using-hostpath-pvc.yaml 的文件，描述如下的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: pvc-hostpath

在这个配置中，我们定义了一个使用前面定义的 PVC 挂载 volume 的 Nginx Pod。/var/www/html 是 Nginx 容器默认的服务目录，我们将挂载 HostPath 持久卷到这个位置。

使用 kubectl 创建 Pod：

kubectl apply -f pod-using-hostpath-pvc.yaml

注意：HostPath 存储方式只能在单个节点上工作，数据不会在集群中的其他节点上共享。因此，这个方案通常仅限于测试和开发环境使用，不适用于生产。对于生产环境，建议使用网络存储解决方案，如 AWS EBS、Google Persistent Disk 或者 NFS、Ceph 等分布式存储系统。