Поздравляю победителей 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.

Зачем обсуждать последний iPhone, если можно поговорить про новый кубер?

Из каждого утюга сегодня летят новости от Apple, а между тем Kubernetes ничем не хуже. Он вполне cебе живой и бодрый организм, и новые релизы выкатывает даже чаще, чем яблоко. Версия 1.34 вышла, между прочим, совсем недавно, в конце августа.

Подробный обзор новых фич подготовили коллеги из Фланта, а я пройдусь по самым интересным для меня нововведениям.

🔷 Dynamic Resource Allocation with structured parameters

Не секрет, что AI захватил рынок потребления электричества посредством нагревания GPU. Dynamic Resource Allocation помогают драйверам устройств сообщать обратно в k8s свои возможности и ресурсы. Например: объём видеопамяти, какие функции поддерживаются, и можно ли шарить GPU между подами.

Теперь драйверы публикуют объект ResourceSlice, таким образом давая возможность scheduler более корректно выполнять свою работу.

apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: example
spec:
  nodeName: worker-node-1
  pool:
    name: my-gpu-pool
    generation: 1
    resourceSliceCount: 1
  driver: dra.example.com
  sharedCounters:
    - name: gpu-memory
      counters:
        memory:
          value: 8Gi
  devices:
    - name: gpu-1
      consumesCounters:
        - counterSet: gpu-memory
          counters:
            memory:
              value: 8Gi

​
🔷 PreferSameNode теперь beta

Роутинг трафика со сложными правилами — это вам не котиков гладить. По умолчанию k8s распределяет между всеми подами, независимо от их физического расположения (даже в другом ДЦ). Это может привести к нестабильной latency.
Для решения этого вопросы можно использовать политики распределения трафика:

➡️ PreferSameNode: по возможности трафик не покидает ноду, если целевой под находится на той же ноде, где источник запроса.
➡️ PreferSameZone: существующая политика PreferClose была переименована в PreferSameZone, что точнее отражает её суть.

Примеры:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  selector:
    app: workload
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  trafficDistribution: PreferSameNode # Либо PreferSameZone

​
Prefer же значит: если нет нужного пода на ноде (PreferSameNode), или в той же AZ (PreferSameZone), то трафик польётся туда, где запущен нужный под.

А что ближе вам: iPhone или k8s 😌?

❤️ — если яблоко
👍 — если кубы
🤔 — хоть разорвись