Search
Write a publication
Pull to refresh

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

Level of difficultyMedium
Reading time3 min
Views2.4K
Или "я получу от этого cisco все"
Или "я получу от этого cisco все"

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

Tags:
Hubs:
Total votes 4: ↑4 and ↓0+4
Comments0

Articles