…про то, что «Kubernetes для разработчиков» стартует через неделю.

С 8 сентября новый поток студентов сядет за парты, и мы с Марселем Ибраевым и Павлом Селивановым подробно и с примерами расскажем, как:

🔷 собирать приложения под k8s;
🔷 автоматизировать деплои через CI/CD;
🔷 создавать и конфигурировать Service и Ingress для различных Deployment;
🔷 создавать и настраивать Helm-чарты для приложений,
🔷 самим дебажить проблемы в поде и многим другим полезным вещам.

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

🟠 Подробнее изучить программу и выбрать тариф можно по ссылке.

Прячем секреты приложения. Как Kubernetes помогает защитить ваши данные — запись вебинара доступна к просмотру.

На этом вебинаре мы с Максимом Киселёвым собрали воедино картину работы с секретами и обсудили:

🟠почему Kubernetes популярен;
🟠где хранить конфигурацию;
🟠как ничего не делать и чтобы всё было безопасно;
🟠кейсы и примеры использования.

Ссылки на запись для тех, кто просил:

🍿 VK
😘 youtube

Приятного просмотра!

Год назад я проходил собеседование на должность SRE в нидерландском бигтехе.

Меня бесило, что нужно было учесть миллион разных моментов, продумать, О ЧЁМ стоит говорить и КАК говорить… Я готовился к интервью больше, чем к переезду)

Но обо всём по порядку. Мой пайплайн интервью состоял из следующих этапов:

➡️ HR-скрининг: стандартная процедура — говорили о мотивации, опыте и зарплатных ожиданиях.

🟣 Я понимал, что здесь очень важно чётко и структурировано излагать свои мысли, а также демонстрировать понимание ценностей компании. Поэтому заранее прокачивал английский язык и готовил ответы. Никто не поймёт, какой ты молодец, если ты не сможешь это объяснить на неродном языке. Причём нередко людям, для которых английский тоже является вторым языком 🙂

➡️ Техническое интервью: проверка того самого литкода. Тут всё стандартно, на эту тему есть тонны статей и видео.

➡️ System Design. Задача этого этапа — проверить насмотренность и умение мыслить, а также протестировать навыки общения. Это идеальный момент, чтобы блеснуть знаниями деталей и нюансов построения больших систем по максимуму. Но при этом донести ход своих мыслей до интервьюера нужно всего за час!

🟣 Какую систему можно построить за это время? Только гипотетическую. Я и построил.

➡️ Culture Fit: испытание на общую адекватность и соответствие культуре компании. Обсуждали командную работу, конфликты, подходы к решению проблем.

🟣 Правила игры я изучил заранее, поэтому успел подготовиться и к этому этапу. Взял на вооружение метод STAR и был готов предоставить кейсы из практики по этому методу.

Что я хочу сказать по итогу. Твои скиллы — это только полдела. Вторая половина — это умение продать их по правилам игры, которые устанавливает компания.

Я справился, чего и вам желаю. Но серебряной пули нет, и без подготовки, будь ты хоть senior ultra principal distinguished инженер, можно легко провалиться.

А какие моменты раздражают вас при прохождении интервью?

🟠 Встречаемся на Quizbernetes завтра, в 19:00 по мск.
Кто не успел зарегистрироваться, вот ➡️ ссылка ⬅️

Та-да-дамммм!

Трубите фанфары, стучите барабаны — мы начинаем Quizbernetes!

Что вас ждёт:
🟣 простые и каверзные вопросы про k8s и не только;
🟣 шутки от Всеволода Севостьянова;
🟣 подарки для победителей — футболка в стиле нашего канала для лучших в Kubernetes🔥

5 минут вам на сборы и встречаемся в 19:00 мск.

➡️ Ссылка для входа тут.

Поздравляю победителей Quizbernetes 🥳

🟠rachiy
🟠Test user
🟠mrg1790
🟠EgorkiN

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

Абсолютно всех участников благодарю за игру, было здорово! Поделитесь обратной связью, что понравилось, что нет, какой вопрос зацепил?

APF

Вчера на Quizbernetes подняли вопрос, что APF — тема, в которую если и влезаешь, то раз в год, когда под нагрузкой API-сервер начинает либо отклонять запросы, либо обрабатывать дольше обычного. У вас же есть метрики и алерты на API-сервер?🙃

➡️ Вот пример инцидента, которого могло бы не быть, или импакт которого был бы сильно ниже, будь APF правильно настроен. Да, ChatGPT лежал несколько часов, потому что ноды заддосили API-сервер. Хоть постмортем и не упоминает явно APF, по описанию ясно, что API-сервер был перегружен запросами, связанными с телеметрией.

