Народный бондинг для облачного хранилища данных

Данная статья окажется полезной для организации сред разработки или тестирования в условиях ограниченного бюджета. Может пригодиться в продуктивной среде, пока нужная железка едет месяцами. Актуально при насыщенности сетевого интерфейса хранилища входящим трафиком от множества рабочих узлов kubernetes.

Собственно, некое хранилище с несколькими сетевыми интерфейсами:

nslookup qnap Server:         127.0.0.53 Address:        127.0.0.53#53  Non-authoritative answer: Name:   qnap.local Address: 192.168.1.250 Name:   qnap.local Address: 192.168.1.251 Name:   qnap.local Address: 192.168.1.252 Name:   qnap.local Address: 192.168.1.253 

На самом сервере может быть настроен честный бондинг или не настроен, для входящих соединений это не важно.

Намеренно абстрагируюсь от конкретных схем: у вас может быть простой сегмент локальной сети, или же может быть дополнительный резервный сегмент, даже несколько, не влияет на организацию нашего народного бондинга соединений из облака.

Поды и PVC

Поды в кластере kubernetes получают затребованные тома постоянного хранилища с помощью манифестов persistent volume claim (PVC). PVC могут быть сформированы контроллером statefulset из шаблонов:

apiVersion: apps/v1 kind: StatefulSet metadata:   name: userapp spec:   replicas: 8   selector:      matchLabels:        app: userapp   template:     metadata:       labels:         app: userapp     spec:       containers:       - name: userapp         image: busybox         imagePullPolicy: IfNotPresent         command: ["/bin/sh"]         args:           - "-c"           - "sleep 10000"         volumeMounts:         - name: userapp           mountPath: /home   volumeClaimTemplates:     - metadata:         name: userapp       spec:         accessModes: ["ReadWriteMany"]         storageClassName: userapp         resources:           requests:             storage: 30Gi

Или заранее размещены для deployment:

kind: PersistentVolumeClaim apiVersion: v1 metadata:   name: userapp-0 spec:   accessModes:   - ReadWriteMany   resources:     requests:       storage: 10Gi   storageClassName: userapp

Для осуществления автоматического выбора следующего тома с указанными сетевыми адресами из списка добавим класс хранилища:

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:   name: userapp provisioner: kubernetes.io/no-provisioner reclaimPolicy: Retain volumeBindingMode: WaitForFirstConsumer

Генерация постоянных томов может быть осуществлена статически, в виде манифестов:

--- apiVersion: v1 kind: PersistentVolume metadata:   name: userapp-shared-data-1 spec:   accessModes:   - ReadWriteMany   capacity:     storage: 300Gi   nfs:     path: /home/share     server: 192.168.1.250   persistentVolumeReclaimPolicy: Retain   storageClassName: userapp   volumeMode: Filesystem --- apiVersion: v1 kind: PersistentVolume metadata:   name: userapp-shared-data-2 spec:   accessModes:   - ReadWriteMany   capacity:     storage: 300Gi   nfs:     path: /home/share     server: 192.168.1.251   persistentVolumeReclaimPolicy: Retain   storageClassName: userapp   volumeMode: Filesystem  apiVersion: v1 kind: PersistentVolume metadata:   name: userapp-shared-data-3 spec:   accessModes:   - ReadWriteMany   capacity:     storage: 300Gi   nfs:     path: /home/share     server: 192.168.1.252   persistentVolumeReclaimPolicy: Retain   storageClassName: userapp   volumeMode: Filesystem --- apiVersion: v1 kind: PersistentVolume metadata:   name: userapp-shared-data-0 spec:   accessModes:   - ReadWriteMany   capacity:     storage: 300Gi   nfs:     path: /home/share     server: 192.168.1.253   persistentVolumeReclaimPolicy: Retain   storageClassName: userapp   volumeMode: Filesystem

Следует создать достаточное количество постоянных томов заранее. PVC можно переиспользовать бесконечно без дополнительных контроллеров. PVC, сгенерированные из шаблонов statefulset также остаются вне зависимости от scale down, перезапуска подов и дополнительные контроллеры для переиспользования не требуются.

Динамическое создание постоянных томов осуществляется настройкой api-server admission controller. Отработка изменений, удаления PVC обеспечивается добавлением соответствующего io provisioner в кластер.

Поды могут обращаться к некоторым папкам как одновременно, так и изолированно, добавляя в примонтированный путь уникальные данные проекта, пользователя.

Выводы

Таким образом, путем добавления storage class и набора PV, при минимальном изменении манифестов приложения, никак не меняя внутренние алгоритмы можно добиться кратного увеличения производительности разделяемого хранилища на любом исправном сетевом оборудовании.