уже 1.4.1 зарелизили

Да я так и понял )

Но кстати второй вариант через weave нормально заработал

Успешно устанавливаем kubernetes ансиблом, но только на CentOS 7 пока. Роли ансибла свои, с фэйрволом.

а карго пробовали?

Успешно устанавливаем kubernetes ансиблом, но только на CentOS 7 пока. Роли ансибла свои, с фэйрволом.

а за основу брались не эти скрипты? https://github.com/kubernetes/contrib/tree/master/ansible

За основу брались не скрипты, а руководство по установке на RHEL. С contrib впоследствии был взят только README :)

Также еще с других руководств по нитке :)

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

За основу брались не скрипты, а руководство по установке на RHEL. С contrib впоследствии был взят только README :)

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

лучше по частям и самому - тогда приходит понимание

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

лучше по частям и самому - тогда приходит понимание

Вот абсолютно согласен... Пока сам ручками не докопаешься, полное понимание никогда не придет

Сначала ETCD кластер или просто на мастер, потом flannel, 3 компонента: APIserver, Cotro;ler Manager иScheduler, потом kubelet и kubeproxy

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

Рабочая демка: https://github.com/takama/k8sdemo

спасибо! сейчас попробую

Dashboard и SkyDNS там ставятся отдельно, одной коммандой - не по умолчанию.

Если понадобятся то в доке есть комманда как поставить

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

Разработчики пишут микросервисы не привязываясь к kubernetes - 12 факторные требованя к микросервисам покрывают большую часть условий + согласование на этапе конфигурации, в итоге все очень легко масштабируется

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

Разработчики пишут микросервисы не привязываясь к kubernetes - 12 факторные требованя к микросервисам покрывают большую часть условий + согласование на этапе конфигурации, в итоге все очень легко масштабируется

это оно?) https://habrahabr.ru/post/258739/ я начал разворачивать кубернет, чтобы посмотреть, как там конфиги можно хранить и так вещи, чтобы уже начать сервисы писать с такими идеями) сейчас почитаю статью - если не будет привязки к кубернету, то это вообще мечта)

Да оно, касательно конфигов - 100% идеальное решение: всю динамику только через переменные окружения ENV, всю статику залинковывать в контейнеры

Kubernetes может легко работать без SkyDNS если есть соглащение по именованию ENV, в демке про это упоминается

Кстати оно уже с переводом вроде в оригинале: https://12factor.net/ru/

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

У Kubernetes используется кластерный IP - именно он и заполнен в переменных окружения ENV. Обращение к сервису происходить по кластерному IP. Если одна из реплик отваливается, то поднимается другая реплика. С этим проблем нет

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

Тупо резолвишь днс с headless-сервисом раз в секунду-две-десять, подтягиваешь новые айпишники. Запросы делашеь настолько идемпотентными, насколько возможно, в случае провала либо делаешь ретрай на следующем сервере, либо сразу возвращаешь ошибку в случае неидемпотентности

Кластерный IP - это адрес сервиса, а не конкретной реплики. Обращение происходит к одной из живых реплик

Кластерный IP - это адрес сервиса, а не конкретной реплики. Обращение происходит к одной из живых реплик

вроде этого? postgresql: http://postgresql:45678 redis: http://redis:22334

не, там именно IP

ipv4

не, там именно IP

понял получается IP, который не меняется в жизни контейнера с сервисом, верно?)

Тупо резолвишь днс с headless-сервисом раз в секунду-две-десять, подтягиваешь новые айпишники. Запросы делашеь настолько идемпотентными, насколько возможно, в случае провала либо делаешь ретрай на следующем сервере, либо сразу возвращаешь ошибку в случае неидемпотентности

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

не меняется с регистрацией сервиса, даже если реплик нет

не меняется с регистрацией сервиса, даже если реплик нет

понял! шикарно! это отличная новость, спасибо)

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

Если tcp-коннект не рвется, у тебя все на одну реплику уходить будет.

Там еще какие-то edge cases были, но я уже не вспомню сейчас

по хорошему еще нужно в продакшин поставить Ingres для балансировки правильной

Если tcp-коннект не рвется, у тебя все на одну реплику уходить будет.

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

по сути там HAProxy

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

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

если подключение к БД создалось, то уже никак)

Чтобы все было четко с TCP и балансировкой - используйте Ingres - HaProxy

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

К БД тоже HAProxy и лучше отдельно, вне кластера Kubernetes

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

никто не дает таких гарантий

Балансировка к БД - отдельная тема

никто не дает таких гарантий

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

У нас стоит Galera 7 нод мастер-мастер через HAProxy

Балансировка к БД - отдельная тема

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

а как быть с secret токенами? например от AWS S3?

их тоже хранить в переменных среды?

Хранить можно где угодно, но в переменные среды они попадают хоть как

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

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

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

а как быть с secret токенами? например от AWS S3?

есть такая штука, как secrets

Можно для этого запускать контейнер с секретами :)

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

понял

есть такая штука, как secrets

secrets - это тоже штука отвязанная от кубертнета? я пытаюсь понять, что гуглить)

не-не, это прям его фичаа

Можно для этого запускать контейнер с секретами :)

типа еще один сервис?)

http://kubernetes.io/docs/user-guide/secrets/

secrets в Кубернетисе вроде

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

ERROR: S client not available

http://kubernetes.io/docs/user-guide/secrets/

сейчас прочту но по идее, это уже завязка на кубернете - не очень наверное, не?)

там тоже все выливается в ENV-переменные

там тоже все выливается в ENV-переменные

