Модуль 4.4: Знімки томів та клонування

Складність: [СЕРЕДНЯ] — захист даних та клонування

Час на проходження: 30-40 хвилин

Передумови: Модуль 4.2 (PV та PVC), Модуль 4.3 (StorageClass’и)

---

Що ви зможете зробити

Після завершення цього модуля ви зможете:

• Створювати VolumeSnapshot’и та відновлювати PVC зі знімків для резервного копіювання та відновлення.
• Налаштовувати VolumeSnapshotClass’и та порівнювати, як вони пов’язані зі StorageClass’ами, драйверами та політиками видалення.
• Впроваджувати стратегію резервного копіювання та валідації на основі знімків для робочих навантажень зі станом.
• Діагностувати збої знімків і клонування, перевіряючи підтримку CSI-драйвера, поведінку контролера знімків, розмір відновлення та події PVC.

---

Чому цей модуль важливий

Гіпотетичний сценарій: ваша команда збирається застосувати міграцію бази даних, яка перезаписує кілька таблиць, а план відкату каже «за потреби відновитися з резервної копії». Це речення корисне лише тоді, коли резервна копія фіксує правильний момент у часі, її можна відновити у справжній PVC, і її протестували до вікна обслуговування. VolumeSnapshot’и Kubernetes та клонування PVC дають вам інструменти на рівні API для таких сценаріїв, але вони не є чарівними кнопками безпеки. Вони залежать від можливостей CSI-драйвера, контролерів знімків, поведінки бекенду сховища та рішень щодо консистентності застосунку, які ви маєте оцінити, перш ніж дані вже будуть пошкоджені.

Знімки томів надають копії персистентних даних на певний момент у часі — їх використовують для відновлення після збоїв, для створення тестових середовищ, для репетиції міграції та для криміналістичного огляду. Клонування тому, своєю чергою, створює новий PVC з наявного PVC без попереднього створення окремого об’єкта-знімка, придатного для повторного використання. Обидві ці можливості спираються на ту саму ментальну модель, яку ви вже вивчили для PV, PVC та StorageClass’ів: Kubernetes зберігає об’єкт бажаного стану, контролери узгоджують цей об’єкт із дійсністю, а бекенд сховища виконує фактичну операцію з даними. Екзаменаційний кут зору тут зазвичай практичний, а не теоретичний, тож ви маєте вміти прочитати маніфест, передбачити, чи зможе він взагалі спрацювати, та діагностувати, в якій саме ланці розірвався ланцюг, коли він не спрацьовує так, як очікувалося.

Уявіть VolumeSnapshot як фотографію диска в певний момент. Фотографія фіксує розкладку диска, яку система сховища пізніше може використати для створення іншого тому, але фотографія корисна рівно настільки, наскільки якісні камера, бекенд сховища та дисципліна людини, яка її робить. VolumeSnapshotClass — це налаштування камери: він обирає CSI-драйвер та поведінку видалення. Відновлення PVC — це акт друку нової робочої копії з цієї фотографії. Клон більше схожий на пряме фотокопіювання поточної сторінки, що зручно, коли джерело справне й поряд, але марно, коли вам потрібен учорашній стан.

---

Архітектура знімків та готовність

Знімки в Kubernetes навмисно віддзеркалюють зв’язок PV і PVC, але мета тут — стан для відновлення, а не сховище для активного Под’а. VolumeSnapshotClass має область видимості кластера й зазвичай створюється адміністратором, так само як StorageClass. VolumeSnapshot належить до простору імен і створюється командою застосунку або інструментом резервного копіювання, щоб запросити копію конкретного PVC на певний момент часу. VolumeSnapshotContent має область видимості кластера й представляє фактичний дескриптор знімка, який розуміють CSI-snapshotter і бекенд.

┌──────────────────────────────────────────────────────────────────────┐
│                    Snapshot Architecture                              │
│                                                                       │
│   Similar to PV/PVC model:                                           │
│                                                                       │
│   VolumeSnapshotClass         VolumeSnapshot        VolumeSnapshot   │
│   (cluster-scoped)            (namespaced)          Content          │
│   ┌─────────────────┐         ┌─────────────┐      (cluster-scoped)  │
│   │ Defines HOW     │         │ Request to  │      ┌─────────────┐  │
│   │ snapshots are   │         │ snapshot a  │      │ Actual      │  │
│   │ created         │◄────────│ specific PVC│─────►│ snapshot    │  │
│   │                 │         │             │      │ reference   │  │
│   │ - driver        │         │ - source    │      │             │  │
│   │ - deletionPolicy│         │ - class     │      │ - driver    │  │
│   └─────────────────┘         └─────────────┘      │ - handle    │  │
│                                                     └─────────────┘  │
│                                                                       │
│   Admin creates               Dev creates          Auto-created      │
│   (once per cluster)          (when needed)        (by controller)   │
└──────────────────────────────────────────────────────────────────────┘

Це зіставлення достатньо близьке, щоб використати його як підказку для запам’ятовування, але назви не є взаємозамінними. PVC просить придатне для використання сховище, яке може примонтувати Под, тоді як VolumeSnapshot просить точку відновлення, яка пізніше може стати сховищем. PV вказує на живий том бекенду, тоді як VolumeSnapshotContent вказує на знімок бекенду. StorageClass описує, як провіжняться нові живі томи, тоді як VolumeSnapshotClass описує, як створюються нові знімки та що має статися зі знімком бекенду, коли об’єкт-знімок Kubernetes видаляється.

Сховище	Знімки
StorageClass	VolumeSnapshotClass
PersistentVolume	VolumeSnapshotContent
PersistentVolumeClaim	VolumeSnapshot

Перш ніж писати YAML для знімка, переконайтеся, що в кластері є потрібний механізм. API-сервер має знати CRD знімків, контролер знімків має узгоджувати VolumeSnapshot і VolumeSnapshotContent, а відповідний CSI-драйвер має підтримувати операції зі знімками. Кластер може приймати PVC від CSI-драйвера й при цьому бути неспроможним знімати їх, якщо зовнішніх компонентів snapshotter’а немає або якщо драйвер не реалізує підтримку знімків. Ця відмінність — поширена причина, чому правильний на вигляд маніфест залишається застряглим.

# Check if snapshot CRDs are installed
kubectl get crd | grep snapshot
# volumesnapshotclasses.snapshot.storage.k8s.io
# volumesnapshotcontents.snapshot.storage.k8s.io
# volumesnapshots.snapshot.storage.k8s.io

# Check for snapshot controller
kubectl get pods -n kube-system | grep snapshot

Зробіть паузу й передбачте: якщо kubectl get crd | grep snapshot нічого не повертає, чи зазнає невдачі створення VolumeSnapshot на етапі допуску, чи воно створить об’єкт, який ніколи не стане готовим? Відповідь залежить від того, наскільки далеко просувається запит. Без CRD API-сервер взагалі не розпізнає цей вид (kind). За наявності CRD, але без контролера чи підтримки драйвера, об’єкт може існувати, але статус ніколи не досягне readyToUse: true.

Контролер знімків відповідає за життєвий цикл на рівні Kubernetes, але він сам по собі не є бекендом сховища. Sidecar CSI-snapshotter спілкується з CSI-драйвером, а вже драйвер спілкується безпосередньо із системою сховища. Коли знімок зазнає невдачі, подумки розділіть ці рівні один від одного: розпізнавання виду на рівні API, узгодження контролером, можливості драйвера, дозволи на стороні бекенду та стан вихідного тому. Ця багаторівнева модель запобігає випадковим, хаотичним правкам і дає вам короткий, передбачуваний діагностичний шлях під час іспиту CKA, коли часу на здогадки немає.

VolumeSnapshotClass та контракти драйвера

