Какие знаешь Storage в Kubernetes?

Обзор Storage в Kubernetes

Как DevOps Engineer с более чем 10-летним опытом работы с Kubernetes, я рассматриваю storage не просто как "диск", а как критически важный ресурс со своим жизненным циклом, который требует глубокого понимания архитектуры контейнеров и распределенных систем. Storage в Kubernetes - это многоуровневая система абстракций, где каждый уровень решает конкретные проблемы.

Основные концепции и типы Storage

1. Ephemeral Storage (Временное хранилище)

Это storage, связанный с жизненным циклом Pod. При удалении Pod данные теряются.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: cache-volume
      mountPath: /cache
  volumes:
  - name: cache-volume
    emptyDir: {}  # Классический пример ephemeral storage

Основные типы ephemeral storage:

• emptyDir: Создается при запуске Pod, существует пока Pod активен
• hostPath: Монтирует директорию с ноды (опасно для production!)
• ConfigMap/Secret: Специальные типы volume для конфигурации

2. Persistent Storage (Постоянное хранилище)

Данные сохраняются после удаления Pod и могут быть переиспользованы.

Ключевые компоненты:

PersistentVolume (PV)

Ресурс кластера, представляющий физическое/логическое хранилище:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-mysql
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: fast-ssd
  hostPath:
    path: /data/mysql

PersistentVolumeClaim (PVC)

Запрос пользователя на определенный объем storage:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-ssd

Типы Storage Providers

Встроенные провайдеры:

• Local (hostPath, local volumes) - для single-node или тестирования
• NFS - сетевая файловая система
• iSCSI - блочное хранилище по сети
• CephFS/RBD - распределенное хранилище

Cloud Provider Storage:

• AWS: EBS, EFS, FSx
• GCP: Persistent Disk, Filestore
• Azure: Disk, Files, NetApp Files

# Пример AWS EBS
apiVersion: v1
kind: PersistentVolume
metadata:
  name: aws-ebs-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: vol-12345678
    fsType: ext4

Software-Defined Storage (SDS):

• Ceph/Rook - полный SDS solution
• Longhorn (от Rancher) - распределенное блочное хранилище
• OpenEBS - контейнеризованное хранилище
• Portworx - enterprise-grade solution
• GlusterFS - распределенная файловая система

Современные подходы и best practices

Storage Classes и Dynamic Provisioning

Автоматическое создание PV по требованию:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
volumeBindingMode: WaitForFirstConsumer

CSI (Container Storage Interface)

Стандартизированный интерфейс для интеграции storage систем:

Преимущества CSI:

• Единый интерфейс для всех провайдеров
• Out-of-tree драйверы (не требуют изменений в коде k8s)
• Поддержка расширенных операций (snapshot, clone, resize)

# Пример установки CSI драйвера
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/deploy/kubernetes/overlays/stable/iam/rbac.yaml

StatefulSets для stateful workload

Для баз данных и других stateful приложений:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Критические аспекты для production

Выбор правильного access mode:

• RWO (ReadWriteOnce) - один узел для чтения/записи
• ROX (ReadOnlyMany) - много узлов для чтения
• RWX (ReadWriteMany) - много узлов для чтения/записи

Рекомендации по проектированию:

1. Разделение storage по классам:

   • Fast SSD для transactional workload
   • HDD/стандартные диски для backup/архивов
   • Общее хранилище для shared data

2. Резервное копирование:

   • Использование Velero/Restic для backup PV
   • Регулярные snapshot через CSI

3. Мониторинг и алертинг:

   • Мониторинг использования PV/PVC
   • Alert на 80% заполнение
   • Метрики latency и throughput

4. Безопасность:

   • Pod Security Policies для ограничения hostPath
   • Encryption at rest для чувствительных данных
   • Правильные SELinux/AppArmor контексты

# Проверка состояния storage
kubectl get pv,pvc,storageclass
kubectl describe pvc/my-claim
kubectl top pod --containers --use-protocol-buffers

Проблемы и их решения

Распространенные проблемы:

1. Pending PVC - нет подходящего PV или проблемы с provisioner
2. Terminating PV - проблемы с finalizer или reclaim policy
3. Performance issues - неправильный выбор storage class

Диагностика:

# Проверка событий storage
kubectl get events --field-selector involvedObject.kind=PersistentVolumeClaim
kubectl logs -n kube-system -l app=ebs-csi-controller

В реальных production средах я обычно комбинирую несколько решений: local SSD для hot data, сетевое блочное хранилище для баз данных, и распределенную файловую систему для shared контента. Ключевой принцип - понимание требований приложения и выбор storage solution, которое оптимально балансирует стоимость, производительность и надежность. Современный тренд - использование CSI-совместимых драйверов и операторов (как Rook), которые значительно упрощают управление storage в Kubernetes.