а, понял

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

либо в файлы - тут уже как удобнее

супер, @takama , @etkee спасибо за инфу! буду кодить тогда с использованием docker-compose последний вопрос: для связки API ендпоинтов используете nginx? например, есть 2 сервиса, которые доступны из внешнего мира по адресам: 1) /api/users 2) /api/tasks и чтобы сделать единую точку входа для клиентов (example.com/api/...), то тут нужен nginx по идее, верно? кстати, конфиг nginx в этом случае тоже будет выглядеть необычно - т.к. он не знает четких IP, на какие сервисы перенаправлять запросы или nginx тоже будет перенаправлять запросы на кластерные IP?

супер, @takama , @etkee спасибо за инфу! буду кодить тогда с использованием docker-compose последний вопрос: для связки API ендпоинтов используете nginx? например, есть 2 сервиса, которые доступны из внешнего мира по адресам: 1) /api/users 2) /api/tasks и чтобы сделать единую точку входа для клиентов (example.com/api/...), то тут нужен nginx по идее, верно? кстати, конфиг nginx в этом случае тоже будет выглядеть необычно - т.к. он не знает четких IP, на какие сервисы перенаправлять запросы или nginx тоже будет перенаправлять запросы на кластерные IP?

Конкретно у нас в проектах есть апи-прослойка, которая смотрит наружу и занимается только дерганьем остальных сервисов. Т.е. пришел запрос - прослойка отправляет токен на верификацию в менеджер пользователей, в случае успеха начинает оббивать другие сервисы, и, если нужно, мерджить сущности. У прослойки свой собственный API, который и является API всего приложения. Сама прослойка в кубе в таком случае была бы обычным сервисом, который смотрел бы наружу прямо или за nginx'ом/аналогом.

Мы для всего внешнего используем HAProxy

HAProxy нам дает и балансировку и High Availability и Failover

понял вариант с кастомным сервисом, который принимает запросы из внешнего мира и перенаправляет все во внутренние сервисы звучит очень разумно - плский с бубном вокруг конфигов nginx'а отваливаются

Мы для всего внешнего используем HAProxy

а как HAProxy узнает на какие внутренние сервисы переводить запросы?

там ведь тоже конфиг, как у nginx'а, с фиксированными айпишниками

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

В самом крайнем случае можно попробовать подцепить в pod confd или аналог и заставить его пересобирать конфигурацию конечного сервиса. Там те еще костыли получатся, но работать должно.

Каждый сервис может также легко реплициоваться, главное чтобы удовлетворял всем факторам. HAProxy настраивается по ACL - в которых куча всяких условий может быть отражена. Но в вашем случае скорее всего нужно будет либо применять еще nginx - либо как-то также заводить провайдера со своим API

а кто будет обновлять днс записи?) например: по внутреннему адресу 192.168.22.22 был доступен сервис и nginx туда корректно перенапрвлял по DNS записи: "service_users: 192.168.22.22" но сервис отвалился и рестартанул уже по адресу 192.168.22.23, а DNS запись осталась прежней получается тут должен быть кластерный IP с "умным балансировщиком", который сам обновляет DNS записи

За такими вещами HAProxy и следит с помощью health check, если сервис отвалился, он исключается из балансировки, пока не будет снова доступен

в случае с HAProxy Kubernetes и DNS не обязательны :)

За такими вещами HAProxy и следит с помощью health check, если сервис отвалился, он исключается из балансировки, пока не будет снова доступен

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

а кто будет обновлять днс записи?) например: по внутреннему адресу 192.168.22.22 был доступен сервис и nginx туда корректно перенапрвлял по DNS записи: "service_users: 192.168.22.22" но сервис отвалился и рестартанул уже по адресу 192.168.22.23, а DNS запись осталась прежней получается тут должен быть кластерный IP с "умным балансировщиком", который сам обновляет DNS записи

И nginx, и haproxy в конфиге позволяют указать время повторного резолва dns, т.е. это не один раз задал и все. Единственный косяк - nginx'у нужно зарезолвить dns при старте, иначе он не поднимется. Kube-dns или что там внутри кубернетеса заботится уже о том, чтобы dns-запись содержала актуальные айпишники, будь то один виртуальный айпи на сервис или куча айпишников сервиса в случае headless-сервиса

HAProxy то все равно должен ходить к etcd узнавать, какие сервисы не умерли а каждый сервис должен сообщать о себе в etcd, что он живой, верно?)

HAProxy то все равно должен ходить к etcd узнавать, какие сервисы не умерли а каждый сервис должен сообщать о себе в etcd, что он живой, верно?)

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

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

там можно просто проверят жив ли сервис по TCP, можно по HTTP опрос делать, да еще сравнивать результат - вариантов масса

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

я думал ввод нового сервиса в среду делается через etcd

Конечно, с помощью health check от HAProxy он определяет, что сервис жив и снова его включает в балансировку

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

зарезолвит днс еще через 10 секунд. если сервис не headless, то kube-dns обновит записи, соответствующие виртуальному айпи, там все на уровне iptables, и haproxy даже не заметит, что произошло

Похоже тут начали говорить уже о разных вещах :)

зарезолвит днс еще через 10 секунд. если сервис не headless, то kube-dns обновит записи, соответствующие виртуальному айпи, там все на уровне iptables, и haproxy даже не заметит, что произошло

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

Если хотите получить High Alailability и Failover не в контейнерах - то HAProxy достаточно одного. Если речь о контейнерах, то там полный набор включая Kubernetes, ETCD и HAProxy (Ingres)

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