2025-05-01: SQAdays - традиционно: интересные доклады и общение

Короткая ссылка: SQAdays-2025a

Ссылки сюда (4) →

О других конференциях

В субботу 26.04 был и выступал на 36 конференции SQAdays. Конференция, как обычно, проходила два дня, но в пятницу я участвовал в DUMP, отчет DUMP-2025 я уже опубликовал. Поэтому на SQA — только в субботу. Реально я очень жалею? что не был в пятницу, особенно на afterpaty, где всегда идет активное общение. На Dump это тоже было, но ведь хочется успеть везде. Интересно, что между конференциями есть контраст. Dump — более молодежно-сленговый, маркером для меня служит вайб для описания хорошей атмосферы ненапряжной работы - по мотивам вайбкодинг (создание программ с помощью LLM), но в более широком смысле: на Dump оно в активном словаре, а на SQA — не звучит. Это — не единственное отличие, но остальные сложно отчетливо сформулировать, ты просто видишь разницу культур.

На конференции я впервые засек, что LLM в некоторых командах перестал быть чем-то новым, о чем надо отдельно рассказывать, а превратился в рабочий инструмент для определенного класса задач. «Мы развернули локальный LLM и научили разработчиков создавать тестовые наборы данных с его помощью» — характерная цитата — маркер такого отношения.

Я рассказывал про интеграцию, доклад Обеспечиваем устойчивость интеграции — развитие доклада Что такое - хорошая интеграция (Saint Highload-2021), с фокусом на тестирование. Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. Это организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса). Это смежные с этим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно. Отдельного рассмотрения требуют вопросы альтернатив для распределенных транзакциям. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат — насколько оно реалистично. И подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери. У меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать.

В одном из докладов мое внимание привлекло использование SDLC, Systems Development Lifecycle, которая была вставлена в докладе про Quality Gates в двух вариантах: замкнутая в кольцо и развернутая. Мне схема показалась ребрендингом водопада, я полез смотреть источники и в вики обнаружил, что это не ребрендинг, а почти оригинал, доработка водопада в методологии SSADM в 1980-х. Не обнаружив в водопаде Ройса необходимого менеджерам планирования, они приписали его в самом начале, заодно заменив requirements на analysis, ибо не менеджерское дело — над требованиями думать, и выкинув тестирование. Получился процесс для выполнения царских пожеланий «пойди туда, не знаю куда, принеси то, не знаю что». При этом, как и положено столь обобщенной задаче, ИТ-содержание на схеме отсутствует. Практическая иллюстрация к тому, что сон разума рождает чудовищ. Надо будет об этом статью написать, хотя вряд ли это что серьезно изменит. Потому что люди же берут старые схемы, и не особо думают о смысле, который в них заложен, и об их адекватности реальному миру. Отмечу, что в схемах в докладе тестирование сохранено, а планирование и анализ идут параллельно — авторы адекватно смотрят на мир. Но я видел схему SDLC не только в этом докладе, и часто это — просто проходной слайд, тиражирующий ложную конструкцию.

А в завершении конференции была классный доклад про кубернетис, в котором его конструкция иллюстрировалась понятными метафорами с котиками в квартире.

Дальше — мои заметки и конспекты докладов.

Виктор Хохлов и Сергей Жуков из ГНИВЦ. Наш опыт изменения подхода к тестированию, или Как мы уронили рожок мороженого

Это рассказ о структурировании системы тестов для того, чтобы снизить время тестирования, и при этом увеличить его надежность. Таких докладов много. но в этом интересен объект тестирования — аналитический кластер, который собирает данные из разных источников, выполняет по ним расчеты производных показателей по сложным алгоритмам и представляет данные на графиках. При этом полный цикл расчетов занимает около 1.5 часов, поэтому обычный цикл тестирования нашел ошибку — исправил — проверил оказывается слишком долгим.