VolumeSnapshotClass — це об’єкт політики. Він називає CSI-драйвер, який створюватиме знімки, і оголошує deletionPolicy для відповідного VolumeSnapshotContent. Значення driver має збігатися з назвою CSI-драйвера, яку використовує встановлений драйвер сховища, а не з привабливою назвою хмарного продукту, знайденою в неспорідненому прикладі. Мапа parameters є специфічною для драйвера, тож не припускайте, що опції одного постачальника працюють в іншого, навіть коли вид (kind) Kubernetes ідентичний.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"  # Optional
driver: ebs.csi.aws.com                    # Must match CSI driver
deletionPolicy: Delete                      # Delete or Retain
parameters:                                 # Driver-specific params
  # Example for some drivers:
  # csi.storage.k8s.io/snapshotter-secret-name: snap-secret
  # csi.storage.k8s.io/snapshotter-secret-namespace: default

Політика видалення — це більше, ніж уподобання щодо очищення. З Delete видалення Kubernetes-об’єкта VolumeSnapshot зазвичай призводить до видалення VolumeSnapshotContent і відповідного знімка бекенду, коли драйвер може завершити цю операцію. З Retain об’єкт-запит Kubernetes може зникнути, тоді як вміст знімка та знімок бекенду залишаються для ручного відновлення чи довготривалого зберігання. Правильна відповідь залежить від того, чи знімок є одноразовим тестовим артефактом, чи точкою відновлення з операційною цінністю.

Політика	Поведінка
Delete	VolumeSnapshotContent і базовий знімок видаляються разом із видаленням VolumeSnapshot
Retain	VolumeSnapshotContent і знімок зберігаються після видалення VolumeSnapshot

Приклади постачальників корисні лише тоді, коли ви ставитеся до них як до прикладів форми. AWS EBS, Google Persistent Disk та Azure Disk — усі надають CSI-драйвери, але назви драйверів і параметри відрізняються. На реальному кластері огляньте встановлені StorageClass’и, об’єкти CSIDriver та документацію постачальника, перш ніж створювати клас. В екзаменаційному середовищі віддавайте перевагу назві драйвера, уже видимій у ресурсах кластера, замість того, щоб вигадувати значення з пам’яті.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapclass
driver: ebs.csi.aws.com
deletionPolicy: Delete

Приклад AWS EBS навмисно невеликий, тому що багато корисних налаштувань живуть поза об’єктом Kubernetes, наприклад дозволи IAM та встановлення CSI-драйвера EBS. Якщо клас існує, але знімки зазнають невдачі, не змінюйте раз за разом назву класу. Перевірте, чи встановлено CSI-драйвер EBS, чи розгорнуто його підтримку знімків, і чи має контролер дозвіл створювати та видаляти знімки в обліковому записі.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: gcp-snapclass
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
parameters:
  storage-locations: us-central1

Приклад Google Persistent Disk містить параметр розташування, тому що специфічне для постачальника розміщення може мати значення. Це не робить той самий ключ переносним. Якщо ви скопіюєте цей параметр до іншого CSI-драйвера, Kubernetes може прийняти YAML, тоді як драйвер пізніше відхилить запит. Саме тому усунення несправностей знімків часто вимагає читання подій контролера й драйвера, а не лише перевірки синтаксису.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: azure-snapclass
driver: disk.csi.azure.com
deletionPolicy: Delete
parameters:
  incremental: "true"

Приклад Azure Disk показує ще одну специфічну для бекенду деталь: інкрементні знімки можуть впливати на характеристики вартості та продуктивності. API Kubernetes не обіцяє, що кожен бекенд зберігає знімки однаково. Деякі системи використовують метадані copy-on-write, деякі матеріалізують копії інакше, а деякі накладають обмеження на ланцюги знімків чи регіони. Тому ваш дизайн має визначати мету відновлення та правило зберігання, а потім перевіряти, що обраний драйвер і бекенд справді це підтримують.

Створення та читання VolumeSnapshot’ів

VolumeSnapshot — це запит у межах простору імен до наявного PVC у тому самому просторі імен. Він називає VolumeSnapshotClass і вихідний PVC, а потім чекає, поки контролери та CSI-бекенд створять VolumeSnapshotContent. Вихідний PVC не замінюється, а Под, який використовує PVC, не призупиняється автоматично. Це робить знімки зручними, але також означає, що сам об’єкт не гарантує консистентності на рівні застосунку.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-snapshot
  namespace: production
spec:
  volumeSnapshotClassName: csi-snapclass   # Reference to class
  source:
    persistentVolumeClaimName: data-pvc    # PVC to snapshot

Потік контролера короткий, але кожен крок може зазнати невдачі з іншої причини. Контролер має побачити запит, перевірити вказаний PVC і клас, попросити CSI-драйвер створити знімок, створити чи прив’язати VolumeSnapshotContent та оновити статус. Якщо статус так і не стає готовим, не переходьте одразу до видалення та повторного створення об’єкта. Спочатку визначте, чи збій є валідацією вхідних даних, відсутньою підтримкою драйвера, відмовою бекенду чи повільним створенням знімка.

┌─────────────────────────────────────────────────────────────────────┐
│                      Snapshot Creation Flow                          │
│                                                                      │
│   1. Create VolumeSnapshot                                          │
│          │                                                          │
│          ▼                                                          │
│   2. Snapshot controller validates                                  │
│      - PVC exists                                                   │
│      - VolumeSnapshotClass exists                                   │
│      - CSI driver supports snapshots                                │
│          │                                                          │
│          ▼                                                          │
│   3. CSI driver creates snapshot on storage backend                 │
│          │                                                          │
│          ▼                                                          │
│   4. VolumeSnapshotContent created (auto)                          │
│          │                                                          │
│          ▼                                                          │
│   5. VolumeSnapshot status: readyToUse=true                        │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Читання статусу — це навичка, яку варто практикувати, тому що збої знімків спершу часто виглядають тихими. READYTOUSE показує, чи можна використати знімок як джерело відновлення. RESTORESIZE показує розмір, який Kubernetes очікує, що відновлений PVC запросить. Назва прив’язаного вмісту показує, який об’єкт із областю видимості кластера представляє дескриптор бекенду. Події та поля помилок показують, чи побачив контролер проблему валідації або драйвера.

# List snapshots
kubectl get volumesnapshot -n production
# NAME            READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS
# data-snapshot   true         data-pvc                           10Gi          csi-snapclass

# Detailed status
kubectl describe volumesnapshot data-snapshot -n production

# Check the VolumeSnapshotContent
kubectl get volumesnapshotcontent

Об’єкт статусу нижче невеликий, але містить найрелевантніші для іспиту підказки. readyToUse: true означає, що на знімок може посилатися PVC відновлення. restoreSize — це мінімальний розмір запиту для нової заявки у звичайних потоках відновлення. error — це місце, де спливає багато збоїв драйвера чи контролера, коли знімок не вдається завершити.

status:
  boundVolumeSnapshotContentName: snapcontent-xxxxx
  creationTime: "2024-01-15T10:30:00Z"
  readyToUse: true                        # Snapshot is ready
  restoreSize: 10Gi                       # Size when restored
  error:                                  # If failed, error message here

Зробіть паузу й передбачте: ви робите знімок PVC розміром 50Gi, у якому записано лише 2Gi даних. Коли ви відновлюєте з цього знімка, чи має новий PVC запитувати 50Gi, чи він може запросити лише 2Gi? Операційною підказкою є restoreSize, а не обсяг даних застосунку, який ви вважаєте наявним. Системи сховища відновлюють форму тому так само, як і файли, тож заявка призначення має задовольняти потрібний розмір знімка.

Час зняття знімка заслуговує на таку саму увагу, що й читання статусу. Для простого файлового навантаження crash-консистентний знімок цілком може бути достатнім, оскільки файлова система здатна відтворити свої метадані, а застосунок здатен витримати такий стан без втрат. Однак для бази даних, черги повідомлень чи об’єктного сховища знімок, зроблений саме під час записів у польоті, може згодом потребувати відновлення, може втратити підтверджені, але ще не записані на диск дані, або взагалі не пройти перевірки цілісності застосунку після відновлення. Об’єкт Kubernetes дає вам лише момент у часі; саме ваші операційні процедури для конкретного навантаження вирішують, чи є цей момент безпечним для відновлення.

Відновлення PVC зі знімків

