Этот вопрос касается поведения конфигураций PersistentVolume и PersistentVolumeClaim в Kubernetes.Мы прочитали документацию и у нас осталось несколько вопросов.
Мы используем службу Azure Kubernetes для размещения нашего кластера, и мы хотим предоставить общий бэкэнд для постоянного хранения для многих наших модулей.Мы планируем использовать PersistentVolumes для достижения этой цели.
В этом сценарии мы хотим выпустить PersistentVolume, поддерживаемый ресурсом хранения AzureFile.Мы развернем Jenkins в нашем кластере и сохраним каталог jenkins_home в PersistentVolume, чтобы наш экземпляр мог выдержать сбои pod и node.Мы будем работать с несколькими узлами Master Jenkins, все из которых будут настроены с одинаковой версией развертывания.
Мы заранее создали все необходимые учетные записи хранения и соответствующие общие ресурсы, а также необходимые секреты.
Сначала мы выпустили следующую конфигурацию PersistentVolume;
apiVersion: v1
kind: PersistentVolume
metadata:
name: jenkins-azure-file-share
labels:
usage: jenkins-azure-file-share
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
azureFile:
secretName: azure-file-secret
shareName: jenkins
readOnly: false
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
Затем мы выпустили следующую конфигурацию PersistentVolumeClaim;
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: jenkins-file-claim
annotations:
volume.beta.kubernetes.io/storage-class: ""
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
volumeName: "jenkins-azure-file-share"
Далее мы используем это утверждениев наших развертываниях следующим образом:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: jenkins-instance-name
spec:
replicas: 1
template:
metadata:
labels:
role: jenkins
app: jenkins-instance-name
spec:
containers:
- name: jenkins-instance-name
image: ContainerRegistry.azurecr.io/linux/jenkins_master:latest
ports:
- name: jenkins-port
containerPort: 8080
volumeMounts:
- name: jenkins-home
mountPath: /var/jenkins_home
subPath: "jenkins-instance-name"
volumes:
- name: jenkins-home
persistentVolumeClaim:
claimName: "jenkins-file-claim"
imagePullSecrets:
- name: ImagePullSecret
Это все работает, как ожидалось.Мы развернули несколько мастеров Jenkins в нашем кластере Kubernetes, и каждый из них правильно распределяет новую папку на общем ресурсе, характерном для каждого главного экземпляра.
Теперь на мои вопросы
В PersistentVolume сконфигурировано 100 ГБ хранилища.Означает ли это, что Kubernetes будет разрешать максимум 100 ГБ общего хранилища в этом томе?
Когда PersistentVolumeClaim привязан к PersistentVolume, PersistentVolumeClaim, кажется, показывает, что у него доступно 100 ГБ общего хранилища, даже если для PersistentVolumeClaim было настроено 10 ГБ хранилища;
C:\ashley\scm\kubernetes>kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
jenkins-azure-file-share 100Gi RWX Retain Bound default/jenkins-file-claim 2d
C:\ashley\scm\kubernetes>kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
jenkins-homes-file-claim Bound jenkins-azure-file-share 100Gi RWX 2d
Это просто неверный вывод команды get pvc или я неправильно интерпретирую вывод команды get pvc?
При совместном использовании PersistentVolumeClaim таким образом;
- Имеет ли каждое развертывание ТОЛЬКО доступ к сконфигурированному максимуму 10 ГБ хранилища из емкости 100Gig в PersistentVolume?
- Или, каждое развертывание имеет доступ к своему собственному срезу 10 ГБ из общего хранилища 100 ГБ, настроенного для PersistentVolume?
Что в этой конфигурации произойдет, когда одна емкость PersistentVolumeClaim будет полностью использована?Все ли развертывания, использующие этот единственный PersistentVolumeClaim, перестают работать?