默认StorageClass:检查什么？

Question

我被这个问题困住了:我配置了kubeadm (目前在一个专用服务器上的集群)。我用头盔安装了elasticsearch。除了储存，它几乎工作得很好。图表使用默认的StorageClass来动态配置PV。

因此，我创建了一个默认的StorageClass (kubernetes.io/gce/pd标准)，并在apiserver中激活了DefaultStorageClass接纳插件，以支持动态配置。但这个还是没用的。pods仍然具有FailedBinding事件“对于此声明没有持久卷可用，也没有设置存储类”。

我检查了elasticsearch的舵图，它没有为它的PVC指定一个StorageClass，所以它应该可以工作。另外，我还缺少了其他的东西:我不知道kubernetes将在磁盘上分配PV的位置，我从未在任何地方配置过它。它也不在StorageClass里。

我检查了动态配置是否有效，因为它在PVC定义中插入了默认的StorageClass：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd
  creationTimestamp: "2019-12-19T10:37:04Z"
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    app: kibanaelastic-master
  name: kibanaelastic-master-kibanaelastic-master-0
  namespace: elasticsearch
  resourceVersion: "360956"
  selfLink: /api/v1/namespaces/elasticsearch/persistentvolumeclaims/kibanaelastic-master-kibanaelastic-master-0
  uid: 22b1c23a-312e-4b56-a0bb-17f2da372509
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: slow
  volumeMode: Filesystem
status:
  phase: Pending

那我还应该查什么？

有线索吗？

Answer 1

别介意我发现了错误。我在默认存储类中使用了错误的提供程序。而这个供给者没有被配置。我很好奇如何才能让这个错误更加明显和容易理解。

Answer 2

让我在这里广告我的5分钱:)。

我不知道kubernetes将在磁盘上分配PV，我从未在任何地方配置它。它也不在StorageClass里。

假设我们使用的是GCP，存储类的整个过程，预计PV声明将以以下方式工作：

1. StorageClass
2. PersistentVolumeClaim (例如，在部署中的存储Class)
3. volumes:字段中)

示例：

$ cat minio-storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: minio-disk
provisioner: kubernetes.io/gce-pd
parameters:
    type: pd-standard
reclaimPolicy: Delete
volumeBindingMode: Immediate

在GCP中创建一个新的存储类。

然后，我们使用存储类参数声明我们的持久卷：

$ cat minio-pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: minio-claim
  namespace: default
  annotations:
    volume.beta.kubernetes.io/storage-class: minio-disk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

重要的是我们已经在minio-disk中指定了annotations存储类。在此基础上，我们可以看到，最小的索赔PVC是创建和阶段是“绑定”。

​

​

在此之后，我们可以在部署中使用它(为了清楚起见，我省略了文件的3/4 )：

cat minio-deploy.yaml 
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: minio
  ...
spec:
  ...
  template:
    ...
    spec:
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: minio-claim
     ...

，我很好奇如何才能让这个错误更加明显和容易理解。

如果您将PVC视为“未决”，您可能会使用：$ kubectl describe persistentvolumeclaim <your-pvc-name>来麻烦它。

在我的例子中，看起来是：

$ kubectl describe persistentvolumeclaim minio-claim-broken

Name:          minio-claim-broken
Namespace:     default
StorageClass:  minio-disk-1
Status:        Pending
Volume:        
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-class: minio-disk-1
               volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Mounted By:    <none>
Events:
  Type     Reason              Age                   From                         Message
  ----     ------              ----                  ----                         -------
  Warning  ProvisioningFailed  61s (x10 over 6m47s)  persistentvolume-controller  Failed to provision volume with StorageClass "minio-disk-1": invalid option "diskformat" for volume plugin kubernetes.io/gce-pd

这提供了对创建错误的洞察(存储类定义中的无效选项)

希望有帮助:)