Комментарии 5
Читал статью и не покидало ощущение, что вы не совсем в ту сторону воюете.
Например, прежде, чем удалять поды с ноды, судьба которой неизвестна, стоит убедиться, что нода действительно умерла. Например с помощью https://github.com/kvaps/kube-fencing если ваш кластер на железе или с помощью Клауд провайдера, если на виртуалках.
Неймспейсы значительно проще настраивать, если запретить пользователям их создавать и начать их определять через гит. Но если единый гит для всех сделать невозможно, то трюки с дополнительным конфигурирование делаются с помощью адмишен контроллеров, а именно mutating webhook.
Интересная статья, которая в очередной раз доказывает, что кубернетес - не готовый продукт, а полуфабрикат. Кое что унес к себе
Это дополнительные kube API-серверы, которые скейлятся в зависимости от пользовательской нагрузки. Таким образом, все внешние запросы обрабатываются отдельным deployment kube-api-server. Они работают внутри кластера, сами себя регистрируют в стандартном сервисе Kubernetes, обрабатывают внутрикластерные url на kube API и внутрикластерные запросы пользовательской нагрузки.
непонятно, зачем это надо, если там нет кастомной логики кастомных ресурсов. Получается, не масштабирование, а наоборот - отличный SPOF.
БОльшую часть можно решить через Kyverno, но подход интересный, спасибо
Дополнительная обвязка K8s и самописные компоненты в Kubernetes: для чего и кому нужны