совсем не следит за состоянием самих нод - если одна ООМится
Уже пофиксили через
HEALTHCHECK /
STOPSIGNAL в Dockerfile. Да и давно работает
стандартый OOM.
Как я понимаю, эту проблему решает кубернетс - это некая надстройка(??)
Нет, кубер это в первую очередь средство управления ресурсами, причём любыми...
Так как есть CRD и
custom controller'ы, c
Operator Framework'oм.
ComCast, например, управляет железом для стриминга и соответствующим SDN полностью в рамках K8S.
Для кубера придумали
довольно много всякого (
говна в том числе), что бы упростить деплой и способ описания жизненного цикла приложений.
Пока ничего лучше
Operator Framework поверх
Argo /
Spinnaker не знаю.
Есть для "простых" - rancher.
Rancher сам по себе только деплоит Kubernetes класстер на пачку серверов, мониторит его, а также позволяет немного бэкапить, накатывать простенькиие Helm Chart'ы.
Потому в 99% случаев всё сводиться к "Terraform'у
ручками" и к самописным Custom Node Driver'ам.
Вот что реально можно и стоит автоматизировать на Rancher'e так это Cluster Nodes Autoscaling, когда ранчер сам в Node Pool добавляет / удаляет машин по текущим метрикам и делает соответствующий rebuild всякого...
Практической пользы от rancher'a в случае использования Kubernetes as a Service хостингов не много, если часто не приходиться клонить / обновлять / удалять пачки кластеров и переносить всё с одного хостинга на другой, ну там с подвала в GCP / AWS и наоборот.
Мне хочется избавиться от проблемы докера (особенно когда сворм все запихивает на одну оставшуюся ноду), и попрпобовать что-то новое.
Можно жить в проде и без докера - он используется только для сборки образов.
Пробуйте
Kata Containers под
gVisor в Kubernetes (получается довольно секурно).
Сам Kubernetes можно запустить например не в докере а в
Nomad'e (так делает Sony).
И есть ли адекватные gui для управления кубером?
Кроме ранчера не видел больше ничего ...
Сам пишу им конкурента сейчас.