Відновлення зі знімка створює новий PVC, чий dataSource посилається на VolumeSnapshot. Воно не відкочує наявний PVC назад на місці. Цей дизайн безпечніший, тому що ви можете відновити в окрему заявку, примонтувати її у валідаційний Под, підтвердити дані, і лише потім вирішити, як перемістити застосунок. У продакшн-відновленні таке розділення цінне, оскільки зменшує ймовірність перезапису останньої доступної копії, поки ви все ще діагностуєте інцидент.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-data
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd              # StorageClass for new PVC
  resources:
    requests:
      storage: 10Gi                       # Must be >= snapshot size
  dataSource:                             # The magic part!
    name: data-snapshot                   # Name of VolumeSnapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Заявка відновлення все ще має задовольняти звичайні вимоги PVC. Їй потрібен сумісний StorageClass, режим доступу, який може задовольнити драйвер, достатня запитана місткість і провіжнер, здатний створити том саме з джерела-знімка. Якщо PVC залишається застряглим у стані Pending, опишіть і сам PVC, і знімок, з якого він відновлюється. Відновлення може зазнати невдачі з кількох різних причин: через те, що знімок ще не готовий до використання, через те, що клас чи драйвер не підтримують відновлення саме з цього знімка, через те, що запитаний розмір замалий для тому, або через те, що споживчий Под усе ще чекає на розв’язання топології.

┌─────────────────────────────────────────────────────────────────────┐
│                      Restore from Snapshot                           │
│                                                                      │
│   VolumeSnapshot                    New PVC                          │
│   ┌─────────────┐                   ┌─────────────┐                 │
│   │ data-snap   │                   │ restored    │                 │
│   │             │                   │             │                 │
│   │ restoreSize:│◄──dataSource──────│ storage:    │                 │
│   │ 10Gi        │                   │ 10Gi        │                 │
│   └──────┬──────┘                   └──────┬──────┘                 │
│          │                                 │                         │
│          ▼                                 ▼                         │
│   VolumeSnapshotContent             New PV (with data)              │
│   (contains snapshot                (provisioned from               │
│    handle)                           snapshot)                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Відновлення між просторами імен тонше, ніж відновлення в межах одного простору імен. Об’єкт VolumeSnapshot належить до простору імен, а VolumeSnapshotContent має область видимості кластера, тож просунуті патерни відновлення можуть посилатися на знімок з іншого простору імен через dataSourceRef, коли кластер підтримує джерела даних між просторами імен, а вихідний простір імен надає цей дозвіл на посилання. Відновлення між просторами імен потребує feature gate CrossNamespaceVolumeDataSource (альфа з v1.26) плюс CRD ReferenceGrant з Gateway API. У кластерах епохи Kubernetes 1.35 ставтеся до цього як до функції, керованої політикою, а не до обходу дозволів. Власник вихідного простору імен має навмисно дозволити шлях відновлення.

# In namespace "production" — grant dr-test permission to reference the snapshot
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-dr-restore
  namespace: production
spec:
  from:
    - group: ""
      kind: PersistentVolumeClaim
      namespace: dr-test
  to:
    - group: snapshot.storage.k8s.io
      kind: VolumeSnapshot

# In namespace "dr-test"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dr-restore
  namespace: dr-test              # Different namespace!
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 10Gi
  dataSourceRef:                  # Use dataSourceRef for cross-namespace
    name: data-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
    namespace: production         # Source namespace

Важлива дизайнерська відмінність — це володіння. Відновлення в межах одного простору імен прямолінійне, оскільки команда застосунку контролює і знімок, і відновлений PVC. Відновлення між просторами імен перетинає межу, тож воно має поважати політику на рівні простору імен і будь-який потрібний ReferenceGrant. Якщо ваша спроба зазнає невдачі, огляньте потік подій PVC і дозволи вихідного простору імен, перш ніж звинувачувати бекенд сховища. Бекенд може бути цілком здатним відновити, тоді як Kubernetes правильно відмовляє в неавторизованому посиланні.

Перш ніж запускати це в реальному відновленні, який вивід ви очікуєте від kubectl describe pvc restored-data -n production, поки відновлення в стані pending? Ви маєте очікувати події, які називають джерело даних, клас, провіжнер чи проблему місткості. Якщо події згадують недійсне джерело даних, спочатку огляньте статус VolumeSnapshot. Якщо події згадують провіжнінг чи топологію, продовжуйте зі звичайним усуненням несправностей PVC та StorageClass.

Клонування томів та консистентні для застосунку резервні копії

Клонування створює новий PVC з наявного PVC без попереднього створення окремого об’єкта-знімка. З погляду API PVC призначення встановлює dataSource.kind: PersistentVolumeClaim, а провіжнер створює новий том, що містить дані з джерела. Це зручно для тестових копій у межах одного простору імен, експериментів перед оновленням і навантажень аналізу даних. Це не механізм історичного відновлення, тому що воно копіює з джерела таким, яким воно існує на момент клонування.

┌─────────────────────────────────────────────────────────────────────┐
│               Snapshot vs Clone                                      │
│                                                                      │
│   SNAPSHOT                          CLONE                            │
│   ────────                          ─────                            │
│   PVC → Snapshot → New PVC          PVC → New PVC (direct)          │
│                                                                      │
│   Two-step process                  One-step process                 │
│   Point-in-time backup              Immediate copy                   │
│   Can restore multiple times        Single copy operation            │
│   Snapshot persists                 No intermediate artifact         │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 10Gi                 # Must be >= source PVC
  dataSource:                       # Clone from existing PVC
    name: source-pvc                # Name of source PVC
    kind: PersistentVolumeClaim     # Different kind than snapshot!

Вимоги до клонування навмисно вужчі, ніж до відновлення зі знімка. Вихідний PVC і PVC призначення мають перебувати в одному просторі імен для звичайного CSI-клонування, бекенд сховища має підтримувати операцію клонування, запит призначення має бути щонайменше таким же великим, як і джерело, а StorageClass зазвичай має бути сумісним із вихідним томом. Якщо вам потрібен тестовий простір імен, наповнений продакшн-даними, то робочий процес «знімок-і-відновлення» зазвичай є кращим відправним пунктом. Якщо ж вам потрібна лише швидка копія в межах одного й того самого простору імен для репетиції міграції, то клонування може виявитися простішим рішенням.

Сценарій використання	Опис
Dev/Test-середовища	Клонувати продакшн-дані для тестування
Резервні копії перед оновленням	Клонувати перед ризикованими змінами
Аналіз даних	Клонувати для аналітики, не впливаючи на продакшн
Паралельна обробка	Кілька клонів для паралельних навантажень

Зупиніться й подумайте: вам потрібно створити тестове середовище з копією продакшн-даних. У вас є два варіанти: зробити знімок продакшн-PVC і відновити в тестовому просторі імен або клонувати продакшн-PVC напряму. Який підхід працює для сценаріїв між просторами імен, а який — ні? Шлях зі знімком можна спроєктувати під межі простору імен, коли кластер підтримує потрібну політику посилань, тоді як прямий клон зазвичай обмежений одним простором імен. Компроміс — додаткові об’єкти й перевірки політики проти швидшої, простішої копії в межах одного простору імен.

Знімки й клони також відрізняються стратегією резервного копіювання. Клон може бути корисним перед ризикованою зміною, але він не є планом зберігання, оскільки не зберігає каталог точок відновлення. Запланований знімок створює інвентар, який можна багаторазово відновлювати, оглядати й керувати ним за допомогою політики видалення. Система резервного копіювання, побудована на знімках, має фіксувати, який PVC було захищено, коли знімок став готовим, чи був застосунок призупинений і чи пройшов тест відновлення.

# Illustrative VolumeSnapshot shape — a real schedule wraps this spec in a CronJob or external backup tool
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: daily-backup-2024-01-15
  labels:
    backup-type: daily
    source-pvc: database-data
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: database-data

Зберігання має бути явним, оскільки знімки можуть коштувати грошей і водночас бути єдиною копією для відновлення, яку ви маєте. Поширена політика тримає коротке вікно щоденних знімків, менший набір щотижневих точок відновлення та ще менший набір щомісячних архівів, але точні числа мають походити з цілей відновлення та обмежень бекенду. Мітки об’єкта Kubernetes корисні для автоматизації очищення, але вони не замінюють тестування. Збережений знімок, який ніхто не може відновити, — це дороге хибне відчуття безпеки.

