Kuber vs rancher vs docker?

Question

[Илья Родионов]

Коллеги, добрый день. В свете последних тенденций хочется перейти на что-то "модное" как докер или кубернетс. Из-за этого возникает вопрос - а куда идти-то?

В моем понимании докер позволяет сделать очень простую оркестрацию своим swarm/stack методом (прямо сейчас на дев стенде я использую связку portainer+swarm. первый управляет docker-compose из gui, второй все "оркестрирует"), однако с ним проблема в том, что докер совсем не следит за состоянием самих нод - если одна ООМится, ушла и тп, то докер сможет задеплоить контейнер на новой, однако даже если остается 1/5 нод, то он постарается запихнуть все-все контейнеры в нее (возможно это настраивается на уровне лимитов, но как по мне они работают не всегда корректно).

Как я понимаю, эту проблему решает кубернетс - это некая надстройка(??) (тут не совсем все-таки понятно, что это до конца) над докером, которая будет следить за состоянием своих PODов, мигрировать контейнеры и т.п.

Есть для "простых" - rancher. Сейчас он кажется работает только с кубером и представляет собой GUI для управления (хотя тут встает вопрос - зачем, если есть стандартный Kubernets gui от гугла). Или ранчер делает что-то еще, тут вопрос.

Собственно, у меня вот такие мысли и размышления по этому поводу. Мне хочется избавиться от проблемы докера (особенно когда сворм все запихивает на одну оставшуюся ноду), и попрпобовать что-то новое.
Что бы вы посоветовали и почему? Почему кубер, а не ранчер. Или наоборот.
И есть ли адекватные gui для управления кубером?
Спасибо.

Comments

[Stanislav Pugachev]

по-моему вы сильно много вопросов в один втулили
тут обсуждения на часы..

[Илья Родионов]

Stanislav Pugachev, кажется, что да))

Answer 1

[MherArsh]

Илья, посмотри на ютюбе и прочти на хабре блог компании Флант, они молодцы, все расскажут нормально, и понятно, а если кратко:
Докер это сущность где запускаются приложения, это что то типа виртуалки но это не виртуалка а изоляция процессов контейнера, это движок, где работает приложение, все.
Для управления множеством контейнеров, и для очень многих вещей (не буду повторяться, посмотришь) нужен аркестратор, их несколько, самый популярный это kubernetes.
Rancher в свою очередь является инструментом для установки kubernetes, в старых версиях у них был свой аркестратор, на выбор, но потом его закрыли.

А про ui забудь)) ты через него ничего не сделаешь, у ранчера более менее продвинутый ui, но пользы очень мало.

Удачи тебе!

Comments

[Илья Родионов]

спасибо)

[Vitaly Musin]

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

[Алексей Ямщиков]

Vitaly Musin, пионерами быть непросто

Answer 2

[dimagusarov1]

Kubernets это как swarm только swarm плохой и умер.
gui от гугла никто не юзает, rancher более продвинутая штука, можно создавать кластера, управлять и тд.
и внутри ranchera кубер, т.е. ты можешь сетапить кубер ранчером или кубспеем или кубадмом... но там везде кубернетес)

Comments

[Илья Родионов]

то есть краткий бриф: сворм - плохо, лучше отказать. гуи от кубера - фу (кстати, почему?)
и самый лучший(??) гуи для кубера - ранчер? или есть что-то еще более удачное?
плюс вопрос, можно ли как-то так же быстро разворачивать docker-compose в кубере (гуи ранчере)? у меня почему-то не получилось..

[Илья Родионов]

окей, а давайте ещё один вопрос. может я чего-то недопонимаю.

прод на докере работает? купил я вот у Я.Облака виртуалку. дома разрабатывал, писал компоуз файл, грузил образ в докер хаб и хочу запустить продакшн быстро.

всё-таки докер в своем понимании может стать таким продакшеном? или опять же нужно будет кубер разворачивать?

(хотя продакшн из одного инстанса - это сильно, но просто я постарался привести самый простой пример)

