для изучения

Да, в общем-то главная цель — изучение. Побочная — крутить всякое development окружение

Да NodePort я настроил, даже range для портов расширил для удобства. Но теперь хочется сделать правильнее

тогда вопросов нет

а правильне - это понятие относительнее. Если http сервисы и надо чтобы на 80 443 шел траффик и потом по path роутился на разные сервисы - ingress

если tcp сервисы или по path не надо роутить и норм на разных портах - nodeport

а правильне - это понятие относительнее. Если http сервисы и надо чтобы на 80 443 шел траффик и потом по path роутился на разные сервисы - ingress

У куба есть встроенный ingress? В документации тут просто создается ingress и все хорошо, но в других статьях создается nginx-ingress отдельно

в 1.5 и ниже нет встроенного, в версиях новее не подскажу

Я как-то пропустил и в документации тоже упоминается nginx proxy

насколько я помню раньше (с год назад) был "официальный" контейнер для ингресса на gcr.io который используется в документации кубернетеса и был от самого нжинкса на докер хабе

и там и там был нжинкс внутри

как сейчас не знаю, не слежу. В опеншифте у них есть свой официальный контейнер с нжинксом для ингресса плюс опять же их собственный контейнер с их форком oauth proxy от bitly чтобы навешивать авторизацию на различные дашоборды типа той же графаны где авторизации и особенно SSO-SAML нет из коробки

как сейчас не знаю, не слежу. В опеншифте у них есть свой официальный контейнер с нжинксом для ингресса плюс опять же их собственный контейнер с их форком oauth proxy от bitly чтобы навешивать авторизацию на различные дашоборды типа той же графаны где авторизации и особенно SSO-SAML нет из коробки

* с haproxy вместо nginx

О, я тоже логхаус юзаю, только развернул сам кликхаус не в кубе, а на отдельном серваке. Мне нравится гораздо больше чем эластик

О, я тоже логхаус юзаю, только развернул сам кликхаус не в кубе, а на отдельном серваке. Мне нравится гораздо больше чем эластик

Это радует :) в бете все будет намного лучше

Там ещё есть у них пару косяков в дэшборде

Не пара, а их куча :) знаем, будем фиксить. То был poc (альфа). Чуть забили на него, но прямо сейчас вернулись к разработке

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

Пилите на любую проблему/хотелку issue, будем смотреть и допиливать

Будет сделано

А kubespray можно использовать для добавления новых нод, или удаления из кластера?

да, поддерижвается scale

http://itmithran.com/setting-single-node-kubernetes-cluster-using-minikube/

Само реклама???

http://itmithran.com/setting-single-node-kubernetes-cluster-using-minikube/

very useful, thank you

?

Там ещё есть у них пару косяков в дэшборде

Давай все косяки списком! Больше косяков! Мы планируем сделать итерацию и пройтись капитально по дэшборду.

насколько я помню раньше (с год назад) был "официальный" контейнер для ингресса на gcr.io который используется в документации кубернетеса и был от самого нжинкса на докер хабе

Да, нашел такой в документации, поднял. «Магическим» образом все сразу заработало! Получилось что nginx-ingress висит на hostNetwork и светит своими портами 80, 443 (другой вариант как NodePort прокинуть но подумал что лишнее, да и не даст без дополнительных настроек).

Я на bare metal вместо nodeport прописываю тип LoadBalancer и забиваю externalIPs, таким образом на нодах с этими IP начинают слушать 80 и 443 порты

Кстати host_gw так и не завелся нормально с kubespray, а vxlan взлетел только после того как на нодах внешний и внутренний интерфейсы местами поменял)

Господа, а кто-нибудь гоняет postgres на k8s?

я, но в одном поде

есть ещё stolon и patroni

Господа, а кто-нибудь гоняет postgres на k8s?

Да + stolon, данные во внешнем хранилище

А что вы используете в качестве PV?

так локальный диск проще всего. Там всё равно не нужен shared storage

Мне бы желательно просто hostPath, но в доках k8s черным по белому написано, что Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster

это для общего случая

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

в случае постгреса, у каждого пода свой диск

это для общего случая

я тоже подозреваю об этом, поэтому и решил спросить

ну у меня котфиг такой - несколько нод - данные хранятся на сомой ноде - не shared их ревлицирует stolon

Хорошо, а как правильно сделать так, чтобы мастер при смерти не решедулился на другую ноду со всеми вытекающими

как раз надо, чтоб решедулился

для этого столон и нужен

если мастер грохнулся (сам под или нода с ним), то столон назначает один из слейвов на роль мастера

я не в курсе, что это, сейчас прочитаю, спасибо

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

stolon вещь

коннект идёт через прокси сервис, который в курсе, кто сейчас мастер

разумеется, этот прокси можно и нужно реплицировать?

да

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

спасибо огромное, буду копать

Подскажите, как правильно задать в k8s учётку для доступа в eu.gcr.io? Делаю так: kubectl -n kube-system create secret docker-registry giftery-gcr --docker-server "https://eu.gcr.io" --docker-username _json_key --docker-email admin@foobar.ru --docker-password=$(cat gcr.json) (пароль это такой JSON) А если потом декодирую .dockerconf из получившегося секрета - получаю невалидный JSON, часть которого ("auth") тоже декодируется в "_json_key:". И образы конечно не качаются.

Создавайте regsecret в одном неймспейсе с деплойментом

Дело не только в неймспесах, у меня как-то вместо пароля открывающая скобка попадает, это не JSON невалидный.