# Clean up old snapshots (example script concept)
# Keep last 7 daily, 4 weekly, 12 monthly

# List snapshots older than 7 days with daily label
kubectl get volumesnapshot -l backup-type=daily --sort-by=.metadata.creationTimestamp

Консистентність застосунку — це частина, яку Kubernetes не виводить за вас. Якщо ви знімаєте PVC MySQL, поки база даних активно обробляє транзакції, бекенд сховища може створити crash-консистентний образ, подібний до того, який база даних побачила б після раптової втрати живлення. Багато баз даних можуть відновитися з такого стану, але «може відновитися» — це не те саме, що «відповідає бізнес-цілі відновлення». Для важливих даних координуйтеся із застосунком перед зняттям знімка.

# Conceptual sequence — one long-lived session holds the lock while the snapshot runs
mysql> FLUSH TABLES WITH READ LOCK;
# (same session stays open; create VolumeSnapshot and wait for readyToUse here)
mysql> UNLOCK TABLES;

Для справжньої консистентності MySQL віддавайте перевагу mysqldump --single-transaction, Percona XtraBackup чи pre/post-snapshot-хукам CSI, а не ручному глобальному read lock. Безпечніший патерн — призупинити чи відвести записи, скинути буфери на диск, швидко зробити знімок, а потім відновити записи. Деякі команди автоматизують це за допомогою інструментів резервного копіювання, які запускають pre-snapshot- і post-snapshot-хуки. Інші роблять знімки з репліки, яку можна призупинити, не впливаючи на живий трафік. Точний механізм залежить від навантаження, але принцип стабільний: застосунок має допомогти визначити осмислений момент у часі.

Проєктування корисної стратегії резервного копіювання на основі знімків починається з питання про відновлення, а не з команди знімка. Запитайте, до якого стану даних навантаження має відновитися, скільки втрати даних прийнятно, як швидко застосунок має повернутися й хто має право схвалити відновлення. Ці відповіді стають цільовою точкою відновлення, цільовим часом відновлення, процедурою валідації та політикою доступу. Без цих рішень команда може створювати знімки за розкладом, усе ще не маючи надійного шляху відновлення.

Завдання валідації

Для навантажень зі станом валідація — це різниця між артефактом сховища та планом відновлення. Завдання валідації може відновити найновіший знімок у тимчасовий PVC, примонтувати його в невеликий Под і виконати специфічні для навантаження перевірки, як-от наявність файлів, запуск бази даних, версію схеми чи порівняння контрольних сум. Завдання має фіксувати назву знімка, заявку відновлення, результат валідації та статус очищення. Цей запис каже операторам, яку точку відновлення було востаннє доведено, а не просто який об’єкт існує.

Маркування мітками — частина стратегії, тому що операторам потрібно швидко знаходити точки відновлення під час стресу. Знімок, створений автоматизацією, має містити вихідний PVC, назву застосунку, простір імен, тип резервної копії, розклад і власника. Мітки мають бути достатньо стабільними для очищення й звітності, тоді як анотації можуть містити багатшу інформацію, як-от ідентифікатори запусків валідації чи посилання на runbook. Мета — зробити так, щоб кожен знімок відповідав на три питання: що він захищає, навіщо він існує і коли його слід видалити.

Репетиція відновлення має уникати продакшн-шляху запису, поки валідація не пройде успішно. Відновлюйте в окремий простір імен чи ізольовану заявку, монтуйте дані лише для читання, коли можливо, і запускайте перевірки, які виявили б режим збою, що вас турбує. Для бази даних простого переліку файлів недостатньо; сервіс має запуститися, відкрити каталог даних і відповісти на осмислений запит. Для файлового навантаження може вистачити контрольних сум чи відомих сторожових (sentinel) файлів. Узгодьте тест із фактичною обіцянкою відновлення навантаження.

Планування місткості — частина дизайну відновлення. Розмір вихідного PVC, розмір відновлення знімка, квоти StorageClass призначення й ResourceQuota простору імен — усе впливає на те, чи зможе відновлення прив’язатися під час інциденту. Команда, яка зберігає томи бази даних на 100Gi, але дає простору імен відновлення лише 20Gi квоти сховища, побудувала шлях відновлення, який зазнає невдачі під час виклику. Завдання валідації мають виконуватися в тих самих умовах квоти й класу, які використовувало б екстрене відновлення.

Зберігання та політика видалення

Зберігання слід тестувати проти політики видалення, перш ніж це матиме значення. Якщо клас використовує Delete, завдання очищення, яке видаляє старі об’єкти VolumeSnapshot, може також видалити знімки бекенду, що правильно для одноразових резервних копій, але небезпечно для захищених архівів. Якщо клас використовує Retain, видалення об’єкта-запиту може залишити дані бекенду позаду, що захищає точки відновлення, але створює зобов’язання щодо інвентаризації та вартості. Обирайте політику навмисно, а потім репетируйте і очищення, і екстрене відновлення.

Час резервного копіювання має відповідати поведінці застосунку. Нічний знімок може бути достатнім для репозиторію контенту, який змінюється повільно, тоді як завантажена транзакційна база даних може потребувати частих логічних резервних копій плюс знімків сховища перед ризикованими операціями. Частота знімків також взаємодіє з обмеженнями й витратами бекенду. Частіші знімки можуть зменшити втрату даних, але вони можуть збільшити використання сховища, складність ланцюга знімків чи тиск на швидкість API. Хороша стратегія пояснює, навіщо існує розклад, а не лише коли він запускається.

Операційно, автоматизація знімків має виявляти збої до того, як людям знадобиться резервна копія. Налаштуйте оповіщення на знімки, які не стають готовими, відновлення-валідації, що залишаються в стані pending, несподівані зміни розміру відновлення та збої очищення для збереженого вмісту. Також оповіщайте про порожній розклад, тому що жодних збійних об’єктів може не з’явитися, коли CronJob чи контролер резервного копіювання перестав працювати. Тиха відсутність — один із найлегших способів для системи резервного копіювання непомітно занепасти.

Межі безпеки

Межі безпеки мають значення, тому що знімки можуть містити ті самі чутливі дані, що й оригінальний PVC. Відновлення між просторами імен може бути корисним для навчань із аварійного відновлення, але воно також створює шлях для переміщення даних між орендарями чи командами. Вимагайте явних дозволів, обмежте, хто може створювати PVC відновлення із захищених знімків, і проводьте аудит активності відновлення. Система резервного копіювання, яка захищає доступність, але обходить керування даними, створює інший інцидент.

Найзріліший патерн поєднує знімки сховища з нативним для застосунку резервним копіюванням так, щоб кожен підхід покривав слабкі місця іншого. Знімки сховища швидкі й добре інтегруються з відновленням PVC, що робить їх чудовим інструментом для відновлення перед ризикованими змінами та для швидкого тестування відкату. Натомість нативні для застосунку резервні копії значно краще розуміють логічний стан, транзакції та консистентність між кількома томами, що робить їх по-справжньому важливими для баз даних і розподілених систем. Kubernetes дає вам лише примітив сховища; саме архітектура конкретного навантаження вирішує, чи достатньо цього примітиву самого по собі, чи його треба доповнити.

Діагностування збоїв знімків і клонування

Діагностування знімків і клонів починається з питання «який контролер має діяти наступним?». Якщо API-сервер відхиляє вид (kind), CRD відсутні. Якщо об’єкт існує, але ніколи не змінює статус, контролер знімків чи sidecar можуть бути відсутні. Якщо контролер повідомляє про помилки драйвера, огляньте CSI-драйвер і дозволи бекенду. Якщо PVC відновлення в стані pending, огляньте і вихідний знімок, і PVC призначення, тому що відновлення залежить від обох.

kubectl get csidriver
kubectl describe csidriver <driver-name>

Об’єкт CSIDriver не доводить, що кожна опціональна функція працює, але він каже вам, які драйвери зареєстровані, і дає відправну точку для документації постачальника. Поєднайте його з наявними StorageClass’ами, щоб знати, який провіжнер створив вихідний PVC. Якщо клас знімка називає інший драйвер, ніж драйвер вихідного тому, контролер може бути неспроможним створити осмислений знімок, навіть коли кожен окремий об’єкт виглядає валідним.

