Наш опыт с Kubernetes в небольших проектах / Дмитрий Столяров (Флант)
HTML-код
- Опубликовано: 15 янв 2018
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2017, Root Conf
Тезисы:
rootconf.ru/2017/abstracts/270...
Опыт эксплуатации Kubernetes в production есть пока далеко не у всех. Компании «Флант» удалось за последний год внедрить Kubernetes многим клиентам, и именно об этом мы хотим рассказать. Широкий и систематизированный опыт, собранный в этом докладе, должен вызвать интерес у всех тех, кто только слышал о контейнерах Docker или начинает их использовать, или только выбирает «платформу» (Marathon, Rancher, Kubernetes)… или уже давно что-то использует!
...
Спасибо. В универе б так преподавали
Дмитрий - потрясающий докладчик
Очень годно, без воды, максимум информации в минимальное время. Спасибо
Хорошо структурированный доклад, понятный новичкам. И отличная подача.
Прям вот то, что надо, спасибо огромное за проделанную работу!
Спасибо, докладчик прекрасно все объяснил
Обалденно! Работаю с кубом, но я инфрструктуру готовую использую. Было очень полезно!
Чувак - агонь просто! :)
Спасибо!
ААА, йолки, максимально круто. Вот просто нереально. ЫЫ, аж распирает от крутости информации. Спасибо!!
Просто супер! Очень просто и доступно разложил все понятия о K8S!
Круто! Спасибо!
Спасибо за доклад!!!
как же го по маленькому прижало!=)
Спикер от бога
Крутой доклад, быстро и по делу
Топ контент!
просто охренительно качественный доклад
Было интересно, спасибо!
Шикарный доклад, спасибо!
Бомба 💣
Красавчик!
Отличный доклад, спасибо
современный кубернетес тоже достаточно глубоко интегрируется в облачного провайдера, так просто кластер не перенести.
Шедулер - это круто 👍😉💪
51:30 "ПРОСТО подключаем cephfs"
Помимо кубернетеса узнал столько нового))
Отличная структура и содержание
Хороший доклад, отлично воспринимается тем кто с кубернейтсом вообще никогда не работал. p.s. такие тупые токсичные коменты только в русскоязычном сообществе можно найти =)
оператор по ходу устал камеру поворачивать туда-сюда))
Отличный доклад, но "сервайс" так режет слух...
Не поверите но у нас в компании тоже Кубернетес лежит на сефе, квм (проксмокс). Но сейчас я думаю что может перенести его просто на голое железо и это даст больше отказоустойчивости? Потому что много слоев (debian, ceph, proxmox, kvm, ubuntu, k8s, pod, container) это всегда черевато проблемами в будущем. Если есть мощностя заказать железо и вывести на него Кубернетес это будет лучше, как думаете?
Я думаю что самое лучшее увеличение отказоустойчивости будет в случае георезервирования, разносить ЦОДы территориально на огромные расстояния, чтобы падения всего было вызвано взрывом планеты.
У нас в компании так и сделано.
сервАйс инвЁрментов через балАнсер
Но про метрику и логирование тема не раскрыта
докладчик уровень "Бог"
я ещё не прочитал доку и не поигрался, но после такой презентации немного не понятно становится, а чем кубер страшен?
Тем что, что это дорого. Когда будешь работать в коммерческом проекте, то поймёшь. У нас например не совсем маленькая компания (где-то 6000 сотрудников). Есть группа разработки, аналитики, тестеры, админы и тд. Из-за того, что компания росла пришлось разделить обязанности и до кучи к админам создать еще небольшую отдельную группу из девопсеров, чтобы работали на конкретном проекте и не только сервера админили, а ci/cd и всем этим занимались. Цена каждого такого специалиста от 120 до 300 тысяч с учетом налогов, который платить работодатель. Ну и цена от качества зависит. В моём отделе где-то 50 человек и из них 4 девопс инженера (сеньор, два мидла и джун) и в сумме по деньгам это выходит около 800к в месяц всего на 4 сотрудника. Причем 4 человек мало на 50 рыл группы разработки и причем это только один из маленьких отделов внутри компании. Они занимаются только интранетом нашим, а что там на реальных проектах и сколько девопсов надо спрашивать ещё.
Так вот я надеюсь после этого будет понятно, что страшного в кубере: это цена специалиста, который грамотно сможет все это настроить. Это очень дорого. Поднимать настоящий кубер, а не миникуб - это другая история совершенно. Тем более хорошо бы было это всё автоматизировать для установки не сервера баш скриптами, как это к нас сделано к примеру. Потому что серверов 50 штук к примеру и на каждом надо поднять кластер и/или какая-то ВМ из строя вышла и нужно с нуля кластер разворачивать. Без автоматизации это полный заеб будет кубер с нуля на каждой тачке поднимать, даже если уже два года курил мануалы 😂
Надеюсь смог донести хоть как-то инфу. Кубер это нестрашно, если ты просто админ. Если ты девопс или идешь на него, то это оч страшно, когда в первый раз и так со всеми инструментами. Но в кубере очень много абстракций и почти нет никаких инструментов для безопасности кластера из под коробки. Только недавно в этом направлении стали всё развиваться, как стали в 18 году этот вопрос поднимать… В общем мелочей тут очень много. Кубер страшен в мелочах. Не снаружи, а внутри.
А когда начнешь играться, то надолго засядешь только с логикой работы его… Даже через миникуб. Мне в свое время миникуб намного сложнее показался, чем нормальный кластер)))
Доброго времени суток. Кейс такой, сейчас все сервисы крутятся в Docker Swarm. Как определить требуемые ресурсы "железа" для переезда на k8s, возможно с оглядкой на докер.
Так конечно так себе. Название «небольшой» чето там проект и кубер. А в итоге: куча ингресс+лоадбалансер до кучи еще хелм и надстройка на хелмой упаси господь. Для небольшого проекта на кубере спокойно можно обойтись и без хельма и без облачного лоадбалансера. Можно использовать haproxy или просто nginx создать в кач-ве лоандбалансера, потому что он так умеет…. Вот и вся магия
СерВАЙС...
режет слух! Кажется мелочь, но всё прекрастное выступление портит.
Надо доклад А когда не нужен кубер
Я джун, и самое странноое, что я почти всё понял 🙂
Лекция классная, но я вчера набухался и сегодня приходится закрывать рукой докладчика, т.к. он ходит туда-сюда и хочется блевать.)
Как тебе тут 5 лайков поставить?
очень странный доклад, если виртуальные машины то есть изоляция, а если просто сервисы запущены то нет изоляции. Есть лимиты, есть cgroups, lxc что с несколько раз покрывает потребности в изоляции. По мимо вопроса изоляции и отказоустойчивости есть вопрос стоимости железа. Я понимаю что ребята зарабатывают на внедрении модных штук, а для этого еще желательно привязать клинта к себе что бы получать какие то денежки за поддержку. Иногда даже нет смысла что то автоматизировать, ты просто накатил и в следующий раз будешь накатывать только через 3 года.
Ну если это сайт визитка, то да. Если это интернет-магазин, который набирает популярность, то уже не вариант. Нужно начинать с книг по девопсу. У нас на проекте в день происходит по 4-6 обнов в среднем на тест серверах. В ДЕНЬ. И все это дерьмо от разрабов конфигурировать руками было бы невозможно. Просто проще им сказать на какую кнопку в jenkins нажать и все. Или прикрутить к джобе триггер, тогда им вообще ничего нажимать не придется. Как-то. Я бы сказал не доклад странный, а вы. В видео не было речи о том, что проект НАСТОЛЬКО небольшой, что он 3 года не обновляется… Что же это за проект такой и какой у него цикл разработки жизненный вообще составлен? Или не составлен?)
К слову 4-6 обнов а день это еще не так много. На полное поднятие обновы на тесте уходит где-то минут 10. Поэтому страшно представить, что там у ребят из какого-нибудь яндекса или сбера.
А так просто америку конечно вы открыли))) здесь все понимают, что если есть процессы, которые не нужно автоматизировать, то их не трогают. Тяга ко всем этим штукам появляется, когда руками это все уже невозможно настраивать. Это совершенно другие объемы… Для понимания желательно попробовать поработать в компании, где занимаются этим. Высоконагруженными сервисами.
19:30 "pod" - это не английское слово, на русском означающее "стручёк".
"pod" - это принятое в английский язык русское слово "под", означающее "под" - то на чём размещают что-то другое.
Откуда такая информация? Где про это почитать?
@@MrMikhailDJ > Откуда такая информация?
Прямиком из сознания ─ много я думал на тему сути слов и букв ─ и понял, что старые, короткие слова ─ это прямое выражение мысли ─ без "люфта" между графемой (буквой), фонемой (звуком произношения) и ?? (базовым/фундаментальным движением духа). А новые слова (и переводы слов с языка на язык) ─ это изкажение мысли, вызваные непониманием сути букв и слов ─ потому что утерян правильный уровень абстракции.
> Где про это почитать?
Я думаю, что нигде. Максимум - вот здесь я комментарий оставлял на эту тему: ruclips.net/video/Mp-5cwq_8Fg/видео.html&lc=Ugy-W9aQqlr5z9CPbHd4AaABAg.9_bp9qwQmuR9_dJPgewjYI.
Не видел я, чтобы кто-то ещё об этом говорил. По сути, моя уверенность в выражении этой мысли основана на полном осознании, что я живу в мире дебилов.
@@roman_mishin спасибо, что развернуто ответил. Это интересное замечание. Я немного иначе об этом думал. Я предполагал, что могли просто так назвать это как-то, потому что вполне нормально использовать какое-то слово, которые в терминах того или иного ПО может просто не иметь перевода и являться нарицанием
@@MrMikhailDJ Я думаю, что он (pod), в терминах этого ПО, правильно назван pod'ом. Я не знаю ход мысли разработчиков, выбравших этот термин (тем более на английском языке), но я думаю, что это очень точный, в данном случае, термин - это то "на чём" (или "где") размещено что-то другое, в данном случае ─ контейнеры. "Стручок" здесь ─ метафора; причём не стручок целиком, а только, как мы называем, "створки", где лежат горошины ─ как pod, на котором "лежат" контейнеры.
Помимо Kubernetes, П О Д (по буквам языка, предшествовавшего "русскому", как я его понял) означает (сложно выразить меньшее большим) ─ нечто, плотность/опору дающее или affordance/impulse (Д) of density/substance (П).
@@roman_mishin я уже понял вашу мысль. Спасибо.
Шедулер😂😂😂😂 всегда так буду называть
Слово service НЕ ПРОИЗНОСИТСЯ как сервайс!
и шедулер, не как шедулер :)))
и инвёрмент, не как инвёрмент.
@@SamuelBSRпо английски шедулер, по американски скедулер
@@Das.Kleine.Krokodil шедьюлэ и скеджулэ
@@lGambit зависит от того какой дитэйлс и фабрик
Досмотрел до 8:41. Нашел две технические ошибки:
1. MySql может скалироваться горизонтально на AWS по чтению. Переходить на Mongu почти никогда не нужно. Это очень редкий случай
2. Редис может скалироваться тоже горизонтально. Можно не переходить с него
Жаль что у Дмитрия Столярова такое проскакивает в докладе. Продолжать смотреть не стал, так как боюсь перенять неправильные знания там где у меня нет экспертизы
Личное мнение:
Докладчик пытается проговорить много вещей, не умея быстро и четко говорить, от этого его речь рваная и сам он нервный и постоянно производит рваные движения и дерганые движения. Лично мне такая модель доклада сильно режет слух и заставляет напрягаться при просмотре. Просто не хватает нервов смотреть. Смотрю из-за этого кусками и с перерывами. В живую не выдержал бы и ушел.
Хочется пожелать докладчику сильно работать над речью и меньше жестикулировать.
Твой отзыв - дерьмо!
Смотрится, на одном дыхании. Даже на speed 1,25
Так не смотри, а лучше нервишки подлечи. Когда руками деплоить будешь, тебе понадобятся.
час трепа ни о чем) сори, но доклад нулевой, обо всем и ни о чем - мастер речи)) Вы молодец, можете часами говорить ни о чем))
Очень перспективный канал, подписывайтесь!
www.twitch.tv/zaqzaq