Господа, я делаю вывод что никто тут не зопатчился от meltdown, иначе бы тут было сильно больше сообщений, что докер не может остановить контейнеры. Гонка в runc, которая начала проявляться после meltdown патчей. Фикс есть в runc включенном в докер 18.01

У меня centos 7 с ядром 3.10.0-693.11.6.el7.x86_64 (вроде в нем патч вышел) и докер версии 17.12.0-ce, build c97c6d6 - вроде все окей.

Господа, я делаю вывод что никто тут не зопатчился от meltdown, иначе бы тут было сильно больше сообщений, что докер не может остановить контейнеры. Гонка в runc, которая начала проявляться после meltdown патчей. Фикс есть в runc включенном в докер 18.01

А есть линк на PR?

У меня centos 7 с ядром 3.10.0-693.11.6.el7.x86_64 (вроде в нем патч вышел) и докер версии 17.12.0-ce, build c97c6d6 - вроде все окей.

Много контейнеров гоняете туда-сюда?

У нас есть Proof of Concept. Пока глубокая альфа, но гораздо легче, чем ElasticSearch. В плане ресурсов, конечно. Юзабилити ещё тянуть и тянуть. https://github.com/flant/loghouse

о, норм пул реквесты начали принимать)

Много контейнеров гоняете туда-сюда?

Мало, кластер 3 ноды по ~15 подов на ноду + десяток кронджоб

А есть линк на PR?

https://github.com/moby/moby/issues/33820

Merci!

Господа, я делаю вывод что никто тут не зопатчился от meltdown, иначе бы тут было сильно больше сообщений, что докер не может остановить контейнеры. Гонка в runc, которая начала проявляться после meltdown патчей. Фикс есть в runc включенном в докер 18.01

они так и не осилили багфикс-релизы?

Merci!

Связанный фикс в runc https://github.com/moby/moby/issues/36010

ребят подскажите у меня кластер слушает порт которого нет в сервисах  netstat + ps выдают мне строку что это kube-proxy

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

lsof -i :port (or something similar)

А кто подскажет с какой версии kube-dns подтягивается в эко-систему? Я поставил 1.5 (по инструкции с сайта), но в запущеных не вижу пода с ДНС. Соответственно не могу находить контейнеры по ДНС или по Имени. Возможно есть вариант подкрутить консула для автодискавери сервисов или все намного проще?

А кто подскажет с какой версии kube-dns подтягивается в эко-систему? Я поставил 1.5 (по инструкции с сайта), но в запущеных не вижу пода с ДНС. Соответственно не могу находить контейнеры по ДНС или по Имени. Возможно есть вариант подкрутить консула для автодискавери сервисов или все намного проще?

А в каком неймспейсе смотришь? Попробуй kubectl get pod -n kube-system

Alexander ns —all :)

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

Ребят, а куб умеет loadbalancer делать не в облаках, а в чем то более приземлённом вроде nginx или haproxy?

Подскажите как правильно реализовать кубернетес, чтобы закрыть все порты наружу на сервере кроме 80 и 443. Почитал, что для этого нужен ингресс-нжинкс. пробовал ставить по 3 разным гайдам и получается связка: деплоймент-сервис-ингресс. Но сервис прокидывает на белый ip порты только с 30000, а мне нужны 80 и 443. Или для этой цели нужен нжинкс на хосте с proxy-pass?

ингресс делает listen на 80,443 и при запросе роутит на нужный сервис

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

Ребят, а куб умеет loadbalancer делать не в облаках, а в чем то более приземлённом вроде nginx или haproxy?

эт слишком общая задача, loadbalancer расчитывает на готовую инфраструктуру. думаю пилить балансировщики не входит в рамки задач к8с

Ребят, а куб умеет loadbalancer делать не в облаках, а в чем то более приземлённом вроде nginx или haproxy?

для этого и есть ингресс)

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

ингресс делает listen на 80,443 и при запросе роутит на нужный сервис

Да по идее так должно быть, но при просомтре портов котоыре слушает сервер там нет 80 порта. хотя ингресс активен, все поды активны и в статусе ингресса стоит 80 и нужный ip

посмотри что за nginx правило генерится

в чем проблема

Подскажите как правильно реализовать кубернетес, чтобы закрыть все порты наружу на сервере кроме 80 и 443. Почитал, что для этого нужен ингресс-нжинкс. пробовал ставить по 3 разным гайдам и получается связка: деплоймент-сервис-ингресс. Но сервис прокидывает на белый ip порты только с 30000, а мне нужны 80 и 443. Или для этой цели нужен нжинкс на хосте с proxy-pass?

порты с 30000 выделяются для service NodePort. самый простой способ забиндить ingress-nginx на 80,443 - запустить его с hostnetwork

для этого и есть ингресс)

Ingress подразумевает что сверху оно еще и балансером накрыто либо в dns указаны все ноды. Вот я и хочу сверху приделать лоадбалансер, но хочется чтоб куб умел им управлять. Я слышал про то что он умеет в гуглклауде и тп это делать, но хочется чтоб он управлял чем то более приземленным, наприсер nginx/haproxy и тп

Ingress подразумевает что сверху оно еще и балансером накрыто либо в dns указаны все ноды. Вот я и хочу сверху приделать лоадбалансер, но хочется чтоб куб умел им управлять. Я слышал про то что он умеет в гуглклауде и тп это делать, но хочется чтоб он управлял чем то более приземленным, наприсер nginx/haproxy и тп

ингресс эт и есть лоадбалансер, по сути херовина которая генерит нжинкс правила)

посмотри что за nginx правило генерится

а как и где это можно посомтреть?