вот и узнаешь)

но вообще у меня есть разные ing для одного и того же домена..в разных namespace лежат, вроде вс ок работает

да, работает, спасибо

Так. Новая пачка глупых вопросов. :) Правильно понимаю, что ingress сам по себе никаких сущностей не создает, а лишь сообщает ingress-контроллеру, как ему разруливать запросы? Ingress-контроллер - обычный под, в котором крутится, скажем, nginx + что-то, что опрашивает api-сервер по поводу состояния кластера, какие адреса у каких подов, чтобы менять, например, upstream-ы и так далее?

агась

плюс оно еще меняет конфиг nginx и ребутает его для принятия нового состояния

ща вроде как пишут тоже самое на HAproxy

при этом этот под доступен через NodePort или типа того?

Ну и контроллер может быть и вне пода (и да же вне кластера) (Если вы любите извращения, но это не тру вей)

Да через NodePort если контроллер часть кластера

Казалось бы, наоборот, если нет ведь.

Вот, собственно, здесь вопрос. Где-то видел, что упоминалось требование на доступность через NodePort. Но ведь если контроллер - часть кластера, зачем ему ходить на сервисы не через внутренние адреса, а требовать NodePort?

а как он будет отдавать upstream внешнему клиенту?

А вот к подам он как раз ходит по внутернеей сети и по внутренним ip адрессам

ExtClient -> NodePort -> IngressController -> InternalService так ?

Хм...

Тут что-то с сущностями не так)

Не-не, я как раз думал, что ExtClient -> IngressController -> NodePort (?) -> InternalService.

В смысле Ingress впереди всего ведь должен быть.

IngressController это Прокси) и он вешается на NodePort, что бы отвечать внешним клиентам

IngressController это Прокси) и он вешается на NodePort, что бы отвечать внешним клиентам

вот

Тааак

а сам заберает upstream по внутренним адресам

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

либо если Cloud Provider настроен

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

Ну да...

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

У меня 3 с антиафинити - норм

ТАм всегда один лидер)

Но по сути ни какой, у меня 4, работают через ds

вернее деплоятся

Кто-нибудь деплоит проекты из гитлаба в кубер?

Тут заметил, что у всех нод EXTERNAL-IP почему-то <none>. Смотрю describe - публичный адрес написан в InternalIP. Что можно с этим сделать?

kubectl edit no

Тут заметил, что у всех нод EXTERNAL-IP почему-то <none>. Смотрю describe - публичный адрес написан в InternalIP. Что можно с этим сделать?

А зачем экстернал айпи?

А зачем экстернал айпи?

ну его можно юзать вместо NodePort при вывешивании сервиса в октрытый мир, но эта фича была объявлена устаревшей и кажись в 1.6 её выпилили

или в 1.7 точно выпилять

Так...

Ладно, в моем случае это, пожалуй, и правда не нужно.

Но, скажем, если есть локалка, а есть интерфейс, точащий в интернеты. Как сказать, что общаться нодам через такой-то интерфейс, а порты, открытые через NodePort были на том, который в интернеты? Указать InternalIP и ExternalIP отдельно, верно?

Вроде бы, это не для этого.

Поды меж собой пускай по dns имени разговаривают. А выставлять во внешний мир - я бы сделал при помощи ингресс.

Вот, есть у тебя сервис. У него есть имя. Вот, оно и есть то имя, которое подами резолвится в айпи, который нужен подам.

Хотя, вот вопрос - а если мне во внешний мир нужно открыть какой-то определённый порт - ингресс тут поможет?

Я про ноды

Про InternalIP и ExternalIP ноды.

Аа.

Есть оверлейная сеть - ноды по ней связаны.

Чтобы ноды между собой через один интерфейс общались, а то, что я выставлю через тот же NodePort/Ingress - чтобы на другом ждало запросы извне.

Ноды что будут друг другу передавать?

В смысле?

О чём им общаться? Они же просто содержат контейнеры.

Ну, контейнеры-то друг с другом общаются.

Больше ничего не делают.

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

Похоже, оверлейную сеть надо не в кубере тогда поднимать.

Возможно я просто не совсем хорошо написал. Скажем, вначале, до всего, есть два интерфейса: eth1 и eth0. Первый - 10GbE приватная сеть, между всеми машинами, второй - торчит в интернеты. Собственно, нужно как-то сказать кубернетесу, мол, пусть оверлей-сеть для общения между подами на eth1, а для внешних клиентов/Ingress пусть используется eth0.