kubectl get pods -n kube-system | grep snapshot
kubectl logs -n kube-system deploy/snapshot-controller

Логи контролера найкорисніші після того, як ви звузили коло до залученого об’єкта. Опишіть VolumeSnapshot, занотуйте простір імен і назву, а потім шукайте в логах навколо того узгодження. Для збоїв відновлення опишіть PVC призначення й прочитайте події, перш ніж редагувати YAML. Події PVC часто згадують недійсне джерело даних, недостатній запитаний розмір, відсутній вихідний об’єкт, непідтримувану операцію драйвера чи затримки провіжнінгу через WaitForFirstConsumer.

Симптом	Імовірний рівень	Що перевірити першим
the server doesn't have a resource type "volumesnapshot"	Розширення API	CRD знімків не встановлено
Знімок існує, але readyToUse лишається false	Контролер або драйвер	Логи контролера знімків та події VolumeSnapshot
PVC відновлення лишається Pending	Контракт вихідного чи цільового PVC	Готовність знімка, розмір відновлення, StorageClass, події PVC
PVC клону одразу зазнає невдачі	Обмеження клонування	Той самий простір імен, розмір джерела, підтримка клонування драйвером
Видалення знімка прибирає копію бекенду	Політика видалення	deletionPolicy VolumeSnapshotClass і план зберігання

Який підхід ви б обрали тут і чому: PVC відновлення в стані pending, а знімок показує readyToUse: true з restoreSize: 100Gi, але PVC запитує 10Gi. Найшвидше виправлення — не перестворювати знімок. Джерело готове; запит призначення замалий. Створіть або пропатчте заявку відновлення, яка запитує щонайменше розмір відновлення, з урахуванням правил розширення та провіжнінгу драйвера.

Для усунення несправностей зі швидкістю іспиту використовуйте багаторівневу послідовність команд. Почніть із kubectl get volumesnapshot -A, щоб визначити готовність, потім kubectl describe volumesnapshot для подій, потім kubectl get volumesnapshotcontent для прив’язки, потім kubectl describe pvc для заявок відновлення чи клону. Переходьте до логів контролера лише після того, як статус об’єкта й події перестають пояснювати збій. Це не дає вам витрачати дорогоцінний час у логах, коли потік подій уже називає проблему.

Навчання з відновлення мають включати негативний випадок, а не лише щасливий шлях. Створіть PVC відновлення із замалим обсягом сховища в одноразовому просторі імен і простежте за повідомленням події, потім видаліть його й створіть правильну заявку. Це навчає різниці між готовністю джерела та валідністю призначення. Це також дає вам упевненість, що ваш моніторинг може виявити збої відновлення до того, як реальний інцидент залежатиме від того самого шляху.

Навчання з клонування мають явно перевіряти припущення про простір імен і розмір. Клон у межах одного простору імен із запитом призначення, рівним розміру джерела, має бути базовою лінією. Запит призначення, який замалий, має зазнати невдачі чи залишитися в стані pending залежно від поведінки провіжнера. Спроба між просторами імен має бути відхилена звичайними правилами клонування. Ці невеликі експерименти будують інтуїцію швидше, ніж багаторазове читання опису функції.

Діагностуючи з подій, звертайте увагу на суб’єкт кожного повідомлення. Подія VolumeSnapshot описує створення та прив’язку знімка. Подія PersistentVolumeClaim описує рішення щодо відновлення, клонування, провіжнінгу, топології, квоти чи режиму доступу. Подія Под’а описує планування та поведінку монтування. Той самий інцидент може породити повідомлення на всіх трьох об’єктах, але кожен об’єкт говорить про власний контракт. Читання правильного об’єкта запобігає хибним висновкам.

Очищення простору імен після тестування заслуговує на обережність, тому що об’єкти-знімки та знімки бекенду можуть мати різні терміни життя. У класі Delete видалення простору імен може запустити видалення VolumeSnapshot із простору імен, що своєю чергою може прибрати пов’язаний вміст і знімок бекенду. У класі Retain очищення може залишити вміст із областю видимості кластера чи зовнішній стан бекенду, який усе ще потребує перегляду володіння. Лабораторна робота може бути простою, але ментальна модель має залишатися точною.

Для готовності до продакшну пишіть runbook відновлення в термінах об’єктів і перевірок, а не окремих людей чи разових команд. Runbook має казати, яка мітка знімка обирає кандидата, як підтвердити готовність, як визначити розмір відновленого PVC, який простір імен отримує валідаційну заявку, який Под чи завдання валідує дані і як схвалюється переключення застосунку. Така структура робить відновлення повторюваним навіть тоді, коли звичайний оператор недоступний.

Нарешті, відокремте впевненість у резервній копії від комфорту резервної копії. Приємно бачити список успішних об’єктів-знімків, але впевненість походить від нещодавнього відновлення, яке задіяло той самий клас, квоту, політику простору імен і перевірки застосунку, які ви очікуєте використати під час відновлення. Іспит CKA зазвичай попросить меншу версію цих міркувань, але звичка переноситься прямо на реальні кластери: кожен об’єкт захисту даних має мати протестований шлях назад до придатних для використання даних, названого власника, задокументоване правило очищення, що відповідає політиці класу знімка, і достатньо операційного контексту, щоб інший інженер міг повторити відновлення без здогадок під час напруженого вікна обслуговування чи екзаменаційної лабораторної роботи в умовах нестачі часу.

---

Патерни та антипатерни

Патерни знімків працюють найкраще, коли вони відокремлюють створення точки відновлення від валідації відновлення. Платформна команда надає класи й контролери, команди застосунків вирішують, коли дані безпечно зафіксувати, а навчання з відновлення доводять, що знімок може стати придатним для використання PVC. Коли ці обов’язки розмиваються, команди часто створюють привабливі дашборди успішних об’єктів-знімків, не знаючи, чи може відновлений застосунок завантажитися, прочитати свої дані й видати правильні результати.

Патерн	Коли його використовувати	Чому він працює	Міркування щодо масштабування
Знімок перед ризикованою зміною	Міграції схеми, великі оновлення, деструктивне обслуговування	Фіксує названу точку відновлення перед зміною стану	Поєднуйте з призупиненням застосунку та репетицією відновлення
Відновлення у валідаційний PVC	Будь-який важливий робочий процес відновлення	Дозволяє оглянути дані перед перемиканням навантажень	Автоматизуйте очищення, щоб валідаційні заявки не накопичувалися
Клас зі збереженням для відновлення	Захист даних для відповідності чи високоцінних даних	Запобігає видаленню знімка, коли об’єкти-запити прибираються	Потребує ручного зберігання й перегляду вартості
Клон для копій у межах одного простору імен	Тестова копія чи репетиція міграції поряд із джерелом	Уникає створення придатного для повторного використання знімка, коли історія не потрібна	Не є стратегією резервного копіювання між просторами імен чи історичного

Антипатерни часто походять зі ставлення до об’єктів-знімків як до доказу резервної копії. Знімок — лише одна частина системи відновлення, і API Kubernetes не знає, чи скинув ваш застосунок дані, чи правильно ваша процедура відновлення спрямовує застосунок на новий PVC і чи доступний збережений знімок бекенду через місяці. Краща альтернатива — зробити тестування відновлення частиною дизайну, а не окремим майбутнім проєктом.

Антипатерн	Що йде не так	Краща альтернатива
Робити знімок кожного PVC без перегляду класу	Деякі драйвери чи класи можуть не підтримувати придатне відновлення	Інвентаризуйте драйвери, класи та поведінку відновлення перед плануванням
Використовувати клони як резервні копії	Клон фіксує поточний стан і не створює придатної точки відновлення	Використовуйте VolumeSnapshot’и для названого відновлення на певний момент часу
Видаляти знімки з невідомою політикою	Знімки бекенду можуть несподівано зникнути чи затриматися	Прочитайте deletionPolicy і задокументуйте володіння зберіганням
Відновлювати напряму в продакшн-шлях	Погане відновлення може замінити один інцидент іншим	Відновлюйте в окремий PVC і валідуйте перед перемиканням
Ігнорувати консистентність застосунку	Бази даних можуть відновитися до crash-консистентного чи пошкодженого стану	Призупиніть, скиньте буфери, використайте хук чи знімайте з підготовленої репліки
Сліпо копіювати YAML постачальника	Назви драйверів і параметри відрізняються між кластерами	Спершу огляньте встановлені CSI-ресурси й документацію постачальника