Но начиналось все с ручного тестирования по результатам расчетов. При этом регресса с полной проверкой всего функционала никогда не существовало, тестирование выполнялось по новым фичах, а затем выполняли некоторое количество sanity тестов по связям данных и исследовательское тестирование, проверяя разные стремные мест. При этом существовала логическая связь обработки данных — часть тестов можно было проверять перед началом расчета. Были разные наборы данных для разных тестов и тут надо было быть аккуратным, чтобы тесты не повлияли друг на друга: цикл загрузки и расчетов обрабатывает все данные вместе, нельзя поднять много тестовых экземпляров с разными наборами данных. Особенность ситуации была в том, что команда проекта полностью поменялась, поэтому устная традиция передачи опыта нарушилась, а описаний — не было.

Сначала попробовали подхватить те методы, которые были. Но по мере проработки тестов количество фич и тест-кейсов увеличивалось, sanity-наборы составлять становилось все сложнее. Получилась перевернутая пирамида тестирования. И проявлялись проблемы длинного цикла тестирования. Тест-кейс: загрузили — посчитали — смотрим UI вручную. Такие кейсы быстро и просто составлять, можно привлекать ресурсы. Но система тестов получается хрупкая, а тестирование идет через UI.

Решили изменить подход. И для начала — разобраться в конструкции системы. В презентации была схема, внизу озеро данных, над ним несколько слоев обработки и два выходных плеча: на UI и на другие системы. Плечо на другие системы в тестировании вообще задействовано не было проверяли только UI.

На основе структуры получилось сложить тестовую модель. Сделать автоматизированные тестирование на интеграцию, озеро данных — системное плечо. А на UI — смешанное тестирование. Про новую фичу было понятно, где она расположена в модели и как ее тестировать.

Стало много тестов на озеро данных, заливка data-lake покрыта компонентными тестами, которые можно делать сразу, до проектирования сценариев обработки. Много автотестов на автоматическую ветку. И это пререквизит на ручное тестирование, приводит систему в нужное состояние. А тесты на UI стали простыми: проверяем, что витрина совпадает с озером, а UI корректно показывает витрину. Используют Artifactory, очень удобно делать слепки — embeded база данных nitrite.

Легаси из большого непонятного монстра стало понятным и перестало быть легаси. Если система покрыта тестами — она больше не легаси.

Пришли к разработчикам, чтобы выставить новое API, например, для тестирования сортировки, чтобы не делать его на интерфейсе. Но разработчики не умеют вести тестирование — они начали делать чек-листы для разработчиков. А потом развернули LLM и показали разработчикам, как с помощью LLM готовить тестовые примеры — это взлетело.

За счет автотестов получается сделать ночное тестирование. И хотя оно только ночное, потому что автотестов — 16 часов, из них 15 — расчеты, это дает большое продвижение по сравнению с чисто ручными тестами, которые были раньше.

Изменение было безболезненно, потому что долго и нужно продумывали процесс, думали, как откатиться, если не взлетит — как откатиться на прежние кейсы, что делать с техдолгом. Потому что там были end2end сценарии в старой идеологии, их разбирали на новые тесткейсы — разные. Полгода продумывали, и год время перехода, сценарии переписывали по мере того, как их дергали.

Хороший доклад. Жаль только, что метафору про рожок мороженного не раскрыли…

Диана Ахметова Александр Наумов из SM Lab. Промахи руководителя или как учиться на своих ошибках

Четыре истории ошибок руководителей и уроков из них. У меня по ним неожиданная ассоциация: истории очень похожи на истории неудачного построения отношений: в одной паре историй — о том, как партнера (команду) пытаются изменять, а он тебя посылает, а в другой паре — о том, как партнер оказывается крутым, но при этом слабо организованным, что напрягает, и развеивает ореол крутизны. Но уроки при этом о приемах, а не о смене отношения: для первой пары — о том, что надо изменять другими приемами, а для второй — что тщательнее отбирать. А значит истории будут повторятсья, потому что по сути конструкт взаимоотношений не меняется, а именно он является причиной конфликта. Вообще интересно смотреть на истории рабочих отношений с точки зрения создания личных, можно подметить и типовые ошибки и типовые слепые зоны.

Это — общее впечатления. А теперь — что было в докладе, и послужило основанием. Александр рассказывал первую и третью историю, Диана — вторую и четвертую, в рассказе я их переставлю, потому что истории Александра — про реорганизацию команды, а у Дианы — про включение нового сотрудника.

