kubernetes/minikube

Creation of additional storage classes with dynamic volume provisioning: impossible or documentation lacking?

Ouverte

#11 947 ouverte le 9 juil. 2021

Voir sur GitHubGuide contributeur
 (27 commentaires) (2 réactions) (0 personne assignée)Go (5 222 forks)batch import
addon/storage-provisionerhelp wantedkind/featurelifecycle/stalepriority/backlog

Métriques du dépôt

Stars
 (31 799 étoiles)
Métriques de merge PR
 (Merge moyen 12j 19h) (43 PRs mergées en 30 j)

Description

Running minikube version: v1.20.0, commit: c61663e942ec43b20e8e70839dcca52e44cd85ae

There is only one storage class created when starting a minikube:

$ kubectl get sc
NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   k8s.io/minikube-hostpath   Delete          Immediate           false                  18h

Dynamic Provisioning in this storage class works fine.

I would like to add more storage classes with dynamic volume provisioning, so that I could test my PersistentVolumeClaim manifests (written for EKS) on Minikube without modifications. These storage classes need not be different physically or programmatically from the standard Minikube sc, but I need to test manifests for other clusters without modifications. Those manifests have different "storageClassName" attributes, like "gp3", "sc1" etc.

If the creation of additional storage classes with dynamic volume provisioning is possible, I cannot find it anywhere if it's documented for Minikube.

Guide contributeur

Direction de recherche
Étudiez comment minikube crée la classe de stockage par défaut 'standard'. Examinez le code du provisionneur hostpath dans le dépôt minikube (probablement dans pkg/storage ou similaire). Déterminez s'il existe un moyen de configurer des classes de stockage supplémentaires via un fichier de configuration ou des drapeaux de ligne de commande. Envisagez de proposer une fonctionnalité permettant aux utilisateurs de définir des classes de stockage personnalisées via un fichier de configuration ou une nouvelle commande. Vérifiez la documentation existante et voyez s'il manque quelque chose.
Stack technique
go
Domaine
backendinfrastructuredevops
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
Kuberneteskubectl
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60