Kubernetes示例yaml：3. service-statefulset.yaml

service-statefulset.yaml 示例

apiVersion: apps/v1
kind: statefulset
metadata:
  ......
spec:
  ......
          volumeMounts:
          - name: pvc
            mountPath: /var/lib/arangodb3
  VolumeClaimTemplates:
  - metadata:
      name: pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storangeClassName: hw-block-class
      resources:
        requests:
          storange: 8Gi

---
apiVersion: v1
kind: Service
metadata:
  ...
spec:
  ...

解释

• volumeMounts：定义了 StatefulSet 中 Pod 的 Volume 挂载信息。

  • name: pvc：指定了要挂载的 VolumeClaimTemplates 的名称为 pvc，这需要与下面定义的 VolumeClaimTemplates 的名称相匹配。
  • mountPath: /var/lib/arangodb3：指定了将 Volume 挂载到容器内部的 /var/lib/arangodb3 路径下，使得容器可以访问该路径下的持久化存储。

• volumeClaimTemplates：定义了 StatefulSet 中使用的 PersistentVolumeClaim (PVC) 模板。

  • metadata.name: pvc：指定了 PVC 模板的名称为 pvc，这个名称将被上面的 volumeMounts 中使用。
  • spec.accessModes: [ "ReadWriteOnce" ]：指定了 PVC 的访问模式为 ReadWriteOnce，表示该卷可以被单个节点挂载为读写模式。
  • spec.storageClassName: hw-block-class：指定了 PVC 的存储类名称为 hw-block-class，用于动态分配存储资源。
  • spec.resources.requests.storage: 8Gi：指定了 PVC 请求的存储容量为 8GiB。

综合起来，这段配置的作用是：

• 在 Pod 中创建一个名为 pvc 的 PersistentVolumeClaim (PVC)，请求至少 8GB 的存储空间，使用存储类 hw-block-class，并且可以在单个节点上以读写模式挂载。
• 将名为 pvc 的 Volume（实际映射到 PVC）挂载到容器内部的 /var/lib/arangodb3 路径下，让容器可以访问该持久化存储空间，例如存储 ArangoDB 数据或配置等。

问题

问题1

• spec.storageClassName: hw-block-class：指定 PVC 的存储类名称为 hw-block-class，用于匹配集群中已定义的存储类，从而提供不同的存储选项。这个从哪儿来的

存储类（StorageClass）是 Kubernetes 中用于动态管理持久化存储的对象。存储类定义了动态分配的存储属性，例如存储类型、复制策略、IOPS 等。通过定义存储类，集群管理员可以为不同的应用程序提供不同的存储选项，并根据需求自动分配存储资源。

在上述配置中，spec.storageClassName: hw-block-class 这一行指定了 PersistentVolumeClaim (PVC) 使用的存储类名称为 hw-block-class。这意味着该 PVC 请求的存储空间会使用集群中预先定义的名为 hw-block-class 的存储类来分配对应的存储资源。存储类定义了存储的类型和其他属性，例如是云存储还是本地存储、存储的容量、访问模式等。

在 Kubernetes 集群中，存储类通常由集群管理员预先定义，并且根据不同的存储需求创建不同的存储类。例如，对于不同的应用程序可能需要不同类型的存储，比如高性能存储、低成本存储、备份存储等。通过指定存储类，开发人员可以方便地为他们的应用程序请求适合的存储资源，而不需要关心底层的存储细节。

因此，spec.storageClassName: hw-block-class 这一行是根据集群管理员预先定义的存储类来指定 PVC 的存储属性，以满足应用程序对存储资源的需求。

问题2

• spec.accessModes: [ "ReadWriteOnce" ]：指定 PVC 的访问模式为 ReadWriteOnce，表示该卷可以被单个节点挂载为读写模式。其他访问模式还包括 ReadOnlyMany 和 ReadWriteMany，分别用于多节点只读和多节点读写。分别有什么意义和作用呢？

• ReadWriteOnce (RWO):
  • 该访问模式表示卷可以被单个节点挂载为读写模式。
  • 单个 Pod 可以挂载该卷，并且可以同时对该卷进行读取和写入操作。
  • 适用于需要单个节点独占性能或需要写入操作的场景。
• ReadOnlyMany (ROX):
  • 该访问模式表示卷可以被多个节点挂载为只读模式。
  • 多个 Pod 可以同时挂载该卷，但只能对该卷进行读取操作，无法进行写入操作。
  • 适用于多个 Pod 需要共享只读数据的场景，例如静态文件或配置文件等。
• ReadWriteMany (RWX):
  • 该访问模式表示卷可以被多个节点挂载为读写模式。
  • 多个 Pod 可以同时挂载该卷，并且可以对该卷进行读取和写入操作。
  • 适用于需要多个 Pod 共享读写数据的场景，例如数据库或共享文件系统等。

