давай на какой-нибудь pastbin и ссылку сюда

https://gist.github.com/vmakhaev/b0caef4361907cd733279823b2002d52

Кстати, про docker в swarm mode читали уже же?

https://habrahabr.ru/company/redmadrobot/blog/318866/

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

"С выходом Docker 1.12 у сторонников Kubernetes практически не осталось аргументов в пользу использования последнего"

фигасе наброс :)

да там комменты тоже набрасывают )

"С выходом Docker 1.12 у сторонников Kubernetes практически не осталось аргументов в пользу использования последнего"

чет в голосину

https://gist.github.com/vmakhaev/b0caef4361907cd733279823b2002d52

10.0.0.10 - это фиксированный адрес в GKE, (при дефолтных настройках) у меня он будет доступен там же?

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

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

о а че так можно? во я лошпен, а я каждый раз в dns айпишники обновляю :)

че за параметр?

10.0.0.10 - это ip kube-dns сервиса. можно вот так посмотреть: kubectl get svc --namespace=kube-system kube-dns

че за параметр?

apiVersion: v1 kind: Service metadata: name: ingress-forwarder spec: selector: service: ingress ports: - name: ingress protocol: TCP port: 80 targetPort: 80 loadBalancerIP: YARRRRRRR # <--------- type: LoadBalancer

10.0.0.10 - это ip kube-dns сервиса. можно вот так посмотреть: kubectl get svc --namespace=kube-system kube-dns

благодарю

то есть ты еще сервис перед ингрессом добавил? ок

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

хз )

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

фигасе пошло получилось, не хотел :))

в спеке у ингресса не вижу статичного айпи

что очень странно... такое ощущение что они хотят только вендорлок на aws и gke (смешная шутка получилась?)

"С выходом Docker 1.12 у сторонников Kubernetes практически не осталось аргументов в пользу использования последнего"

это религия. Причем скорее всего, автор статьи не работал с docker-dc или docker-swarm

Я 1.12 в альфе пробовал только

Потом о кубе узнал

Ребят, еще раз по поводу встречи. Я выдвигаюсь, всех жду там. Место: 19:00 в Чайхона №1 по адресу ул Тверская, 24 Мой телефон: +79854257677

а если кворума не будет как вы мастера сможете выбрать?

шутка :) фотки пришлите потом

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

тоже скоро выезжаю

Блин, а у меня завал((( не получится

выхожу, через 10-15 мин буду

На месте. Стол возле стены с кальянами. Кальян готовится. Подходите.

блин!!

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

Тоже на месте, сейчас приду

до скольки будете сидеть ?

@ivan4th @vmakhaev ?

Приходи. Через час все только соберутся, как показывает практика. Сидим обычно до 12.

мне из Зелика еще добираться. понял, спасибо

мне из Зелика еще добираться. понял, спасибо

ого, в зеленограде есть компании пользующие k8s

пока нет, но я с этим борюсь :)

а где работаешь, если не секрет?

http://clouddc.ru

а где у вас там внедрять k8s? в опенстек?)

не понял вопрос

куда внедрять kubernates хочешь? у вас же облака

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

куда внедрять kubernates хочешь? у вас же облака

Для начала сервисы внутренние(таск трекеры И так далее)

Далее опенстек внутри кубернетса :)

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

Неа

Неа

добавить?

Далее опенстек внутри кубернетса :)

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

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

Пока только я :)

Пока только я :)

если что, есть чатик по опенстку. @pro_openstack

я бы послушал о таких планах)

добавить?

Давай :)

попросили ещё раз сюда скинуть https://github.com/Mirantis/k8s-AppController

и это https://github.com/kubernetes-incubator/kargo

а че https://github.com/kubernetes/charts/tree/master/incubator/mongodb-replicaset из инкубатора не вынесли еще?

https://github.com/kubernetes/charts/pull/428 как обещал :)

https://github.com/kubernetes-incubator/cri-o

https://github.com/Mirantis/virtlet

https://github.com/kubernetes/community/tree/master/sig-on-prem

ссылки выше постились в процессе дискуссии в Чайхоне :)

хорошо вчера посидели. всем спасибо

Всем привет, пришел за советом.

Если вкратце: хочу разворачивать версии приложения (мультиконтейнерного) на разных сабдоменах. Есть мысль запускать каждую версию как отдельный сервис, при этом каждый контейнер будет отдельным подом. А вот как запрос по сабдомену пробросить на конкретный сервис и где в сервисе описать, какой сабдомен он слушает – с этим вообще непонятно. Буду рад услышать, в каком направлении копать

@yolkov заметка про Helm — https://hackernoon.com/the-missing-ci-cd-kubernetes-component-helm-package-manager-1fe002aac680#.21d0bc8hm

в частности см. --values и --set

спс

