RK
у нас k8s на своём железе есть, но мы выбрали ECS для прод-сервисов потому что ECS намного проще в operational work, при этом у EKS есть некоторые отставания от современного кубера, которые наши спецы по куберу назвали трагедией 🙂
Size: a a a
2020 December 23
SB
Я к тому что можете рассказать почему я как девелопер должен выбрать и изучить ваше решение а не HELM для разворачивания.
SB
Ruslan Kosolapov
у нас k8s на своём железе есть, но мы выбрали ECS для прод-сервисов потому что ECS намного проще в operational work, при этом у EKS есть некоторые отставания от современного кубера, которые наши спецы по куберу назвали трагедией 🙂
спасибо за информацию
стало понятнее с контекстом как и для чего вам это дело
стало понятнее с контекстом как и для чего вам это дело
RK
про helm хороший вопрос на самом деле, ибо я могу ответить за нас и за тех, с кем я уже разговаривал на эту тему и кто выбрал ECS, но вот как раз тех людей, которые осознанно выбрали EKS и helm я не так много видел, может получиться интересный разговор 🙂
SB
Ruslan Kosolapov
у нас k8s на своём железе есть, но мы выбрали ECS для прод-сервисов потому что ECS намного проще в operational work, при этом у EKS есть некоторые отставания от современного кубера, которые наши спецы по куберу назвали трагедией 🙂
кстати ради интереса а какие фичи есть у ECS которые не умеет EKS?
AS
Ну да, год назад EKS отжигал. Там и версия кубера еще не поддерживала норм volumes в multy AZ и создавала volume в AZ где попало и потом pod не цеплял потому что был на ноде в другой AZ.
И поддержка ALB как-то сыровато выглядела. В NLB сам ловил баг что поменялось число нод и слетали автоматические записи в security groups для него и трафик переставал входить, а чинить это быстро никто не собирался.
И поддержка ALB как-то сыровато выглядела. В NLB сам ловил баг что поменялось число нод и слетали автоматические записи в security groups для него и трафик переставал входить, а чинить это быстро никто не собирался.
RK
я могу попробовать найти записи, почему конкретно мы не пошли в EKS, там были прямо конкретные проблемы, но я уже забыл их 🙂
SB
Ну да, год назад EKS отжигал. Там и версия кубера еще не поддерживала норм volumes в multy AZ и создавала volume в AZ где попало и потом pod не цеплял потому что был на ноде в другой AZ.
И поддержка ALB как-то сыровато выглядела. В NLB сам ловил баг что поменялось число нод и слетали автоматические записи в security groups для него и трафик переставал входить, а чинить это быстро никто не собирался.
И поддержка ALB как-то сыровато выглядела. В NLB сам ловил баг что поменялось число нод и слетали автоматические записи в security groups для него и трафик переставал входить, а чинить это быстро никто не собирался.
C волюмами до сих пор так
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
AS
C волюмами до сих пор так
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Баг с NLB сейчас уже починен конечно. Просто от репорта в гитхаб Амазона до фикс немало месяцев было. И только в следующей вышедшей версии куба починили. Тут конечно можно понять и простить, вроде задержки версий в основном из за сертификации, где-то в их докладе слышал
AS
C волюмами до сих пор так
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
С volumes фича давно есть. Вот этого нам не хватало
https://kubernetes.io/blog/2018/10/11/topology-aware-volume-provisioning-in-kubernetes/
https://kubernetes.io/blog/2018/10/11/topology-aware-volume-provisioning-in-kubernetes/
DZ
Все внутренние инфраструктурные решения, которые пытались продавать наружу и которые я видел были, кхм, странными, потому-что внутри себя несли те подходы, костыли и прочее легаси, которые были в этой компании или которыми эта компания обрастала по ходу своего развития.
DZ
Новичкам вся эта автоматизация не нужна, у них и так всё просто. Кому нужна - те уже и сами сделали.
DZ
C волюмами до сих пор так
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Надо просто изолировать поды которые используют эти волюмы на нодах в соответсвуюзих зонах
NLB у меня создается кубером через анотации
пока проблем не было
Чет не верится, простите. WaitForFirstConsumer у сторадж класса точно стоит?
DZ
Короче хотелось бы реальную историю почему в 2021 году юзать ecs а не устаревшие байки первых дней eks а то и кубера 16 года
SB
Dmytro Zavalkin
Чет не верится, простите. WaitForFirstConsumer у сторадж класса точно стоит?
как это поможет?
Это ограниение EC2 что инстанс должен быть в той же зоне для доступа к волюму амазоновскому ebs_volume
к нему при создании терафформом надо обяазательно оную зону указывать
И если куб запустит ПОД которому надо этот волюм на ноде из другой зоны то получить доступ к ваолюму не получится.
Поэтому мне приходится привязывать поды к нодам в специфичной зоне.
Это ограниение EC2 что инстанс должен быть в той же зоне для доступа к волюму амазоновскому ebs_volume
к нему при создании терафформом надо обяазательно оную зону указывать
И если куб запустит ПОД которому надо этот волюм на ноде из другой зоны то получить доступ к ваолюму не получится.
Поэтому мне приходится привязывать поды к нодам в специфичной зоне.
LB
как это поможет?
Это ограниение EC2 что инстанс должен быть в той же зоне для доступа к волюму амазоновскому ebs_volume
к нему при создании терафформом надо обяазательно оную зону указывать
И если куб запустит ПОД которому надо этот волюм на ноде из другой зоны то получить доступ к ваолюму не получится.
Поэтому мне приходится привязывать поды к нодам в специфичной зоне.
Это ограниение EC2 что инстанс должен быть в той же зоне для доступа к волюму амазоновскому ebs_volume
к нему при создании терафформом надо обяазательно оную зону указывать
И если куб запустит ПОД которому надо этот волюм на ноде из другой зоны то получить доступ к ваолюму не получится.
Поэтому мне приходится привязывать поды к нодам в специфичной зоне.
Куб видит, что под использует вольюм и не запустит его на ноде в другой зоне. Раньше была проблема в том, что вольюмы и поды создавались независимо и при первом запуске пода вольюм под него мог быть создан в другой зоне, сейчас если поставить WaitForFirstConsumer на storage class, то сначала поду назначается нода, потом в зоне этой ноды создаётся вольюм
SB
Куб видит, что под использует вольюм и не запустит его на ноде в другой зоне. Раньше была проблема в том, что вольюмы и поды создавались независимо и при первом запуске пода вольюм под него мог быть создан в другой зоне, сейчас если поставить WaitForFirstConsumer на storage class, то сначала поду назначается нода, потом в зоне этой ноды создаётся вольюм
я создаю волюм терраформом и контролирую его жизненый цикл
куб не создает его а пользуется тем что дают
Он поидее даже не знает о том в какой зоне этот волюм (это слишком специфичное для aws знание)
Это kubernetes_persistent_volume для долговременного хренения
куб не создает его а пользуется тем что дают
Он поидее даже не знает о том в какой зоне этот волюм (это слишком специфичное для aws знание)
Это kubernetes_persistent_volume для долговременного хренения
LB
я создаю волюм терраформом и контролирую его жизненый цикл
куб не создает его а пользуется тем что дают
Он поидее даже не знает о том в какой зоне этот волюм (это слишком специфичное для aws знание)
Это kubernetes_persistent_volume для долговременного хренения
куб не создает его а пользуется тем что дают
Он поидее даже не знает о том в какой зоне этот волюм (это слишком специфичное для aws знание)
Это kubernetes_persistent_volume для долговременного хренения
если я правильно помню, то шедулеру нужны аннтоации на вольюме. Попробуйте создать pvc, подключить в под и посмотреть какие будут аннотации на получившемся pv, затем повторить их на вольюме, который создаёте сами
SB
если я правильно помню, то шедулеру нужны аннтоации на вольюме. Попробуйте создать pvc, подключить в под и посмотреть какие будут аннотации на получившемся pv, затем повторить их на вольюме, который создаёте сами
спасибо попробую