在您的配置中，使用了 spec.accessModes: [ "ReadWriteOnce" ]，表示该 PVC 请求的存储卷可以被单个节点挂载为读写模式。这通常用于需要单个 Pod 对存储进行读写操作的场景。如果需要多个 Pod 共享只读数据或共享读写数据，可以根据实际需求选择其他的访问模式，如 ReadOnlyMany 或 ReadWriteMany。

问题3

没用deploment而是用了statefulset，有什么意义呢？

1. 稳定的网络标识符：
   • StatefulSet 为每个 Pod 分配一个稳定的网络标识符，通常以序号的形式命名，例如 pod-0, pod-1 等。
   • 这些标识符对于有状态的应用程序（如数据库）非常重要，因为它们确保了每个 Pod 都有唯一的标识符，并且可以持久化地存储和管理数据。
2. 有序部署和扩展：
   • StatefulSet 支持有序部署和扩展。即使在有多个副本的情况下，StatefulSet 也会确保 Pod 的创建、启动和关闭都是有序的。
   • 这对于依赖特定顺序启动或关闭的应用程序非常重要，例如数据库集群中的主节点和从节点顺序启动。
3. 稳定的持久化存储：
   • StatefulSet 结合 PersistentVolumeClaim (PVC) 可以提供稳定的持久化存储，每个 Pod 都可以访问其自己的持久化存储卷。
   • 这对于需要持久化存储的有状态应用程序（如数据库、消息队列）非常关键，确保数据不会丢失或被随意清理。
4. 有状态应用程序支持：
   • StatefulSet 更适合部署有状态应用程序，例如数据库、缓存系统等，这些应用程序需要稳定的网络标识符和持久化存储。

总的来说，如果您的应用程序是有状态的，并且需要稳定的网络标识符、有序部署和扩展以及持久化存储，那么使用 StatefulSet 是更合适的选择。而 Deployment 则更适用于无状态应用程序或可以快速水平扩展的应用程序。

问题4

PVC 需要在外部创建是吗？

是的，PersistentVolumeClaim (PVC) 需要在 Kubernetes 集群外部先创建好，然后在 Pod 或 StatefulSet 的配置中引用该 PVC。下面是一些创建 PVC 的步骤：

1. 定义 PersistentVolumeClaim：
   在 Kubernetes 集群外部（通常是通过kubectl或YAML文件），定义要创建的 PersistentVolumeClaim。在 PVC 的定义中通常包括存储类、访问模式、请求的存储容量等信息。
2. 创建 PersistentVolumeClaim：
   使用kubectl apply命令或其他管理工具，在 Kubernetes 集群中创建上述定义的 PersistentVolumeClaim。Kubernetes 将根据 PVC 的定义请求集群中可用的持久化存储资源。
3. 在 Pod 或 StatefulSet 中引用 PVC：
   在 Pod 或 StatefulSet 的配置文件中，通过volumeClaimTemplates或volumeMounts等字段引用上述创建的 PersistentVolumeClaim。这样，Pod 或 StatefulSet 就可以访问到该 PVC 提供的持久化存储空间。

总的来说，PersistentVolumeClaim (PVC) 是对持久化存储的一种请求，它需要依赖集群中已经存在的持久化存储资源（如存储卷）来提供实际的存储空间。因此，在创建 PVC 之前，您需要确保集群中已经存在适合的存储资源或存储类，并按照需要进行配置和管理。

创建存储类（StorageClass）通常有几种方式，取决于您的 Kubernetes 环境和存储后端支持的特性。下面是几种常见的创建存储类的方式示例：

1. 静态创建存储类
   静态创建存储类是通过直接创建存储类的 YAML 文件或使用 kubectl 命令手动创建存储类的方式。

示例 YAML 文件（hw-block-class.yaml）：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: hw-block-class
provisioner: your-provisioner-name
parameters:
  type: block
  zone: us-west1-a

使用 kubectl 创建：kubectl apply -f hw-block-class.yaml

2. 动态创建存储类
   动态创建存储类是通过集群中已经安装的存储控制器动态创建存储类的方式。您需要确保已经安装了支持动态存储的存储插件，如csi-hostpath、rook、ceph等。

示例 YAML 文件（dynamic-hw-block-class.yaml）：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: dynamic-hw-block-class
provisioner: your-dynamic-provisioner-name
parameters:
  type: block
  zone: us-west1-a

使用 kubectl 创建：kubectl apply -f dynamic-hw-block-class.yaml
注意事项：
provisioner 字段指定了存储后端的名称，例如 CSI 驱动、FlexVolume 驱动或云服务提供商的存储插件名称。
parameters 字段中的配置取决于您的存储后端，例如存储类型、区域、性能选项等。
在实际操作中，请根据您的环境和存储后端的要求调整上述示例中的字段和数值。创建存储类后，您就可以在 PersistentVolumeClaim (PVC) 的定义中引用该存储类，以请求动态分配的持久化存储资源。