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

а вот сервис, что пересылает трафик на поды, уже в публичной сети

это как раз то, что я сейчас задумал, в рамках изучения kubernetes :)

и нужным тебе сервисам назначать ClusterIP=IP на интерфейсе

^_^

thank you guys!

thank you guys!

всегда пожайлуста

и не сработает. там же схема что они все пишут и читают из etcd

Да. Не сработало. Придётся поднимать кластер по другому...

Перенос данных сработает

я уже так делал

Не работает отствие etcd в процессе.

Он(нода), как бы, начал отображать все. Но задеплоить ничего с неё не могу.

Есть какое-то руководство по кластеру etcd?

Не работает отствие etcd в процессе.

То есть, грубо говоря, нужно, чтобы /var/lib/etcd были одинаковые везде? Это и будет кластером?

Господа, никто не встречался с проблемой резолва dns имен в подах под alpine-glibc. У меня есть три суффикса на ноде. Соответственно в поде добавляется еще 3 суффикса - ns, svc, cluster.local. Судя по strace он нормально делает запрос на первые 4 днс имени (прибавляя первые 4 суффикса), а потом косячит, отправляет одно и то же, получает таймауты и отваливается. Не уверен в чем проблема. То ли днс сервер как то неправильно работает и не отвечает нормально если часто спрашивать, то ли resolv неправильно реализован. Было у кого такое? Ltrace, кстати вообще ничего не показывает.

такой вопрос, а вы к мониторингу через vpn пускаете?

У алпайна проблемы с днс

Особенно если их несколько

вообще vpn в кластер это же хорошая практика? но только тип на какие-то определенные внутренние сервисы

У меня впн в кластер, мегаудобно

В есть кто юзает istio/linkerd ? Очень хочется экспириенс получить

Кто юзает kubespray? Там ноду просто добавить же? Просто прописать её одну в prepare и сделать deploy?

Кто юзает kubespray? Там ноду просто добавить же? Просто прописать её одну в prepare и сделать deploy?

Да, для инвентори есть lcm

Да, для инвентори есть lcm

То есть, он его не перезапишет, а дополнит, если я masters и etcds не укажу?

Да, но лучше глазом проверить

Спасибо.

Да, но лучше глазом проверить

А установить 1.7.2 с помощью него можно? Или только указанная в мануале версия 1.6.7?

А установить 1.7.2 с помощью него можно? Или только указанная в мануале версия 1.6.7?

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

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

И ещё нубовский вопрос: если я указал 2 мастера, то мне эти же сервера нужно указывать в nodes? Я хочу, чтобы и на них тоже разворачивались поды. Или они автоматически являются нодами, только нужно снять с них SchedulingDisabled?

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

У меня впн в кластер, мегаудобно

а какой впн пробрасывал, openvpn же норм, подходит под best practices?

Хз что там в практисес, из хелм чартов впн норм по мне

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

можно поподробнее?

можно поподробнее?

что именно интересует?

про проблемы с динамическим провижинингом вольюмов можно посмтреть мой тред https://kubernetes.slack.com/messages/C3QUFP0QM/convo/C3QUFP0QM-1499372693.903314/

а автоскейлер работает тока с ASG https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#deployment-specification

господа, поковырял я все эти linkerd и другие istio, и задался вопросом: зачем они могут быть именно мне нужны в кубере (см ниже)? 1) все киллер-фичи есть в той или иной мере в кубере из коробки (балансировка по раундробину, дискавери через днс, циркут брекинг через хелсчеки) 2) вещи типа дебаг-трасировок и метрик решаются отдельно (все равно встроеного функционала не будет хватать) 3) остальные фичи заточены чисто под http (маршрутизация, ретраи, шифрование трафика внутри сети): но ведь amqp дает гораздо больше свободы (все что выше описал + подписка на события, схемы переноса недоставленых сообщений в очередях и тп) я к тому что архитектору при выборе структуры не проще ли вместо того чтобы завязываться на сторонние инструменты которые пытаются решать проблемы устаревшего протокола, использовать идеологически более правильный протокол с самого начала? это немного философский вопрос, поразмышляем?

господа, поковырял я все эти linkerd и другие istio, и задался вопросом: зачем они могут быть именно мне нужны в кубере (см ниже)? 1) все киллер-фичи есть в той или иной мере в кубере из коробки (балансировка по раундробину, дискавери через днс, циркут брекинг через хелсчеки) 2) вещи типа дебаг-трасировок и метрик решаются отдельно (все равно встроеного функционала не будет хватать) 3) остальные фичи заточены чисто под http (маршрутизация, ретраи, шифрование трафика внутри сети): но ведь amqp дает гораздо больше свободы (все что выше описал + подписка на события, схемы переноса недоставленых сообщений в очередях и тп) я к тому что архитектору при выборе структуры не проще ли вместо того чтобы завязываться на сторонние инструменты которые пытаются решать проблемы устаревшего протокола, использовать идеологически более правильный протокол с самого начала? это немного философский вопрос, поразмышляем?