Турбота про масштабування — це операційний інвентар. Щойно знімки стають рутиною, вам потрібні мітки, власники, вікна зберігання, записи тестів відновлення та видимість витрат. Невелика лабораторна робота може видалити все наприкінці. Продакшн-кластеру потрібна чітка відповідь на те, хто володіє збереженим знімком, навіщо він існує, коли він спливає і коли його востаннє успішно відновлювали.

---

Фреймворк прийняття рішень

Обирайте між знімком, клоном і звичайною міграцією PVC, питаючи, який момент у часі вам потрібен і де має жити копія. Якщо вам потрібні поточні дані в межах одного простору імен, клон зазвичай є найпростішим варіантом, коли драйвер його підтримує. Якщо вам потрібна історична точка відновлення, повторні відновлення, зберігання чи відновлення між просторами імен, знімок є кращим примітивом. Якщо драйвер не підтримує жодної операції, поверніться до нативного для застосунку резервного копіювання чи міграції на рівні файлів, а не вдавайте, що об’єкт Kubernetes виконає роботу, яку бекенд не виконує.

Питання для рішення	Віддати перевагу знімку	Віддати перевагу клону	Віддати перевагу нативному резервному копіюванню
Потрібна історична точка відновлення?	Так, знімки зберігають названий момент у часі	Ні, клони копіюють поточний стан джерела	Так, особливо для логічного відновлення БД
Потрібна швидка копія в межах одного простору імен?	Працює, але створює зайві об’єкти відновлення	Так, коли драйвер підтримує клонування	Зазвичай повільніше й більш специфічне для застосунку
Потрібне відновлення між просторами імен?	Можливе з підтримуваною політикою посилань	Звичайне клонування — в межах одного простору імен	Часто корисне, коли політика платформи блокує посилання
Потрібен консистентний для застосунку стан БД?	Лише з призупиненням чи хуками	Лише з контролем консистентності джерела	Часто найкраще для гарантій на рівні транзакцій
Потрібне довге зберігання поза життєвим циклом кластера?	Використайте Retain і керування бекендом	Не є механізмом зберігання	Часто потрібне для архівів відповідності

Практичний шлях прийняття рішення — це почати з конкретного збою або робочого процесу, а не з абстрактного вибору. Для зіпсованих даних, спричинених поганою міграцією, відновлюйте зі знімка, зробленого ще перед міграцією; клонування поточного PVC лише слухняно скопіює ті самі погані дані. Для розробника, якому потрібна швидка копія справного PVC у тому самому просторі імен, клонуйте, якщо тільки драйвер це підтримує. Для аварійного відновлення в окремому просторі імен чи навіть окремому кластері відновлення зі знімка може допомогти, але ви спершу маєте перевірити політику посилань, переносність бекенду та те, чи не прив’язані знімки до конкретного регіону. Нарешті, для баз даних зі строгими вимогами до відновлення поєднуйте знімки сховища з повноцінними процедурами резервного копіювання й відновлення на рівні самої бази даних.

Ставтеся до результату як до плану, який можна протестувати. Обраний клас знімка слід задіяти з реальним PVC, реальним VolumeSnapshot, PVC відновлення та валідаційним Под’ом. Обраний робочий процес клонування слід протестувати з вихідним PVC у тому самому просторі імен і заявкою призначення потрібного розміру. Обрану політику зберігання слід протестувати, видаливши об’єкт-запит і підтвердивши, що відбувається з вмістом і станом бекенду. Рішення стають надійними лише тоді, коли вони витримують невелику репетицію.

---

Чи знали ви?

• API знімків томів досягли GA у Kubernetes 1.20 (грудень 2020); стабільна група — snapshot.storage.k8s.io/v1, а контролер знімків документується окремо від sidecar’а CSI-драйвера, тому що потрібні обидва.
• VolumeSnapshotClass можна позначити як типовий за допомогою snapshot.storage.kubernetes.io/is-default-class: "true", але обраний клас усе одно має відповідати поведінці CSI-драйвера за вихідним PVC.
• dataSource для PVC відновлення може посилатися на VolumeSnapshot, тоді як dataSource для клону посилається на PersistentVolumeClaim; значення kind — найшвидший спосіб визначити, який робочий процес запитує YAML.
• dataSourceRef.namespace між просторами імен є альфою (v1.26+); потребує gate CrossNamespaceVolumeDataSource і ReferenceGrant у вихідному просторі імен.

---

Типові помилки

Помилка	Чому вона трапляється	Як її виправити
Немає CSI-драйвера з підтримкою знімків	Команди припускають, що будь-яке персистентне сховище можна знімати, бо PVC працюють	Перевірте встановлений CSI-драйвер, sidecar’и знімків і підтримку знімків постачальником перед написанням планів резервного копіювання
Відсутні CRD чи контролер знімків	Розширення API й контролер окремі від звичайної підтримки PVC	Встановіть CRD і контролер знімків із підтримуваного шляху релізу CSI external-snapshotter
Неправильний драйвер у VolumeSnapshotClass	Приклади постачальників копіюють без відповідності встановленому драйверу кластера	Порівняйте driver класу з провіжнерами StorageClass і назвами CSIDriver
Замалий розмір відновлення	Оператори плутають використані дані файлової системи з потрібним розміром тому знімка	Прочитайте .status.restoreSize і запитайте щонайменше стільки сховища в PVC призначення
Клонування між просторами імен	Клонування здається копіюванням, тож люди очікують, що межі простору імен не мають значення	Використайте відновлення зі знімка з підтримуваною політикою dataSourceRef або тримайте клони в одному просторі імен
Зарано видалене вихідне PVC	Команди припускають, що клон чи знімок завершилися, бо об’єкт було створено	Дочекайтеся прив’язки клону чи readyToUse: true знімка перед видаленням джерела
Пропуск консистентності застосунку	Знімки сховища плануються без координації із записами бази даних	Використовуйте хуки застосунку, read lock, репліки чи нативні інструменти резервного копіювання для створення безпечної точки фіксації

---

Тест

Питання 1: Ваша продакшн-база даних PostgreSQL має пошкоджені дані після поганої міграції. У вас є VolumeSnapshot, зроблений за годину до міграції, а оригінальний PVC усе ще працює з пошкодженими даними. Вам слід клонувати PVC чи відновити зі знімка?

Відновити зі знімка. Клон скопіював би поточний стан вихідного PVC, який уже пошкоджений, тож він створив би ще одну копію поганих даних. Знімок представляє названий момент у часі перед міграцією, тож новий PVC із dataSource.kind: VolumeSnapshot дає вам ціль для відновлення. Вам усе одно слід спочатку відновити в окремий PVC, провалідувати базу даних, а потім планувати переключення застосунку.

Питання 2: Розробник створює VolumeSnapshot, але він залишається на `readyToUse: false`. `kubectl get volumesnapshotclass` не повертає ресурсів, а кластер використовує CSI-драйвер AWS EBS для звичайних PVC. Чого бракує?

Інфраструктура знімків неповна. Звичайний провіжнінг PVC через CSI-драйвер EBS не доводить автоматично, що CRD знімків, контролер знімків, sidecar CSI-snapshotter і відповідний VolumeSnapshotClass встановлені. Розробник має перевірити CRD, розгорнути чи оглянути контролер знімків і створити клас, чий driver відповідає ebs.csi.aws.com. Перестворення того самого VolumeSnapshot без цих компонентів не зробить його готовим.

Питання 3: Вам потрібен staging-простір імен із даними, подібними до продакшну. Прямий клон із продакшн-PVC зазнає невдачі, але продакшн-VolumeSnapshot існує. Чому клон зазнав невдачі і який дизайн відновлення вам слід оцінити?