[dimagusarov1]

gui от гугла - если это про GKE то это ок (я про дашборд подумал), но гугол за тебя будет апдейтить кластер, следить за мастерами и тд и за это нужно платить.
если нужно самому развернуть и нужен гуй то ранчер наверно ок.
docker-compose нельзя развернуть, есть тулза которая конвертит композ в манифесты для кубера но нужно всеравно понимать че куда. в кубере свои примитивы.
если для прода хватает 1 ноды юзай композ

[Илья Родионов]

dimagusarov1, под гуи я понимал https://kubernetes.io/docs/tasks/access-applicatio...
т.е. это "не то", и в принципе лучше использовать rancher? Или тут подойдет и то, и другое?

UPD: если под кубером понимают "средство для развертывания докеров", то как-то странно, что там нельзя развернуть стандартный компоуз?

UPD2: хорошо, а как быть с persistent volume? как можно работать с nfs и подобными штуками?

[dimagusarov1]

это дашборд который ставится уже в развернутый кластер, а ранчер из его гуя позволяет создавать кластера и управлять ими и все то что может тот дашборд и больше.
ты можешь создать ранчером кластер и поставить туда еще тот дашборд если нужно, но скорее всего не нужно)
дашборд работает внутри кластера, а ранчер над кластерами и внутри также и больше.

[dimagusarov1]

кубер работает с контейнерами и не обязатально докер. композ это штука которая запускает контейнера.
можно так https://kubernetes.io/docs/concepts/storage/persis...

[Илья Родионов]

dimagusarov1, про ранчер и кубер сложно. что же из гуи в итоге выбрать то, как вы посоветуете?

[Vitaly Karasik]

прод на докере работает? купил я вот у Я.Облака виртуалку. дома разрабатывал, писал компоуз файл, грузил образ в докер хаб и хочу запустить продакшн быстро.

всё-таки докер в своем понимании может стать таким продакшеном? или опять же нужно будет кубер разворачивать?

Если мы говорим о единственном контейнере, то разумеется Kubernetes не нужен. Но и продакшен это сегодня назвать трудно - нет high availability, [auto]scaling, zero-downtime deploy и т.п.
Kubernetes позволяет оркестрировать много компонент (micro-services), для каждой из которых можно задать свои требования по CPU/RAM, свои правила для [auto]scaling, deploy.

[Илья Родионов]

Vitaly Karasik, нет-нет, 1 инстанс - это был всего лишь пример, конечно же не 1 виртуала))

[sorx00]

Илья Родионов, стандартный дашборд k8s позволяет полноценно управлять кластером. Просто люди любят кнопочки/гуи и не любят разбираться в тонкостях технологии. При этом нужно понимать, что Rancher вводит дополнительные абстракции, которых в нативном кубере нет.
Ранчер ставит кубер на базе докера (containerd/runc), но также бывают инсталляции на cri-o (от RedHat). На crio полноценно Ранчер поставить пока ещё нельзя.
Теперь про compose: это изначально формат докера (и ранчера с cattle), в кубере вместо compose используются yaml-файлы спецификаций. Но есть конвертеры compose2kubernetes.
Чтобы выбрать технологию, необходимо знать ваши требования: размер кластера, рабочая нагрузка, типы серверов.

Answer 3

[Юрий Ярош]

совсем не следит за состоянием самих нод - если одна ООМится

Уже пофиксили через 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 для управления кубером?

Кроме ранчера не видел больше ничего ...
Сам пишу им конкурента сейчас.

Comments

[Илья Родионов]

а как вам сам nomad с docker?
я потыкал и понял - а это классная вещь. как вам?

вроде сам номад и оркеструет докер. правда не понимаю, как там например изолировать инстансы (или это делает докер?), добавлять >1 инстанса на 1 хост, если я открываю/пробрасываю порт..

[Юрий Ярош]

> а как вам сам nomad с docker?

Есть мелкие проблемы, но если это какое-то простое приложение, без 10тка контейнеров, типа Kubernetes :) - можно использовать.

