Минимальное сравнение swarmkubernetesmesosnomadrancher
В прошлой статье мы разобрались зачем нужны оркестраторы, теперь осталось понять какой их них лучше подходит под наши задачи.
Сравнение оркестраторов — штука сложная. Я знаю людей, для которых выбор системы запуска контейнеров — это вопрос религии: одни построили гигантский алтарь кубернетиса и приносят человеческие жертвы гуглу, другие проводят извращенные оргии в славу месосферы, третьи просто фигачат грибы и смотрят ковёр откровения от докера.
В ходе консультирования разных компаний мне приходилось сталкиваться с этим вопросом. Зная итоговую цель, всегда проще сделать выбор, особенно учитывая, что некоторые из оркестраторов представляют собой набор компонентов.
Вступительное описание
Swarm
Разработан докером в отчаянной попытке не вылететь из мира контейнеров, который он же и создал. По субъективным ощущениям это второй по популярности оркестратор.
Mesos
Изначально оркестратор для java vm. Сейчас работает и с контейнерами. Монстр-убийца, супергибкий, легко писать свои модули для всяких странных штук. Поверх месоса можно иметь разные шедулеры (в том числе и самописные). Шедулеры занимаются тем, что запускают контейнеры.
What is Rancher?
Самые популярные шедулеры — Marathon и Aurora.
Kubernetes
Написан гуглом, похож на оркестратор, который использует гугл внутри компании, но не он. Очень популярный.
Nomad
Оркестратор от hashicorp для тех, кто подсел на хашикорповский стек. Работает не только с docker, большой упор сделан на поддержку серьезных сетапов и мультидатацентр.
Rancher
Красивый GUI, оркестрация контейнеров для новичков. Работает на своём движке Cattle, поддерживает работу поверх swarmkubernetesmesos, правда, с ограничениями.
Сеть
Лучше всего сеть в докере работает в режиме —net=host , но в оркестраторах, из-за необходимости запускать множество приложений на одном хосте, этот вариант не прокатывает.
Swarm
Нативная сеть в swarm не очень хорошая тест от percona и ещё один тест, хотя для бытовых задач в принципе хватает. Сети создаются достаточно просто.
Из необычного и удобного — возможность делать docker run в сеть в которой крутятся инстансы swarm.
Mesos
По умолчанию определённой сети нет: новые контейнеры не получают свой ip адрес, а регистрируются в zookeeper на каком-то порту, после чего любой желающий может к ним обратиться напрямую или через разные балансеры. Летом 16-го года разработчики таки впилили Container Network Interface (CNI) для Mesos, который позволяет каждому контейнеру получать свой ip адрес при помощи использования разных виртуальных сетей типа calico или weave.
Kubernetes
Работает с виртуальными сетями и поддерживает (ещё бы) сетку от GCE. Как мне показалось, поддерживает самое большое количество разных сетевых решений. Чаще всего поднимают flannel, но в последнее время набирает популярность Romana. В общем, на любой вкус и цвет.
Kubernetes, rancher [1]
Nomad
По умолчанию просто запускает контейнеры и регистрирует их в consul, но можно настроить на работу вместе с weave. Дискавери по умолчанию работает как в mesos, только с consul вместо zookeeper. Удивительно, правда?
Rancher
Своя сеть, достаточно медленная. Тест 1, тест 2.
Вывод по сети
Мне больше всего понравились сети в кубернетисе. В качестве альтернативы при нагруженной сети можно использовать прямое дискавери в стиле netflix вместе с mesosnomad. В любом случае, стоит присмотреться и решить, что вам не нужно.
Если вам не нужна высоконагруженная сеть, из которой вы будете выжимать все соки, то подойдёт любой вариант. Если не хотите лишних уровней абстракции и готовы потратить время на переделывание готовых приложений — добро пожаловать в mesosnomad клуб.
Деплой и запуск
Swarm
Атомарная единица в swarm — это сервис. Сервис представляет собой контейнер с параметрами запуска, такими как сеть и команда. Сервисы можно объединять в стеки — yaml файлы, описывающие группу сервисов. Также начиная с версии 1.13 сервисы можно деплоить прямо из compose файла, что достаточно удобно и быстро.
Mesos
Атомарная единица в месосе — это. хм, зависит от шедулера. Фактически это приводит нас к тому, что при наличии напильника можно сделать вообще что угодно. Мне в своё время понравился пример создания шедулера для kafka консьюмеров. В принципе не могу представить аналогичное решение для любого другого оркестратора.
Mesos: marathon
Можно работать как с отдельными контейнерами, так и с подами — групой контейнеров, которые используют какой-то один ресурс. Например, диск. Ребята из mesosphere предполагают, что поды будут использоваться только как переходной вариант между легаси и микросервисами. Наивные. Впрочем, для обычной группировки они предлагают application groups.
Mesos: aurora
Аврора оперирует только сервисами — это контейнер, который надо держать запущенным и рестартовать, если он упал.
Kubernetes
Атомом в кубернетесе является Pod — контейнер или набор контейнеров, которые будут запущены обязательно на одной ноде. Под описывает, что будет запущено, а для запуска есть несколько разных механизмов. Сейчас рекомендуется использовать Deployments, которые управляют всеми остальными компонентами типа replica sets.
Отдельно стоит отметить возможность создавать daemon sets — обещание, что под будет запущен на каждой ноде в кластере и stateful set – обещание что под по возможности будет пытаться перезапуститься на той же ноде, где был запущен изначально и будет имеет постоянное имя (что является хостнеймом для конечного приложения).
В совокупности с init контейнерами и helm кубернетис может использоваться почти для чего угодно. С другой стороны, большое количество ручек и наименований (в том числе и некоторые legacy штуки) сбивают с толку, и кривая вхождения в kubernetes достаточно кривая.
Nomad
Номад оперирует job-ами, которые представляют собой группы задач, которые должны быть запущены на одном инстансе. Задача может быть как сервисом, так и обычной задачей.
Сами файлы очень простые в написании, тут здорово помогают фирменные доки от hashicorp. Не знаю, кто их пишет, но 5+ за документацию. Лучшей документации для новичков просто не может быть.
Из минусов — нет никакой возможности запустить задачи в какой-то последовательности в рамках одного деплоя. Люди, которым это необходимо, извращаются при помощи общих переменных окружения. Вот уже действительно «голь на выдумки хитра».
Rancher
Ранчер оперирует сервисами, из которых можно собрать стэки. Всё очень похоже на swarm и даже есть импорт docker-compose файлов через UI. Если надо, то можно сделать так, чтобы сервисы запускались на одной и той же ноде через Sidekick связь.
Вывод по деплою и запуску
Самый простой вариант сейчас — это запустить swarm и создавать сервисы из docker-compose файла. Никаких новых знаний. Зато в rancher можно просто накликать контейнеры из UI, что определённо будет плюсом для людей, которые вообще не знакомы с докером.
Если располагать по простоте, то я бы поделил места так:
- Rancher (если вам надо просто накликать сервисы)
- Swarm (сразу сели и поехали)
- Nomad (простая документация, простые концепты)
- Kubernetes (куча ручек, но можно накрутить много разных штук)
- Mesos (может быть и простым, но можно вообще сделать самописную убер пушку)
Диски
Swarm
Если вам нужно хранить информацию на диске, то в swarm по умолчанию можно использовать либо диск с инстанса, либо volume контейнер. Если между запусками вам надо сохранять информацию, которую сгенерировал контейнер, то рекомендуется использовать что-то вроде ceph для этого или какой-то nfs. Для разных cloud провайдеров докер разработал и менеджит cloudstor — плагин, который мапит диск к контейнеру. То есть даже если контейнер будет перезапущен на другой ноде, он сможет получить доступ к своим данным.
Также можно использовать разные плагины типа flocker, которые делают примерно то же самое.
Mesos
Kubernetes
То же, что и выше, + отлично работает с облачными провайдерами самостоятельно. Самый большой выбор способов работы с волюмами.
Дополнительно стоит отметить, что в случае с StatefulSets они до последнего момента будут пытаться стартовать на той же ноде, на которой были запущенны первоначально. Что делает их достаточно удобным механизмом для хранения всяких кешей, без использования плагинов. Хорошая практика для баз данных использовать StatefulSet + мапинг диска из облака.
Nomad
Сейчас в номаде нет персистентных дисков. Вот тут длинный тред с 2015 года. В конце треда разработчики пообещали крутую возможность работы с дисками в версии 0.6, а в версии 0.5 они добавили возможность пробрасыватьиспользовать докер волюмы и докер плагины. Сейчас 0.5 ещё rc2, но у вас, в далёком будущем, она может уже быть. Так что, в принципе, не так много отличий от swarm.
upd. в чатике Ievgen Khmelenko обратил внимание, что в 0.5.5 версии, которая зарезилилась 14 марта уже есть поддержка докер драйверов для волюмов.
Rancher
По умолчанию Rancher работает с дисками через Convoy, который поддерживает Device Mapper, VFSNFS и Amazon EBS. В любом случае, есть интеграция с flocker, что расширяет возможности ранчера, хоть и уменьшает его ценность как «всё из коробки» продукта.
Выводы по дискам
Лучше всего, как мне кажется, для приложений, которые так или иначе работают с диском, подходит kubernetes. Можно настроить почти как угодно. Всё остальное идёт практически нос к носу, можно только выделить аутсайдера в виде Nomad. Хотя у него дела однозначно поправятся после релизов 0.5 .6.
Я бы не рекомендовал поднимать базы данных в любом из оркестраторов, если у вас нет какой-то дополнительной необходимости в этом. Дополнительный уровень абстракции и множество плагинов-компонентов могут привнести много боли в ежедневную работу с БД.
Мультидатацентр
Swarm
Заявляется работа в режиме нескольких датацентров и есть разные лейблы, которыми можно помечать ноды из разных ДЦ, после чего достаточно негибко можно цеплять сервисы к этим нодам. Федерация происходит посредством сторонних сервисов.
Mesos
Федерации и мультидатацентра из коробки нет. Есть отдельное решение от huawei на основе этого proposal. У huawei работает, но если честно, очень мало инфы.
Kubernetes
Имеет встроенную федерацию. Вот тут неплохая статья на эту тему.
Nomad
Имеет встроенную поддержку всего что только можно. Ребята этим очень гордятся. По их словам, у них самое стабильное решение.
Rancher
Хоть из UI и можно управлять несколькими серверами в разных датацентрах, на этом всё и заканчивается. Ожидаемо самое слабое решение.
Разное
Kubernetes
Куб, как самый популярный оркестратор, имеет множество финтифлюшек и дополнений.
Helm
Helm это менеджер приложений для kubernetes. Используется для того, чтобы последо запуска контейнера сделать там какие-то дела вроде «добавить в кластер». В месосе такую задачу пришлось бы решать кастомным шедулером, а в других оркестраторах — каким-то хитрым стартовым скриптом.
Serverless
Для kubernetes есть множество плагинов для serverless: FUNKTION, Kubeless, Fission. Для mesos это решается только кастомным шедуллером. Для остальных участников этой специальной олимпиады я не знаю таких решений.
Mesos
Фреймворки
В Mesos очень просто написать свой фреймворк. Есть обвязки для разных языков. Мне, например, очень нравится обвязка для golang.
Big data
Месос, если я правильно помню, изначально был разработан для работы с бигдатой. Тут внушительный список софта, который работает поверх месоса.
Rancher
Отличное UI и супермаркет приложений.
Выводы
Как ни странно, у меня в голове всё уложилось и мне наконец-то удалось дописать эту статью. Если бы у меня попросили совета по выбору оркестратора сейчас, я бы отвечал так:
Если вам не нужен оркестратор — не используйте никакой. Любой оркестратор — это дополнительный уровень абстракции, требующий поддержки и знаний.
Если вы разработчик, которому надо, чтобы всё быстро завелось и работало для какого-то PoC, то смело используйте Rancher. Он очень простой в установке, имеет приятный UI и так далее.
Если у вас непритязательный вкус, много stateless приложений и немного statefull, то используйте swarm или nomad. На стороне nomad очень хорошая и понятная документация и хорошо продуманный механизм кросс датацентров.
На стороне swarm встроенные оверлейные сети и простое создание сервисов. К тому же, он уже есть на ваших нодах.
Если вы хотите миксовать statefull/stateless сервисы, запускать лямбды в своём кластере и творить всякие непотребства, стоит обратить внимание на kubernetes. Из минусов — высокий порог входа, множество internal вещей, немного запутанная документация. Из плюсов — всё остальное.
Если сеть — это ваш corner case, то смотрите на nomadmesos.
Если у вас есть бигдата, то скорее всего у вас уже есть mesos.
Если вы хотите делать что-то вот вообще своё, или у вас много legacy иили интерпрайза, который надо запускать каким-то своим индийским путём, то mesos с кастомными шедуллерами отличный вариант.
Спасибо. Сори, что без картинок.
Источник: dvps.blog
Kubernetes в Hetzner при помощи Rancher (с картинками)
Доброго времени суток. Последние несколько месяцев я пытался запустить кластер kubernetes для взаимных пыток и изучения. За это время я прочитал большое количество разных статей, многие из которых были хорошими, но совершенно не подходящими для человека, не сталкивавшегося с кубером.
В этой статье я не преследую цель рассказать «как правильно», я хочу рассказать как сделать чтобы работало и дать возможность людям учиться дальше, а не лысеть и седеть раньше положенного возраста
Изначально я хотел запустить кластер на dedicated сервере с виртуалками на hyper-v, однако узнал, что «просто запустить мастер и подключить ноды» недостаточно для полноценного кластера, еще нужно установить сетевой плагин, озаботиться Persistent volumes и желательно каким-никаким loadbalancer-ом.
Дальнейшие попытки привели меня в hetzner и к rancher.
Почему hetzner? У них есть одно очень весомое преимущество. Вот цена на виртуальный сервер в hetzner:
И на его аналог в Mail Cloud:
Да, в hetzner нет managed баз данных, очередей, s3 хранилища и прочего, но того, что у них уже есть — вполне достаточно для того, чтобы получить рабочий кластер, а все остальное можно запустить в нем же, либо на соседних серверах/dedicated (физический сервер можно подключить к приватной сети виртуальных серверов)
Rancher же берет на себя весь (или почти весь) геморрой по сборке кластера, его администрированию и расширению, а так же позволяет управлять им через ui, а не через консоль.
Прежде чем начать, нам понадобится домен для rancher и аккаунт в hetzner cloud, которые, я надеюсь, вы сможете сделать без инструкций.
Первым делом создаем приватную сеть. Заходим в Hetzner Cloud, создаем проект, переходим на вкладку Networks, жмем Create Network, меняем подсеть с 16 на 8, запоминаем название нашей сети, оно нам еще пригодится.
Далее переходим на вкладку Security -> API Tokens, жмем Generate API Token, ставим переключатель в Read Buy now. Ждем пару секунд, пока создается сервер.
Далее нужно направить на него ваш домен (создать A запись) и подождать, пока сервер будет по нему доступен.
После этого подключаемся к серверу по ssh (через putty или другой ssh клиент) и приступаем к установке rancher.
Сначала ставим docker:
apt-get update apt install -y docker.io systemctl start docker systemctl enable docker
После запускаем контейнер с rancher:
docker run -d —restart=unless-stopped -p 80:80 -p 443:443 -v /root/rancher:/var/lib/rancher —privileged —name rancher-server rancher/rancher:latest —acme-domain your.domain.com
Измените your.domain.com на домен, который вы привязали к серверу. Ждем несколько минут, пока rancher сделает свои дела и получит ssl сертификат.
Про rancher и docker
В документации rancher рекомендуется использовать такой метод установки (Single Node Using Docker) только для тестирования и разработки, но мы этим и занимаемся
Переходим по нашему домену и наблюдаем приветственное окно. Устанавливаем пароль администратора, указываем, что хотим администрировать множество кластеров, принимаем лицензионное соглашение
Далее подтверждаем, что rancher правильно определил домен и попадаем на главную страницу.
Теперь нужно установить расширения для работы с hetzner. Для этого переходим в Tools > Drivers
Далее вкладка Node Drivers и жмем Add Node Driver
В открывшемся окне нужно указать ссылки на скачивание плагина:
В репозитории драйвера берем ссылку на последний релиз linux_amd64 (на данный момент это https://github.com/JonasProgrammer/docker-machine-driver-hetzner/releases/download/3.3.0/docker-machine-driver-hetzner_3.3.0_linux_amd64.tar.gz) и копируем в поле «Download Url».
В репозитории UI плагина берем ссылку на Custom UI URL (на данный момент это https://storage.googleapis.com/hcloud-rancher-v2-ui-driver/component.js) и вставляем ее в поле «Custom UI URL»
Добавляем в White List домен storage.googleapis.com
Жмем Create, через пару секунд драйвер будет скачан и установлен. Теперь мы готовы к разворачиванию кластера.
Переходим на главную страницу (выпадающее меню справа от лого > Global), нажимаем на «Add Cluster». В списке появился Hetzner, нажимаем
В следующем окне обзываем кластер по желанию (поле Cluster Name), вписываем Prefix для имени ноды, ставим галки в колонки etc и Control Pane, после жмем на кнопку Add Node Template:
В открывшемся окне вводим API Token Hetzner (я говорил, что он еще понадобится).
Далее выбираем локацию сервера (там, где вы разместили самый первый сервер), ОС, тип сервера (CP21 или выше). Обязательно выбираем в списке приватную сеть и ставим галку «Use private network» и даем имя шаблону.
После создания шаблона нужно добавить пул рабочих нод, для этого жмем кнопку Add Node Pool, в новой строчке опять вводим префикс, ставим галку в Worker, указываем желаемое количество и шаблон сервера (выбрать такой же, как у мастера, либо добавить новый, помощнее).
После чего спускаемся ниже, до Cluster Options, разворачиваем Kubernetes Options, указываем желаемую версию кубера (лучше последнюю, т.к. hetzner поддерживает только три последних версии), Network provider — Flannel, Cloud Provider — external, после чего нажимаем кнопку «Edit as YAML».
Перед нажатием на Edit as YAML можно спуститься чуть ниже и поменять настройки, если вы знаете, что они делают
В открывшемся окошке нужно добавить следующий текст в rancher_kubernetes_engine_config:
. rancher_kubernetes_engine_config: . addons: |- — apiVersion: v1 stringData: token: network: kind: Secret metadata: name: hcloud namespace: kube-system — apiVersion: v1 stringData: token: kind: Secret metadata: name: hcloud-csi namespace: kube-system addons_include: — https://github.com/hetznercloud/hcloud-cloud-controller-manager/releases/latest/download/ccm-networks.yaml — https://raw.githubusercontent.com/hetznercloud/csi-driver/master/deploy/kubernetes/hcloud-csi.yml .
заменяем на токен hetzner (в двух местах), на имя приватной сети, которую указывали у серверов. Последние две строки с ссылками содержат в себе Cloud Controller Manager и Container Storage Interface driver. На странице репозиториев есть таблицы с этими ссылками, выбираем подходящие под версию kubernetes (CCM берем With Networks support)
Должно получиться что-то вроде этого:
Жмем на «Create» и наблюдаем за магией: rancher создаст сервера, установит на них все необходимое и объеденит в кластер. После создания кластера жмем на кнопку Cluster explorer (в шапке) и попадаем в админку. На этом установка кластера завершена, можно тыкать по менюшкам и изучать содержимое kubernetes.
В следующей статье расскажу про деплой и установку приложений через helm (на примере gitlab runner).
PS При создании сервиса LoadBalancer, он не сможет запуститься самостоятельно, т.к. нужно указать место его физического расположения. Для этого переходим в Services, жмем три точки у нужного сервиса > Edit Config > Labels https://temofeev.ru/info/articles/kubernetes-v-hetzner-pri-pomoshchi-rancher-s-kartinkami/» target=»_blank»]temofeev.ru[/mask_link]
Многоузловое развёртывание с помощью Rancher и Docker Machine в Ubuntu 16.04
Rancher поддерживает оркестровку на основе Docker Machine, благодаря чему вы можете быстро создавать хосты Docker у облачных провайдеров или в собственном дата-центре. Rancher позволяет запускать вычислительные узлы непосредственно через пользовательский интерфейс. Это пусть и небольшой, но чрезвычайно важный шаг, который обеспечивает возможность создавать и управлять многоузловыми (а в скором будущем – и многооблачными) развертываниями с помощью единого интерфейса.
В руководстве используется встроенный драйвер Rancher, с помощью которого можно создавать облачные серверы и проводить их оркестровку. Это позволяет вам быстро создавать вычислительные ноды Docker, которые можно отслеживать, масштабировать и использовать для развёртывания контейнеров.
Требования
- Доступ к программному интерфейсу.
- Сервер Ubuntu 16.04 (1Гб оперативки минимум).
- Предварительно установленная платформа Docker 1.12 (инструкции по установке можно найти в статье Установка и использование Docker в Ubuntu 16.04).
- Аккаунт GitHub, который нужен для настройки Rancher.
1: Сервер для Rancher
Чтобы приложение Rancher могло управлять хостами и контейнерами Docker, нужно создать для него отдельный сервер.
Чтобы платформа Rancher запускалась вместе с сервером, используйте скрипт:
#!/bin/bash
docker run -d —name rancher-server -p 80:8080 rancher/server
Убедитесь, что новый сервер работает и поддерживает Rancher:
Запросите список контейнеров Docker:
Следующий результат подтверждает, что Rancher работает:
ec5492f1b628 rancher/server «/usr/bin/entry /usr/» 15 seconds ago Up 13 seconds 3306/tcp, 0.0.0.0:80->8080/tcp rancher-server
Если команда не выдала эту строку, подождите пару минут и попробуйте снова запустить её. Убедившись, что Rancher работает, можете покинуть сервер.
2: Настройка аутентификации Rancher
Откройте в браузере http://your_server_ip/ и запустите интерфейс Rancher. На данный момент сервер Rancher находится в открытом доступе, потому нужно настроить аутентификацию. Для этого можно использовать OAuth.
В верхней части страницы (возле ADMIN) вы увидите предупреждение:
Access Control is not configured
Выберите Access Control в меню ADMIN. В качестве метода аутентификации по умолчанию выбран Github; чтобы зарегистрировать новое приложение в GitHub, следуйте инструкциям на странице.
Затем скопируйте Client ID и Client Secret со страницы Github и вставьте в соответствующие поля в интерфейсе Rancher. Нажмите Save.
Под Test and enable authentication найдите и кликните Authenticate with Github, выберите Authorize application во всплывающем окне. После этого страница перезапустится, инструкции по настройке OAuth будут заменены разделом Configure Authorization. Добавьте других пользователей, у которых должен быть доступ к Rancher. Изменив настройки авторизации, нажмите кнопку Save.
3: Создание среды
Среда Rancher позволяет группировать хосты. Rancher предоставляет стандартную среду Default, но лучше создать свою. Найдите в верхней части экрана Default и перейдите по этой ссылке, чтобы попасть в меню Environments. Затем нажмите Manage Environments и Add Environment.
Укажите название среды, добавьте её описание. Оставьте остальные параметры по умолчанию и нажмите Create. С помощью меню проекта выберите новую среду.
Теперь попробуйте запустить хосты в новой среде.
4: Запуск нод Rancher
Теперь нужно запустить несколько нод Rancher. Для этого выберите Hosts в меню Infrastructure и нажмите кнопку Add Host.
Экран Add Host предлагает выбрать провайдера: Custom, Amazon EC2, DigitalOcean, Azure или Packet. Опция Custom предоставляет список команд, которые нужны для ручного запуска нод Rancher на сервере с предварительно установленным Docker. Остальные опции используются для запуска вычислительных узлов в соответствующих облачных системах.
Выберите провайдера и заполните появившуюся форму.
- Server Name: введите любое имя (например, host01).
- Quantity: оставьте 1. Если вы увеличите это значение, программа автоматически создаст несколько хостов и выберет для них имена.
- Access Token: токен доступа к программному интерфейсу.
- Image: выберите в списке образ, который нужно запустить (Ubuntu 16.04.1 x64). Не все опции в списке работают – некоторые из них несовместимы с Rancher.
- Size: объём памяти сервера (в данном случае 1Гб).
- Region: географический регион, в котором создан сервер.
В завершение нажмите Create. Rancher использует Docker Machine, чтобы создать указанный сервер и установить на него Docker. Также Rancher запустит на новом сервере rancher-agent.
В течение нескольких минут новый вычислительный узел появится в интерфейсе Rancher. Также вы получите базовую информацию о хосте (IP-адрес, сведения о процессоре, памяти и т.п.). Повторите инструкции этого раздела несколько раз, чтобы запустить остальные ноды.
Теперь рассмотрим встроенные функции мониторинга, удаления и отключения нод.
5: Мониторинг и масштабирование развёртывания
После запуска всех нод нажмите на название одной из них, чтобы открыть экран Monitoring. Здесь можно увидеть сведения об использовании процессора и потреблении памяти этого вычислительного узла.
Если нода использует большую часть памяти или ресурсов процессора, запустите несколько дополнительных нодов.К примеру, если нода использует 80% памяти, нужно запустить еще несколько нод, чтобы распределить нагрузку. Как раз в таких ситуациях очень полезна интеграция docker-machine: вы можете быстро отреагировать и загрузить больше вычислительных нод, не выходя из интерфейса Rancher.
После устранения перенагрузки можно отключить дополнительные ноды. Для этого откройте Hosts, найдите ненужный хост и нажмите Deactivate.
Позже можно включить ноды, нажав Activate, или удалить их при помощи Delete. Все эти опции находятся в том же меню.
Заключение
Теперь вы умеете запускать, мониторить и отключать вычислительные узлы с помощью Rancher. Чтобы узнать, как использовать Rancher в качестве балансировщика нагрузки, обратитесь к документации проекта.
Источник: www.8host.com
☸️ Установка производственного кластера Kubernetes с Rancher RKE
Как использовать RKE для развертывания готового кластера Kubernetes?
Kubernetes приобрел большую популярность и теперь является стандартным уровнем оркестрации для контейнерных рабочих нагрузок.
Если вам нужна система с открытым исходным кодом для автоматизации развертывания контейнерных приложений, не беспокоясь о масштабировании и управлении, то Kubernetes – подходящий инструмент.
Существует много стандартных способов развертывания промышленного кластера Kubernetes.
Это включает использование таких инструментов, как kops, kubespray или создание кластера вручную с помощью kubeadm.
У нас есть несколько руководств, которые вы можете использовать для справки.
- ☸️ Как развернуть легкий кластер Kubernetes за 5 минут с K3s
- ☸️ Разверните готовый кластер Kubernetes с помощью Ansible https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl» chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl kubectl version —client
2. rke
— Linux — curl -s https://api.github.com/repos/rancher/rke/releases/latest | grep download_url | grep amd64 | cut -d ‘»‘ -f 4 | wget -qi — chmod +x rke_linux-amd64 sudo mv rke_linux-amd64 /usr/local/bin/rke rke —version — macOS — curl -s https://api.github.com/repos/rancher/rke/releases/latest | grep download_url | grep darwin-amd64 | cut -d ‘»‘ -f 4 | wget -qi — chmod +x rke_darwin-amd64 sudo mv rke_darwin-amd64 /usr/local/bin/rke rke —version
3. helm
— Helm 3 — curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh
Установка Kubernetes с RKE
Я буду работать на 5 узлах:
- 3 мастер ноды – etcd и controlplane ( 3 для HA)
- 2воркер ноды– м асштабируйте для удовлетворения ваших потребностей
Это спецификации для моей установки.
- Мастера – 8 ГБ ОЗУ и 4 vcpus
- Воркеры – 16 ГБ ОЗУ и 8 vpcus
RKE Поддерживаемые операционные системы
RKE работает практически на любой ОС Linux с установленным Docker.
Rancher был протестирован и поддерживает работу с:
- Red Hat Enterprise Linux
- Oracle Enterprise Linux
- CentOS Linux
- Ubuntu
- RancherOS
Шаг 1: Обновите вашу систему Linux
Первым шагом является обновление ваших машин Linux, которые будут использоваться для создания кластера.
— CentOS — $ sudo yum -y update $ sudo reboot — Ubuntu / Debian — $ sudo apt-get update $ sudo apt-get upgrade $ sudo reboot
Шаг 2: Создайте пользователя rke
Если вы используете Red Hat Enterprise Linux, Oracle Enterprise Linux или CentOS, вы не можете использовать пользователя root в качестве пользователя SSH из-за Bugzilla 1527565.
По этой причине мы создадим учетную запись пользователя с именем rke для целей развертывания.
Используя Ansible Playbook:
— — name: Create rke user with passwordless sudo hosts: rke-hosts remote_user: root tasks: — name: Add RKE admin user user: name: rke shell: /bin/bash — name: Create sudo file file: path: /etc/sudoers.d/rke state: touch — name: Give rke user passwordless sudo lineinfile: path: /etc/sudoers.d/rke state: present line: ‘rke ALL=(ALL:ALL) NOPASSWD: ALL’ — name: Set authorized key taken from file authorized_key: user: rke state: present key: «>»
Создание пользователя вручную на всех хостах
Войдите в каждый из узлов вашего кластера и создайте пользователя rke.
sudo useradd rke sudo passwd rke
Включите sudo без пароля для пользователя:
$ sudo vim /etc/sudoers.d/rke rke ALL=(ALL:ALL) NOPASSWD: ALL
Скопируйте ваш открытый ключ ssh в пользовательский файл ~/.ssh/authorized_keys.
Подтвердите, что вы можете войти на вашей рабочей станции:Шаг 3: Включите необходимые модули ядра:
Создайте плейбук с содержимым, показанным ниже и запустите его для инвентаризации ваших серверов RKE.
— — name: Load RKE kernel modules hosts: rke-hosts remote_user: root vars: kernel_modules: — br_netfilter — ip6_udp_tunnel — ip_set — ip_set_hash_ip — ip_set_hash_net — iptable_filter — iptable_nat — iptable_mangle — iptable_raw — nf_conntrack_netlink — nf_conntrack — nf_conntrack_ipv4 — nf_defrag_ipv4 — nf_nat — nf_nat_ipv4 — nf_nat_masquerade_ipv4 — nfnetlink — udp_tunnel — veth — vxlan — x_tables — xt_addrtype — xt_conntrack — xt_comment — xt_mark — xt_multiport — xt_nat — xt_recent — xt_set — xt_statistic — xt_tcpudp tasks: — name: Load kernel modules for RKE modprobe: name: «>» state: present with_items: «>»
Ручной способ
Войдите на каждый хост и включите модули ядра, необходимые для запуска Kubernetes.
for module in br_netfilter ip6_udp_tunnel ip_set ip_set_hash_ip ip_set_hash_net iptable_filter iptable_nat iptable_mangle iptable_raw nf_conntrack_netlink nf_conntrack nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat nf_nat_ipv4 nf_nat_masquerade_ipv4 nfnetlink udp_tunnel veth vxlan x_tables xt_addrtype xt_conntrack xt_comment xt_mark xt_multiport xt_nat xt_recent xt_set xt_statistic xt_tcpudp; do if ! lsmod | grep -q $module; then echo «module $module is not present»; fi;
Шаг 4: Отключите SWAP и измените записи sysctl
Рекомендация Kubernetes – отключить swap и добавить некоторые значения sysctl.
— — name: Disable swap and load kernel modules hosts: rke-hosts remote_user: root tasks: — name: Disable SWAP since kubernetes can’t work with swap enabled (1/2) shell: | swapoff -a — name: Disable SWAP in fstab since kubernetes can’t work with swap enabled (2/2) replace: path: /etc/fstab regexp: ‘^([^#].*?sswaps+.*)$’ replace: ‘# 1’ — name: Modify sysctl entries sysctl: name: ‘>’ value: ‘>’ sysctl_set: yes state: present reload: yes with_items: — — —
$ sudo vim /etc/fstab # Добавте комментарий $ sudo swapoff -a
$ sudo tee -a /etc/sysctl.d/99-kubernetes.conf
Подтверждение отключения:$ free -h total used free shared buff/cache available Mem: 7.6G 180M 6.8G 8.5M 633M 7.2G Swap: 0B 0B 0B
Шаг 5: Установите поддерживаемую версию Docker
Каждая версия Kubernetes поддерживает разные версии Docker.
Примечания к выпуску Kubernetes содержат текущий список проверенных версий Docker.
На момент этой статьи, поддерживаются следующие версии Docker:
Версия Docker скрипт установки 18.09.2 curl https://releases.rancher.com/install-docker/18.09.2.sh | sh 18.06.2 curl https://releases.rancher.com/install-docker/18.06.2.sh | sh 17.03.2 curl https://releases.rancher.com/install-docker/17.03.2.sh | sh Вы можете либо следовать инструкциям по установке Docker, либо использовать один из скриптов установки Rancher для установки Docker.
Я установлю последнюю поддерживаемую версию:
curl https://releases.rancher.com/install-docker/18.09.2.sh | sudo bash —
Запустите и включите службу Docker:
sudo systemctl enable —now docker
Убедитесь, что на вашем компьютере установлена версия Docker с поддержкой Kubernetes:
$ sudo docker version —format ‘>’ 18.09.2Добавить пользователя rke в группу Docker.
$ sudo usermod -aG docker rke $ id rke uid=1000(rke) gid=1000(rke) groups=1000(rke),994(docker)
Шаг 6: Откройте порты на брандмауэре
- Для установки с одним узлом вам нужно только открыть порты, необходимые для того, чтобы Rancher мог взаимодействовать с нижестоящими пользовательскими кластерами.
- Для установки HA необходимо открыть те же порты, а также дополнительные порты, необходимые для настройки кластера Kubernetes, на котором установлен Rancher.
Таблицу портов можно посмотреть тут : https://rancher.com/docs/rancher/v2.x/en/installation/requirements/#operating-systems-and-docker-requirements
for i in 22 80 443 179 5473 6443 8472 2376 8472 2379-2380 9099 10250 10251 10252 10254 30000-32767; do sudo firewall-cmd —add-port=$/tcp —permanent done sudo firewall-cmd —reload
for i in 8285 8472 4789 30000-32767; do sudo firewall-cmd —add-port=$/udp —permanent doneШаг 6: разрешить проброс SSH TCP
Вам необходимо включить общесистемный проброс TCP вашего сервера SSH.
Откройте файл конфигурации ssh, расположенный в /etc/ssh/sshd_config:
$ sudo vi /etc/ssh/sshd_config AllowTcpForwarding yes
Перезапустите службу ssh после внесения изменений.
— CentOS — $ sudo systemctl restart sshd — Ubuntu — $ sudo systemctl restart ssh
Шаг 7: Сгенерируйте файл конфигурации кластера RKE.
RKE использует файл конфигурации кластера, называемый cluster.yml, чтобы определить, какие узлы будут в кластере и как развернуть Kubernetes.
Есть много параметров конфигурации, которые могут быть установлены в cluster.yml.
Этот файл может быть создан из минимальных примеров шаблонов или сгенерирован командой rke config.
Запустите команду rke config, чтобы создать новый cluster.yml в вашем текущем каталоге.
rke config —name cluster.yml
Эта команда запросит у вас всю информацию, необходимую для создания кластера.
Если вы хотите создать пустой файл шаблона cluster.yml, укажите флаг –empty.
rke config —empty —name cluster.yml
Вот так выглядит мой файл конфигурации кластера – не копируйте и не вставляйте, просто используйте его как ссылку для создания собственной конфигурации.
# https://rancher.com/docs/rke/latest/en/config-options/ nodes: — address: 10.10.1.10 internal_address: hostname_override: rke-master-01 role: [controlplane, etcd] user: rke — address: 10.10.1.11 internal_address: hostname_override: rke-master-02 role: [controlplane, etcd] user: rke — address: 10.10.1.12 internal_address: hostname_override: rke-master-03 role: [controlplane, etcd] user: rke — address: 10.10.1.13 internal_address: hostname_override: rke-worker-01 role: [worker] user: rke — address: 10.10.1.114 internal_address: hostname_override: rke-worker-02 role: [worker] user: rke # using a local ssh agent # Using SSH private key with a passphrase — eval `ssh-agent -s` ssh-add ssh_agent_auth: true # SSH key that access all hosts in your cluster ssh_key_path: ~/.ssh/id_rsa # By default, the name of your cluster will be local # Set different Cluster name cluster_name: rke # Fail for Docker version not supported by Kubernetes ignore_docker_version: false # prefix_path: /opt/custom_path # Set kubernetes version to install: https://rancher.com/docs/rke/latest/en/upgrades/#listing-supported-kubernetes-versions # Check with -> rke config —list-version —all kubernetes_version: # Etcd snapshots services: etcd: backup_config: interval_hours: 12 retention: 6 snapshot: true creation: 6h retention: 24h kube-api: # IP range for any services created on Kubernetes # This must match the service_cluster_ip_range in kube-controller service_cluster_ip_range: 10.43.0.0/16 # Expose a different port range for NodePort services service_node_port_range: 30000-32767 pod_security_policy: false kube-controller: # CIDR pool used to assign IP addresses to pods in the cluster cluster_cidr: 10.42.0.0/16 # IP range for any services created on Kubernetes # # This must match the service_cluster_ip_range in kube-api service_cluster_ip_range: 10.43.0.0/16 kubelet: # Base domain for the cluster cluster_domain: cluster.local # IP address for the DNS service endpoint cluster_dns_server: 10.43.0.10 # Fail if swap is on fail_swap_on: false # Set max pods to 150 instead of default 110 extra_args: max-pods: 150 # Configure network plug-ins # KE provides the following network plug-ins that are deployed as add-ons: flannel, calico, weave, and canal # After you launch the cluster, you cannot change your network provider. # Setting the network plug-in network: plugin: canal options: canal_flannel_backend_type: vxlan # Specify DNS provider (coredns or kube-dns) dns: provider: coredns # Currently, only authentication strategy supported is x509. # You can optionally create additional SANs (hostnames or IPs) to # add to the API server PKI certificate. # This is useful if you want to use a load balancer for the # control plane servers. authentication: strategy: x509 sans: — «k8s.computingforgeeks.com» # Set Authorization mechanism authorization: # Use `mode: none` to disable authorization mode: rbac # Currently only nginx ingress provider is supported. # To disable ingress controller, set `provider: none` # `node_selector` controls ingress placement and is optional ingress: provider: nginx options: use-forwarded-headers: «true»
Источник: itisgood.ru