В третьем пункте как раз вся соль

балансировка по раундробину, дискавери через днс, циркут брекинг через хелсчеки это все не риалтайм в кубе, в itsio вроде как отзывчивее (теоретизирую). circuit breaker вообще нет

про проблемы с динамическим провижинингом вольюмов можно посмтреть мой тред https://kubernetes.slack.com/messages/C3QUFP0QM/convo/C3QUFP0QM-1499372693.903314/

Нет доступа почему-то... Я не зареган в слаке.

Нет доступа почему-то... Я не зареган в слаке.

ну зарегайся

ну зарегайся

If you have an @get-an-invite-at.slack.kubernetes.io email address, you can create an account Другого способа зарегаться нет.

и?

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

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

Да ладно. Я думал, что это проще и не надо ходить в гугл, чтобы это сделать. Ни разу слаком не пользовался)

почему это неправильный ответ?

чяднт??

решил: все ответы правильные

дай ссыль потыкать

https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS158x+2T2017/course/

много полезного для себя нашел в этом курсе btw

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

если выбран четвертый ответ, то и третий не выбирать нет смысла

видимо хотели акцентировать на этом внимание

привет, у кого получилось сделать кластеризацию etcd на 1.7? вот тут описано: https://kubernetes.io/docs/admin/high-availability/ но оно судя по всему для 1.6 или ранее, там даже image etcd в yaml какой-то старый... или заинититься с 1.6 и не морочить голову?

а как кластеризация etcd связана с версией k8s?

ну это же часть его?

или я чето не так понимаю?

etcd это вообще отдельный сервис, который релизится и управляется без каких-либо кивков в сторону куба

как мускуль в любом приложении

привет, у кого получилось сделать кластеризацию etcd на 1.7? вот тут описано: https://kubernetes.io/docs/admin/high-availability/ но оно судя по всему для 1.6 или ранее, там даже image etcd в yaml какой-то старый... или заинититься с 1.6 и не морочить голову?

С помощью kubespray сделал. Очень удобно.

или я чето не так понимаю?

https://coreos.com/etcd/docs/latest/op-guide/clustering.html Вот есть офф дока как закластерить етсд. По сути это база данных, в которых кубер хранит инфу о своем кластере.

etcd это вообще отдельный сервис, который релизится и управляется без каких-либо кивков в сторону куба

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

https://coreos.com/etcd/docs/latest/op-guide/clustering.html Вот есть офф дока как закластерить етсд. По сути это база данных, в которых кубер хранит инфу о своем кластере.

спс

ERROR: S client not available

С помощью kubespray сделал. Очень удобно.

спс

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

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

Не совсем понял вопрос, пустить подключение только с некоторых ip?

Не совсем понял вопрос, пустить подключение только с некоторых ip?

нет, я могу сейчас по vpn зайти в кластер и перейти на любой внутренний сервис (kubernetes dashboard, database, backend сервисы и всякие службы мониторинга) так вот я хочу, чтобы впн пускал только на всякие службы мониторинга (grafana, metabase), это мне в какую сторону смотреть?

В сторону впн, думаю

Опенвпн например может пускать только в подсеть, тогда вопрос упирается в изначальное планирование сети0. Типа мониторинг в этой, а остальное в этой

Мож, это и не правильно

что-то типа того, но ладно, попробую разобраться как-то с этим, спасибо! а то мне что-то совсем не нравится, что получив впн можно случайно зайти в kube dashboard и уронить весь кластер

Ну дели изначально на функциональные сегменты

Опять же, предпологается что впн юзают доверенные лица

Опять же, предпологается что впн юзают доверенные лица

не у всех доверенных лиц одинаковая авторизация

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

Зачем это взваливать на более низкий уровень?

Врядли чуваки с доступом по впн начнут пытаться взломать ваш дашборд:)

https://kubernetes.io/docs/admin/authorization/rbac/ о, ого, спасибо, возможно это именно то что нужно)

Врядли чуваки с доступом по впн начнут пытаться взломать ваш дашборд:)

мало ли впн ключик админа/оператора куда-то утечет

мало ли впн ключик админа/оператора куда-то утечет

Это уже административные вопросы

Политики обновления ключей и т.п.

нет

Так можно и до токенов дойти)

это попытки спихнуть реальную авторизацию на провайдера )

Весь вопрос в том, насколько секурно надо делать

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

Мне вот хватает басик ауса для большинства вещей

А как он ее сольет?

получив лишние привилегии

надеюсь по https? басик аус передается в base64

надеюсь по https? басик аус передается в base64

Все по https

получив лишние привилегии

Ну если у вас одна роль - админ, то несомненно

Я просто не вижу особого смысла в разделении прав на уровне сети. В большинстве случаев

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