> как вам?

Если не нужно вундервафель - вполне сносно.
Иногда приходиться ковырять исходники / баги фиксить, раз в 2-3 года.
Тем не менее, нет такого цирка как в кубере - когда всё устаревает каждый минорный релиз.

> вроде сам номад и оркеструет докер.

Подключается к демону через сокет, либо выполняет контейнеры самостоятельно через runC, вообще без докера.

> как там например изолировать инстансы (или это делает докер?)

Изоляция контейнеров на уровне сети выполняется через соответствующий overlay network драйвер докера.
Т.е. создаётся виртуальный интерфейс на котором висит несколько адресов.

Так то частенько, если нет VM, добавляют gVisor.
Nomad + Docker + gVisor вполне годно работает.

[Илья Родионов]

Юрий Ярош, я использую portainer.io в связке с докер-свормом. имхо, это почти идеальное решение, которое удовлетворяет всему что надо. проблема в том, что если 5/6 нод умрет, то сворм будет запихивать все в единственную ноду, не подумав об оверкоммите и чем-либо другом.

вот сейчас смотрю на nomad, потому что кубер мне как-то не взлетел и показался чересчур сложным. вопрос nomad в том, стоит ли внутри него ставить тот же самый portainer (или систему для докер-сворм) или остановиться на обычном nomad?

еще вопрос в том, как можно 2 инстанса одного приложения с одним открытым в мир портом запустить на одной ноде? в докере это как-то прозрачно работает, вроде. и он позволяет так сделать..
а в nomad - нет.

[Юрий Ярош]

я использую portainer.io

Илья Родионов, у portainer хватает недостатков и он не покрывает довольно много edge кейсов, но для мелких проектов его достаточно.

если 5/6 нод умрет, то сворм будет запихивать все в единственную ноду,

Сluster Autoscaling мало что умеет, кроме ранчера.

Номад - это класстерный Cron, грубо-говоря, там можно создать healthcheck'ов и автоматическое поднятие новых инстансов в случае проблем, терраформом или через REST API соответствующих хостингов.

что кубер мне как-то не взлетел и показался чересчур сложным

Кубер не сложный, просто документация - говно.

стоит ли внутри него ставить тот же самый portainer (или систему для докер-сворм) или остановиться на обычном nomad?

Это невозможно. Nomad уже выполняет функции Docker Swarm и у него есть отдельно свой UI.

еще вопрос в том, как можно 2 инстанса одного приложения с одним открытым в мир портом запустить на одной ноде?

Докер или номад здесь непричём... нужен любой ingress контроллер - это может быть, например, consul под Ambassador. Как вариант по проще - прикручивают Fabio.

[Илья Родионов]

Юрий Ярош, какой же совет тогда, Юрий..
я совсем в замешательстве и запутался.

начинал с кубера, закончил непонятно чем. как вы счиатете, что использовать, в какую сторону в итоге смотреть?
- docker-swarm+portainer (с ним было пару раз больных и больших инцидентов, было больно)
- kubernetes (вообще не особо хочется)
- nomad+fabilo+consul(вопрос еще - зачем он?)

-----

у portainer хватает недостатков и он не покрывает довольно много edge кейсов, но для мелких проектов его достаточно.

но фактически portainer ~ nomad? так? или это совсем разные вещи

[Юрий Ярош]

- docker-swarm+portainer

docker-swarm и его походные, как и docker-compose, имеют ряд изъянов в дизайне и ни особой стабильностью ни отказоустойчивостью не отличаются.

- nomad+fabilo+consul

Nomad - планировщик
Fabio - как Ingress контроллер
Consul - как K/V хранилище и Service Discovery через DNS
Можно ещё докрутить Vault для хранения и ротации Credentials, аудита доступа

но фактически portainer ~ nomad?

Нет.

portainer - это UI для docker-swarm и registry.

Nomad - это кластерный планировщик, используется вместо docker-swarm.

[Юрий Ярош]

Нормальный Autoscaling придётся в любом случае крутить руками - магии там нет.