🟣Проблема

Через API-сервер проходят все запросы в кластере. В нагруженных кластерах он может стать узким местом. Все компоненты общаются друг с другом строго через API-сервер.

🟣Разберём, что такое APF и зачем он нужен?

APF (API Priority and Fairness) — это механизм, который позволяет k8s управлять приоритетами API-запросов от разных компонентов и гарантировать больше любви более критичным компонентам. А остальные как-нибудь переживут 😌

🟣 APF особенно полезен:

➡️ В кластерах с большим количеством узлов и подов.

➡️ Если нагрузка на кластер сильно колеблется, например, в зависимости от времени суток. APF помогает сохранять стабильность без необходимости скейлинга control plane под пиковые нагрузки, которые могут возникать пару раз за сутки.

➡️ Если ресурсы API-сервера ограничены и не хочется тратить $ на скейлинг. APF помогает более эффективно их использовать за счёт отклонения/откладывания части запросов.

➡️ Разнородные workloads – если в кластере работают приложения с разными требованиями к API k8s. APF позволяет приоритизировать более важные запросы.

🟣 На что это похоже?

Конечно же, на rate limiter. Но со своими нюансами, включая хитрые настройки очередей для обслуживания запросов.

🟣 Нужно ли лезть в APF для маленьких кластеров?

В небольших кластерах APF обычно работает из коробки с настройками по умолчанию, и вы, скорее всего, никогда туда не полезете. Даже и знать не будете о его существовании. Но, тем не менее, метрики APF важны — например, для алертинга, чтобы не пропустить момент, когда нагрузка выросла и кластер стал менее стабильным.

В следующий раз расскажу, когда нужно лезть в APF и как его настроить, а вы поделитесь, сталкивались ли с APF в работе?

#kubнапальцах

Как ИИ меняет работу уже сейчас

Делимся сочными инсайтами из нашего эфира по AI-adoption с Павлом, Senior Engineering Manager, который отвечает за Growth Unit в компании Wrike — одной из крупнейших платформ для управления проектами.

Полная запись здесь: YouTube | VK | Rutube

А для тех, кто любит читать — выжимка главного⬇️

🟣В командах Павла ИИ используют по двум фронтам:

Для разработчиков (в процессе работы):

🟠 Почти все инженеры используют AI-ассистенты для написания кода, например, Cursor и GitHub Copilot.
🟠 AI-powered код-ревью: перед тем как отдать код на проверку живому человеку, его прогоняют через ИИ.
🟠Внутренний AI-портал: это чат-бот, подключенный ко всей документации компании. Если разработчик не знает, как работает какая-то часть продукта, он может быстро спросить у бота.

А в продукте для клиентов есть:

🟠 ИИ-ассистент помогает создавать задачи и проекты. Можно в свободной форме написать, что нужно сделать, а он сам создаст структуру.
🟠 Внутренний "Copilot", которому можно написать: "Дай мне статус по всем моим проектам" или "Суммируй апдейты по моим последним задачам".

➡️ИИ не заменяет разработчиков, а усиливает их навыки.

Для опытных инженеров это мощный инструмент. Он помогает быстро решать рутинные или сложные задачи, например, искать неочевидные баги. Один из примеров: баг, где дни недели считались от 0 до 6 вместо 1 до 7, был найден за несколько минут с помощью ИИ, хотя раньше на это ушли бы дни.

Для новичков это может быть опасно. Если не знать, какой результат ты хочешь получить, ИИ может сгенерировать много некачественного кода, который потом будет сложно исправлять.

▶️Нужно заранее знать, что ты хочешь получить от ИИ, и четко формулировать запрос. Просто сказать "сделай мне хорошо" не сработает.

Что будет с инженерами разных грейдов?

Роль сеньоров меняется. С одной стороны, они могут избавиться от рутины и сфокусироваться на сложных задачах, вернув удовольствие от работы. С другой — есть риск погрязнуть в ревью тонн кода, сгенерированного джунами с помощью ИИ.

С джунами ситуация сложная. Найм младших специалистов сильно сократился. Компании предпочитают брать более самостоятельных инженеров, так как работа джуна требует постоянного контроля, а с ИИ цена ошибки новичка может быть выше.

Главная проблема с ИИ — безопасность🛡

Большой барьер, особенно для B2B-компаний, — это юридические вопросы и безопасность данных. Клиенты не хотят, чтобы их данные передавались для обработки внешним вендорам вроде OpenAI.

Возможное решение: хостить open-source модели у себя (in-house). Это снимает проблему с данными, но создает новую — это очень дорого с точки зрения железа (GPU).