Клон зазнав невдачі, тому що звичайне клонування PVC вимагає, щоб вихідний і цільовий PVC були в одному просторі імен. Для межі простору імен оцініть робочий процес відновлення зі знімка, використовуючи VolumeSnapshot у продакшн-просторі імен і PVC призначення, який посилається на нього через підтримувану поведінку dataSourceRef. Цей дизайн також може потребувати ReferenceGrant чи еквівалентної політики, щоб вихідний простір імен явно дозволив посилання. Якщо кластер не підтримує таку політику, використайте нативний для застосунку експорт чи інший схвалений шлях міграції.

Питання 4: Знімок PVC розміром `100Gi` містить лише `5Gi` файлів. PVC відновлення запитує `10Gi` і залишається в стані pending. Що вам слід перевірити й змінити?

Перевірте статус VolumeSnapshot і прочитайте .status.restoreSize. Розмір відновлення відображає розмір тому, потрібний шляху відновлення зі знімка, а не лише обсяг даних, який наразі зберігає файлова система. Якщо знімок повідомляє 100Gi, PVC призначення має запитати щонайменше 100Gi, інакше провіжнер може його відхилити. Збільшення запиту до розміру відновлення вирішує контракт призначення; це не вимагає перестворення вихідного знімка.

Питання 5: Команда робить погодинні знімки PVC MySQL за допомогою CronJob. Після відновлення MySQL повідомляє про проблеми відновлення, тому що знімок було зроблено під час активних записів. Що пішло не так і як слід змінити стратегію?

Знімок був crash-консистентним на рівні сховища, а не обов’язково консистентним на рівні застосунку. Kubernetes зафіксував момент у часі із системи сховища, але не знав, чи скинув MySQL буфери чи призупинив записи. Стратегія має додати pre-snapshot- і post-snapshot-хуки застосунку, використати read lock чи іншу безпечну процедуру MySQL або робити знімок підготовленої репліки. Команді також слід регулярно тестувати відновлення, тому що готовий об’єкт-знімок не доводить, що база даних може коректно запуститися.

Сильніша стратегія валідації резервного копіювання на основі знімків для навантажень зі станом відновлювала б нещодавній знімок в окремий PVC, завантажувала б валідаційний екземпляр або запускала б перевірки бази даних і фіксувала б результат. Це робить стратегію резервного копіювання вимірюваною, а не покладається лише на створення об’єкта. Якщо валідація зазнає невдачі, команда має вважати робочий процес знімків нездоровим навіть тоді, коли об’єкт Kubernetes повідомляє про готовність.

Питання 6: PVC відновлення в стані pending. Знімок має `readyToUse: true`, клас існує, а події PVC згадують провіжнер, що чекає на першого споживача. Чи зламаний знімок?

Не обов’язково. Джерело-знімок може бути валідним, тоді як PVC призначення затримується звичайною поведінкою провіжнінгу, особливо коли StorageClass використовує WaitForFirstConsumer. Наступний крок — створити чи оглянути Под, який споживатиме відновлену заявку, а потім прочитати події планування та PVC разом. Якщо Под з’являється, а провіжнінг усе одно зазнає невдачі, продовжуйте з класом призначення, топологією та логами драйвера. Не перестворюйте справний знімок лише тому, що PVC відновлення чекає на окрему умову.

Питання 7: Платформна команда хоче зберігати щомісячні точки відновлення для баз даних, але автоматично прибирати короткочасні тестові знімки. Як їм слід використовувати VolumeSnapshotClass'и та мітки?

Використовуйте окремі класи знімків або чітко задокументовані політики, щоб захищені знімки баз даних використовували Retain, де доречно, тоді як одноразові тестові знімки використовували Delete. Додайте мітки, як-от backup-type, source-pvc і метадані власника, щоб автоматизація очищення могла знаходити правильні об’єкти без здогадок. Збереженим знімкам потрібен ручний чи автоматизований процес інвентаризації, тому що видалення об’єкта-запиту може не видалити знімок бекенду. Команді також слід запускати валідацію відновлення, оскільки зберігання без протестованого відновлення — це лише накопичення сховища.

---

Практична вправа: знімок і відновлення

Сценарій вправи: ви створите тестові дані в PVC, зробите знімок, зімітуєте пошкодження даних і відновите оригінальні дані в новий PVC. Команди припускають кластер із CSI-драйвером, що підтримує знімки, CRD знімків і контролером знімків. Якщо ви використовуєте kind чи minikube, вам може знадобитися встановити компоненти знімків і використати CSI-драйвер, що підтримує операції; самого лише local-path-провіжнера може не вистачити для справжніх знімків.

Передумови

Ця вправа потребує кластера з:

• CSI-драйвером, що підтримує знімки
• Встановленими контролером знімків і CRD
• StorageClass’ом, чий провіжнер може створювати томи зі знімків
• Дозволом створювати VolumeSnapshotClass або доступом до наявного

Налаштування локального середовища можна зробити з офіційних маніфестів external-snapshotter, коли вашому практичному кластеру потрібні CRD і контролер. Використовуйте маніфести, що відповідають релізу external-snapshotter, підтримуваному вашою версією Kubernetes і драйвером сховища. Встановлення лише CRD навчає формі API, але повноцінній лабораторній роботі все одно потрібен CSI-драйвер із підтримкою знімків.

# Install Snapshot CRDs
kubectl kustomize https://github.com/kubernetes-csi/external-snapshotter/client/config/crd | kubectl create -f -

# Install Snapshot Controller
kubectl -n kube-system kustomize https://github.com/kubernetes-csi/external-snapshotter/deploy/kubernetes/snapshot-controller | kubectl create -f -

Завдання 1: Перевірте підтримку знімків

Почніть із доведення, що рівні API й класу існують. Якщо ці команди зазнають невдачі, поки не переходьте до тестування відновлення; пізніші маніфести залежать від цих ресурсів. Якщо VolumeSnapshotClass не існує, ви створите його з назви провіжнера встановленого CSI-драйвера в пізнішому завданні.

# Verify CRDs exist
kubectl get crd | grep snapshot

# Check for VolumeSnapshotClass
kubectl get volumesnapshotclass

# If none exists, you'll need to create one based on your CSI driver

Підказка до розв'язання

Ви маєте побачити три CRD знімків і щонайменше один клас знімків у підготовленому кластері. Якщо CRD відсутні, API-сервер не зберігає ресурси VolumeSnapshot. Якщо класи відсутні, знімок усе ще можливий після того, як ви створите клас із правильним драйвером, але вам треба знати, який CSI-провіжнер стоїть за вихідним PVC.

Завдання 2: Створіть тестові дані

Створіть простір імен, PVC і Под, який записує файл. Файл дає вам простий сигнал, що відновлення спрацювало пізніше. Рядок DEFAULT_SC обирає поточний типовий StorageClass, що зручно для лабораторної роботи, але в продакшні ви обирали б клас навмисно на основі драйвера, топології, розширення, політики повернення та підтримки знімків.

# Create namespace
kubectl create ns snapshot-lab

# Get default StorageClass
DEFAULT_SC=$(kubectl get sc | awk '/\(default\)/ {print $1}')

# Create a PVC
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-data
  namespace: snapshot-lab
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ${DEFAULT_SC}
EOF

# Create pod to write data
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: data-writer
  namespace: snapshot-lab
spec:
  containers:
  - name: writer
    image: busybox:1.36
    command: ['sh', '-c', 'echo "Important data created at $(date)" > /data/important.txt; sleep 3600']
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: source-data
EOF

# Wait for pod to be ready and data to be written
kubectl wait --for=condition=Ready pod/data-writer -n snapshot-lab --timeout=60s
kubectl exec -n snapshot-lab data-writer -- cat /data/important.txt

Підказка до розв'язання

Остання команда має вивести рядок, що починається з Important data created at. Якщо Под у стані pending, огляньте події PVC і Под’а перед продовженням. Лабораторна робота зі знімком доводить поведінку відновлення лише після того, як оригінальний PVC справді прив’язаний і примонтований Под’ом.