Если вкратце: хочу разворачивать версии приложения (мультиконтейнерного) на разных сабдоменах. Есть мысль запускать каждую версию как отдельный сервис, при этом каждый контейнер будет отдельным подом. А вот как запрос по сабдомену пробросить на конкретный сервис и где в сервисе описать, какой сабдомен он слушает – с этим вообще непонятно. Буду рад услышать, в каком направлении копать

просто балансировщик поставить, который разбирает хост и скидывает на соответствующий неймспейс или сервис, составляя имя этого неймспейса или сервиса на лету я буквально вчера сюда же за советом по подобной штуке обращался, у меня просто стоит nginx, который ловит <build>.<project>.<environment>.ci.company.name и перебрасывает на ingress.<project>-<environment>-<build>.svc.cluster.local

Если вкратце: хочу разворачивать версии приложения (мультиконтейнерного) на разных сабдоменах. Есть мысль запускать каждую версию как отдельный сервис, при этом каждый контейнер будет отдельным подом. А вот как запрос по сабдомену пробросить на конкретный сервис и где в сервисе описать, какой сабдомен он слушает – с этим вообще непонятно. Буду рад услышать, в каком направлении копать

По идее консул должен в этом помочь, но я не уверен

Раз есть традиция. Доброе утро! Или день > Какой у вас проект или где работаете? Проекта нет, k8s только изучаю > В чём вы специалист? Так, админю по-немножку > Чем можете быть интересны или полезны сообществу? Да я ж пока и не знаю ничего. Что вот так сразу? >Чем интересно сообщество вам? Опытом с k8s. Но я глупыми вопросами не достаю > Откуда вы? Москва > Как узнали про группу? https://github.com/goq/telegram-list/blob/master/README.md - вот отсюда > В сообщении нужно указать тэг #whois

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

С таким подходом, rm -rf / и спокойно спать

Напахнуло мудростью. Сказать то чо хотел ?

Если не хочешь заморочек, то попробуй hashicorp Nomad

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

нет, вполне нормальный. kubeadm в помощь

И то, не помню, решит ли все.

хз, принято ли тут, но хочется высказать благодарность и респект @DenisIzmaylov за часть из тех материалов, которые отсматриваю на youtube крайнюю неделю. ну и всем привет, спасибо что когда-то добавили, начали созревать вопросы, правда, скорее, немного философского толка: а много кто здесь реально перешел на coreos подходы, начал использовать потому что знал конкретно чего именно хочет от платформы, а не "наткнулся и изучил, оказалось подходящим, а там привыкнем", ну и какие масштабы у реальных боевых штук (только не больших корпоративных облаках, где куча людей могут этим заниматься, а, скорее, о выборе для использования в проектах которые имеют выше среднего вычислительные нагрузки (по ощущениям, т.е., без цифр), но саппортится это все будет совсем небольшим количеством людей. ну и верно ли будет предположить что среди вас есть те кто коммитил во что-нибудь из частей coreos и его насадок?

Мимими :) Всем вполный вперёд!

Мимими :) Всем вполный вперёд!

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

а теперь к вопросам: в конце первого сообщения философские вопросы почему-то интересны. 1. глобальный кэш etcd - ощущение, что к нему ни у кого нет критики вообще ни у кого, это нравится, но настораживает. хочется про траблы и "грабли" 2. недоработки, ограничения внутренних днс, что там с srv поддоменами, нескольким a записям или можно ли подружить с внешними днс (роут58, например) 3. вычислительно все красиво и здорово, но что курить для раздумления правил фэн-шуйного хранения данных (ок, шардинг, реплики...), а какие есть coreos ориентированые идеи для распределенных fs, хранилищах ключей и внутрикластерной CA, например (были кейсы, когда микросервисам внутри системы нельзя было доверять друг-другу и вообще все где фигурируют финансы нужно было подписывать, а в ряде случаев, шифровать при общении с кем угодно, навернякак кто-то это уже продумал). 4. какие реальные ощущения от скорости реакции кластера на то, что происходит с его содержимым (образно, если я запущу вагрантовый вариант coreos на десктопе, проброшу все порты к нему, добавлю в кластер и решу все сервисы готовить и обкатывать на локальной ноде кластера, а в продакшн оно улетает не по команде, а просто ради ресурсов и само же "множится до нужного количества и расселяется" после клонирования сервиса/пачки сервисов с признаками продакшн хотелок. странный кейс, но идею "ждать от кластера того что бы он продолжал себя вести идеально" описывает корректно, думаю.) 5. если верно понимаю, то у нод порты для "общения между собой" обычно торчат наружу и можно повынимать кучу разных конфигов просто зная что спрашивать (или мне показалось?)

6. есть способ окончательного раздупления подходов (не логически, а вот это ментальное противоборство, хз, у меня дискомфорт почему-то некий, то ли с непривычки, но пора бы уже, то ли потому что смотрю на этот "склад" как-то близко, но не совсем так, как положено джентельмену) формата 6*2*4 * 3env_ver = количество коробок

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

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

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

как-то так.