Вот что имею в виду.

это в docker-bridge должно быть, разве не?

И всё-таки, если у нод нет externalIP, то будет ли работать Ingress тот же?

Следую https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example

kubectl get ingresses ADDRESS пустой

В 1.6 external точно не выпили ли. Мы их юзаем. В 1.7 тоже есть

какой самый православный способ поднять кубер на CentOS bare-metal? kubespray?

production

какой самый православный способ поднять кубер на CentOS bare-metal? kubespray?

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

спасибо

ERROR: S client not available

возьму карго. ансибл мне ближе

кстати, мы тут в команде запилили альтернативный low-level UI для кубов. для любителей редактировать yaml руками

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

А кубеадм разве плохо подходит для больших проектов?

А кубеадм разве плохо подходит для больших проектов?

ну вообще там при запуске kubeadm написано don’t use in production

Неплохо смотрится! А попробовать можно?)

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

А кубеадм разве плохо подходит для больших проектов?

в нем нет файловера. А без файловера запускать продакшн – самоубийство

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

Спасибо)

в нем нет файловера. А без файловера запускать продакшн – самоубийство

тут https://github.com/kubernetes-incubator/kubespray написано, что The firewalls are not managed, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall.

где ж взять прод с файрволом?..

где ж взять прод с файрволом?..

failover != firewall как не странно

ааа) блин надо отдыхать уже)

Ребята, и всё-таки, что нужно сделать с RBAC, чем-то ещё, чтобы просто запустить хотя бы вот такой экзампл? https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example

Чистый kubeadm с weave, ничгео не трогалось. Сервисы стартуют, но ingress не работает: просто никто не слушает на нужных портах и всё.

failover != firewall как не странно

А можно пояснить, что подразумевается под failover'ом ?

А можно пояснить, что подразумевается под failover'ом ?

устойчивость кластера к падению одного из мастеров.

Ребята, и всё-таки, что нужно сделать с RBAC, чем-то ещё, чтобы просто запустить хотя бы вот такой экзампл? https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example

Я писал где-то выше. Ссылку кидал.

Так чем kubeadm не устраивает? Мы на нем 3 мастера подняли, и пока 2 живы, все ок. И то 2 нужно чтобы кластер etcd не упал только, а так и одного достаточно

Так чем kubeadm не устраивает? Мы на нем 3 мастера подняли, и пока 2 живы, все ок. И то 2 нужно чтобы кластер etcd не упал только, а так и одного достаточно

три мастера в файловере? а давно кубеадм так умеет? в версии 1.4 и 1.5 точно не умел

Ну сам kubeadm такого не умеет, с помощью него делается 1 мастер и джойнятся куча нод. Но чтобы дополнительно превратить еще 2 ноды в 2 мастера нужно минут 20, не больше. Перегенерировать сертификаты и немного поправить kubeapi в манифесте и все

Все тестилось, все работает

спасибо за пак

где ж взять прод с файрволом?..

Ansible

Ansible

а давно в ансибле нормально фаер заработал?

я вот так и не смог заставить его

Нуууу, iptables ами рулю)) не из коробки конечн, но что делать)

Guys, есть работа в Киеве для девопса и девелопера. Проект новый, стек - go, kubernetes, consul, elasticsearch, kafka, cassandra, prometheus. Кому интересно - пишите в личку.

Ну сам kubeadm такого не умеет, с помощью него делается 1 мастер и джойнятся куча нод. Но чтобы дополнительно превратить еще 2 ноды в 2 мастера нужно минут 20, не больше. Перегенерировать сертификаты и немного поправить kubeapi в манифесте и все

А можно поподробнее где-нибудь почитать?

НИЗЯ https://docs.docker.com/engine/userguide/networking/configure-dns/

если очень хочется, то можно. если kubelet настроен на CNI, то контейнер запускатся вообще с net=none, потом CNI скрипты конфигурируют сеть, а kubelet пишет свой resolv.conf

Кто-нибудь знает как на kubeadm сделать renew сертификатов?

осторожней, сертификаты часто используются и для --service-account-key-file, а значит когда оно сменится, то все предыдущие serviceaccounts будут пытаться подсунуть токен, который не пройдет проверку. даже если вы обновите ключ для serviceaccounts (достаточно их удалить,они пересоздадутся например), то надо будет перезапустить все запущенные поды, т.к. они все используют go-client, а он не умеет читать обновленный токен с диска, который куб заботливо положил рядом и даже обновил