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

Данная статья окажется полезной для организации сред разработки или тестирования в условиях ограниченного бюджета. Может пригодиться в продуктивной среде, пока нужная железка едет месяцами. Актуально при насыщенности сетевого интерфейса хранилища входящим трафиком от множества рабочих узлов 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, при минимальном изменении манифестов приложения, никак не меняя внутренние алгоритмы можно добиться кратного увеличения производительности разделяемого хранилища на любом исправном сетевом оборудовании.