Больше деталей и крутых примеров — в полной записи эфира.

↘️А как у вас? Используете ИИ в работе? Что он ускорил, а где создал проблемы? Делитесь в комментариях!

А вот теперь да — курс «Kubernetes для разработчиков» стартовал!

7 недель разработчики будут учиться:

➡️ самостоятельно разрабатывать и разворачивать приложения в Kubernetes;
➡️ настраивать конфигурации для приложений в кластерной среде;
➡️ строить CI/CD-пайплайн для Kubernetes;
➡️ разворачивать локальную dev-среду с Minikube;
➡️ понимать, как устроены и взаимодействуют компоненты кластера;
➡️ запускать Job и CronJob;
➡️ разбираться с авторизацией и дебагом в кластере и др.

Почти 80% программы — практика и работа со стендами.

Ссылка для тех, кто чуть всё не пропустил, тут.

Как настроить APF?

Продолжаем разговор про то, как управлять приоритетами API-запросов.

🟣 Кейсы, когда нужно лезть в APF

В большинстве случаев настройки APF подходят по умолчанию, но есть ситуации, когда требуется ручная настройка:

🟠 Нехватка ресурсов API-сервера
Если вы наблюдаете проблемы с доступностью API-сервера, несмотря на то, что ресурсы узлов control plane кажутся достаточными, — возможно, APF ограничивает запросы. Это можно понять по метрикам. Например, apiserver_flowcontrol_rejected_requests_total

🟠 Странное поведение операторов/контроллёров
Если какие-то операторы или контроллёры работают некорректно из-за ограничений APF, необходимо проверить их конфигурацию и, возможно, увеличить их приоритет.

🟣 Как настроить APF?
APF настраивается с помощью двух основных типов ресурсов:

➡️ PriorityLevelConfiguration: определяет уровни приоритета для API-запросов;
➡️ FlowSchema: матчит входящие запросы с определенными уровнями приоритета.

Пример настроек для нод, чтобы они могли сообщать в API-сервер свой статус. Вы же не хотите, чтобы ноды отвалились из-за того, что они не смогли вовремя отправить heartbeat?)

k get flowschemas.flowcontrol.apiserver.k8s.io system-nodes -o yaml

Ключевой пункт — priorityLevelConfiguration, который указывает, какой priority level применяется к запросам от нод кластера. Здесь это system .

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  ...
spec:
  distinguisherMethod:
    type: ByUser
  matchingPrecedence: 500
  priorityLevelConfiguration:
    name: system
  rules:
  - nonResourceRules:
    ...
    resourceRules:
    ...
    subjects:
    - group:
        name: system:nodes
      kind: Group

k get prioritylevelconfigurations.flowcontrol.apiserver.k8s.io system -o yaml

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

spec:
  limited:
    lendablePercent: 33
    limitResponse:
      queuing:
        handSize: 6
        queueLengthLimit: 50
        queues: 64
      type: Queue
    nominalConcurrencyShares: 30
  type: Lim


status:

Это, пожалуй, главное, что нужно знать про APF.

#kubнапальцах

Вы знали, что вышел Go 1.25?

Наконец-то мы получили из коробки container-aware GOMAXPROCS! Теперь Go runtime автоматически определяет, какие лимиты CPU заданы для контейнера.

🟠 Почему это важно?

До Go 1.25 GOMAXPROCS по умолчанию определялся количеством CPU ядер на хосте. К чему это могло привести ➡️ процесс в контейнере считал, что ему выделено больше ядер, чем есть на самом деле. Как следствие, ядро начинало троттлить процесс. Это всё выливалось в проблемы в tail latency (запросы за 99-м перцентилем могли иметь время ответа сильно выше медианы, если говорить про http API).

🟠 Как мы раньше-то жили?

В основном полагались на пакет uber-go/automaxprocs. Он автоматически выставлял GOMAXPROCS на основе CPU limits, определенных в cgroup.

🟠 Что изменится?

➡️ Исключается целый класс проблем, когда приложение отлично работает в dev/test окружении, но в проде, под высокой нагрузкой, начинается троттлинг на CPU. Это приводит к тормозам.
➡️ Учитывается автоскейлинг, где CPU лимиты могут меняться динамически. Go runtime периодически тюнит GOMAXPROCS с учетом изменений.

🐈 Так что если вы еще не обновились, или даже не слышали о такой проблеме для go-сервисов, есть шанс, что обновление go до 1.25 заставит ваши приложения работать быстрее. Но это не точно🙂

Детальнее можно прочитать в блоге golang.