Наш опыт с Kubernetes в небольших проектах (Флант, RootConf 2017)
ฝัง
- เผยแพร่เมื่อ 1 ต.ค. 2024
- Доклад Дмитрия Столярова, технического директора компании «Флант» (flant.ru/), на конференции RootConf, проходившей в рамках фестиваля РИТ++ 2017 (6 июня 2017 г.). Посвящён устройству и основным возможностями Kubernetes и практике использования этой контейнерной системы в небольших проектах..
* Текстовый обзор доклада: habrahabr.ru/c...
* Презентация: speakerdeck.co...
* Анонс доклада на сайте конференции: rootconf.ru/201...
P.S. Мы всегда рады новым инженерам! Подробности см. на job.flant.ru/
Ничего себе, так доступно , но при этом в деталях! Потрясающий доклад
Дмитрий, смотрю ваши выступления где только можно. Насколько сильно они мне помогают в работе и обучении, я даже не могу передать. Спасибо Вам огромное.
Монументально, без воды, огромное спасибо за доклад!
Отличный доклад. Как жаль что его не было год назад. Убил кучу времени чтобы со всем этим разобраться.
Хороший доклад. Сервайс, эс э кодэ немного режут слух
Энвёйрамент
Мне кажется это лучшее объяснение про кубернетис
Да, остановись ты! Все.... буэээээ ... меня укачало (но пальчик вверх)
Невероятный доклад! Спасибо огромное
Хотел рассказать про опыт, в итоге кратко и внятно рассказал про абстракции и архитектуру кубера:)
Очень полезный и ёмкий доклад, спасибо!
КубернетЭс?
Ну почему толковые чуваки в Рунете так забивают на свой английский?
Отличный доклад!
Какие 4 команды для логирования и метрик)?
Лучший доклад, который слушал, спасибо!!!!!
не понял по поводу mysql, уже давно используем master master wsrep cluster из mariadb. зачем master - slave slave ? не ужели не пробовали нормальный кластер поднять базы? замечетельно работает даже на разнесенных по разным дц с 200мб сеткой как раз для малых проектов. для больших проектов конечно нужна как и для ceph уже 10gb сетка.
Интересно, как сейчас выглядит Kubernetes VS Docker Swarm
Спасибо. А то, читал серию статей на хабре (habrahabr.ru/post/262397/) и комменты, статья старая, но в комментах была обозначена тенденция на перекрытие функционала кубера нативными докер-решениями. Вот и хотел узнать, как сейчас дела обстоят )
Современные тенденции таковы, что Kubernetes становится фаворитом у большинства, но всё может зависеть от конкретных потребностей, т.к. с функциональной точки зрения это больше основа для PaaS, чем готовая PaaS (о последнем мы писали у себя: habrahabr.ru/company/flant/blog/327338/).
swarm - более монолитный, поломается что то, фиг поймешь где
Имхо, для мелких проектов кубер избыточен. Сайтик задеплоить проще в сварме. Из коробки есть Service с балансировщиком и Service Discovery. Плюс что это всё в нативном докере и не надо огород с мастерами кубера городить.
Отличный доклад! Четко и по существу! Так держать!
Офигенный доклад
Спасибо, действительно хороший доклад. Сидел и конспектировал многие моменты)
Отличный доклад! Спасибо! До этого читал статьи, не узнал и десятой части того, о чем узнал из доклада Дмитрия.
Дмитрий, огромное спасибо
Все четко и в тему!!! Спасибо за доклад!
"Сервайсы" - это как "тортЫ" или "звОнить" (((
Очень крутой начало презентации с быстрыми слайдами.
Только, уважаемый, научитесь произносить слово service - режет слух.
Замечание передано, спасибо! :-)
Спасибо за ваш контент! сжато, четко, по делу
Сервайс шедулер:). Доклад интересный. Очень круто.
Отличный доклад, вот только если правильно собрать инфраструктуру на том же AWS, там не должно быть проблем с перелинковкой фронта, бэка и т.д. То есть, по сути, это все та же модель "простой" инфраструктуры и функционал автоматического масштабирования везде.
То есть если есть такие крутые сервисы как SQS, ASG, RDS и так далее вообще нет никаких проблем связываться компоненты друг с другом.
что стоило выяснить, как произносится слово "service" перед докладом?
Все так и случилось, только вместо depp теперь werf :)
Отличный доклад, спасибо!
Отличный доклад, спасибо!
у nginx могут кончиться воркеры, когда отдача файлов с NFS и хранилка падает - каждый воркер идёт за файлом, ловит (un)interraptable sleep и.. всё. Даже с таймаутом 10с и 100 воркерами уже на 10 людях это перестаёт работать.
Спасибо, супер, очень доходчиво.
@Флант снаружи должен быть ingress или HAProxy?
Сильно.Осталос только во всем этом разобраться :)
Спасибо! очень полезно.
Отличный доклад! Большое спасибо!
Спасибо, отличный доклад
Доклад огонь.
Немного сложно стало его серьезно смотреть, когда начались "шедулеры" и "сервайсы".
@choleavv ему типа произношение не понравилось. Коренной англичанин видимо
Спасибо за доклад
Доклад классный, но почему у Дмитрия Столярова голова чистая?
Весь ок на микросервисах! Цирк)))
шикарно))
Если у меня на работе дикий монолит и нет активной стадии разработки, стоит ли ставить кубер чтобы потренироваться и набраться опыта?)
сначало надо в докеры хотя бы перенести попробовать) потом устать от этого и понять, что легаси лучше не трогать)))
Лаконично и понятно. Идеально)
Отлично!
Про кубернетес 16:00
Очень класно и понятно.
сервАйс дисковери
с шедулерами
Спасибо. Отличный доклад. В докладе говорилось о том, что в планах есть с VPN сервером внутри kubernetes. Скажите есть ли положительный опыт в этом вопросе?
Положительный. У нас есть openvpn и pritunl.
Как Вы решали вопорс с масштабированием и отказоустойчивостью? Использовали ли вы несколько мастеров если да то как организовали "Highly available public IPs"? Как я понял не все ЦОДы дают эту возможность для VPN. Умеет ли kubernetes перенаправлять траффик на под в другом ноде если под в текущем ноде стал недоступен (для новых подключений)? Есть ли возможность держать одновременно несколько узлов с VPN сервером и каким то образом балансировать подключения к ним?
Круть! А кто сейчас в России сдаёт в аренду простенькие кластеры из виртуалок как единый кирпич? Типа GKE, в пять кликов. Запускал ещё тестовый кубер на AWS с помощью kops - удобно. Теперь хочется примерно такой же простоты, только за меньшие деньги (например, со стоимостью виртуалок как на FirstVDS). Кто что слышал/использовал?
mcs.mail.ru
Что за Пью-карты и VRP? Это Ciscoтема?
vrrp и ucarp.
А под ceph выделяете локалку/один ДЦ?
Оооочень сильно зависит от множества факторов. Прежде всего от того, что будет потом в этом ceph храниться. Самый лучший вариант для ceph - две 10 Гбит/с локалки (одна для подключения, другая для связи между узлами). У нас есть много инсталляций на "плохих" 1 Гбит/с сетях и все работает "удовлетворительно".
Что ж его так трясет-то.
Ещё один умник - failover stateFulset stateless guarantee share applications dns discovery cloud native решения rasing db резолвиться в пачку ip адресов Discovery статические соседи на dns zoo keeper Consistent switchcover