@yolkov вот ингресс как раз и роутит внутренние адреса для внешних клиентов

какой ИП назначается для ингрес? ип хоста на котором запущен ингрес контролер?

да

а если хост с ингрес котролером упадет?

для этого есть keepalived

запускаешь ingress как daemonset и он работает на всех нодах. а keepalived прозрачно меняет VIP если мастер падает

но это только если инфраструктура умеет vrrp

все равно не очень красиво, т.к. весть траф между кубом и остальной инфрастурктурой будет идти через одну точку

а сейчас он как идет?

Напомните, сервису же нельзя присвоить "нормальный" порт на ноде (e.g. 80), только из эфемерного диапазона?

внутри инрструктуры все сревисы в одной сети

@etkee можно. используй hostPort как в ingress. https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/daemonset/as-daemonset.yaml#L39..L40

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

В общем, так или иначе, ты можешь сделать любой сервис доступным снаружи на каждой ноде

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

но если твоя задача разделить трафик и никак иначе, то можешь попробовать так

@yolkov я очень смутно понимаю о чем ты говоришь. обычные сервисы то у тебя наверняка на ноде. и если эта нода сдохнет, то сервис тоже окажется неработоспособным

я могу по идее на сетевом оборудовании настроить достпность ИП контейнеров и с сетью остальной инфраструктуры

если хочешь отказоустойчивости - используй keepalived и прочие load balancer'ы

сервисы у меня размазаны по нескольким нодам

сервисы у меня размазаны по нескольким нодам

сервис у тебя существует на каждой ноде. контейнеры, к которым он стучится - другое дело

а вот связность ВИРТУАЛЬНОЙ сети сервисов просто не реализовать

хочешь чтобы без ingress - делай как в этом примере: https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/daemonset/as-daemonset.yaml#L39..L40 - но учти, что только один сервис сможет слушать этот порт на ноде. и никакого rolling upgrade

а расскажите про persistenvolumes? правильно ли я понимаю что это абстракция над стораджами? и например если я создасю в GCE pvc=>pv то создается диск в гугле?

то есть я тупо конфигурирую себе хранилища не задумываясь под каким облаком?

$ kubectl get pv NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE pvc-380493c8-870c-11e6-9b8a-42010af00085 8Gi RWO Bound default/ci-jenkins 9m

ммм, вот тут если default/ci-jenkins умрет то ресурс удалится?

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

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

Т.е. администратор так или иначе предоставляет куски хранилища, а они потом привязываются к pvc. Пока живет pvc - этот кусок принадлежит ему (надеюсь, не наврал).

Скорее всего зависит от того, где PVC объявлен, но проще всего либо попробовать руками на тестовом поде, либо дождаться точно знающих людей.

Сам PV при этом уже не удалится, насколько понимаю

почему может не отрабатывать такое правило apiVersion: extensions/v1beta1 kind: Ingress metadata: name: echomap spec: rules: - http: paths: - path: / backend: serviceName: myservicename servicePort: 3000

?

а сервис такой есть? или ошибку какую-то выдает?

хоста нет

сервис есть, а по идее если хост не указываешь, то он любой будет, да и если указывал хост то все равно не работает а кидает на default-backend

а не на сервис

а ты ручками заводишь?

ошибок тоже вроде нет все работает

да, а как то еще можно?

через api

это как?

у k8s есть api, сам kubectl через него работает

смотри есть endpoint у сервиса

смотри логи самого nginx

в логах он в основном ходит на /healthz

Парни, а кто как ограничивает доступ к сервисам через ingress? Вот допустим у меня в кубике апп, который должен быть доступен внешнему сервису, но ни кому более.. SSL прикручивать?

я не уверен, что это проблемы ингресса и самого куба вообще

по-хорошему приложение должно само аутентификацией и авторизацией заниматься

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

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

я ей-богу давно копался в криптографии, но самоподписанный сертификат на HTTP по идее никак не запретит клиентам слать туда запросы

Если хендшейк не пройдет, то и тунеля не будет

С TLS это решается через Mutual Auth, когда клиент тоже отправляет сертификат

А как он не пройдет-то? В сертификате же нет поля "запретить клиентам Х,Y,Z проводить хендшейк".

А просто сертификат некорректный можно заигнорировать.

Клиент может, конечно.. Это его право. Однако на стороне сервера говорим, что это обязательное требование

А так можно сказать на сервере?

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

У того же curl есть флаг --insecure, который позволяет забить на все некорректные требования сервера

Если бы это было вообще возможно, то твой нужный клиент не смог бы подрубиться, потому что его точно так же резал бы сертификат

Так вот, нужный механизм называется Mutual Auth, он есть искаропки

В том же nginx делается так

ssl_trusted_certificate /etc/nginx/ca.crt; ssl_client_certificate /etc/nginx/ca.crt; ssl_verify_client on;

ERROR: S client not available

нужен какой-то из первых двух параметров и третий

Тогда при хендшейке сервер запрашивает у клиента сертификат. Если он подписан тем ca, то его пропустят дальше

Да, именно так.. мы на проде на хапроксях это используем

Значит вы уже имеете всё нужное, чтобы пускать избранные сервисы.

Да, конечно.. я о чем и спрашиваю. Делал ли кто-то подобное с ингресс nginx?

@dshmelev авторизация?

как создать auth secret для ingress: https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/auth и вот так оно используется на примере kibana (см Example of an ingress controller to get an access from outside): https://github.com/kayrus/elk-kubernetes

а при создание nginx-ingrees-constoller когда создаю rc-default ему надо expose делать и type=LoadBalancer?

Нет

а как он с наружи будет виден?

там пробрасывается порт наружу как docker -p 80:80 -p 443:443

т.е к нему нужно по ExternalIP стучаться?

для того он и создан

ну а если он ен может достучаться по не му, как узнать почему?

логи пода посмотреть

Привет, коллеги. Подскажите пожалуйста, как правильно перевести "Kubernetes executor" на русский? Есть какой-нибудь устоявшийся термин? (Контекст: третий абзац https://about.gitlab.com/2016/09/22/gitlab-8-12-released/)

вопрос на миллион

лучше "клиент kubernetes" и "интеграция с kubernetes" ничего в голову не приходит.

@kay_rus в логах пода только 100.96.2.1 - [100.96.2.1] - - [01/Oct/2016:13:10:41 +0000] "GET /login HTTP/1.1" 200 8788 "http://ip/healthz" "Go-http-client/1.1" 159 0.026 100.96.2.39:3000 48433 0.026 200

@etkee ок, попробую с этим что-то сформулировать.

@a_hillo уже хорошо.

))

Дак какие бенефиты ингресс дает по сравнению с нгинксом фронтендом?

и заодно чтоб два раза не вставать: предположим я создаю ingress controller (nginx) и ingress в одном неймспейсе... как-то можно сделать доступ к сервисам в разных неймспейсах? предположим по роуту "GET /" дергаются поды сервиса в production неймспейсе, а по роуту "GET /test" дергаются в staging? так по дефолту, или ingress имеет доступ только в пределах неймспейса?

из примеров rc-default.yaml запускаешь в default namespace

а ingress уже в другой namespace

из каких примеров?

которые тебе недавно кидали :))

https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples

https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/default

ingress контролер в default

не, это я нашел - просто зырю где разные неймспейсы, пока не вижу