История-1. Трудности с сотрудником. Ему предлагаешь изменения, а он — отвергает. Ему дали старую команду, поставили задачу: автоматизация, ИПР, ментора поднанять для автоматизации. И он пошел делать анализ — как двигаются задачи, посмотрел оценки, поискал ментора. К концу недели составил ИПР, провел демо по улучшению бизнес-процесса — работа в jira, составил бэклог, позвал эксперта по автотестом, спланировал 1*1.

Последствия. Первый же 1*1 дал отзыв: ИПР — ерунда, тест-кейсы у нас свежие, 1.5 года как написаны, все ОК. А вообще, ты — руководитель, давай сначала про зарплату. И нововведения — не нужны. Через месяц взаимодействия сотрудник сказал, что выгорел и ушел в отпуск на месяц, а в середине отпуска написал, что уходит.

Что делает по-другому: не составляет ИПР, сотрудник сам; команда сама должна вести технический бэклог — она лучше знает; фиксирует все договоренности; привлек эксперта по области — это было правильно.

История-3. Грабли команды. Приходит эффектвиный менеджер «ребят, все поменяю» — это он такой. Приходит, видит проблемы, а команда говорит «тут все норм». Хотя он видит: тестовая пирамида не описана, точки контроля не настроена, хранение странное, merge не делают. Он пробует сделать изменения: ведение статусов в jira, сделал встреча три амиго. В результате: путаница со статусами в jira, встречи ради встреч, кофейку попить, а merge стали жать формально. Команда месяц так пожила — и на ретро была готова порвать его на клочки: постоянные изменения для решения не существующих проблем, мы что, не квалифицированные? Он отошел на месяц, дал команде поуправлять самим. Прошло две недели — ребята провалили релиз. Грабли стукнули довольно больно.

Как теперь:

• общая страница, где команда пишет текущие проблемы.
• он отслеживает проблемы, но команда должна сама решать, он не хочет быть бас-фактором
• новые практики — итеративно, а не все подряд, предлагает последовательность, команда может не принять
• и дать команде ошибиться

То есть финал этой истории в целом позитивный.

История-2. Была попытка найти сотрудника через ротацию, по пути наименьшего сопротивления. Не удачная, дальше она разгребала последствия. Ситуация: надо было развивать автоматизацию в новом продукте, разворачивать pipeline, чтобы не по кнопке на рабочем месте, а в контейнере. Прежде, чем искать сотрудника снаружи — порекомендовали сотрудника из компании, с хорошим опытом. Первые автотесты появились быстро, их включили в pipeline. Но через некоторое время увидела, что среди тестов — много красных и эта ситуация не меняется. что странно. Пришлось локально развернуть проект, начала смотреть код — и появились вопросики к реализации.

А еще все изменения инициирует она, инициативы от сотрудника не видела. Много 1*1 — что делаем дальше и так далее. Дофига времени ушло, результата не получилось. В итоге автотесты передали разработчикам, тогда пошел классный фидбек. А сотрудника пришлось снова ротировать. Теперь — внимательно смотрит на рекомендации. И смотрит продукт сотрудника на рабочем старом месте — чек-листы, автотесты, и обратную связь на него смотрит. То есть не положиться на чье-то мнение, а решить самой.

Я тут замечу, что есть такая корпоративная проблема, когда вместо нормальной работы с проблемным сотрудником, включая увольнение, его пытаются передать в соседнюю команду. А иногда даже с повышением. Проблема многократно описана в книгах, она — старая. И, казалось бы, ее надо учитывать в работе. Уж HR-то должны быть в курсе, это их профессиональная область. Но на практике это не так. Причины, кстати, описаны в тех же книгах. Тут как с когнитивными искажениями: люди знают, многие даже Канемана читали, но когда сами принимают решения, то об этом не думают.

История-4. Тоже про нового сотрудника, только не по ротации, а снаружи. И задача та же — автоматизация, сделать с нуля и встроить в поток. Нашли звездного сотрудника, инициативного, с богатым опытом. Запустили проект с автотестами, нарастили тестовое покрытие до 80 %, сотрудник писал статьи в духе звезды, команда была рада. Но! Работа сотрудника не сильно прозрачна. Автотесты — неделями, но результат — непредсказуем: сроки, объем. В коммит — большие изменения, на 800 файлов.

