Наш опыт с Kubernetes в небольших проектах / Дмитрий Столяров (Флант)

[@artemsky7334]

Дмитрий - потрясающий докладчик

[@DmitriiFitisov]

Спасибо. В универе б так преподавали

[@metallic_monk]

Очень годно, без воды, максимум информации в минимальное время. Спасибо

[@ares4322]

Хорошо структурированный доклад, понятный новичкам. И отличная подача.

[@sergeydemidov1112]

Обалденно! Работаю с кубом, но я инфрструктуру готовую использую. Было очень полезно!

[@barabucho]

Супер видео!

[@ValentinRudikov]

Просто супер! Очень просто и доступно разложил все понятия о K8S!

[@zakhar_bykov]

ААА, йолки, максимально круто. Вот просто нереально. ЫЫ, аж распирает от крутости информации. Спасибо!!

[@anchovski1788]

Прям вот то, что надо, спасибо огромное за проделанную работу!

[@darjat2632]

Шикарный доклад, спасибо!

[@АнтонВасильев-т2я]

Отличный доклад😀💪🏻

[@provisota]

Чувак - агонь просто! :) Спасибо!

[@nikitasuperhackk6994]

Спасибо, докладчик прекрасно все объяснил

[@caramingo37]

Было интересно, спасибо!

[@native-nature-video]

Спасибо за доклад!!!

[@nilsharafutdinov3679]

Отличный доклад, спасибо

[@altmindo]

51:30 "ПРОСТО подключаем cephfs"

[@pleerock]

Хороший доклад, отлично воспринимается тем кто с кубернейтсом вообще никогда не работал. p.s. такие тупые токсичные коменты только в русскоязычном сообществе можно найти =)

[@Das.Kleine.Krokodil]

Отличная структура и содержание

[@ПетрПетров-г5ъ]

как же го по маленькому прижало!=)

[@HelloWorldTrip]

Спикер от бога

[@rust_game_shop]

Крутой доклад, быстро и по делу

[@tsibulsky4900]

Шедулер - это круто 👍😉💪

[@vyorkin]

просто охренительно качественный доклад

[@SamuelBSR]

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

[@johnk7589]

Помимо кубернетеса узнал столько нового))

[@maxtalin5174]

Отличный доклад, но "сервайс" так режет слух...

[@native-nature-video]

сервАйс инвЁрментов через балАнсер

[@logiqone]

Круто! Спасибо!

[@adambright5416]

я ещё не прочитал доку и не поигрался, но после такой презентации немного не понятно становится, а чем кубер страшен?

[@MrMikhailDJ]

Тем что, что это дорого. Когда будешь работать в коммерческом проекте, то поймёшь. У нас например не совсем маленькая компания (где-то 6000 сотрудников). Есть группа разработки, аналитики, тестеры, админы и тд. Из-за того, что компания росла пришлось разделить обязанности и до кучи к админам создать еще небольшую отдельную группу из девопсеров, чтобы работали на конкретном проекте и не только сервера админили, а ci/cd и всем этим занимались. Цена каждого такого специалиста от 120 до 300 тысяч с учетом налогов, который платить работодатель. Ну и цена от качества зависит. В моём отделе где-то 50 человек и из них 4 девопс инженера (сеньор, два мидла и джун) и в сумме по деньгам это выходит около 800к в месяц всего на 4 сотрудника. Причем 4 человек мало на 50 рыл группы разработки и причем это только один из маленьких отделов внутри компании. Они занимаются только интранетом нашим, а что там на реальных проектах и сколько девопсов надо спрашивать ещё. Так вот я надеюсь после этого будет понятно, что страшного в кубере: это цена специалиста, который грамотно сможет все это настроить. Это очень дорого. Поднимать настоящий кубер, а не миникуб - это другая история совершенно. Тем более хорошо бы было это всё автоматизировать для установки не сервера баш скриптами, как это к нас сделано к примеру. Потому что серверов 50 штук к примеру и на каждом надо поднять кластер и/или какая-то ВМ из строя вышла и нужно с нуля кластер разворачивать. Без автоматизации это полный заеб будет кубер с нуля на каждой тачке поднимать, даже если уже два года курил мануалы 😂

[@MrMikhailDJ]

Надеюсь смог донести хоть как-то инфу. Кубер это нестрашно, если ты просто админ. Если ты девопс или идешь на него, то это оч страшно, когда в первый раз и так со всеми инструментами. Но в кубере очень много абстракций и почти нет никаких инструментов для безопасности кластера из под коробки. Только недавно в этом направлении стали всё развиваться, как стали в 18 году этот вопрос поднимать… В общем мелочей тут очень много. Кубер страшен в мелочах. Не снаружи, а внутри.

