но опять же - смотря что делаешь... иногда это может быть критично

посмотри на это с другой стороны - отрубилась у тебя сеть на секунду - чьи это уже проблемы7

в этом случае реконнект сообщение - норм

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

чет мне кажется прокся от разрыва в середине сообщения не спасет

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

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

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

чет мне кажется прокся от разрыва в середине сообщения не спасет

спасет tcp и подтверждение доставки

неа

покоцанные данные не дойдут а сервер чуть что перепошлет)

если прям очень критично

ну короч всякого можно придумать

так один пакет дошел, а конец сообщения во втором

так один пакет дошел, а конец сообщения во втором

я не про подтверждение доставки tcp пакетов говорю а подтверждение доставки сообщений между клиентом и сервером

если у тебя по какой-то причине это критично - у тебя что-то такое будет)

ну а если нет - сам себе злой буратино

думаю что тут как несколько уровней security - лишний не помешает

думаю что тут как несколько уровней security - лишний не помешает

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

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

ну кому как

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

потому что это время а время это деньги....

и тебе надо что бы затраты перекрывались профитом

ну короч, это все сводится к "it depends"

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

но только с точки зрения рисков это решение не надежно)

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

я не про подтверждение доставки tcp пакетов говорю а подтверждение доставки сообщений между клиентом и сервером

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

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

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

нет, не получится

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

Нет, более того получишь паразитный траффик

ребята а не подскажите как обновить k8s cluster без. даунтайма

обновить версию k8s?

обновить версию k8s?

да у меня сейчас версия 1.5.6

а kops умеет на существующий VPC (в AWS) деплоить?

да

https://github.com/kubernetes/kops/blob/master/docs/run_in_existing_vpc.md

спасибо

да у меня сейчас версия 1.5.6

апгрейд минорной версии или мажорной? в случае мажорной не всегда возможно без даунтайма, нужно читать release notes. Если возможно то сначала нужно обновить мастер ноды потом воркеры, потом обновить apiserver и прочие системные поды до версий в этой мажорной версии. На время пока будет все обновляться очень желательно стопнуть все деплойменты и т.п. активности которые могут менять состояние кластера (хотя бы на время апдейта мастер нод). Ну и тут еще куча вариантов, например kube-adm и kops умеют обновлять сами мажорные версии без даунтайма и сами же обновят версии системных подов. А вот например kube-aws обновит версию кубернетеса но в итоге ты получишь два набора системных подов и надо будет вручную почистить старые версии (ну и могут пока 2 версии паралельно бежит какие-то баги вылезти)

апгрейд минорной версии или мажорной? в случае мажорной не всегда возможно без даунтайма, нужно читать release notes. Если возможно то сначала нужно обновить мастер ноды потом воркеры, потом обновить apiserver и прочие системные поды до версий в этой мажорной версии. На время пока будет все обновляться очень желательно стопнуть все деплойменты и т.п. активности которые могут менять состояние кластера (хотя бы на время апдейта мастер нод). Ну и тут еще куча вариантов, например kube-adm и kops умеют обновлять сами мажорные версии без даунтайма и сами же обновят версии системных подов. А вот например kube-aws обновит версию кубернетеса но в итоге ты получишь два набора системных подов и надо будет вручную почистить старые версии (ну и могут пока 2 версии паралельно бежит какие-то баги вылезти)

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

а лучше хелма же всё равно ничего нет сейчас?

и если так, то хелмом жить с несколькими кластерами - норм?

а лучше хелма же всё равно ничего нет сейчас?

Вы проводили сравнение с другими системами и хелм победил?

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

и точно, вот же он

если б я делал сравнение, то я бы не спрашивал

Вы проводили сравнение с другими системами и хелм победил?

в чистом кубернетесе вроде и вариантов других нет

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

читаю kops high availability доку и никак не пойму, что делать с этим противоречием (если я все верно понял): Kops has experimental support for running multiple masters in the same AZ, but it should be used carefully. If we create 2 (or more) masters in the same AZ, then failure of the AZ will likely cause etcd to lose quorum and stop operating (with 3 nodes). Running in the same AZ therefore increases the risk of cluster disruption, though it can be a valid scenario, particularly if combined with federation. и двумя абзацами ниже: Notes (Best Practice) In regions with 2 Availability Zones, deploy the 3 masters in one zone and the nodes can be distributed between the 2 zones. This can be done by specifying the flags: --master-count=3 --master-zones=$MASTER_ZONE --zones=$NODE_ZONES у кого-то был опыт с двумя зонами и копсом, в чем соль?

в чистом кубернетесе вроде и вариантов других нет

появляются тулзы на jsonnet: kapitan, ksonnet

Нативно манипулировать json , а не текстом и ожидать валидный yaml это очень здорово и окрыляет

то есть Json лучше yaml'a?

вот это новости

то есть Json лучше yaml'a?