Вели работу: декомпозировали задач, обсуждали. Не помогало. Работа не прозрачна, тесты не стабильны, нет единого подхода в автоматизации — несколько лидов считали свое мнение правильным, рефакторинг уже 300 часов для масштабирования. Как итог — с сотрудником расстались и передали автотесты разработчикам. История научила стандартизировать какие-то подходы в автоматизации. Описывать инструкции, должен был баланс. Отслеживание выполнение поставленных задач. И эксперты к ревью проекта.

Итоги. 4 истории. Реально их было больше, их обрезали.

• Признавайте свои ошибки, свои промахи
• спрашивайте, почему так получилось. 5 почему.
• оценивайте полученные результаты — насколько решение разошлось с ожиданиями
• вносите изменения в то, как принимаете решения

Марина Куликова из Garage Eight и Павел Голяков из Яндекс. Quality Gates: путь к качеству на каждом этапе развития компании

Это как раз тот доклад, на котором я увидел SDLC и подумал, что это ребрендинг водопада, я писал в начале отчета. Но сам доклад — рассказ об опыте quality gate, которые обеспечивают качество. Это — хорошая практика, частный случай таких гейтов — всем известные DoR и DoD для конкретных задач, а для больших проектов надо работать с метриками. И в докладе — очень правильные вещи, например, что если вы допускаете релиз с малым процентом красных тестов, то обязательной частью должен быть позднейший разбор с этим тестами, если их оставлять вечно красными — работать не будет. Хотя, конечно, хотелось бы услышать в этом докладе про больше такой поиск рабочего баланса, потому что это — наиболее интересная часть. Ведь отвергают пользу quality gate и подобных практик те. кто на своем опыте сталкивался, как формальное отношение замораживает реальную деятельность. заставляет тратить энергию на преодоление бесполезных препятствий. Поэтому правильный баланс, когда гейт поднимает качество, но не останавливает работу — очень важная часть.

Итак, quality gate — это место, где команда проверяет, что все идет нормально. Он включает процессную часть и техническую, обе части могут быть ручными и автоматическими. Процессные гейты контролируют этапы прохождения процесса по договоренностям внутри команды: * планирование и анализ требований, проектирование архитектуры, соответствие релизной политике, если она есть и так далее. А технические контролируют метрики инженерных аспетов: code review, покрытие автотестами, проверка на безопасность, написанные тест-кейсы и чек-листы, наличие критических ошибок. Проверка может быть ручная или автоматизированная, если ее можно встроить.

Количество и содержание quality gate зависит от этапов развития компании.

• Стартап 20-30 человек — как-нибудь по месту.
• Компания с одним продуктом до 100 — достаточно ручных.
• Несколько продуктов 100—500: технические — стабилизированные и автоматизированные, процессные — в достаточном объеме, можно в jira настроить перевод статусов в зависимости от того, что делают в коде
• Корпорация — нужен безупречный баланс, не облажаться и не закопаться. Тут часто встречается, когда делают copy-paste процессов между разными проектами без учета специфики, в результате quality gate работают во вред, двигаясь по ним часто теряешь качество.

Я тут хочу отметить, что основная проблема с quality gate как раз в желании сделать все единообразно, игнорируя стадии жизненного цикла проекта и его особенности, и начинается это с 3-4 команд в компании. Перекосы идут в обе стороны — недостаточные проверки там, где им пора быть и чрезмерные на этапе разворачивания. А в корпорации может принимать уже одиозные формы, как частный случай развития бюрократизации.

Два примера.

• Тестовые сценарии, процент прохождения автотестов. Например, договорились про 80-85. Но: договариваемся, что красные тесты должны быть разобраны, без этого оно не работает.
• Управление дефектами. Не только разбираемся с конкретным дефектом и со временем его закрытия, но и смотрим находимость дефекта — на какой стадии.

При внедрении гейта должны быть понятны три выгоды: для компании, для каждого сотрудника и для команды. И я тут отмечу, что эти выгоды должны быть не только декларированы: они должны быть явно записаны, и регулярно проверяться. Очень часто выгоды оказываются декларативными и не достигаются, или достигаются не все, что ведет к саботажу. И даже если есть первые успехи и гейт оказывается полезным, забывают о процессе регулярного ревью, и через год он уже превращается в формальное мероприятие или тормоз, а на это не смотрят.

