Certaines applications doivent également stocker des données, mais elles sont tout à fait à l'aise avec le fait que les données ne seront pas enregistrées après un redémarrage.
Par exemple, les services de mise en cache sont limités par la RAM, mais peuvent également déplacer des données rarement utilisées vers un stockage plus lent que la RAM, avec peu d’impact sur les performances globales. Les autres applications doivent être conscientes du fait que les fichiers peuvent contenir des entrées en lecture seule, telles que des paramètres ou des clés secrètes.
Kubernetes a déjà plusieurs types , mais leur fonctionnalité est limitée à ce qui est implémenté dans les K8.
Éphémère a permis à Kubernetes d'être étendu avec des pilotes CSI pour fournir la prise en charge de volumes locaux légers. De cette façon, il est possible d'utiliser : paramètres, secrets, données d'identification, variables, etc. Les pilotes CSI doivent être modifiés pour prendre en charge cette fonctionnalité Kubernetes, car il est supposé que les pilotes standardisés classiques ne fonctionneront pas - mais il est supposé que de tels volumes peuvent être utilisés sur n'importe quel nœud sélectionné pour le pod.
Cela peut poser un problème pour les volumes qui consomment des ressources hôtes importantes ou pour le stockage disponible uniquement sur certains hôtes. C'est pourquoi Kubernetes 1.19 introduit deux nouvelles fonctionnalités de volume de test alpha qui sont conceptuellement similaires aux volumes EmptyDir :
-
volumes éphémères à usage général ;
-
Suivi de la capacité de stockage CSI.
Avantages de la nouvelle approche :
-
le stockage peut être local ou connecté via un réseau ;
-
les volumes peuvent avoir une taille spécifiée qui ne peut pas être dépassée par l'application ;
-
fonctionne avec tous les pilotes CSI qui prennent en charge le provisionnement de volumes persistants et (pour prendre en charge le suivi de la capacité) implémentent l'appel
GetCapacity; -
les volumes peuvent avoir des données initiales en fonction du pilote et des paramètres ;
-
toutes les opérations standards avec un volume (création d'un instantané, redimensionnement, etc.) sont prises en charge ;
-
les volumes peuvent être utilisés avec n'importe quel contrôleur d'application qui accepte une spécification de module ou de volume ;
-
Le planificateur Kubernetes sélectionne lui-même les nœuds appropriés, il n'est donc plus nécessaire de provisionner et de configurer des extensions de planificateur ou de modifier des webhooks.
Applications
Par conséquent, les volumes éphémères à usage général conviennent aux cas d’utilisation suivants :
Mémoire persistante en remplacement de la RAM pour Memcached
Dernières versions de memcached en utilisant de la mémoire persistante (Intel Optane, etc., environ. traducteur) au lieu de la RAM normale. Lors du déploiement de Memcached via un contrôleur d'application, vous pouvez utiliser des volumes éphémères à usage général pour demander qu'un volume d'une taille donnée soit alloué à PMEM à l'aide du pilote CSI, par exemple .
Stockage local LVM comme espace de travail
Les applications qui fonctionnent avec des données plus volumineuses que la RAM peuvent nécessiter un stockage local avec une taille ou des mesures de performances que les volumes EmptyDir classiques de Kubernetes ne peuvent pas fournir. Par exemple, à cet effet, il a été écrit .
Accès en lecture seule aux volumes de données
L'allocation d'un volume peut entraîner la création d'un volume complet lorsque :
-
restauration ;
-
créant ;
-
travail .
Ces volumes peuvent être montés en mode lecture seule.
Comment ça marche
Volumes éphémères à usage général
Une caractéristique clé des volumes éphémères à usage général est la nouvelle source de volume, EphemeralVolumeSource, contenant tous les champs permettant de créer une demande de volume (historiquement appelée demande de volume persistante, PVC). Nouveau contrôleur dans kube-controller-manager examine les pods qui créent une telle source de volume, puis crée un PVC pour ces pods. Pour le pilote CSI, cette requête ressemble aux autres, donc aucune prise en charge particulière n'est nécessaire ici.
Tant que de tels PVC existent, ils peuvent être utilisés comme n’importe quelle autre requête sur le volume. En particulier, ils peuvent être référencés comme source de données lors de la copie d'un volume ou de la création d'un instantané à partir d'un volume. L'objet PVC contient également l'état actuel du volume.
Les noms des PVC créés automatiquement sont prédéfinis : ils sont une combinaison du nom du pod et du nom du volume, séparés par un trait d'union. Les noms prédéfinis facilitent l'interaction avec le PVC car vous n'avez pas besoin de le rechercher si vous connaissez le nom du pod et le nom du volume. L'inconvénient est que le nom est peut-être déjà utilisé, ce qui est détecté par Kubernetes et, par conséquent, le démarrage du pod est bloqué.
Pour garantir que le volume est supprimé avec le pod, le contrôleur envoie une demande au volume appartenant au propriétaire. Lorsque le pod est supprimé, le mécanisme standard de garbage collection fonctionne, qui supprime à la fois la requête et le volume.
Les demandes sont mises en correspondance par le pilote de stockage via le mécanisme normal de la classe de stockage. Bien que les cours avec liaison immédiate et tardive (c'est-à-dire WaitForFirstConsumer) sont pris en charge, pour les volumes éphémères, il est logique d'utiliser WaitForFirstConsumer, le planificateur peut alors prendre en compte à la fois l'utilisation du nœud et la disponibilité du stockage lors de la sélection d'un nœud. Une nouvelle fonctionnalité apparaît ici.
Suivi de la capacité de stockage
En règle générale, le planificateur ne sait pas où le pilote CSI créera le volume. Il n'existe également aucun moyen pour le planificateur de contacter directement le conducteur pour demander ces informations. Par conséquent, le planificateur interroge les nœuds jusqu'à ce qu'il en trouve un sur lequel les volumes sont accessibles (liaison tardive) ou laisse entièrement le choix de l'emplacement au pilote (liaison immédiate).
nouveau CSIStorageCapacity, qui est en phase alpha, permet de stocker les données nécessaires dans etcd afin qu'elles soient disponibles pour le planificateur. Contrairement à la prise en charge des volumes éphémères à usage général, lorsque vous déployez le pilote, vous devez activer le suivi de la capacité de stockage : external-provisioner devrait publier les informations de capacité reçues du conducteur via le canal normal GetCapacity.
Si le planificateur doit sélectionner un nœud pour un espace avec un volume non lié qui utilise une liaison tardive et que le pilote a activé cette fonctionnalité lors du déploiement en définissant l'indicateur CSIDriver.storageCapacity, les nœuds qui n'ont pas suffisamment de capacité de stockage seront automatiquement supprimés. Cela fonctionne à la fois pour les volumes éphémères et persistants à usage général, mais pas pour les volumes éphémères CSI car leurs paramètres ne peuvent pas être lus par Kubernetes.
Comme d'habitude, les volumes immédiatement liés sont créés avant la planification des pods, et leur emplacement est choisi par le pilote de stockage, donc lors de la configuration external-provisioner Par défaut, les classes de stockage avec liaison immédiate sont ignorées, puisque ces données ne seront de toute façon pas utilisées.
Étant donné que le planificateur Kubernetes est obligé de travailler avec des informations potentiellement obsolètes, rien ne garantit que la capacité sera disponible dans tous les cas lors de la création du volume, mais les chances qu'il soit créé sans nouvelle tentative sont néanmoins augmentées.
NB Vous pouvez obtenir des informations plus détaillées, ainsi que « vous entraîner sur le stand des chats » en toute sécurité et, en cas de situation totalement incompréhensible, bénéficier d'une assistance technique qualifiée lors de cours intensifs - aura lieu du 28 au 30 septembre, et pour les spécialistes plus avancés 14-16 octobre.
sécurité
Capacité de stockage CSIS
Les objets CSIStorageCapacity résident dans des espaces de noms ; lors du déploiement de chaque pilote CSI dans son propre espace de noms, il est recommandé de restreindre les droits RBAC sur CSIStorageCapacity dans cet espace, car il est évident d'où proviennent les données. Kubernetes ne vérifie pas cela de toute façon, et généralement les pilotes sont placés dans le même espace de noms, donc en fin de compte, les pilotes sont censés fonctionner et ne pas publier de données incorrectes (et c'est là que ma carte a échoué, environ. traducteur basé sur une blague barbue)
Volumes éphémères à usage général
Si les utilisateurs ont le droit de créer un pod (directement ou indirectement), ils pourront également créer des volumes éphémères à usage général même s'ils n'ont pas le droit de créer une requête sur le volume. En effet, les contrôles d'autorisation RBAC sont appliqués au contrôleur qui crée le PVC, et non à l'utilisateur. C'est le principal changement à ajouter , avant d'activer cette fonctionnalité sur les clusters où les utilisateurs non approuvés ne devraient pas avoir le droit de créer des volumes.
Exemple
Séparé PMEM-CSI contient toutes les modifications nécessaires pour exécuter un cluster Kubernetes 1.19 dans des machines virtuelles QEMU avec toutes les fonctionnalités de la phase alpha. Le code du pilote n'a pas changé, seul le déploiement a changé.
Sur une machine adaptée (Linux, un utilisateur normal peut utiliser , voir détails), ces commandes feront apparaître le cluster et installeront le pilote PMEM-CSI :
git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh
Une fois que tout a fonctionné, la sortie contiendra des instructions d'utilisation :
The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in. Alternatively, use kubectl directly with the
following env variable:
KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Les objets CSIStorageCapacity ne sont pas destinés à être lus par des humains, un certain traitement est donc requis. Les filtres du modèle Golang afficheront les classes de stockage, cet exemple affichera le nom, la topologie et la capacité :
$ kubectl get
-o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}'
csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Un seul objet a le contenu suivant :
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels: <none>
Annotations: <none>
API Version: storage.k8s.io/v1alpha1
Capacity: 30716Mi
Kind: CSIStorageCapacity
Metadata:
Creation Timestamp: 2020-08-11T15:41:03Z
Generate Name: csisc-
Managed Fields:
...
Owner References:
API Version: apps/v1
Controller: true
Kind: StatefulSet
Name: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Resource Version: 2994
Self Link: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
Match Labels:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Storage Class Name: pmem-csi-sc-late-binding
Events: <none>
Essayons de créer une application de démonstration avec un seul volume éphémère à usage général. Contenu du fichier pmem-app-ephemeral.yaml:
# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app-inline-volume
spec:
containers:
- name: my-frontend
image: intel/pmem-csi-driver-test:v0.7.14
command: [ "sleep", "100000" ]
volumeMounts:
- mountPath: "/data"
name: my-csi-volume
volumes:
- name: my-csi-volume
ephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
storageClassName: pmem-csi-sc-late-binding
Après avoir créé, comme indiqué dans les instructions ci-dessus, nous disposons maintenant d'un pod et d'un PVC supplémentaires :
$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-csi-app-inline-volume 1/1 Running 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1 <none> <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-csi-app-inline-volume-my-csi-volume Bound pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
Propriétaire de PVC - sous :
$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
creationTimestamp: "2020-08-11T15:44:57Z"
finalizers:
- kubernetes.io/pvc-protection
managedFields:
...
name: my-csi-app-inline-volume-my-csi-volume
namespace: default
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: true
controller: true
kind: Pod
name: my-csi-app-inline-volume
uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...
Informations mises à jour attendues pour pmem-csi-pmem-govm-worker1:
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Si une autre application a besoin de plus de 26620Mi, le planificateur n'en tiendra pas compte pmem-csi-pmem-govm-worker1 dans tous les cas.
Quelle est la prochaine?
Les deux fonctionnalités sont encore en développement. Plusieurs applications ont été ouvertes lors des tests alpha. Les liens vers la proposition d'amélioration documentent le travail qui doit être effectué pour passer à la phase bêta, ainsi que les alternatives qui ont déjà été envisagées et rejetées :
Source: habr.com