Желательно ещё хотя бы освоить какой-то Terraform c Packer'ом - что бы внедрить полноценный IaC.

[Илья Родионов]

Юрий Ярош, как же сложно. только погружаюсь в контейнеры, и тут бац - терраформ, пекер и тд и тп.

получается, удобно тут использовать продукты hashicorp как единое решение - consul+nomad+terraform+packer как удобная система разворачивания инфраструктуры. как по вашему такая связка?

[Илья Родионов]

Юрий Ярош, особого ingress в fabio я кстати так и не нашел. имхо в rancher это сделано намного приятнее.

есть ли альтернативы fabio в nomad?

[Юрий Ярош]

@ZloyKishechnik

> удобно тут использовать продукты hashicorp как единое решение

Все продукты HashiCorp, кроме Nomad'a и Vagrant'a, чаще всего и используются во всех DevOps/SRE задачах.

> есть ли альтернативы fabio в nomad?

envoy / istio
traefik
ambassador
haproxy
nginx :D

[Илья Родионов]

Юрий Ярош, знаете еще какой вопрос возник..

прочитал интересную статью https://habr.com/ru/company/lamoda/blog/451644/ и задал вопрос: https://habr.com/ru/company/lamoda/blog/451644/#co...

я правильно понимаю, что внутри одного "проекта" (как docker-compose file) я смогу деплоить несколько инстансов, которые взаимодействуют друг с другом?

т.е. например в докере это будет так:

project_nginx
project_php-fpm где project - один проект на 2 инстанса, находящихся в одной оверлей сети

[Юрий Ярош]

Илья Родионов, если это будут две разные физические машины - погоды особо не делает, главное нормально настроить ingress контроллер. Вообще в докере оно выглядит так - ingress контроллер всегда внешний, в закрытой сети - VLan/VXLan/VPN поверх которой уже отрабатывает Overlay.

Абсолютно точно так же оно делается на Nomad'e - там отдельно добавляются задачи на поднятие/добавление хостов в соответствующую сеть, обычно на OpenVSwitch или около того.

[Илья Родионов]

Юрий Ярош, а как лучше сделать ingress внешний (как в кубере это, скрин есть в статье), чтобы весь трафик попадал на какой-то vip и дальше маршрутизировался внутри overlay сети (сам, как в докере).

Посмотрел fabio - не понял. traefic не особо зашел

[Юрий Ярош]

На кождой ноде может быть свой ингресс и масштабирование можно делать на уровне loadbalancer'ов соответствующих хостингов, или даже CloudFlare с Origin сертификатами - погоды не делает.

В качестве loadbalancer'a между нодами внутри кластера может быть в свою очередь ещё один ingress controller c cоответствующим Origin сертификатом... часто это HAProxy или traefix/fabio/ambassador.

Посмотрел fabio - не понял. traefic не особо зашел

А разницы между ними не много.

Answer 4

[Vitaly Karasik]

Kubernetes - это оркестрация для докер, помимо поддержания нужного кол-ва контейнеров K8S умеет деплоить разными способами, делать auto-scaling несколькими способами, и т.д.
Я бы посоветовал начать с Kubernetes.
Rancher в моем понимании это "надстройка" над Kubernetes, которая должна облегчить deploy / upgrades, работать с multi-cluster configuration и в целом создать "более умный" API.

Comments

[Илья Родионов]

такой же комментарий и к вам: как вы считаете, какой гуи выбрать? стандартный дашборд от гугла ВНУТРИ кубера или внешний ранчер как надстройка над кубером?

[Vitaly Karasik]

Илья Родионов, скажу честно - не знаю. Я еще не работал с ранчер, а в Kubernetes в основном пользуюсь CLI и немного dashboards GKE (managed Kubernetes from Google Cloud).
Меня пугают дополнительные надстройки, возможно я не прав.

[dimagusarov1]

ранчер это деплоилка и управлялка кубернетисом через гуй, если не нужен гуй можно юзать kubeadm и работаьт с консоли