виртуальных машин на VMWare с Debian 10.
Использую kubeadm для настройки. Контейнеризация Docker. Хост Windows 10 :D
Хочу попробовать сделать "HA Cluster" (в учебных целях), из 3 ETCD (в виде отдельного кластера), 3 MASTER, 3 WORKER.
Документация и другие статьи в сети говорят, что должен быть LoadBalancer между MASTER и WORKER узлами кластера.
А так же, должен быть доступ к кластеру и приложениям работающим в контейнерах извне. (который настраивается индивидуально под задачи)
Я понял, что это достигается за счет таких сущностей как Service\Ingress. И что по сути это просто правила маршрутизации iptable, а ingress это правила на основании которого сгенерируется конфиг для ingress controller, который сам является контейнеризированным приложением, который будет "роутить" трафик к PODs.
И тут случилось оно ... я запутался :D
Подскажите, можно ли как то совместить и балансировку между master\worker нодами и доступ извне к кластеру и роутинг, в одной сущности, например, с помощью ingress nginx.
Или это глупость, так делать нельзя и вообще так работать ничего не будет.
Я знаю, что можно использовать, вроде как "hostnetwork true". Но, что указывать в опции --control-plane-endpoint = ? при инициализации )))
Еще смущает, что пишут про nginx L7, а хотелось бы не только с HTTP\HTTPS работать.
Ребят, помогите разобраться. Хочется какой то прозрачности и однозначности в этом вопросе. 🙂
https://metallb.universe.tf/
Спасибо, сейчас почитаю
и вместо nginx ingress можно использовать другие
https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
Благодарю, Андрей.
Не слушай его. Он тебя плохому учит )
возможно, предлагай варианты, мне самому интересно, но я скинул то, что сам юзаю
Я благодарен любой помощи )))
чтобы не было недопонимания, ссылку на ingress controllers я скинул когда ты спросил про "Еще смущает, что пишут про nginx L7, а хотелось бы не только с HTTP\HTTPS работать."
Есть пример, где через HAProxy настраивается балансировка между мастерами и воркерами. Я думал, что есть другие варианты ) Видимо, без него никак в HA Cluster, ну или без ему подобного
ну вот в kubespray HA из коробки, тоже смотрел когда-то
Я решил пойти путем через kubeadm ) Kuberspray для меня показался хм магией ))) Но, думаю, разобраться чуть позже надо )
там просто очень много всего и надо разбираться, советую попробовать
Я хочу самый самый минимум сначала сделать ) Когда пойму как этот конструктор собирать ) Мне знакомый сказал, что ты паришься, есть облако ) Но, я с ним не согласен ) Я должен понимать, как эта штука работает )
правильно - кбьюспрей магия
Я только не совсем понимаю, почему, когда видео смотришь про кубспрей, у человека что то долго все ставится ) Или мне кажется или там под капотом столько всего настраивается\качается и тд и тп ))) А когда смотришь на kubeadm то там всего делов то для базовой настройки кластера )))
ансибля - медленная. спрей доставляет нужные пакеты, ставит докер, качает образы - все это доп. время, которое не учитывается при установке руками кубадма.
Я так и думал, спасибо ) А без ансибли сейчас как я понял никуда !?) Стандартный DevOps инструментарий ?)
отдельный балансировщик между мастерами не нужен, это плохой совет в доках. Ставь просто на каждый воркер балансировщик, а сам kubelet на этом воркере будет контектится к локальному балансировщику. Самый надежный способ и не нужны лишние сущности для его реализации. metallb крайне не советую. Из вне, доступ к kube-apiserver через ingress-controller можно сделать - дело вкуса.
Благодарю, Дмитрий ) Буду разбираться )
вот еще странность. я не вижу никаких причин не добавить возможность в kubelet подключаться к нескольким kube-apiserver. Но почему-то до сих пор этого нет, и приходится городить локальные балансировщики 🤷. А новички продолжают страдать от этого совета в доках
С днс не очень вяжется
Я осмелюсь предположить, что это может сломать обратную совместимость, хотя, она на сколько я понял и так +- 1 )))
а причем тут днс?
Ее нет, все так, а запилить не через отдельный фичагейт - нет проблем
А писали уже разработчикам ?) Может, они ждут от пользователей писем с просьбами прикрутить фичу )))
Ну вот как бы ты сделал: по одному имени на каждый апи ендпоинт или три А записи в одном имени?
Да это не проблема. Там же все версионируется. В новой схеме будет просто apiVersion: v1beta kind: Config А не apiVersion: v1
Я не настолько еще искушен ))) Кстати, нужно глянуть версии ) Кхе-кхе ) Совсем про них забыл )
причем тут ДНС я так и не понял. В конфиге вместо server: host, servers: [host1, host2, host3]. А что под host1, host2, host3 ип адреса или домены, это уже вопрос другой и не имеет значения
Обратная совместимость это 2 лишних строчки в темплейте {{- if semverCompare "<1.16.0" .Capabilities.KubeVersion.GitVersion }} apiVersion: extensions/v1beta1 {{- else }} apiVersion: apps/v1 {{- end }}
И сертификаты на айпишники выписывать?)
В чем сложность?
Ну просто выглядит как лишняя ненужная работа
а выписывать сертификат на одно имя сильно проще чем на три имени? Не понял в чем сложность =). Как была O(n) так и осталась
Ну просто смысла не вижу. Если конечно у тебя нет сумасшедших идей вроде «один кубелет взаимодействует с несколькими кластерами»
Смысл в том, чтобы не поднимать балансировщик на каждом воркере
Тяжелыми видами наркотиков пахнет (я про кросс-кластерное взаимодействие)
про него тут речи не было. Он сам его выдумал
это не проблема ) потому что делается один раз
только в доках об этом не пишут. А толкают внешний балансировщик - в этом проблема
ansible потому что и очень много всего там. Я думаю если напишешь свой playbook будет в разы быстрее. Но на самом деле вариантов много. Например rke/rke2, pke
До Rancher еще не добрался )) Через kubeadm руками пробую )
многоо ? вот коллега мучался, что модуль для куба сломан
rke/rke2 можно сетапить просто кластер и не ставить rancher. На самом деле эти тулзы его и не ставят, он отдельно чартом ставится - если нужен
Понял, благодарю )
Как рке отреагировал на новость о докере? Там же полная завязка на него
сейчас для сервисов типа LoadBalancer (например сервис от nginx ingress controller) использую metallb чтобы он external ip выдавал, если без metallb то как это лучше реализовать?
спасибо. почитал, и как я понял смысл тут в том, что не стоит усложнять схему когда и так понятно, что ингресс контроллер будет висеть на всех интерфейсах и тогда metallb не нужен. также посмотрю в сторону hostPort вместо hostNetwork, кажется более секурно. все верно понял?)
hostPort это просто проброс портов через nat
а, окей, а то где-то читал, что это похоже на hostNetwork. а насчет ingress controller я так понял, что и сервис для него него не нужен и запускать надо через DaemonSet судя по доке вот тут https://kubernetes.github.io/ingress-nginx/deploy/baremetal/
Необязательно демонсетом
в общем-то можно просто на одной ноде запустить, так?
Лучше на двух ) чтобы если сложится - у тебя балансировка снаружи не отвалилась
ок спасибо, а если нужно udp то он nginx ingress лучше отказаться и смотреть в сторону envoy?
ну если у тебя сеть хоста, то конечно сервис не нужен. Только если для внутренних коммуникаций, например метрики собирать
спасибо, попробую сегодня заменить этим всем metallb)
Обсуждают сегодня