存储

红帽构建的 MicroShift 存储被广泛分为两类，即临时存储和持久性存储。

除了持久性存储外，Pod 和容器还需要临时或短暂的本地存储才能进行操作。此临时存储的生命周期不会超过每个 pod 的生命周期，且此临时存储无法在 pod 间共享。

Pod 使用临时本地存储进行涂销空间、缓存和日志。与缺少本地存储相关的问题包括：

与持久性卷不同，临时存储是非结构化的，空间在节点上运行的所有 pod 共享，系统的其他使用，以及红帽构建的 MicroShift。临时存储框架允许 Pod 指定其临时本地存储需求。它还允许红帽构建 MicroShift 来保护节点不受过度使用本地存储的影响。

虽然临时存储框架允许管理员和开发人员更好地管理本地存储，但 I/O 吞吐量和延迟不会直接生效。

主分区中始终提供临时本地存储。创建主分区的基本方法有两种： root 和 runtime。

root

默认情况下，该分区包含 kubelet 根目录、/var/lib/kubelet/ 和 /var/log/ 目录。此分区可以在用户 Pod、OS 和 Kubernetes 系统守护进程间共享。Pod 可以通过 EmptyDir 卷、容器日志、镜像层和容器可写层来消耗这个分区。kubelet 管理这个分区的共享访问和隔离。这个分区是临时的，应用程序无法预期这个分区中的任何性能 SLA（如磁盘 IOPS）。

Runtime

这是一个可选分区，可用于 overlay 文件系统。红帽构建的 MicroShift 会尝试识别并提供共享访问以及这个分区的隔离。容器镜像层和可写入层存储在此处。如果 runtime 分区存在，则 root 分区不包含任何镜像层或者其它可写入的存储。

集群管理员可以通过设置配额在非终端状态的所有 Pod 中定义临时存储的限制范围，及临时存储请求数量，来管理项目中的临时存储。开发人员也可以在 Pod 和容器级别设置这个计算资源的请求和限值。

您可以通过指定请求和限值来管理本地临时存储。pod 中的每个容器可以指定以下内容：

临时存储的限制和请求以字节数量来衡量。您可以使用以下后缀之一将存储表示为普通整数或固定点号：E、P、T、G、M、k。您还可以使用两的指数：Ei、Pi、Ti、Gi、Mi Ki。例如，以下数量全部代表大约相同的值：128974848、129e6、129M 和 123Mi。后缀的大小写非常重要。如果您指定了 400m 的临时存储，这个请求 0.4 字节，而不是 400 mebibytes 字节 (400Mi) 或 400 megabytes (400M)，这可能是预期的。

以下示例显示了有两个容器的 pod。每个容器请求 2GiB 本地临时存储。每个容器限制为 4GiB 本地临时存储。因此，pod 的请求为 4GiB 本地临时存储，限值为 8GiB 本地临时存储。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 
      limits:
        ephemeral-storage: "4Gi" 
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi" 
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 

      limits:
        ephemeral-storage: "4Gi" 

    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi" 

    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

pod 规格中的此设置会影响调度程序对调度 pod 的决定，以及 kubelet 如何驱除 pod。首先，调度程序确保调度容器的资源请求总和小于节点的容量。在这种情况下，只有在可用临时存储（可分配资源）超过 4GiB 时，pod 才能分配给节点。

其次，在容器级别上，因为第一个容器设置了资源限值，kubelet 驱除管理器会测量此容器的磁盘用量，并在此容器的存储使用量超过其限制时驱除 pod (4GiB)。在 pod 级别，kubelet 通过添加该 pod 中所有容器的限制来达到总体 pod 存储限制。在本例中，pod 级别的总存储使用量是所有容器的磁盘用量总和，以及 pod 的 emptyDir 卷。如果这个总用量超过整个 pod 存储限制 (4GiB)，则 kubelet 也会标记 pod 进行驱除。

您可以使用 /bin/df 作为监控临时容器数据所在卷的临时存储使用情况的工具，即 /var/lib/kubelet 和 /var/lib/containers。如果集群管理员将 /var/lib/containers 放置在单独的磁盘上，则可以使用 df 命令来显示 /var/lib/kubelet 的可用空间。

要在 /var/lib 中显示已用和可用空间的信息，请输入以下命令：

df -h /var/lib

$ df -h /var/lib

输出显示 /var/lib 中的临时存储使用情况：

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

通用临时卷是临时卷类型，可以由支持持久性卷和动态置备的所有存储驱动程序提供。通用临时卷与 emptyDir 卷类似，它们为从头开始数据提供每个 pod 目录，这通常在置备后为空。

通用临时卷在 pod 规格中内联指定，并遵循 pod 的生命周期。它们与 pod 一起创建和删除。

通用临时卷具有以下功能：

