VictoriaMetrics: міграція даних VMSingle та VictoriaLogs між кластерами Kubernetes

Автор |  27/06/2025
0 коментарів
 

Є у нас VictoriaMetrics і VictoriaLogs, працюють на AWS Elastic Kubernetes Service.

Мажорні апгрейди EKS ми робимо через створення нового кластеру, а тому з’явилась задача перенесення даних моніторингу зі старого інстансу VMSingle на новий.

Для VictoriaMetrics можемо використати vmctl, яка через API старого і нового інстансу може мігрувати дані працюючи в ролі проксі між двома інстансами.

З VictoriaLogs ситуація поки що дещо складніша і наразі є два варіанти – далі їх подивимось.

Отже, що маємо:

  • старий Kubernetes cluster EKS 1.30
  • новий Kubernetes cluster EKS 1.33

Деплоїться нашим власним Helm-чартом, який через dependencies встановлює victoria-metrics-k8s-stack та victoria-logs-single, плюс пачка різних додаткових сервісів типу PostgreSQL Exporter.

Міграція метрик VictoriaMetrics

Запуск vmctl

vmctl підтримує міграцію як з VMSinlge на VMClutser, так і навпаки, або просто між інстансами VMSinlge => VMSinlge, або VMClutser => VMClutser.

В нашому випадку це просто два інстанси VMSingle.

Встановити vmctl можна встановити локально у поді з VMSingle, див. How to build, але так як CLI все одно працює через API – то простіше створити окремий Pod, і все робити з нього. Docker-образ доступний тут – victoriametrics/vmctl.

Так як entrypoint для цього образу заданий в /vmctl-prod, то аби просто зайти в контейнер – передамо --command, запустимо в циклі ping та sleep, і далі спокійно з консолі будемо робити все, що нам треба:

$ kubectl run vmctl-pod --image=victoriametrics/vmctl --restart=Never --command -- /bin/sh -c "while true; echo ping; do sleep 5; done"
pod/vmctl-pod created

На якому саме кластері запускати в принципі різниці нема.

Підключаємось в Pod:

$ kk exec -ti vmctl-pod -- sh  
/ #

Перевіримо:

/ # /vmctl-prod vm-native --help
NAME:
   vmctl vm-native - Migrate time series between VictoriaMetrics installations via native binary format

USAGE:
   vmctl vm-native [command options] [arguments...]

OPTIONS:
   -s                              Whether to run in silent mode. If set to true no confirmation prompts will appear. (default: false)
   ...

Запуск міграції

Kubernetes Pod з vmctl буде працювати в ролі проксі між source та destination, тому повинен мати стабільний нетворк.

Крім того, якщо мігруєте великий об’єм даних – то подивіться в бік опції --vm-concurrency для запуску міграції в кілька паралельних потоків, при цьому кожен воркер буде додатково використовувати CPU/Memory.

В документації також описані можливі проблеми з лімітами – див. Migrating data from VictoriaMetrics, і корисно глянути розділ Migration tips.

Також рекомендується додати фільтр --vm-native-filter-match='{__name__!~"vm_.*"}' аби не переносити метрики, які відносяться до самої VictoriaMetrics, бо це може призвести до data collision – появи дублікатів тайм-серій.

Хоча в моєму випадку у нас через VMAgent до всіх метрик додається метрика з іменем кластеру:

...
  vmagent:
    enabled: true
    spec:
      externalLabels:
        cluster: "eks-ops-1-33"
...

Якщо для VMSingle задані resources.limits – краще їх відключити або збільшити, і збільшити реквести, бо я ловив 504 та Pod Eviction.

І можливо є сенс винести VMSingle на окрему WorkerNode, бо в нашому випадку для моніторингу використовуються t3, ще й Spot.

Що і куди мігруємо:

  • source: VMSingle на EKS 1.30
    • ендпоінт vmsingle.monitoring.1-30.ops.example.co
  • destination: VMSingle на EKS 1.33
    • ендпоінт vmsingle.monitoring.1-33.ops.example.co

З нашого поду з vmctl перевіряємо доступ до обох ендпоінтів:

/ # apk add curl

/ # curl -X GET -I https://vmsingle.monitoring.1-30.ops.example.co
HTTP/2 400

/ # curl -X GET -I https://vmsingle.monitoring.1-33.ops.example.co
HTTP/2 200

І запускаємо міграцію за весь період – не пам’ятаю, коли саме цей кластер було створено, нехай буде січень 2023:

/ # /vmctl-prod vm-native \
> --vm-native-src-addr=https://vmsingle.monitoring.1-30.ops.example.co/ \
> --vm-native-dst-addr=https://vmsingle.monitoring.1-33.ops.example.co \
> --vm-native-filter-match='{__name__!~"vm_.*"}' \
> --vm-native-filter-time-start='2023-01-01'
VictoriaMetrics Native import mode
...

Процес пішов:

Ресурси на source – память до 5-6 гігабайт піднімалась:

На destination було трохи більше CPU, але менше пам’яті:

І завершення – зайняло 6 годин, але це я робив без --vm-concurrency:

...
2025/06/23 19:07:29 Import finished!
2025/06/23 19:07:29 VictoriaMetrics importer stats:
  time spent while importing: 6h30m8.537582366s;
  total bytes: 16.5 GB;
  bytes/s: 705.9 kB;
  requests: 6882;
  requests retries: 405;
2025/06/23 19:07:29 Total time: 6h30m8.541808518s

Тепер на новому кластері маємо графіки за місяць, хоча кластер створений тиждень тому:

Якщо міграція зафейлилась

Спочатку перевіряємо запит – треба знайти старі метрики на новому кластері.

Перевіряємо на новому кластері використовуючи лейблу cluster – корисна штука:

$ curl -s 'http://localhost:8429/prometheus/api/v1/series' -d 'match[]={cluster="eks-ops-1-30"}' | jq
...
    {
      "__name__": "yace_cloudwatch_targetgroupapi_requests_total",
      "cluster": "eks-ops-1-30",
      "job": "yace-exporter",
      "instance": "yace-service:5000",
      "prometheus": "ops-monitoring-ns/vm-k8s-stack"
    }
...

Документація з видалення метрик і взагалі роботі з VictoriaMetrics API – How to delete or replace metrics in VictoriaMetrics і Deletes time series from VictoriaMetrics.

Виконуємо запит на /api/v1/admin/tsdb/delete_series:

$ curl -s 'http://localhost:8429/api/v1/admin/tsdb/delete_series' -d 'match[]={cluster="eks-ops-1-30"}

Перевіряємо:

$ curl -s 'http://localhost:8429/prometheus/api/v1/series' -d 'match[]={cluster="eks-ops-1-30"}' | jq
{
  "status": "success",
  "data": []
}

Тепер можна повторити міграцію.

Інший варіант – додати опцію dedup.minScrapeInterval=1ms, тоді VictoriaMetrics сама видалить дублікати, але я цей варіант не тестив.

Міграція VictoriaLogs

З VictoriaLogs ситуація трохи складніша, бо vlogscli поки що (сподіваюсь, додадуть) не має якоїсь опції для переносу даних як в vmctl.

І тут є проблема:

  • якщо в VictoriaLogs на новому кластері ще нема ніяких даних – то можна просто скопіювати старі даних з rsync в PVC нового інстансу VictoriaLogs
    • аналогічно, якщо дані є, але нема overlapping днів, бо дані в VictoriaLogs storage зберігаються в каталогах по дням, і їм можна спокійно переносити
  • але якщо дані є, та/або дні дублюються – то поки що єдиний варіант це запускати два інстанси VictoriaLogs: один зі старими даними, один з новими, а перед ними мати інстанс vlselect

Коли додадуть Object Storage – то буде простіше, і це вже є в Roadmap. Тоді можна буде просто все тримати в AWS S3, як це у нас зараз в Grafana Loki.

Варіант 1: копіювання даних з rsync

Отже перший варіант – якщо в новому інстансі VictoriaLogs даних нема, або нема записів в одні і ті ж  дні на обох інстансах – старому і новому.

