时间戳

首页 > 解决方案 > 本地持久卷中的容量

kubernetes - 本地持久卷中的容量

问题描述

我有一个存储类：

    kubectl describe storageclass my-local-storage

    Name:            my-local-storage
    IsDefaultClass:  No
    Annotations:     kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"my-local-storage"},"provisioner":"kubernetes.io/no-provisioner","volumeBindingMode":"WaitForFirstConsumer"}

    Provisioner:           kubernetes.io/no-provisioner
    Parameters:            <none>
    AllowVolumeExpansion:  <unset>
    MountOptions:          <none>
    ReclaimPolicy:         Delete
    VolumeBindingMode:     WaitForFirstConsumer
    Events:                <none>

永久卷

kubectl describe pv my-local-pv
Name:              my-local-pv
Labels:            <none>
Annotations:       pv.kubernetes.io/bound-by-controller: yes
Finalizers:        [kubernetes.io/pv-protection]
StorageClass:      my-local-storage
Status:            Bound
Claim:             default/my-claim
Reclaim Policy:    Retain
Access Modes:      RWO
VolumeMode:        Filesystem
Capacity:          1Mi
Node Affinity:     
  Required Terms:  
    Term 0:        kubernetes.io/hostname in [kubenode2]
Message:           
Source:
    Type:  LocalVolume (a persistent volume backed by local storage on a node)
    Path:  /home/node/serviceLogsNew
Events:    <none>

持久卷声明

node@kubemaster:~/Desktop$ kubectl describe pvc my-claim
Name:          my-claim
Namespace:     default
StorageClass:  my-local-storage
Status:        Bound
Volume:        my-local-pv
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Mi
Access Modes:  RWO
VolumeMode:    Filesystem
Mounted By:    podname-deployment-897d6947b-hnvvq
               podname-deployment-897d6947b-q4f79
Events:        <none>

现在，我创建了一个容量为：1Mi 的持久卷。

我正在运行 2 个使用 PVC 连接到 PV 的 pod。Pod 正在创建日志文件。用于 PV 的文件夹 (/home/node/serviceLogsNew) 中的文件大小增加到 5 MB。仍然一切正常。

那么，使用本地 PV / PVC 时会忽略容量吗？是否可配置？

标签： kubernetes

解决方案

请看一下这个github问题。我相信这个评论也回答了你的问题：

这按预期工作，kube 不能/不会强制执行 PV 的容量，PV 上的容量字段只是一个标签。这取决于“管理员”，即 PV 的创建者来准确标记它，以便当用户创建需要 >= X Gi 的 PVC 时，他们得到他们想要的。

此建议可能对您的情况也有用：

...如果您想要使用主机路径进行硬容量边界，那么您应该创建一个具有您需要的大小的分区，或者使用文件系统配额。

如果这只是临时数据，那么您可以考虑使用 emptyDir 卷。从 1.7 开始，您可以指定容量限制，如果超出限制，kubelet 将驱逐您的 pod。

报告该问题的人实际上使用了 hostPath卷类型，但本地的工作方式几乎相同，并且capacity在PV定义设置时，此处应用了相同的规则。Kubernetes没有任何机制可以对您挂载到Podfrom的目录强制执行特定的磁盘配额node。

请注意，在您的PV定义中，您可以设置capacity比底层磁盘的实际容量高得多的 a。这样PV将在没有任何错误的情况下创建，并且可以使用，允许您将数据写入到其实际最大容量。

虽然定义只是一个标签，capacity但它的故事有点不同。在这种情况下可以解释为对特定最小容量的请求。如果您的存储供应商能够满足您的请求，则将供应存储。如果它无法以您声明中定义的最小容量为您提供存储，则不会对其进行配置。PVPVCcapacity

假设您已经PV基于主机/节点上的特定目录定义了 a，容量为150Gi. 如果您PVC在其中定义您要求的151Gi，则不会像PV声明的那样配置存储capacity（无论它是真实值还是某些虚构的值）将无法满足我们在PVC. 因此，在 的情况下PVC，capacity可以解释为一种约束，但它仍然不能强制/限制使用实际可用的底层存储。

不要忘记，本地卷代表已安装的本地存储设备，例如磁盘、分区或目录，因此它不仅仅是您可以使用的目录。它可以是例如您的/dev/sdb磁盘或/dev/sda5分区。您还可以决定使用具有严格定义容量的 LVM 分区。

推荐阅读