A container runtime compatible with Kubernetes (Docker v1.13+, containerd v1.3.7+, etc.)

У лонгхорна нет завязки на докер

В плане?

вплане rke2 требует еще написать плейбук для того что бы его установить)

[plugins.cri.registry]
      [plugins.cri.registry.mirrors]
        [plugins.cri.registry.mirrors."docker.io"]
          endpoint = ["https://registry-1.docker.io"]

В кубспрей  я добавил регистри миррор для контайнерд, для крио пр тоже есть. Седня, завтра примут

Crictl убога в сравнении с docker-cli

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

всем привет!
подскажите, пожалуйста, кто может потреблять API ендпоинтов, которые выставляют наружу sheduller и controller-manger?
Не могу нигде в доках найти конкретных примеров.

Вопрос возник в связи с тем, что хотим адаптировать кластер к некоторым проверкам CIS Benchmark-а. В нем есть пункт требующий чтобы флаг --bind-adress sheduller-а и controller-manger-а указывал на 127.0.0.1 вместо 0.0.0.0. В таком случае их API станет недоступно снаружи ноды. При этом в офф доках кубера по этому поводу сказано The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. Но что это за CLI/web clients - никакого пояснения.
Кластер при этом вроде работает, но уверенности в том, что позже не всплывут проблемы нет =).
Подскажите, кто пользуется в итоге этими API? =)

А как-то можно создать сервис, который селекторами будет выбирать несколько деплойментов(в зависимости от порта)?

конкретные ссылки дай плз

по идее нафиг не нужны

Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. (#93570, liggitt) [SIG API Machinery, Apps and Cluster Lifecycle]

1. в спеке шедуллера флаг --bind-address
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/

1. рекомендация к настройке
https://docs.datadoghq.com/security_monitoring/default_rules/cis-kubernetes-1.5.1-1.4.2/

ну и секурный порт есть 10259

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

т.е. в моем мире с понями - 10251 отключаешь, 10259 оставляешь

значит тебе рекомендации cis по барабану

т.к. они про 10251

точно так, без вопросов.
но это порт, а не адрес.
в рекомендациях бенчмарка еще и запрет на доступ снаружи

ну у них же написано

типо 10251 без аутентификации - следовательно публикуй на 127.0.0.1