[@MrMikhailDJ]

А когда начнешь играться, то надолго засядешь только с логикой работы его… Даже через миникуб. Мне в свое время миникуб намного сложнее показался, чем нормальный кластер)))

[@aws_arch]

Не поверите но у нас в компании тоже Кубернетес лежит на сефе, квм (проксмокс). Но сейчас я думаю что может перенести его просто на голое железо и это даст больше отказоустойчивости? Потому что много слоев (debian, ceph, proxmox, kvm, ubuntu, k8s, pod, container) это всегда черевато проблемами в будущем. Если есть мощностя заказать железо и вывести на него Кубернетес это будет лучше, как думаете?

[@ivansokolov1584]

Я думаю что самое лучшее увеличение отказоустойчивости будет в случае георезервирования, разносить ЦОДы территориально на огромные расстояния, чтобы падения всего было вызвано взрывом планеты.

[@MrMikhailDJ]

У нас в компании так и сделано.

[@MrKelebras]

докладчик уровень "Бог"

[@justalex7450]

Красавчик!

[@HelloWorldTrip]

Но про метрику и логирование тема не раскрыта

[@AnatoliiKudriashov]

Доброго времени суток. Кейс такой, сейчас все сервисы крутятся в Docker Swarm. Как определить требуемые ресурсы "железа" для переезда на k8s, возможно с оглядкой на докер.

[@korolisimus]

оператор по ходу устал камеру поворачивать туда-сюда))

[@ШураАрхипов-м9ц]

Бомба 💣

[@nataly2163]

Надо доклад А когда не нужен кубер

[@bo44arov]

СерВАЙС...

[@stivkuhn2093]

режет слух! Кажется мелочь, но всё прекрастное выступление портит.

[@ArtyomArzamasow47]

Досмотрел до 8:41. Нашел две технические ошибки: 1. MySql может скалироваться горизонтально на AWS по чтению. Переходить на Mongu почти никогда не нужно. Это очень редкий случай 2. Редис может скалироваться тоже горизонтально. Можно не переходить с него Жаль что у Дмитрия Столярова такое проскакивает в докладе. Продолжать смотреть не стал, так как боюсь перенять неправильные знания там где у меня нет экспертизы

[@БендерЗадунайский-щ9ы]

Я джун, и самое странноое, что я почти всё понял 🙂

[@roman_mishin]

19:30 "pod" - это не английское слово, на русском означающее "стручёк". "pod" - это принятое в английский язык русское слово "под", означающее "под" - то на чём размещают что-то другое.

[@MrMikhailDJ]

Откуда такая информация? Где про это почитать?

[@roman_mishin]

​@@MrMikhailDJ > Откуда такая информация? Прямиком из сознания ─ много я думал на тему сути слов и букв ─ и понял, что старые, короткие слова ─ это прямое выражение мысли ─ без "люфта" между графемой (буквой), фонемой (звуком произношения) и ?? (базовым/фундаментальным движением духа). А новые слова (и переводы слов с языка на язык) ─ это изкажение мысли, вызваные непониманием сути букв и слов ─ потому что утерян правильный уровень абстракции. > Где про это почитать? Я думаю, что нигде. Максимум - вот здесь я комментарий оставлял на эту тему: kzbin.info/www/bejne/g6GQZpatpsRrfMk&lc=Ugy-W9aQqlr5z9CPbHd4AaABAg.9_bp9qwQmuR9_dJPgewjYI. Не видел я, чтобы кто-то ещё об этом говорил. По сути, моя уверенность в выражении этой мысли основана на полном осознании, что я живу в мире дебилов.

[@MrMikhailDJ]

@@roman_mishin спасибо, что развернуто ответил. Это интересное замечание. Я немного иначе об этом думал. Я предполагал, что могли просто так назвать это как-то, потому что вполне нормально использовать какое-то слово, которые в терминах того или иного ПО может просто не иметь перевода и являться нарицанием

[@roman_mishin]

​@@MrMikhailDJ Я думаю, что он (pod), в терминах этого ПО, правильно назван pod'ом. Я не знаю ход мысли разработчиков, выбравших этот термин (тем более на английском языке), но я думаю, что это очень точный, в данном случае, термин - это то "на чём" (или "где") размещено что-то другое, в данном случае ─ контейнеры. "Стручок" здесь ─ метафора; причём не стручок целиком, а только, как мы называем, "створки", где лежат горошины ─ как pod, на котором "лежат" контейнеры. Помимо Kubernetes, П О Д (по буквам языка, предшествовавшего "русскому", как я его понял) означает (сложно выразить меньшее большим) ─ нечто, плотность/опору дающее или affordance/impulse (Д) of density/substance (П).