Завдання 3: Створіть VolumeSnapshotClass (за потреби)

Створюйте цей клас, лише якщо ваш кластер ще не надає відповідного типового класу. Назва драйвера походить від провіжнера StorageClass, тож клас знімка відповідає сховищу, яке створило вихідний PVC. Якщо ваш постачальник сховища документує іншу назву драйвера знімків чи потрібні параметри, використайте значення, підтримуване постачальником, замість сліпого копіювання цього лабораторного класу.

# Get the CSI driver of the default StorageClass
CSI_DRIVER=$(kubectl get sc ${DEFAULT_SC} -o jsonpath='{.provisioner}')

cat <<EOF | kubectl apply -f -
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
driver: ${CSI_DRIVER}
deletionPolicy: Delete
EOF

Підказка до розв'язання

Запустіть kubectl get volumesnapshotclass csi-snapclass -o yaml і підтвердьте, що поле driver заповнене. Якщо CSI_DRIVER порожній, пошук типового класу зазнав невдачі або типового StorageClass немає. У такому разі оберіть StorageClass явно й повторіть видобуток драйвера з тією назвою класу.

Завдання 4: Створіть знімок

Створіть знімок, поки файл існує у вихідному PVC, а потім дочекайтеся readyToUse. Команда очікування важлива, тому що створений об’єкт — це не те саме, що придатна точка відновлення. Якщо очікування завершується за тайм-аутом, опишіть знімок і перевірте логи контролера перед переходом до пошкодження й відновлення.

cat <<EOF | kubectl apply -f -
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: source-snapshot
  namespace: snapshot-lab
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: source-data
EOF

# Wait for snapshot to be ready
kubectl wait --for=jsonpath='{.status.readyToUse}'=true volumesnapshot/source-snapshot -n snapshot-lab --timeout=120s
# Verify snapshot status
kubectl get volumesnapshot source-snapshot -n snapshot-lab

Підказка до розв'язання

Знімок має повідомити про статус готовності й розмір відновлення. Якщо цього не сталося, запустіть kubectl describe volumesnapshot source-snapshot -n snapshot-lab і прочитайте події. Поширені причини включають відсутній контролер знімків, неправильний драйвер класу, вихідний PVC, який не прив’язаний, або драйвер сховища, що не підтримує знімки.

Завдання 5: «Пошкодьте» оригінальні дані

Тепер перезапишіть файл в оригінальному PVC. Це імітує погану міграцію чи випадковий запис після того, як знімок було зроблено. Ви не лагодите оригінальну заявку на місці; ви створюєте контрольовану відмінність, щоб відновлений PVC міг довести, що він походить із попередньої точки відновлення.

# Simulate data loss
kubectl exec -n snapshot-lab data-writer -- sh -c 'echo "Corrupted!" > /data/important.txt'
kubectl exec -n snapshot-lab data-writer -- cat /data/important.txt
# Shows: Corrupted!

Підказка до розв'язання

Вивід тепер має показати Corrupted! з оригінального PVC. Це той момент, де клон був би неправильним інструментом відновлення, тому що він скопіював би поточний пошкоджений стан. Знімок цінний, тому що він зафіксував попередній вміст файлу.

Завдання 6: Відновіть зі знімка

Видаліть Под-записувач, щоб оригінальна заявка не була активно примонтована, потім створіть новий PVC зі знімка та Под-читач, який монтує відновлену заявку. Цей шлях відновлення валідує суттєвий контракт: знімок стає новим PVC з оригінальними даними. У продакшн-відновленні ви додали б валідацію застосунку перед переміщенням трафіку.

# Delete the pod (to release PVC)
kubectl delete pod -n snapshot-lab data-writer

# Create new PVC from snapshot
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-data
  namespace: snapshot-lab
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ${DEFAULT_SC}
  resources:
    requests:
      storage: 1Gi
  dataSource:
    name: source-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
EOF

# Create pod to verify restored data
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: data-reader
  namespace: snapshot-lab
spec:
  containers:
  - name: reader
    image: busybox:1.36
    command: ['sh', '-c', 'cat /data/important.txt; sleep 3600']
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: restored-data
EOF

# Wait for reader pod to be ready
kubectl wait --for=condition=Ready pod/data-reader -n snapshot-lab --timeout=60s

# Verify original data is restored
kubectl logs -n snapshot-lab data-reader
# Should show: Important data created at <original timestamp>

Підказка до розв'язання

Под-читач має вивести оригінальний рядок Important data created at, а не Corrupted!. Якщо відновлений PVC у стані pending, опишіть його й порівняйте запитаний розмір із розміром відновлення знімка. Якщо Под у стані pending після прив’язки PVC, огляньте звичайні події планування й монтування, тому що знімок міг уже виконати свою частину.

Критерії успіху

• VolumeSnapshotClass створено чи підтверджено з правильним CSI-драйвером.
• VolumeSnapshot показує readyToUse: true.
• Новий PVC створено зі знімка й успішно прив’язано.
• Відновлені дані відповідають оригінальному файлу, а не пошкодженій версії.
• Ви можете пояснити, чому клон не виправив би цей сценарій пошкодження.
• Ви можете описати стратегію валідації резервного копіювання на основі знімків для навантажень зі станом.

Очищення

kubectl delete ns snapshot-lab
kubectl delete volumesnapshotclass csi-snapclass

Тренувальні вправи

Використовуйте ці вправи, щоб напрацювати швидкість роботи з командами після основної лабораторної роботи. Кожна вправа достатньо мала, щоб повторювати її, поки ви не зможете набрати її з пам’яті, але не ставтеся до команд як до магічних рядків. Для кожної з них скажіть, який рівень вона перевіряє: виявлення API, політику класу, готовність знімка, форму PVC відновлення, форму PVC клону, вимогу до розміру чи прив’язку вмісту.

# Task: Find all snapshot-related resources
kubectl api-resources | grep snapshot

# Task: Create SnapshotClass for your CSI driver with Delete policy
cat <<EOF | kubectl apply -f -
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: practice-snapclass
driver: ${CSI_DRIVER} # Use driver found in lab
deletionPolicy: Delete
EOF

# Task: Verify a snapshot is ready to use
kubectl get volumesnapshot <name> -o jsonpath='{.status.readyToUse}'

# Task: Create PVC from snapshot "backup-snap"
# Key: dataSource with kind: VolumeSnapshot
# Add -n <namespace> and a storageClassName for your cluster
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  dataSource:
    name: backup-snap
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
EOF

# Task: Clone PVC "source-pvc" to "clone-pvc"
# Key: dataSource with kind: PersistentVolumeClaim
# Add -n <namespace> and a storageClassName for your cluster
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: clone-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  dataSource:
    name: source-pvc
    kind: PersistentVolumeClaim
EOF

# Task: Get the restore size of a snapshot
kubectl get volumesnapshot <name> -o jsonpath='{.status.restoreSize}'

# Task: Find the VolumeSnapshotContent for a VolumeSnapshot
kubectl get volumesnapshot <name> -o jsonpath='{.status.boundVolumeSnapshotContentName}'

---

Перевірка для учня

Відновлення між просторами імен потребує feature gate CrossNamespaceVolumeDataSource (альфа з v1.26) плюс CRD ReferenceGrant з Gateway API.

Перш ніж відновлювати знімок в інший простір імен, який об’єкт має існувати у вихідному просторі імен і який feature gate має бути увімкнено?

---

Джерела

• https://kubernetes.io/docs/concepts/storage/volume-snapshots/
• https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/
• https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/
• https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• https://github.com/kubernetes-csi/external-snapshotter
• https://github.com/kubernetes-csi/external-snapshotter/tree/master/client/config/crd
• https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller
• https://github.com/kubernetes-sigs/aws-ebs-csi-driver
• https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/volume-cloning
• https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/gce-pd-csi-driver
• https://learn.microsoft.com/en-us/azure/aks/azure-csi-disk-storage-provision
• https://learn.microsoft.com/en-us/azure/aks/azure-disk-csi

Наступний модуль

Продовжте до Модуля 4.5: Усунення несправностей сховища, щоб навчитися діагностувати й виправляти поширені проблеми зі сховищем.