卷声明的参数允许在 pod 的卷源内。支持声明(PVC)的标签、注解和整个字段。当创建这样的 pod 时，临时卷控制器随后会在与 pod 相同的命名空间中创建实际的 PVC 对象（来自 创建通用临时卷 流程中显示的模板），并确保在 pod 被删除时删除 PVC。这会以两种方式之一触发卷绑定和置备：

就资源限制而言，具有通用临时存储的 pod 是提供该临时存储的 PVC 的所有者。当 pod 被删除时，Kubernetes 垃圾回收器会删除 PVC，然后，后者通常会触发删除卷，因为存储类的默认重新声明策略是删除卷。您可以使用一个带有保留策略的存储类创建 quasi-ephemeral 本地存储：存储会活跃 pod，在这种情况下，您必须确保卷清理单独发生。虽然这些 PVC 存在，它们可以像任何其他 PVC 一样使用。特别是，可以在卷克隆或快照中被引用为数据源。PVC 对象也保存卷的当前状态。

您可以启用通用临时卷功能，以便可以创建 pod 的用户也可以间接创建持久性卷声明 (PVC)。即使这些用户没有直接创建 PVC 的权限，此功能也可以正常工作。集群管理员必须了解这一点。如果这不适用于您的安全模型，请使用准入 Webhook 来拒绝对象，如具有通用临时卷的 pod。

PVC 的一般命名空间配额仍适用，因此即使允许用户使用此新机制，它们也无法使用它来绕过其他策略。

自动创建的持久性卷声明(PVC)由 pod 名称和卷名称的组合命名，中间带有连字符(-)。这种命名惯例还引入了不同 pod 之间以及 pod 和手动创建 PVC 之间潜在的冲突。

例如，pod-a 带有卷 scratch，pod 带有卷 a-scratch，它们都使用相同的 PVC 名称 pod-a-scratch。

检测到这样的冲突，如果为 pod 创建，PVC 仅用于临时卷。此检查基于所有权关系。现有 PVC 不会被覆盖或修改，但这不会解决冲突。如果没有正确的 PVC，pod 无法启动。

PVC 特定于一个命名空间，开发人员创建并使用它作为使用 PV 的方法。PV 资源本身并不特定于任何单一命名空间；它们可以在整个红帽构建的 MicroShift 集群间共享，并从任何命名空间进行声明。在 PV 绑定到 PVC 后，就不会将 PV 绑定到额外的 PVC。这会影响到一个命名空间的 PV 的影响。

PV 由 PersistentVolume API 对象定义，它代表了集群中现有存储的片段，这些存储可以由集群管理员静态置备，也可以使用 StorageClass 对象动态置备。它与一个节点一样，是一个集群资源。

PV 是卷插件，与 Volumes 资源类似，但PV 的生命周期独立于任何使用它的 pod。PV 对象捕获存储实现的详情，即 LVM、主机文件系统（如 hostpath 或原始块设备）。

与 PersistentVolumes 一样，PersistentVolumeClaims (PVCs) 是 API 对象，代表开发人员对存储的一个请求。它与一个 pod 类似，pod 会消耗节点资源， PVC 消耗 PV 资源。例如：pod 可以请求特定级别的资源，比如 CPU 和内存，而 PVC 可以请求特定的存储容量和访问模式。OpenShift Container Platform 支持的访问模式也可以在红帽构建的 MicroShift 中定义。但是，因为红帽构建的 MicroShift 不支持多节点部署，所以只有 ReadWriteOnce (RWO)。

PV 是集群中的资源。PVC 是对这些资源的请求，也是对该资源的声明检查。PV 和 PVC 之间的交互有以下生命周期。

每个 PV 都会包括一个 spec 和 status，它们分别代表卷的规格和状态，例如：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 
spec:
  capacity:
    storage: 5Gi 
  accessModes:
    - ReadWriteOnce 
  persistentVolumeReclaimPolicy: Retain 
  ...
status:
  ...

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 

spec:
  capacity:
    storage: 5Gi 

  accessModes:
    - ReadWriteOnce 

  persistentVolumeReclaimPolicy: Retain 

  ...
status:
  ...

oc get pv <pv-claim>

$ oc get pv <pv-claim>

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 

    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

每个 PersistentVolumeClaim 对象都会包括一个 spec 和 status，它们分别代表了声明的规格和状态。例如：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim 
spec:
  accessModes:
    - ReadWriteOnce 
  resources:
    requests:
      storage: 8Gi 
  storageClassName: gold 
status:
  ...

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim 

spec:
  accessModes:
    - ReadWriteOnce 

  resources:
    requests:
      storage: 8Gi 

  storageClassName: gold 

status:
  ...

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

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 

        name: mypd 

  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 

如果存储卷包含很多文件（1,000,000 或更多），您可能会遇到 pod 超时问题。

这是因为，红帽构建的 MicroShift 会递归更改每个卷内容的所有权和权限，以便在挂载卷时与 pod 的 securityContext 中指定的 fsGroup 匹配。对于大型卷，检查和更改所有权和权限可能会非常耗时，从而会减慢 pod 启动的速度。您可以使用 securityContext 中的 fsGroupChangePolicy 字段来控制红帽构建的 MicroShift 检查和管理卷的所有权和权限的方式。

