Для этого создаём StorageClass с необходимыми параметрами дебага.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: csi-s3
provisioner: ru.yandex.s3.csi
parameters:
  mounter: geesefs
  options: "--memory-limit=1000 --dir-mode=0777 --file-mode=0666 --debug_s3 --debug_fuse --log-file /var/log/s3.txt --no-systemd"
  bucket: cam-xxxxxxx
  csi.storage.k8s.io/provisioner-secret-name: csi-s3-secret
  csi.storage.k8s.io/provisioner-secret-namespace: kube-system
  csi.storage.k8s.io/controller-publish-secret-name: csi-s3-secret
  csi.storage.k8s.io/controller-publish-secret-namespace: kube-system
  csi.storage.k8s.io/node-stage-secret-name: csi-s3-secret
  csi.storage.k8s.io/node-stage-secret-namespace: kube-system
  csi.storage.k8s.io/node-publish-secret-name: csi-s3-secret
  csi.storage.k8s.io/node-publish-secret-namespace: kube-system

Ошибка.

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524: unknown

Описание проблемы.

Корневая проблема - следствием утечек памяти и срабатываний OOM Killer было увеличение числа Zombie-процессов, затем увеличению числа вызовов в BPF, что приводило к большому выделению страниц памяти путем вызова метода vmalloc(), а также к отбрасыванию всех последующих вызовов к BPF после достижения лимита в опции bpf_jit_enable. Это приводило к утечкам
памяти в seccomp и проблемам при создании подов в окружении Kubernetes.

Решение.
1. Можно развернуть DaemonSet с root привилегиями для подов, которые смогут менять значения bpf_jit_limit.
Однако, у этого решения есть минус. При достижении нового лимита, проблема повторится.

2. Обновить ядро на воркер-нодах до более новой версии, в которых есть патч.
Как указывается в данном обсуждении:
https://github.com/moby/moby/issues/45498#issuecomment-1542155705
Бэкпорт, с удвоением лимита bpf_jit_limit, для этой ветки был начиная с версии 5.4.240.

С даунскейлом нод группы действительно могут возникать проблемы. Это происходит в случае когда на всех нодах автомасштабируемой группы находятся системные поды, которые не могут эвакуироваться с неё. Такое поведение может наблюдаться с подами CoreDNS, которые управляются PDB. Или некоторыми компонентами CNI, у которых есть хранилище emptydir.

Если в кластере есть одна автомасштабируемая нод группа, то такую группу поскейлить в 0 не получится. Так как этому будут препятствовать системные поды. Которые будут хотеть приземлиться на ноду. А контроллер будет заботливо эту ноду создавать. Поэтому всегда будет минимум одна нода.

В тоже время, если создать фиксированную группу, то такую группу можно поскейлить в 0. Так как вы сами управляете числом нод в группе, а не контроллер.

Это можно сделать с помощью команды:

yc k8s node-group update <id_node_group> --fixed-size=0

Также стоит учесть, что самостоятельно системные поды не уедут с ноды, если её не задрейнить. Для этого поможет команда:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force

Но если в кластере несколько нод групп из которых одна масштабируемая, то такую группу поскейлить в 0 можно. В этом случае системные поды можно эвакуировать на нод группу с фиксированным числом нод.

Поэтому, если необходимо иметь возможность скейлить одну или несколько масштабируемых нод групп в ноль, то при их создании необходимо выбрать минимально количество ВМ в группе - ноль. Также иметь группу, можно с минимальной конфигурацией, куда системные поды будут эвакуироваться в случае дрейна нод из масштабируемой группы.

Причина.

Если зайти на хост, то с помощью df -h можно будет заметить, что не подключился диск с базой.

Что делать.

В этом случае поможет сделать стоп процесса postgres.

systemctl stop postgresql

После чего диск должен подключиться и начаться процесс наливки реплики.

Ошибка будет вида.

2023-11-09 23:01:08.728 MSK,,,738013,,654d3a84.b42dd,2,,2023-11-09 23:01:08 MSK,,0,FATAL,08P01,"could not receive data from WAL stream: ERROR: requested WAL segment 0000001700000DA1000000C4 has already been removed",,,,,,,,,"","walreceiver",,0

ports:
- containerPort: 8080
  hostPort: 55080
  name: busybox
  protocol: TCP
hostNetwork: true

Причина.

Containerd рестартовал демонсет. Поды которого выступали как прокси для приложения. Контейнеры сами по себе не рестартовались.

Было древнее ишью, где реализовали игнор данной ошибки со стороны containerd: https://github.com/containerd/containerd/pull/3419

Вот описание проблемы от чела: https://github.com/containerd/containerd/issues/9140?ysclid=lnyheugjka538858773

У него стартует контейнер, а потом падает с этой ошибкой.

Операция обновления отменится. Выпадет ошибка.

Aborting due to multiple operations on the same target

И начнёт выполняться операция удаления группы.

Текущая версия CRI.

crictl version
Version:  0.1.0
RuntimeName:  containerd
RuntimeVersion:  1.6.22
RuntimeApiVersion:  v1

Текущая версия является LTS версией. С поддержкой до February 15, 2022 max(February 15, 2025 or next LTS + 6 months)

Версия 2.0 пока не готова.

Подробнее об этом здесь: https://containerd.io/releases/

На текущий момент конфигурационный файл containerd у нас выглядит так:

oom_score = -999

[debug]
  level = "info"

[plugins.linux]
  shim = "/home/kubernetes/bin/containerd-shim"
  runtime = "/home/kubernetes/bin/runc"

[plugins.cri]
  stream_server_address = "127.0.0.1"
  enable_tls_streaming = false
  sandbox_image = "cr.yandex/crpsjg1coh47p81vh2lc/pause:3.8"
  [plugins.cri.containerd]
    snapshotter = "overlayfs"

[plugins.cri.cni]
  bin_dir = "/home/kubernetes/cni/bin"
  conf_dir = "/etc/cni/net.d"

Путь к конфигурационному файлу :

cat /etc/containerd/config.toml