Господа, а кто нибудь инитил кубадмом кластер без докера, сразу

с контейнерд? Что имею:
kubeadm, kubelet v 1.22.4
containerd 1.5.8

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
criSocket: "/run/containerd/containerd.sock"
kubeletExtraArgs:
runtime-cgroups: /system.slice/containerd.service
container-runtime: remote
container-runtime-endpoint: unix:///run/containerd/containerd.sock
cgroup-driver: "systemd"
v: "4"

В процессе инита (kubeadm init --v=2 --config ./kconfig.yaml --node-name k8s-master1) кублет говорит Cannot connect to the Docker daemon at unix:///var/run/docker.sock
Так же в видно, что nodeConfig ContainerRuntime:docker
Пробовал в кублетовый юнит докидывать ключи через енв Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock" тож не помогло. Если запустить кублет руками с ключами - таких ошибок нет

Я бы посмотрел какие конфиги рендерит кубспрей для контейерд и украл бы, а потом разбирался.

нет необходимости указывать containerd в nodeRegistration. kubeadm сам умеет обнаруживать что у вас containerd. повысьте verbose левел еще больше, до 5 или 7. Он вам подробней напишет почему он хочет докер сокет. Возможно это вообще варнинг в механизме обнаружения (типо пробую докер сокет - его нет, пробую containerd сокет - он есть). У меня тоже containerd. Конфиги для kubeadm выглядят как-то так: https://pastebin.com/X3nXuYzv, нигде containerd явно не указываю

из доки: > By default, Kubernetes uses the Container Runtime Interface (CRI) to interface with your chosen container runtime. If you don't specify a runtime, kubeadm automatically tries to detect an installed container runtime by scanning through a list of well known Unix domain sockets. The following table lists container runtimes and their associated socket paths: Runtime Path to Unix domain socket Docker /var/run/dockershim.sock containerd /run/containerd/containerd.sock CRI-O /var/run/crio/crio.sock If both Docker and containerd are detected, Docker takes precedence. This is needed because Docker 18.09 ships with containerd and both are detectable even if you only installed Docker. If any other two or more runtimes are detected, kubeadm exits with an error. The kubelet integrates with Docker through the built-in dockershim CRI implementation. See container runtimes for more information.

Ну и для точного указания cri я бы реконмедовал использовать не kubeletExtraArgs в InitConfiguration , KubeletConfiguration https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/

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

а вот в кублетконфиге не нашел возможности указать кри

и правда нет, ошибся сорян

ну это норма что он стучится же. Я полагаю в ситуации если у вас есть докер, но вы все равно указали containerd сокет явно. То результат будет непредсказуемый, поскольку докер и kubelet будут делить containerd между собой. Скорее всего именно поэтому при существовании сокета докера выбирается он и пофиг что вы указали containerd сокет явно

но если докера нет, то кублет же и не должен выбирать докеровский сокет?

он его и не выберает. То что он проверяет его существование же не значит что он его выбрал

но кублет валится с ошибкой "не могу подключиться к докер сокету"

а он валится или просто пишет ее?

именно что валится

тогда увеличивайте verbose и смотрите что там. Можно с чатом поделетися полным выводом, мб поможем