@kubernetes_ru

Страница 632 из 958

Сергей

20.06.2018
12:14:12

< HTTP/1.1 403 Forbidden < x-amz-request-id: 9040F56F7A211FCA < x-amz-id-2: Jjx02adA89BeJvVeCSM+rECxb1ISYNgznMnrHVFnAzvzVJgsSPNqJJqsN2RsGzwrwpxMEGCMH/Y= < Content-Type: text/html; charset=utf-8 < Content-Length: 338 < Date: Wed, 20 Jun 2018 12:13:27 GMT < Server: AmazonS3

Denis

20.06.2018
12:41:17

кажется не успею добраться

Будет запись в https://t.me/kubernetesMSK

Sergey

20.06.2018
12:49:28

https://www.youtube.com/watch?v=7VRyeMxQqTA

это оно?

Google

Александр

20.06.2018
13:26:04

это оно?

Сегодня будет в 19 вроде, это трансялция?

Sergey

20.06.2018
13:26:51

ну вот это она

ток почему то трансляцией делюсь я а не организаторы ?

Denis

20.06.2018
13:39:46

Блин, такой сюрприз испортили

Готовьте вопросы:)

Репортаж будет в https://t.me/kubernetesMSK

Pavel

20.06.2018
15:01:31

Может и правда не доехать а послушать транлсяцию. Блин)

Denis

20.06.2018
15:38:21

Mikhail

20.06.2018
15:55:34

Говорят гостевого wifi нет

Pasha

20.06.2018
15:55:45

Все так)

Denis

20.06.2018
15:58:45

Nikolay

20.06.2018
15:59:19

Ingress

а ингресс умеет трафик балансировать по тэгам?

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

Google

Andrey

20.06.2018
16:00:03

а ингресс умеет трафик балансировать по тэгам?

По тегам? Список IP? Я не совсем понимаю вашей архитектуры.

Nikolay

20.06.2018
16:00:49

По тегам? Список IP? Я не совсем понимаю вашей архитектуры.

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

но чтобы оно работало - приходится сейчас прописывать список айпишников этих самых воркеров явно внутрь ресурса ингресса

можно этого избежать?

Andrey

20.06.2018
16:01:28

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

Воркеры внутри кластера?

Nikolay

20.06.2018
16:01:39

Воркеры внутри кластера?

да

Andrey

20.06.2018
16:01:48

Тогда ведь можно просто указать на сервис, а сервис привязать через selector к нужным подам.

Как всё и делается обычно. Или я чего-то недопонимаю?

Nikolay

20.06.2018
16:03:05

я не очень сам знаю пока, как именно трафик балансируется на сервисе. Вроде как в ингрессе уже есть ha-proxy или nginx, зачем тогда трафик дополнительно еще и через сервис гнать?

или я неправильно рассуждаю?

Andrey

20.06.2018
16:04:20

Давай разберём подробно.

Есть Ingress Controller. Это что угодно, что взаимодействует с API Kubernetes и понимает, что такое Ingress объект в Kubernetes и позволяет роутить трафик снаружи внутрь кластера.

Контроллер может быть хоть nginx, хоть haproxy, хоть traefik, и есть ещё тонна реализаций.

Мы используем этот. По совместительству самый популярный. https://github.com/kubernetes/ingress-nginx

У вас какой?

Nikolay

20.06.2018
16:05:49

окей, да

у нас на основе ha-proxy сейчас стоит

его не я настраивал, не помню точно, откуда его взяли

Andrey

20.06.2018
16:07:59

Я расскажу, как этот работает, а haproxy по аналогии должен уметь всё, только я с ним не работал. Для него создаётся т.н. Ingress ресурс, там описывается список хостов и URL paths и куда их роутить. Это им объекта Service и порт в нём.

Сервис в свою очередь указывает на нужные поды с воркерами.

Google

Andrey

20.06.2018
16:08:35

Nginx получается список IP из объекта Endpoint, который автоматически создаётся вместе с сервисом.

И по нему делает балансировку по свои внутреннием механизмам (upstreams).

Nikolay

20.06.2018
16:08:55

да, это я, вроде как, понимаю. А что если я не хочу явно список хостов передавать?

Andrey

20.06.2018
16:09:16

wildcard звёздочку ввалить в Ingress объект?

Nikolay

20.06.2018
16:09:21

а хочу спокойно добавлять воркеры без изменений в самом контроллере

wildcard звёздочку ввалить в Ingress объект?

о, а так можно?

Andrey

20.06.2018
16:09:36

На нескольких клиентах работает.

Но это сильно зависит от самого контроллера. Nginx Ingress Controller поддерживает.

Nikolay

20.06.2018
16:10:53

спасибо, попробуем

Mikhail

20.06.2018
16:12:05

Documentation is available here.

http://romana.readthedocs.io/en/latest/ - правильный линк