Как внедрять -понятный сценарий пилотного внедрения с дальнейшим распространением: построение процесса, фиксация договоренностей и процесса, тестовая группа, запуск, контроль, сбор обратной связи, работа над ошибками, масштабирование. Замечу, что в этом описании фокус — на процесс и его исполнение, а про фиксацию гипотез о выгодах и их проверку не говорят. Начинать с лояльных — минимум сопротивления. В корпорации команды разной зрелости — и надо уметь работать с разными.

Опыт. Не внедряйте Quality gate сразу много — это будут грабли на пути команды вместо помощи. Quality gate дает прозрачность процесса. Ее не любят из разных соображений? в том числе потому, что прозрачность повышается даже кривого процесса. И это можно контролировать. Это контролируемый процесс.

Quality gate не должен замедлять команду (сильно). Если их слишком много — попробуй убрать, может они личные. Есть отказные гейты, а есть — где можно пренебречь. Но должна быть договоренность — записали в долг и так далее.

Отдельный вопрос — про метрики качества. Спросите их у команды, у продукта, у других стейкхолдеров — а потом попробуйте эти представления выравнять. Это — нетривиально.

Сделать все и сразу — не работает. Фиксируйте договоренности, готовьтесь работать с возражениями, учитывайте уровень зрелости команд. Отсутствие метрик процесса или аудита — вы не поймете куда двигаетесь. Сделайте дашборд, и не лезьте в сложное. Соблюдайте критерии качества и надежности — их забывают проговаривать. Это все — очень правильные рекомендации, но, к сожалению, без примеров, без приземления на конкретные кейсы. А без примеров такие штуки — как благие пожелания об активном образе жизни: все согласны, некоторые даже покупают абонемент в фитнес, а вот сколько реально его ведут? Опыт был бы очень интересен.

Agile и гибкость. Очень часто там под этим флагом полностью отвергают любые договоренности. И весь agile ломается. Я тут полностью согласен, и хочу сказать, что agile-манифест писали действующие ИТ-шники, и что помимо ценностей там принципы, где очень много инженерных моментов. Как раз про работающий продукт. А scrum в этом смысле жесткий: в конце спринта должен быть потенциально поставляемый продукт, который несет (увеличивает) ценность пользователю. Но фокус при этом — на результат, а не на процесс, потому что. к сожалению, процесс не позволяет в ИТ гарантировано достигать результата. Причины, известные много лет назад, описанные Бруксом в Мифическом человеко-месяце и Томом ДеМарко в Человеческом факторе — по-прежнему актуальны.

Когда пересматривать? Когда что-то идет не так. Все юниты зеленые — а оно падает. Смотришь в тесты — а они вечно зеленые. И осознанный переход на ручной режим, временное снижение критериев — но ведем техдолг. А еще — инструмент ушел, команда сменилась — надо уметь перейти на ручной режим.

Я бы сказал, что когда что-то идет не так — уже поздно. Это значит quality gate давно работает во вред: он не обеспечивает качество, и забирает энергию на его обход. Правильно делать регулярный review, и оценивать там достижение целей, которые гейт должен обеспечивать. А еще полезно, если командам разрешены эксперименты. Если чего-то нельзя изменить, то это невозможно и улучшить.

Ксения Мосина из Альфа-банка. Ценность в каждом: инструменты для работы с развитием команды

Как рассказала Ксения, она еще не так давно была из тех тестировщиков, которые искренне переживают за продукт, отслеживают метрики. но при этом не обращают внимания на команду, на человеческие отношения в ней. Но потом отношение изменилось. Она поняла, что процессы и эмоциональное состояние — две стороны, надо работать с обоими. Но, оставаясь тестировщиком, который любит все мерить.

И, как люди поступают сейчас, она не стала искать различные опросы, а поручила ИИ сделать радар команды, а потом проверила результат. В презентации есть ссылка на группу в телеграме, оттуда можно перейти в чат-бот, который умеет проводить опросы, и у него можно получить ссылку на системный промпт, который вам поможет сделать свой опрос, если вы хотите доработать то, что получилось. Системный промпт протестирован на всех популярных ИИ, их список тоже дают. В презентации довольно много примеров того, что выдает опрос, и как работать с его результатами, разбираются примеры конкретных гипотез, организация ретроспективы в целом. Можно пользоваться. Пересказывать я не буду, презентация Ксении, как и остальные уже опубликованы на сайте конференции.

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

