вкратце: создает ветку vanilla/stack куда просто вываливается дефолтный конфиг из kube-aws, затем на основе нее создается tailored/stack где все правки/дополнения/улучшения общие для всех кластеров, из них создается defaults/<AWS-account> которые по сути tailored/stack с заполненными полями вроде vpc-id, subnet id и т.д.,затем из них уже создается kluster/<kluster-name> где финальный конфиг конкретного кластера. таким образом изменения можно вносить на всех уровнях, "релизить" кластеры по будто это код ну и подтягивать всю свежесть из новых версий kube-aws относительно легко, без ручного переноса кастомизаций

десятком кластеров таким методом управлять получается довольно просто. при росте >20-30 кластеров наверно нужно будет дальше автоматизировать роботами

кто как разворачивает кубер?

coreos ignition конфиги. Шаблонизируем через Ansible. За основу брали coreos matchbox, но сильно всё переделано.

то есть вы скопировали kargo?

kargo умеет AWS Autoscaling groups?

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

если вы не планируете расширять инсталляцию - нет.

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

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

Олег, у вас же там девопсы должны быть?

у меня я девопс )

на чем san разворачиваете?

на чем san разворачиваете?

у нас ceph. решение неидеальное, но из того, что можно поднять в BMR я лучше не нашел

Ребята подскажите в чем может быть проблема, у нас периодически ingress начинает на все запросы отдавать 503, в логах повляется надписи наподобие service default/company_1 does not have any active endpoints service default/company_2 does not have any active endpoints service default/company_3 does not have any active endpoints

так происходит минут 5 потом все восстанавливается

т.е. такое ощущение будто сервисы массово теряют endpoint

при этом поды не пересоздаются

а в логах кубелета есть что-нибудь интересное?

а в логах кубелета есть что-нибудь интересное?

не ничего

Изучаю куб. Поднимаю тестовое приложение, типа вебсервера, который отображает на странице hostname (имя пода, в котором поднят контейнер). Создал нэймспейс, сервис и деплоймент. По умолчанию под не поднимается на мастер-ноде (10.0.0.10), но поднимается на node1 (10.0.0.11). Если я с node1 выполню curl http://127.0.0.1:30001, то всё хорошо - показывается hostname. Если я с мастер-ноды выполню curl http://127.0.0.1:30001 (порт этот есть в списке открытых) - у меня таймаут соединения. В связи с этим вопрос: что мне ещё нужно предпринять, чтобы схема заработала? Реализовать хочу такую схему: допустим я поднял несколько реплик на разных нодах - что-то должно балансировать запросы между ними. Пускай это делает nginx. Сейчас я вижу только то, что мне вручную придётся править конфиг энджинкса и прописывать там ноды. Может это как-то по другому делается?

Ну и второе: где и что нужно разрешить, чтобы я с мастер-ноды мог выполнить curl http://10.0.0.11:30001? Сейчас у меня тоже таймаут, если я пытаюсь это сделать. Думаю, это потому, что каких-то прав нехватает...

А вот такой вопрос - чем лучше сделать простые (301/302) редиректы, если их нужно много и не хочется билдить для этого новые имаджи? Чтоб при этом можно было регэкспы задавать, а не просто мап

Ну и второе: где и что нужно разрешить, чтобы я с мастер-ноды мог выполнить curl http://10.0.0.11:30001? Сейчас у меня тоже таймаут, если я пытаюсь это сделать. Думаю, это потому, что каких-то прав нехватает...

https://kubernetes.io/docs/concepts/services-networking/service/ https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport https://kubernetes.io/docs/concepts/services-networking/ingress/

Привет всем. На работе внедряется Kubernetes. Где можно подробно и с примерами почитать? В доке? Или лучше есть? Может видео?

а вы не пробовали самостоятельно искать информацию?

а то такой вопрос выглядит даже не как хамство

для начала можно взять официальный док и курс на юдасити

lmgtfy

А вот такой вопрос - чем лучше сделать простые (301/302) редиректы, если их нужно много и не хочется билдить для этого новые имаджи? Чтоб при этом можно было регэкспы задавать, а не просто мап

Гляньте внутри nginx-ingress, может там есть какие-нибудь хуки специально под это дедл

Гляньте внутри nginx-ingress, может там есть какие-нибудь хуки специально под это дедл

Там была опция, но как-то не очень красивое решение получается особенно если gce ingress тоже использовать

Ребят, можно вопрос?

Мне надо ноду развернуть, чтобы было, как здесь infura.io

https://github.com/ethereumproject/etherkube

может кто-то помочь с этим?

Помочь - сделать?

вот мне тоже интересно стало

Коллеги, правильно ли я понимаю схему кластеризации мастер-нод: каждый из процессов (etcd, kube-apiserver , kube-dns) должен быть запущен как docker контейнер. Каждый процесс объявить cервисом, с проброшенным наружу IP, ну и настроить Replication Controllers. Соответственно снаружи запросы на них будут поступать через какой-нибудь балансировщик (тот же nginx+, например). Собственно требуется повысить отказоустойчиость самого кластера, чтобы при падении мастера (где у меня крутится апи и прочее), кластер оставался доступным. Может я чего не так понимаю ? Буду благодарен, если кто подскажет, как лучше всего это должно быть спроектировано :)