fsGroupChangePolicy 定义在 pod 中公开卷之前更改卷的所有权和权限的行为。此字段仅适用于支持 fsGroup- 控制的所有权和权限。此字段有两个可能的值：

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" 
  ...

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" 

  ...

您可以在存储卷被创建后，使用 Container Storage Interface (CSI) 来扩展它们。

CSI 卷扩展不支持以下内容：

您可以使用本地存储操作器(LSO)手动扩展持久性卷(PV)和持久性卷声明(PVC)。

根据需要，kubelet 应该自动扩展卷上的底层文件系统，并更新 PVC 的 status 字段来反映新的大小。

根据需要重新定义文件系统大小的卷类型扩展 PVC，如 GCE Persistent Disk 卷(gcePD)、AWS Elastic Block Store EBS (EBS)和 Cinder，分为两个步骤。首先，扩展云供应商中的卷对象。其次，扩展节点上的文件系统。

只有在使用这个卷启动新的 pod 时，才会在该节点中扩展文件系统。

如果扩展底层存储失败，红帽构建的 MicroShift 管理员可以手动恢复持久性卷声明(PVC)状态并取消调整大小的请求。否则，控制器会持续重试大小的请求。

在红帽构建的 MicroShift 中使用 LVMS 需要以下系统规格：

Warning  ProvisioningFailed    3s (x2 over 5s)  topolvm.cybozu.com_topolvm-controller-858c78d96c-xttzp_0fa83aef-2070-4ae2-bcb9-163f818dcd9f failed to provision volume with
StorageClass "topolvm-provisioner": rpc error: code = ResourceExhausted desc = no enough space left on VG: free=(BYTES_INT), requested=(BYTES_INT)

Warning  ProvisioningFailed    3s (x2 over 5s)  topolvm.cybozu.com_topolvm-controller-858c78d96c-xttzp_0fa83aef-2070-4ae2-bcb9-163f818dcd9f failed to provision volume with
StorageClass "topolvm-provisioner": rpc error: code = ResourceExhausted desc = no enough space left on VG: free=(BYTES_INT), requested=(BYTES_INT)

在红帽构建的 MicroShift 启动后，LVMS 会自动部署到 openshift-storage 命名空间中的集群。

LVMS 使用 StorageCapacity 跟踪来确保在请求的存储大于卷组可用存储时不会调度带有 LVMS PVC 的 pod。有关 StorageCapacity 跟踪的更多信息，请参阅 Storage Capacity。

当红帽构建的 MicroShift 运行时，它将使用 /etc/microshift/lvmd.yaml 中的 LVMS 配置（如果提供的话）。您必须将您创建的任何配置文件放在 /etc/microshift/ 目录中。

红帽构建的 MicroShift 支持通过 LVM 配置，并允许您指定自定义卷组、精简卷置备参数和保留未分配的卷组空间。您可以随时编辑您创建的 LVMS 配置文件。您必须重启红帽构建的 MicroShift，以便在编辑该文件后部署配置更改。

以下 lvmd.yaml 示例文件显示了基本的 LVMS 配置：

socket-name: 
device-classes: 
  - name: 
    volume-group: 
    spare-gb: 
    default: 
  - name: hdd
    volume-group: hdd-vg
    spare-gb: 10
  - name: striped
    volume-group: multi-pv-vg
    spare-gb: 10
    stripe: 
    stripe-size: 
  - name: raid
    volume-group: raid-vg
    lvcreate-options: 
      - --type=raid1

socket-name: 

device-classes: 

  - name: 

    volume-group: 

    spare-gb: 

    default: 

  - name: hdd
    volume-group: hdd-vg
    spare-gb: 10
  - name: striped
    volume-group: multi-pv-vg
    spare-gb: 10
    stripe: 

    stripe-size: 

  - name: raid
    volume-group: raid-vg
    lvcreate-options: 

      - --type=raid1

可以使用专用选项 (stripe 和 stripe-size) 和 lvcreate-options 来配置条带。可以使用任一选项，但不能一起使用它们。将 stripe 和 stripe-size 与 lvcreate-options 一起使用会导致重复参数到 lvcreate。您不应该同时设置 lvcreate-options: ["--stripes=n"] 和 stripe: n。但是，当 lvcreate-options 没有用于条带时，您可以同时使用这两个选项。例如：

stripe: 2
lvcreate-options: ["--mirrors=1"]

stripe: 2
lvcreate-options: ["--mirrors=1"]

LVMS StorageClass 使用一个默认 StorageClass 部署。任何没有自动定义的 .spec.storageClassName 的 PersistentVolumeClaim 对象，都会有一个从默认 StorageClass 置备的 PersistentVolume。使用以下步骤将逻辑卷置备并挂载到 pod。