Andrey

20.06.2018
16:12:33

спасибо, попробуем

Т.е. у вас воркеры разные по доменам что ли?

Nikolay

20.06.2018
16:13:04

Т.е. у вас воркеры разные по доменам что ли?

у нас еще хуже сейчас

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

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

Andrey

20.06.2018
16:14:24

Он совсем не умеет на несколько.

Это бы лучше в один namespace, конечно. Какие бонусы вы получаете от разных?

Nikolay

20.06.2018
16:14:43

а что использовать в таком случае лучше?

Это бы лучше в один namespace, конечно. Какие бонусы вы получаете от разных?

надо разным юзерам ресурсы ограничивать по-разному

Andrey

20.06.2018
16:15:09

Окей, я понял, используете квоты.

Nikolay

20.06.2018
16:15:17

да

Google

Andrey

20.06.2018
16:16:05

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

На каком языке программируете?

Nikolay

20.06.2018
16:16:33

основная логика пока на питоне, но на го тоже можем

но что именно будет балансировать на разные неймспейсы? ставить отдельно руками nginx/haproxy вне кластера?

Andrey

20.06.2018
16:18:11

Балансировка ведь в пределах одного namespace? Т.е. один URL (domain + path) ведёт в один сервис в каком-то конкретном namespace, верно?

Nikolay

20.06.2018
16:19:25

Балансировка ведь в пределах одного namespace? Т.е. один URL (domain + path) ведёт в один сервис в каком-то конкретном namespace, верно?

есть один урл, допустим, example.com . Может быть так, что example.com/abc ведет на один сервис в одном неймспейсе, а example.com/def - на другой в другом. Нужен ресурс, где можно прописывать роутинг в таком виде

Andrey

20.06.2018
16:20:16

Так без проблем же это стандартным Ingress ресурсом делается.

Nikolay

20.06.2018
16:20:17

я, вроде как, понимаю, что можно настроить внешний nginx и разложить все по ингрессам, но хочется встроенными средствами и динамически

Andrey

20.06.2018
16:20:49

Встроенно всё и настраивается. Просто, чтобы не словить геморроя от большого количества ingress'ов с кучей правил, можно с API напрямую поработать.

Denis

20.06.2018
16:21:31

Полетели!

Nikolay

20.06.2018
16:22:17

Встроенно всё и настраивается. Просто, чтобы не словить геморроя от большого количества ingress'ов с кучей правил, можно с API напрямую поработать.

перефразирую вопрос. Какой ресурс, не привязанный к конкретному неймспейсу, поможет раскидать трафик по разным ингрессам в разных неймспейсах?

Andor

20.06.2018
16:22:52

перефразирую вопрос. Какой ресурс, не привязанный к конкретному неймспейсу, поможет раскидать трафик по разным ингрессам в разных неймспейсах?

а разве поды могут быть не в неймспейсе?

Andrey

20.06.2018
16:23:18

перефразирую вопрос. Какой ресурс, не привязанный к конкретному неймспейсу, поможет раскидать трафик по разным ингрессам в разных неймспейсах?

Никакого. Но без труда можно насоздавать много Ingress ресурсов в каждом Namespace и динамически управлять ими извне.

Nikolay

20.06.2018
16:23:19

а разве поды могут быть не в неймспейсе?

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

Andor

20.06.2018
16:23:33

ингресс создаёт поды

Andrey

20.06.2018
16:23:37

К контроллер БУДЕТ роутить и балансировать в разные неймспейсы.

ингресс создаёт поды

Не путайте Ingress и Ingress Controller.

Nikolay

20.06.2018
16:25:34

К контроллер БУДЕТ роутить и балансировать в разные неймспейсы.

а если создать новый неймспейс - то контроллер его автоматом подцепит?

Andrey

20.06.2018
16:25:58

а если создать новый неймспейс - то контроллер его автоматом подцепит?

Да, если там будет Ingress ресурс создан, а вы его создадите через вашу Python программу. Сразу же.

Google

Nikolay

20.06.2018
16:26:22

Да, если там будет Ingress ресурс создан, а вы его создадите через вашу Python программу. Сразу же.

спасибо, попробуем

Andrey

20.06.2018
16:27:14

Вся суть Kubernetes, в том, что он невероятно гибок. Это самое важное, что в нём есть. Стабильное API (kind of), через которое вы можете как угодно манипулировать объектами. Не ограничивайте себя kubectl и Helm, мыслите шире. :)

Nikolay

20.06.2018
16:27:47

да мы через API все и создаем ?

Andrey

20.06.2018
16:28:54

да мы через API все и создаем ?

Так вообще проблем не будет тогда у вас. Создавайте Ingress объекты динамически, контроллер их подхватит. HAproxy Ingress Controller, вроде, уже достаточно взрослый, проблем не будет.

Eugene