[@MrMikhailDJ]

@@roman_mishin я уже понял вашу мысль. Спасибо.

[@serhiizaika.]

Как тебе тут 5 лайков поставить?

[@MrMikhailDJ]

Так конечно так себе. Название «небольшой» чето там проект и кубер. А в итоге: куча ингресс+лоадбалансер до кучи еще хелм и надстройка на хелмой упаси господь. Для небольшого проекта на кубере спокойно можно обойтись и без хельма и без облачного лоадбалансера. Можно использовать haproxy или просто nginx создать в кач-ве лоандбалансера, потому что он так умеет…. Вот и вся магия

[@DmitryOlyenyov]

Слово service НЕ ПРОИЗНОСИТСЯ как сервайс!

[@SamuelBSR]

и шедулер, не как шедулер :))) и инвёрмент, не как инвёрмент.

[@Das.Kleine.Krokodil]

​@@SamuelBSRпо английски шедулер, по американски скедулер

[@lGambit]

@@Das.Kleine.Krokodil шедьюлэ и скеджулэ

[@Das.Kleine.Krokodil]

@@lGambit зависит от того какой дитэйлс и фабрик

[@konst2087]

Шедулер😂😂😂😂 всегда так буду называть

[@n0b0dynvkz]

очень странный доклад, если виртуальные машины то есть изоляция, а если просто сервисы запущены то нет изоляции. Есть лимиты, есть cgroups, lxc что с несколько раз покрывает потребности в изоляции. По мимо вопроса изоляции и отказоустойчивости есть вопрос стоимости железа. Я понимаю что ребята зарабатывают на внедрении модных штук, а для этого еще желательно привязать клинта к себе что бы получать какие то денежки за поддержку. Иногда даже нет смысла что то автоматизировать, ты просто накатил и в следующий раз будешь накатывать только через 3 года.

[@MrMikhailDJ]

Ну если это сайт визитка, то да. Если это интернет-магазин, который набирает популярность, то уже не вариант. Нужно начинать с книг по девопсу. У нас на проекте в день происходит по 4-6 обнов в среднем на тест серверах. В ДЕНЬ. И все это дерьмо от разрабов конфигурировать руками было бы невозможно. Просто проще им сказать на какую кнопку в jenkins нажать и все. Или прикрутить к джобе триггер, тогда им вообще ничего нажимать не придется. Как-то. Я бы сказал не доклад странный, а вы. В видео не было речи о том, что проект НАСТОЛЬКО небольшой, что он 3 года не обновляется… Что же это за проект такой и какой у него цикл разработки жизненный вообще составлен? Или не составлен?)

[@MrMikhailDJ]

К слову 4-6 обнов а день это еще не так много. На полное поднятие обновы на тесте уходит где-то минут 10. Поэтому страшно представить, что там у ребят из какого-нибудь яндекса или сбера.

[@MrMikhailDJ]

А так просто америку конечно вы открыли))) здесь все понимают, что если есть процессы, которые не нужно автоматизировать, то их не трогают. Тяга ко всем этим штукам появляется, когда руками это все уже невозможно настраивать. Это совершенно другие объемы… Для понимания желательно попробовать поработать в компании, где занимаются этим. Высоконагруженными сервисами.

[@mikhaildiesperov2345]

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

[@klaus408]

Личное мнение: Докладчик пытается проговорить много вещей, не умея быстро и четко говорить, от этого его речь рваная и сам он нервный и постоянно производит рваные движения и дерганые движения. Лично мне такая модель доклада сильно режет слух и заставляет напрягаться при просмотре. Просто не хватает нервов смотреть. Смотрю из-за этого кусками и с перерывами. В живую не выдержал бы и ушел. Хочется пожелать докладчику сильно работать над речью и меньше жестикулировать.

[@aws_arch]

Твой отзыв - дерьмо!

[@ZVA_NOOK]

Смотрится, на одном дыхании. Даже на speed 1,25

[@moon.trance]

Так не смотри, а лучше нервишки подлечи. Когда руками деплоить будешь, тебе понадобятся.

[@junegton]

час трепа ни о чем) сори, но доклад нулевой, обо всем и ни о чем - мастер речи)) Вы молодец, можете часами говорить ни о чем))

[@wynor751]

Очень перспективный канал, подписывайтесь! www.twitch.tv/zaqzaq