Вы увидели не то, что написано :)

вероятно я не так понял фразу про "здорово и окрыляет"

Нет, вы не так поняли "нативно манипулировать json" :)

появляются тулзы на jsonnet: kapitan, ksonnet

Хмм, я ожидал что-то вроде "blue-green изкаропки"

Нет, вы не так поняли "нативно манипулировать json" :)

тогда уж всю фразу не так понял

Да пока проблема просто blue описать :)

читаю kops high availability доку и никак не пойму, что делать с этим противоречием (если я все верно понял): Kops has experimental support for running multiple masters in the same AZ, but it should be used carefully. If we create 2 (or more) masters in the same AZ, then failure of the AZ will likely cause etcd to lose quorum and stop operating (with 3 nodes). Running in the same AZ therefore increases the risk of cluster disruption, though it can be a valid scenario, particularly if combined with federation. и двумя абзацами ниже: Notes (Best Practice) In regions with 2 Availability Zones, deploy the 3 masters in one zone and the nodes can be distributed between the 2 zones. This can be done by specifying the flags: --master-count=3 --master-zones=$MASTER_ZONE --zones=$NODE_ZONES у кого-то был опыт с двумя зонами и копсом, в чем соль?

3 мастера нужны чтобы не было split brain ситуации и чтобы при восстановлении коннекта между 3 мастерами был кворум "кто главный"

читаю kops high availability доку и никак не пойму, что делать с этим противоречием (если я все верно понял): Kops has experimental support for running multiple masters in the same AZ, but it should be used carefully. If we create 2 (or more) masters in the same AZ, then failure of the AZ will likely cause etcd to lose quorum and stop operating (with 3 nodes). Running in the same AZ therefore increases the risk of cluster disruption, though it can be a valid scenario, particularly if combined with federation. и двумя абзацами ниже: Notes (Best Practice) In regions with 2 Availability Zones, deploy the 3 masters in one zone and the nodes can be distributed between the 2 zones. This can be done by specifying the flags: --master-count=3 --master-zones=$MASTER_ZONE --zones=$NODE_ZONES у кого-то был опыт с двумя зонами и копсом, в чем соль?

Это скорее всего не обновили документацию. По факту делаешь instance group на 3 az и все норм раскидывает

Ну и 3 разных ig для мастеров оно само сделает

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

всех мастеров в одну az или 2 мастера в одну az, а 3-го в другую?

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

делать три мастера. Потому что два мастера делать нет смысла

всех мастеров в одну az или 2 мастера в одну az, а 3-го в другую?

второй вариант

вот это противоречит абзацу Best Practice

вот это противоречит абзацу Best Practice

этот абзац про случай с тремя az, это же очевидно

нет, это неочевидно, мало того, там цифра 2 явно обозначена

и эта цифра относится к .. ?

количеству AZ?

In regions with 2 Availability Zones, deploy the 3 masters in one zone and the nodes can be distributed between the 2 zones.

а, понял

недочитал

но это странно. Я бы распределил 2 и 1

Проверь что под может изнутри иметь доступ до этих внутренних днсов

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

так вот, я это понимаю так: "Если у вас только две зоны, то мастерам в любом случае хана, если одна из зон завалится. Поэтому положите их всех в одну зону, так хотя бы 50% у вас есть."

не в любом, только если завалится зона с большинством мастеров. А советуют в одну наверное затем, чтоб network latency меньше был

а, ну то есть те же 50%, поэтому нет смысла размазывать, ок, понял, спасибо

Друзья, Мы рады анонсировать очередную нашу встречу 6 марта в 19:00. На этот раз компания "Dino Systems" порадует нас докладами о разработке приложений в Kubernetes. 19:00 - 20:00: Kubernetes - от идеи до продукта. Спикер: Иван Анисимов «Реальный пример развития проекта прошедшего от фазы идеи до крайне успешного продукта менее чем за 2 года. Я покажу, как мы перешли с железных серверов на Mesos, с Mesos на Self-hosted Kubernetes и как в самом конце мы освоили полностью облачный GKE. В ходе доклада я рассмотрю наши успехи и неудачи и то, как росло наше понимание работы с Kubernetes на протяжении этих 2-х лет.» 20:00 - 20:30: Пицца, чай кофе. 20:30 - 21:30: Kubernetes и микросервисы. Спикер: Иван Анисимов «Один из лучших способов развернуть свой продукт на Kubernetes - это использование микросервисов. Этот семинар про то, какими именно должны быть эти микросервисы, как они должны быть настроены и развернуты. Мы обсудим использование gRPC и Protobuf, поговорим о Ingress и балансировке нагрузки и о том, как можно развернуть множество разных типов микросервисов вместе». https://www.meetup.com/Kubernetes-Novosibirsk/events/248011940/

начать ходить на митапы чтоли

но это странно. Я бы распределил 2 и 1

да толку-то, один всё равно работать не будет