etcd это отдельная песня.запускаете их нечетное количество >2 и все

матсер ноды: на каждой apiserver, scheduller , controller (ну и kubelet но он везде кроме etcd)

apiserver они stateless, так что все просто работает. scheduller и controller manager умеют leader election если передать соответствующий флаг. тогда они между собой через etсd будут договариваться кто из них главный, а остальные на подхвате

Всем привет. Подскажите что такое Deployments в контексте Kubernetes?

Какие вопросы возникли после прочтения оф.доки?

"(etcd, kube-apiserver , kube-dns) должен быть запущен как docker контейнер. " можно и в качестве бинарника.

православенее в докере

бинари тоже работают

Спасибо за ответы!

православенее в докере

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

С резервированием

ахха

Всем привет. Подскажите что такое Deployments в контексте Kubernetes?

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

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

ясно. получается к deployment можно привязать автоматическое обновление?

etcd это отдельная песня.запускаете их нечетное количество >2 и все

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

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

НУ почти https://coreos.com/etcd/docs/latest/v2/clustering.html

оп,спасибо! Пошел изучать :)

https://coreos.com/etcd/docs/latest/op-guide/clustering.html подозреваю что для третьей версии это

ясно. получается к deployment можно привязать автоматическое обновление?

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

обновляете == заливаете новый yaml

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

etcd-wrapper работает из коробки, всё что нужно задать - ETCD_INITIAL_CLUSTER или что-то такое

есть кто работает с разной оркестрацией? docker swarm mode сильно отстаёт от кубера по функционалу?

Ребят, пытаюсь продумать как сделать правильно, но не получается с собой даже договориться. Подскажите, пожалуйста. Есть сервис, который из себя представляет бинарь на go, общающийся с redis в качестве хранилки. Допустым есть несколько нод в кластере kubernetes (предположим 4). Хочется размножить на эти ноды данный сервис. С размножением go-шного бинарника в контейнере никаких проблем нет, делаем replicas 4 и забываем. Как быть с редисом я не совсем понимаю, а конкретно - с консистентностью данных. Можно на каждой ноде сделать вольюм, который будет монтироваться по сети, но мне кажется что это костыль. Может кто сталкивался с подобным, подскажите добрым словом.

вам нужно сменить хранилище. я не шучу.

Ребят, пытаюсь продумать как сделать правильно, но не получается с собой даже договориться. Подскажите, пожалуйста. Есть сервис, который из себя представляет бинарь на go, общающийся с redis в качестве хранилки. Допустым есть несколько нод в кластере kubernetes (предположим 4). Хочется размножить на эти ноды данный сервис. С размножением go-шного бинарника в контейнере никаких проблем нет, делаем replicas 4 и забываем. Как быть с редисом я не совсем понимаю, а конкретно - с консистентностью данных. Можно на каждой ноде сделать вольюм, который будет монтироваться по сети, но мне кажется что это костыль. Может кто сталкивался с подобным, подскажите добрым словом.

Кажется мне, проблема твоя вне плоскости кубера

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

ERROR: S client not available

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

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

вам нужно сменить хранилище. я не шучу.

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

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

редис для данных плохая затея

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

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

да можно тарантул взять даже? вопрос был именно о редисе)

спасибо, ребят)

да можно тарантул взять даже? вопрос был именно о редисе)

https://github.com/kubernetes/contrib/tree/master/pets/redis

оп,спасибо! Пошел изучать :)

https://kubernetes.io/docs/admin/high-availability/

Ещё чуток инфы. Вообще на офф сайте очень много интеренсого написано...

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

redis умеет кластер нативно

redis умеет кластер нативно

Да я ему даже готовый конфиг скинул, но тут вопрос в целесообразности

редис не нужен ?

Using Projected volumes | Kubernetes https://kubernetes.io/docs/tasks/configure-pod-container/projected-volume/

> We are excited to announce that we are working in partnership with both Google and IBM to bring Envoy to Kubernetes. https://eng.lyft.com/envoy-7-months-later-41986c2fd443 https://news.ycombinator.com/item?id=14194026

> We are excited to announce that we are working in partnership with both Google and IBM to bring Envoy to Kubernetes. https://eng.lyft.com/envoy-7-months-later-41986c2fd443 https://news.ycombinator.com/item?id=14194026

Это ещё один линкерд?

Это ещё один линкерд?

Видимо, предпочитаемый гуглом.

Возможно плюсы им ближе скалы

"linkerd’s memory and CPU requirements are significantly higher than Envoy’s. In contrast to Envoy, linkerd provides a minimalist configuration language, and explicitly does not support hot reloads, relying instead on dynamic provisioning and service abstractions." Особенно если память не бесплатная

а кто-то использует подобный линкерд софт или сам линкерд?

НУ почти https://coreos.com/etcd/docs/latest/v2/clustering.html

v2 уже нет в 1.6, используйте мануалы для v3

v2 уже нет в 1.6, используйте мануалы для v3

как это? всё есть :) 1.6 умеет общаться с v2

Помнится была ремарка на офф сайте, что лучше оставаться на v2

etcd v3 дефолтный в 1.6, обратная совместимость с v2 есть, но v3 - основной

Помнится была ремарка на офф сайте, что лучше оставаться на v2

где?

не было такого

мы готовили release notes, и добавили это - https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#warning-etcd-backup-strongly-recommended