Тут ми можемо просто скопіювати дані, і вони будуть доступні на новому Kubernetes-кластері.

Я робив з rsync, але можна спробувати зробити з утилітами типу korb.

Перевіримо де зберігаються логи в VictoriaLogs Pod:

$ kk describe pod atlas-victoriametrics-vmlogs-new-server-0
Name:             atlas-victoriametrics-vmlogs-new-server-0
...
Containers:
  vlogs:
    ...
    Args:
      --storageDataPath=/storage
    ...
    Mounts:
      /storage from server-volume (rw)
    ...
Volumes:
  server-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  server-volume-atlas-victoriametrics-vmlogs-new-server-0
    ReadOnly:   false
...

І зміст директорії /storage:

~ $ ls -l /storage/partitions/
total 32
drwxrwsr-x    4 1000     2000          4096 Jun 16 00:00 20250616
drwxrwsr-x    4 1000     2000          4096 Jun 17 00:00 20250617
drwxrwsr-x    4 1000     2000          4096 Jun 18 00:00 20250618
drwxrwsr-x    4 1000     2000          4096 Jun 19 00:00 20250619
drwxrwsr-x    4 1000     2000          4096 Jun 20 00:00 20250620
drwxr-sr-x    4 1000     2000          4096 Jun 21 00:00 20250621
drwxr-sr-x    4 1000     2000          4096 Jun 22 00:00 20250622
drwxr-sr-x    4 1000     2000          4096 Jun 23 00:00 20250623

Але в самому поді нема ані rsync, ані SSH, і ми навіть не можемо їх встановити:

~ $ rsync
sh: rsync: not found
~ $ apk add rsync
ERROR: Unable to lock database: Permission denied
ERROR: Failed to open apk database: Permission denied
~ $ su
su: must be suid to work properly
~ $ sudo -s
sh: sudo: not found
~ $ ssh
sh: ssh: not found

Тому просто зробимо rsync зі старого EC2 на новий.

Як знайти потрібний каталог на хості – писав в Kubernetes: знайти каталог з mounted volume в Pod на хості.

Налаштування доступу SSH на EC2 в EKS – AWS: Karpenter та SSH для Kubernetes WorkerNodes.

Перевіряємо Pod на старому кластері – знаходимо його EC2 та Container ID:

$ kk describe pod atlas-victoriametrics-vmlogs-new-server-0 | grep 'Node\|Container'
Node:             ip-10-0-39-190.ec2.internal/10.0.39.190
Containers:
    Container ID:  containerd://db9fa73a4d37045b0338ae48438f9815e4f6f92c3fd6546604ca5d1338f19844
...

Підключаємось на WorkerNode:

$ ssh -i ~/.ssh/eks_ec2 [email protected]

В mounts[] знаходимо каталог для /storage:

[root@ip-10-0-39-190 ec2-user]# crictl inspect  db9fa73a4d37045b0338ae48438f9815e4f6f92c3fd6546604ca5d1338f19844 | jq
...
    "mounts": [
      {
        "containerPath": "/storage",
        "gidMappings": [],
        "hostPath": "/var/lib/kubelet/pods/5192e1f9-20ea-49c6-99ed-775af5e44183/volumes/kubernetes.io~csi/pvc-43c427fa-b05c-45b8-8bdb-92b00bff3496/mount",
...

Перевіряємо зміст:

[root@ip-10-0-39-190 ec2-user]# ll /var/lib/kubelet/pods/5192e1f9-20ea-49c6-99ed-775af5e44183/volumes/kubernetes.io~csi/pvc-43c427fa-b05c-45b8-8bdb-92b00bff3496/mount
total 24
drwxrwsr-x  3 ec2-user 2000  4096 Nov 19  2024 cache
-rw-rw-r--  1 ec2-user 2000     0 Jun 20 19:20 flock.lock
drwxrws---  2 root     2000 16384 Sep  4  2024 lost+found
drwxrwsr-x 10 ec2-user 2000  4096 Jun 25 00:25 partitions

Нам тут треба тільки дані з каталогу partitions.

Повторюємо для VictoriaLogs на новому кластері, правда Amazon Linux 2023 не має critctl – втім, є ctr.

Перевіряємо Linux Namespaces для контейнерів:

[root@ip-10-0-41-247 ec2-user]# ctr ns ls
NAME   LABELS 
k8s.io

Перевіряємо контейнер з ctr containers info:

[root@ip-10-0-41-247 ec2-user]# ctr -n k8s.io containers info 9fd6fefaec92ab76093651239f6e177686e7c7dd012d53d4bf2e6820260aa884
...
            {
                "destination": "/storage",
                "type": "bind",
                "source": "/var/lib/kubelet/pods/4b2f179d-9ada-403e-9680-b76e3507563f/volumes/kubernetes.io~csi/pvc-da384ead-50e8-425f-b3b0-47c35f3a5155/mount",
...

І зміст /var/lib/kubelet/pods/4b2f179d-9ada-403e-9680-b76e3507563f/volumes/kubernetes.io~csi/pvc-da384ead-50e8-425f-b3b0-47c35f3a5155/mount:

[root@ip-10-0-41-247 ec2-user]# ll /var/lib/kubelet/pods/4b2f179d-9ada-403e-9680-b76e3507563f/volumes/kubernetes.io~csi/pvc-da384ead-50e8-425f-b3b0-47c35f3a5155/mount
total 20
-rw-rw-r--.  1 ec2-user 2000     0 Jun 25 12:18 flock.lock
drwxrws---.  2 root     2000 16384 Jun 10 09:41 lost+found
drwxrwsr-x. 10 ec2-user 2000  4096 Jun 25 00:32 partitions

Зверніть увагу на UID юзерів та групи даних, мають бути однакові – ec2-user(1000) та група 2000 на обох EC2 інстансах.

На старому кластері створюємо SSH-ключ і перевіряємо підключення на EC2 нового кластеру:

[root@ip-10-0-39-190 ec2-user]# ssh -i .ssh/eks [email protected]
...
[ec2-user@ip-10-0-41-247 ~]$

ОК, є.

Тепер на обох інстансах встановлюємо rsync:

[root@ip-10-0-39-190 ec2-user]# yum -y install rsync

Про всяк випадок – можна забекапити дані на новому інстансі – або снапшот EBS, або з tar.

І ще нюанс – з retention period, добре, що згадав – він у нас всього 7 днів. Тому якщо скопіювати дані зараз – то старі логи видаляться.

Міняємо:

...
retentionPeriod: 30d
...

На новому інстансі зробимо каталог, куди будемо переносити дані (можна і відразу в каталог PVC):

[root@ip-10-0-41-247 ec2-user]# mkdir vmlogs

І зі старого запускаємо rsync на новий інстанс в $HOME/vmlogs:

[root@ip-10-0-39-190 ec2-user]# rsync -avz --progress -e "ssh -i .ssh/eks" \
> /var/lib/kubelet/pods/5192e1f9-20ea-49c6-99ed-775af5e44183/volumes/kubernetes.io~csi/pvc-43c427fa-b05c-45b8-8bdb-92b00bff3496/mount/partitions/ \
> [email protected]:/home/ec2-user/vmlogs/
...

Тут:

  • -a: архівний режим (зберігає права, час create/modify та структуру)
  • -v: verbose режим
  • -z: компресія даних
  • --progress: відобразити прогрес
  • -e: команда з ssh-ключем

Першим аргументом задаємо локальну директорію, другим – куди копіюємо.

І для source вказуємо “/” в кінці .../mount/partitions/ – скопіювати зміст, а не саму папку.

Якщо витикають помилки з permission denied – додаємо --rsync-path="sudo rsync".

Передача завершена:

...
sent 2,483,902,797 bytes  received 189,037 bytes  20,614,869.99 bytes/sec
total size is 2,553,861,458  speedup is 1.03

Перевіряємо дані на новому інстансі:

[root@ip-10-0-41-247 ec2-user]# ll vmlogs/
total 0
drwxrwsr-x. 4 ec2-user ec2-user 35 Jun 18 00:00 20250618
drwxrwsr-x. 4 ec2-user ec2-user 35 Jun 19 00:00 20250619
drwxrwsr-x. 4 ec2-user ec2-user 35 Jun 20 00:00 20250620
drwxr-sr-x. 4 ec2-user ec2-user 35 Jun 21 00:00 20250621
drwxr-sr-x. 4 ec2-user ec2-user 35 Jun 22 00:00 20250622
drwxr-sr-x. 4 ec2-user ec2-user 35 Jun 23 00:00 20250623
drwxr-sr-x. 4 ec2-user ec2-user 35 Jun 24 00:00 20250624
drwxr-sr-x. 4 ec2-user ec2-user 35 Jun 25 00:00 20250625

Ну і тут власне я зіткнувся з проблемою overlapping data:

[root@ip-10-0-41-247 ec2-user]# cp -r vmlogs/* /var/lib/kubelet/pods/84a4ecd3-21a0-4eec-bebc-078a5105bf86/volumes/kubernetes.io~csi/pvc-da384ead-50e8-425f-b3b0-47c35f3a5155/mount/partitions/
cp: overwrite '/var/lib/kubelet/pods/84a4ecd3-21a0-4eec-bebc-078a5105bf86/volumes/kubernetes.io~csi/pvc-da384ead-50e8-425f-b3b0-47c35f3a5155/mount/partitions/20250618/datadb/parts.json'?

Питав розробників про варіант з JSON merge – але це не спрацює.

Якщо ж дані не перетинаються – то просто копіюємо дані і рестартимо Pod з VictoriaLogs.

В моєму випадку довелось робити трошки інакше.

Варіант 2: запуск двох VMLogs + vlselect

Отже, якщо у нас є дані за одні і ті ж дні на старому і новому інстансах VictoriaLogs – то робимо таким чином:

  • на новому EKS-кластері створюємо другий інстанс VMLogs
  • в його PVC копіюємо дані зі старого кластеру
  • додаємо Pod з vlselect
  • для vlselect вказуємо два source – обидва інстанси VMLogs
  • і потім для Grafana VictoriaLogs data source використовуємо URL сервісу vlselect

Можна було б просто додати vlselect, і роутити запити на старий кластер – але нам треба старий кластер видаляти.

vlselect vs VMLogs

Фактично vlselect це той самий бінарний файл, що і VictoriaLogs, що дуже спрощую нам весь сетап – див. документацію VictoriaLogs cluster:

Note that all the VictoriaLogs cluster components – vlstorage, vlinsert and vlselect – share the same executable – victoria-logs-prod.

Тому ми просто можемо взяти ще один чарт victoria-logs-single, і все запускати з нього.

І насправді ми будемо будувати такий собі “VictoriaLogs cluster на мінімалках”:

  • наш поточний інстанс VictoriaLogs буде грати роль vlinsert та vlstorage – туди пишуться нові логи нового кластеру
  • новий інстанс VictoriaLogs буде грати роль vlstorage – в ньому ми будемо зберігати дані зі старого кластеру
  • третій інстанс VictoriaLogs буде грати роль vlselect – він буде ендпоінтом для Grafana, і буде робити API-запити з пошуком логів з обох інстансів VictoriaLogs

Helm chart update

Я поки не готовий запускати повноцінну версію VictoriaLogs cluster, тому просто додамо ще парочку dependencies в наш поточний Helm chart.

Редагуємо Chart.yaml:

...
dependencies:
...
- name: victoria-logs-single
  version: ~0.11.2
  repository: https://victoriametrics.github.io/helm-charts
  alias: vmlogs-new
- name: victoria-logs-single
  version: ~0.11.2
  repository: https://victoriametrics.github.io/helm-charts
  alias: vmlogs-old
- name: victoria-logs-single
  version: ~0.11.2
  repository: https://victoriametrics.github.io/helm-charts
  alias: vlselect
...

Тут деплоїмо три чарти (точніше, чарт один – просто з різними values, див. Helm: multiple деплой одного чарта з Chart’s dependency), і кожному задаємо власний alias:

  • vmlogs-new: поточний інстанс VMLogs на новому EKS кластері
  • vmlogs-old: новий інстанс, в який будемо переносити дані зі старого EKS кластеру
  • vlselect: буде нашим новим ендпоінтом для пошуку логів

Єдиний момент, що під час деплою може бути помилка через довжину імен подів, бо я спочатку задав надто довгі імена в alias:

...
Pod "atlas-victoriametrics-victoria-logs-single-old-server-0" is invalid: metadata.labels: Invalid value: "atlas-victoriametrics-victoria-logs-single-old-server-77cf9cd79d": must be no more than 63 characters
...

Що треба перевірити в дефолтному values.yaml чарту victoria-logs-single:

...
  persistentVolume:
    # -- Create/use Persistent Volume Claim for server component. Use empty dir if set to false
    enabled: true
    size: 10Gi
...
  ingress:
    # -- Enable deployment of ingress for server component
    enabled: false
...

Для інстансу vlselect додаємо storageNode, де через кому вказуємо ендпоінти обох VictoriaLogs, і при потребі задаємо параметри для persistentVolume:

...
vmlogs-new:
  server:
    persistentVolume:
      enabled: true
      storageClassName: gp2-retain
      size: 30Gi
    retentionPeriod: 14d

vmlogs-old:
  server:
    persistentVolume:
      enabled: true
      storageClassName: gp2-retain
      size: 30Gi
    retentionPeriod: 14d

vlselect:
  server:
    extraArgs:
      storageNode: atlas-victoriametrics-vmlogs-new-server:9428,atlas-victoriametrics-vmlogs-old-server:9428
...

Деплоїмо стек, і перевіряємо Pods:

$ kk get pod | grep 'vmlogs\|vlselect'
atlas-victoriametrics-vlselect-server-0                           1/1     Running     0              19h
atlas-victoriametrics-vmlogs-new-server-0                         1/1     Running     0              76s
atlas-victoriametrics-vmlogs-old-server-0                         1/1     Running     0              76s

Сервіси:

$ kk get svc | grep 'vmlogs\|vlselect'
atlas-victoriametrics-vlselect-server                    ClusterIP   None             <none>        9428/TCP                     22h
atlas-victoriametrics-vmlogs-new-server                  ClusterIP   None             <none>        9428/TCP                     42s
atlas-victoriametrics-vmlogs-old-server                  ClusterIP   None             <none>        9428/TCP                     42s

Тепер у нас Promtail на новому кластері продовжує писати в atlas-victoriametrics-vmlogs-new-server, а atlas-victoriametrics-vmlogs-old-server у нас пустий інстанс VMLogs.

Можемо перевірити доступ до логів через інстанс vlselect:

$ kk port-forward svc/atlas-victoriametrics-vlselect-server 9428

Перенос даних зі старого кластеру

Далі, власне, просто повторюємо те, що робили вище – знаходимо каталог PVC, і копіюємо туди дані зі старого кластеру.

Цього разу спочатку собі на робочу машину, а потім звідси вже в Kubernetes:

[setevoy@setevoy-work ~] $ mkdir vmlogs_back

Поки писав, VictoriaLogs на старому кластері вже переїхав на новий EC2, тому шукаємо дані заново.

Переключаємо kubectl на старий кластер, і шукаємо Pod:

$ kk describe pod atlas-victoriametrics-victoria-logs-single-server-0 | grep 'Node\|Container'
Node:             ip-10-0-38-72.ec2.internal/10.0.38.72
Containers:
    Container ID:  containerd://c168d4487282dd7d868aadcfcd1840e4e15cfd360f56f542a98b77978f91e252
...

Підключаємось, знаходимо директорію:

[root@ip-10-0-38-72 ec2-user]# crictl inspect c168d4487282dd7d868aadcfcd1840e4e15cfd360f56f542a98b77978f91e252
...
    "mounts": [
      {
        "containerPath": "/storage",
        "gidMappings": [],
        "hostPath": "/var/lib/kubelet/pods/f84ef4b9-272f-437e-9f98-649e1707ed09/volumes/kubernetes.io~csi/pvc-43c427fa-b05c-45b8-8bdb-92b00bff3496/mount",
...

Встановлюємо там rsync, і копіюємо дані на робочу машину:

$ rsync -avz --progress -e "ssh -i .ssh/eks_ec2" \
> --rsync-path="sudo rsync" \
> [email protected]:/var/lib/kubelet/pods/f84ef4b9-272f-437e-9f98-649e1707ed09/volumes/kubernetes.io~csi/pvc-43c427fa-b05c-45b8-8bdb-92b00bff3496/mount/partitions/ \
> /home/setevoy/vmlogs_back/
...

Перевіряємо в себе:

$ ll ~/vmlogs_back/
total 32
drwxrwsr-x 4 setevoy setevoy 4096 Jun 19 03:00 20250619
drwxrwsr-x 4 setevoy setevoy 4096 Jun 20 03:00 20250620
drwxrwsr-x 4 setevoy setevoy 4096 Jun 21 03:00 20250621
...

Тепер переносимо все на новий кластер, там де Pod atlas-victoriametrics-vmlogs-old-server-0.

Переключаємо kubectl на новий кластер, знаходимо WorkerNode і Container ID:

$ kd atlas-victoriametrics-vmlogs-old-server-0 | grep 'Node\|Container'
Node:             ip-10-0-36-143.ec2.internal/10.0.36.143
Containers:
    Container ID:  containerd://f10118b10afab75c43e03adcc0644af5caa8654687cd81e59cdf15bd8c32cb31
...

Логінимось і знаходимо директорію:

[root@ip-10-0-36-143 ec2-user]# ctr -n k8s.io containers info f10118b10afab75c43e03adcc0644af5caa8654687cd81e59cdf15bd8c32cb31
...
            {
                "destination": "/storage",
                "type": "bind",
                "source": "/var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount",
...

Перевіряємо – там має бути пусто:

drwxr-sr-x. 2 ec2-user 2000  4096 Jun 26 13:14 partitions
[root@ip-10-0-36-143 ec2-user]# ls -l /var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount/partitions/
total 0

Встановлюємо там rsync і копіюємо дані з локальної директорії /home/setevoy/vmlogs_back/ на новий EKS кластер:

$ rsync -avz --progress -e "ssh -i .ssh/eks_ec2" --rsync-path="sudo rsync" \
> /home/setevoy/vmlogs_back/ \
> [email protected]:/var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount/partitions/
...

Перевіряємо дані там:

[root@ip-10-0-36-143 ec2-user]# ls -l /var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount/partitions/
total 32
drwxrwsr-x. 4 ec2-user ec2-user 4096 Jun 19 00:00 20250619
drwx--S---. 2 root     ec2-user 4096 Jun 26 13:39 20250620
drwx--S---. 2 root     ec2-user 4096 Jun 26 13:39 20250621
drwx--S---. 2 root     ec2-user 4096 Jun 26 13:39 20250622
drwx--S---. 2 root     ec2-user 4096 Jun 26 13:39 20250623
...

Міняємо юзера і групу:

[root@ip-10-0-36-143 ec2-user]# chown -R ec2-user:2000 /var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount/partitions/
[root@ip-10-0-36-143 ec2-user]# ls -l /var/lib/kubelet/pods/297b75ec-63fa-4061-bb23-7a6a120da939/volumes/kubernetes.io~csi/pvc-c7373468-f247-4596-b2e2-87852aad71bb/mount/partitions/
total 32
drwxrwsr-x. 4 ec2-user 2000 4096 Jun 19 00:00 20250619
drwxrwsr-x. 4 ec2-user 2000 4096 Jun 20 00:00 20250620
...

Перезапускаємо Pod atlas-victoriametrics-vmlogs-old-server-0.

Перевірка даних

І пошукаємо щось.

Спочатку щось про ноду hostname: "ip-10-0-36-143.ec2.internal" на новому кластері – це має прийти з інстансу atlas-victoriametrics-vmlogs-new-server-0, тобто зі старого інстансу на новому Kubernetes-кластері:

А тепер якусь ноду зі старого кластера:

Все є.

Готово.