Comments 19
На Bare-Metal конфигурации достаточно ingress контроллера с включенной HostNetwork конфигурацией. Для отказоустойчивости можно развернуть как DaemonSet. Для отказоустойчивой конфигурации нужны три мастера. Metallb ненужный костыль, если разворачивать ingress как я выше написал.
Для отказоустойчивой DNS балансировки успешно использую сервис AWS Route53. Он умеет в Health-check серверов и соответственно подправляет запись в DNS. Не сочтите за рекламу :)
Интересно, спасибо. А что по стоимости?
Traffic Flow
$50.00 per policy record / month
не совсем понял что это но полагаю это опционально
Я свой костыль пилил https://github.com/webtor-io/dnslb
Идея простая, отслеживает живые ноды в кластере на которых работают живые же поды ingress и обновляет соответствующие A-записи в Cloudflare. ingress должен работать с HostNetwork и в DaemonSet. Единственным плюсом подобного решения является бесплатность.
наверное стоит сделать статью по установке Rancher и установки кластера из него в пару кликов. Вся статья уместится в одну-две страницы
Может не стоило переводить control plane как плоскость управления?
А зачем было ломать systemd-resolved? Это вроде бы привычная вещь для свежих образов. Kubespray наоборот на Ubuntu будет ждать настройку с ним.
Спасибо большое за статью, но к сожалению данный тесты никоем образом не покажу уровень доступности вашей схемы. Подключайте мониторинг, настройте дашборды с перцентелями ошибок и нагрузите чем-то типа гатлинга или к6 и только тогда начинайте вырубать мастера. В таком случае сразу поймете, насколько вы проседаете и самое главное где.
С радостью посмотрел бы на эти цифры, в продолжении статьи.
Так же возможно будет полезен данный проект - прорабатываем автоматизацию развертывания кубов в облаках, в частности Яоблако.
В документациях говорят о том, что решение с MetalB на балансировку api не совсем корректное: если будут какие-то проблемы с daemonset, то ip не поднимется и мы получим тыкву (c Ingress такая же история). В интернетах предлагаю решение kube-vip, которое запускается как static pod и позволяет перевозить ip между мастерами. Вот как это включается на kubespray https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kube-vip.md
По идеи это как metalB, только static под на мастер-ноде, но считается, более надёжным
Знаю еще один проект с разворачиванем кубер-кластера в облаках, с мониторингом, алертами и тд.
Классная статья!
Добавлю лишь несколько замечаний
Если etcd-кластер разворачивается на мастер нодах, то их количество должно быть нечетное - т.е. минимум 3, в текущем примере выход из строя одной из мастер-нод переведет оставшуюся ноду etcd в readonly состояние - не будет похоже на HA. Размещение etcd на рабочих нодах, как в примере из статьи, крайне не рекомендуется с точки зрения безопансости.
Не обязательно разворачивать ингресс на каждой ноде - зачастую такого количества ингресов не нужно, можно использовать и Deployment. Без сервиса с типом LoadBalancer лучшим выбором будет hostport, а задачу контроля доступности возложить на балансировщик
Простейшим способом организовать HA для входящего трафика - использовать балансировщик, например haproxy и, используя его возможности по активным проверкам доступности апстримов, балансировать трафик на hostport каждой ноды. Например, запустить 2 инстанса haproxy с публичными IP и использовать DNS Roundrobin в качестве простейшего решения
В качестве DNS сервера можно использовать PowerDNS - он поддерживает активные health-check и может на основе них возвращать разный набор A-записей. Единственная проблема организации HA на уровне DNS сохраняется - это относительно продолжительное время обновления записей в кеширующих DNS, но плюсы тоже на месте - восстановление доступности сервисов произойдет без человеческого вмешательства
Если нас интересует только HA для балансировщиков, то можно настроить "плавающий" ip с использованием keepalived между этими двумя балансировщиками. В случае отказа основного, ip спрыгнет на резервный и трафик продолжит ходить через второй сервис. В таком случае не потребуется приплясывать с DNS
Большое человеское спасибо, за статью! Для начинающих то что надо. Только есть вопросы, не обязательно к автору. (для понимания и развития).
Будет ли работать на REDOS? (Отечественный форк redhat).
Если CentOS- нужно ли отключать Selinux?
Для чего нужно включать переадресацию IPv4?
Это можно определить только опытным путем. Вот тут список поддерживаемых ОС
В предыдущей статье я устанавливал куб на CentOS с помощью kubeadm (kubespray тоже его использует кстати) и не помню чтобы выключал Selinux. Явным образом отключал только firewall, и то только потому-что не хотелось разбираться с исключениями в доступах
В инструкциях не объясняли зачем нужно включать. Но в интернете в принципе отвечают на этот вопрос
Очень хорошая статья, спасибо! Я бы добавил в вашу инструкцию еще один пункт, сразу после соманды git checkou команду pip install -r requirements.txt из дирректории kubespray.
Да, это вроде как очевидно, но думаю, если непосвященные люди захотят повторить ваш гайд, они столкнутся с трудностями.
Самое подробное руководство по установке высокодоступного (почти ಠ ͜ʖ ಠ ) Kubernetes-кластера