Сколько стоит работа с опросами? Опросник 30-60 минут, опрос 15-30 мин, анализ 60-90 лидером, дальше встреча 1.5-3 часа всей команды и и 1*1. Если команда из 5 человек, получается около 40 человеко-часов, раз в квартал — вполне реалистично.

И нельзя упустить человеческий фактор. За метриками стоят участники команд. И важно их слышать. И понимать, что опрос могли проходить формально, ставя максимальные оценки — в этом случае на 1*1 проходим по пунктам, и делаем выводы. Может, в команде действительно все хорошо, команда прекрасна и не надо ничего трогать. А может быть, есть проблемы, о которых принято умалчивать. В любом случае — результат опроса — повод для разговора. А его прохождение — повод для членов команды подумать о команде с разных сторон, и это дает важную подготовку.

Виктория Кухтяева из Альфа-банка. Что нужно знать тестировщикам о Kubernetes

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

И так, рассказ на котиках. Что такое виртуальные машины и контейнеры?

• Виртуальная машина — это дом для котика со слугами и инфраструктурой
• Контейнер — котику для жизни не нужен весь дом, ему нужна коробка с необходимым — игрушки, вода и еда, надо чуть-чуть.

Кубер вылетел из компании Google

• Оркестрация контейнеров
• Масштабирование, мониторинг и нагрузка — но с особенностями
• Автоматизация развертывания — ради этого и берут

Архитектура кубера. Суровый девопсер задает настройки: где поставить коробочку с приложением-котиком.

• Мастер-нода — там управляющие:
  • Контролер-менеджер — бабушки на лавочки следят
  • Планировщик расселяет
  • Домовая книга с логами.
• Рабочая нода
  • Там живут котики в коробках.
  • Но! Там же есть помощники от мастер-ноды.

Рабочая нода должна быть хотя бы одна.

Базовые компоненты кубернетиса

• Нода — физический или виртуальный сервер, это квартира в доме, где стоят коробочки с котиками. Как и во всякой квартире, площадь и другие ресурсы ограничены.
• Кластер — подъезд в доме кубернетиса.
• Поды — набор контейнеров, которые запускаются целиком и имеют ограничения по ресурсам, паттерн sidecar. Поды — логические, они переезжают между нодами.
• Сервис — имеет списков подов, и знает их в лицо, маршрутизирует трафик на нужный под, знает политики доступа к подам и их адреса.
• Реплики — запускают несколько экземпляров пода для масштабирования, если одна из реплик умирает — поднимают другую.

Тут метафора живых котиков работает не совсем корректно: мы с любого котика в коробке можем сделать неограниченное количество дублей и их запустить.

Компоненты мастер-ноды

• Контроллер-менеджеры — бабушки на лавочки, которые знают, что должно быть и что есть в моменте, они отслеживают и поддерживают состояние
• api сервер — девопс связывается через него и воздействует.
• scheduler — размещает поды в кластере. Знает потребности пода и ресурсы нод — и размещает
• etcd — домовая книга key-value, в которую пишут журнал всех изменений

Рабочая нода

• kubelet — любитель котиков — получает манифест для работы с подами, отслеживает состояние внутри ноды, и связывается с мастер-нодой — передает состояния, выполняет команды
• kube-proxy — сервис — в мастер-ноде, рабочие поды — в рабочих, и он маршрутизирует и балансирует нагрузку, смотрит за соблюдением политик

Когда нужен кубернетис? Нужно управлять в огромной инфраструктуре. Надо много денег и классных специалистов. Пока вы не живете в инфраструктурном аду — не заморачивайтесь. Кубер — классная коробка, но в ней над разбираться. Она дает много возможностей, но ими надо хорошо управлять — иначе и с ним будет ад. Стабильность обеспечивает команда сопровождения, health-чеки.

В конце презентации — умные книжки, они достаточно известны, и ссылки на статьи с более подробным рассказамИ, котоыре она отобрала.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 17:37, 1 мая 2025 • нет комментариев