А вот теперь да — курс «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 😌?

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

Вы знали, что необязательно читать талмуд книг в Google, чтобы постичь основные концепции SRE?

Компании наконец-то догадались, что стабильный продукт — это неплохо. (Вот это поворот 😉)
Каждая минута простоя стоит как крыло от Боинга, поэтому все начали дружно «делать надёжность». И, конечно же, делать её правильно — по канону SRE. Ведь где SRE, там аптайм в стиле 99.999999999%.

Книги у Google по теме есть. Но давайте честно: кто их реально читал? Я вот осилил целиком одну, остальные — кусочками.

Что обычно вспоминают, когда речь заходит про SRE? Ну, SLI/SLO/SLA (куда без них), «actionable alerts» (чтобы не будили зря в 3 ночи) и ещё пару модных слов. В теории всё просто: знай определяй SLA, делай правильные алерты, а неправильные — не делай. В реальности всё куда сложнее 🐈

🟠 Но тут нам на выручку пришли добрые люди и сделали выжимку главных идей из гугловских книг в формате микро-уроков. Так что, если хотите быстро получить цельное представление о SRE (google edition, конечно же) и сэкономить кучу времени, добро пожаловать сюда ➡️ https://sre.in100.dev

До сих пор думаете, что SRE это только SLA и ничего больше?

Да-да, я постоянно сталкиваюсь с мнением, что SRE полезен только тогда, когда случился алерт 🙄
Надо ли говорить, что такое мнение, меня, мягко сказать, фрустрирует? 😅

Потому что в реальности можно придумать квантиллион задач! Пройдёмся по примерному списку того, чем SRE обязан заниматься на любом проекте. Естественно, в каждой компании функции будут адаптированы под цели проекта. Но база примерно одна⬇️

🟠 Построение надёжной архитектуры
Сюда входит всё: начиная от настройки правильных таймаутов/ретраев в сервисах, чтобы не создать retry storm, заканчивая применением подходов chaos engineering и проведением учений по отказу ДЦ.

🟠 Инцидент-менеджмент
Тут правильная реакция на алерты, эскалации при необходимости, ведение инцидентов с разделением ролей (incident manager, communication lead, scribe, etc.) и многое другое.

🟠 Постмортемы
Потушенный инцидент ведёт к созданию документа, который подсветит слабые места. С его помощью приоритизируют задачи, которые нужно сделать, чтобы не допускать повторения подобных инцидентов в дальнейшем.

🟠 Наблюдаемость aka observability, она же телеметрия
Это не только метрики, логи и трейсы. Мало просто генерировать сигналы работы системы, нужно их правильно использовать, строить на их основе actionable alerts, которые ещё будут и нешумными и не будить ночью.

🟠 Автоматизация
Любые ручные действия в любой части системы, будь то сложный процесс деплоя с ручной правкой конфигов либо элементарные quality gates, которые работают на основе human review, а не на основе линтеров. Нет линтера, подходящего для твоего кейса — напиши, что ж не как SRE-то, вручную проверяешь на ошибки IaC код?

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

🟠 Кросс-командная коммуникация
Крайне важно командам разработки доносить важность инструментария компании, правильные настройки различного тулинга, процессы работы с инцидентами, ownership частей системы.

🟠 Обучение/менторство
Проведение воркшопов, q&a сессий и прочих форматов передачи знаний. Даже если кажется, что тема «как правильно строить алерты» очевидна, всегда найдётся, кому это будет полезно. И, конечно же, написание документации.

🟠 Управление рисками
Да, неплохо бы понимать, насколько надёжны все те вендоры, что вы используете, для вашего бизнеса, и какие у них SLA. И речь не только про облака, а вообще про любые решения, даже если они деплоятся в вашу инфраструктуру, но обслуживаются снаружи.

🟠 Архитектурные комитеты
Любые значимые изменения в инфраструктуре, сервисах, продукте, должны проходить через такой комитет, куда собираются, в зависимости от характера изменений, люди из разных подразделений (например, из команд service mesh и dbaas). И цель этого не соблюдение бюрократии, а получение фидбека на предлагаемое решение и подсвечивание возможных рисков. Потому что невозможно знать всё, и может случиться так, что решение нужно пилить совсем по-другому, иначе прод развалится через квартал под нагрузкой.

🟠 Определение SLI, SLO, SLA
Добрались и до них)) И до построения поверх них actionable alerts, желательно на основе multi window, multi burn rate alerts. Подробнее об этом тут.

Помимо определения SLA существует ещё огромное количество крайне нетривиальных задач, и SRE должен уметь с ними справляться.

А что добавили бы вы? Или, может, с чем-то не согласны?

Зачем бизнесу и командам DevSecOps?

На следующей неделе состоится бесплатный вебинар, на котором вы соберёте картинку взаимодействия Dev, Sec и Ops и выясните, почему DevSecOps в проекте — это необходимость, а не дань моде.

Спикеры последовательно, от принципов к практике, разберут, как:
🟣интегрировать сканеры в CI/CD так, чтобы они не мешали;
🟣разрулить конфликт между Dev, Ops и Sec раз и навсегда;
🟣 масштабировать безопасность без увеличения команды;
🟣 получать бюджет на безопасность у бизнеса без запугивания;

📅 Когда: 25 сентября, в 19:00 мск.

Спикеры:
▶️ Андрей Сухоруков, Team Lead DevOps/SRE/DevSecOps Лаборатория Касперского
▶️ Мария Шеховцова, руководитель группы архитектуры и анализа, Positive Technologies
▶️ Артём Пузанков, руководитель группы внедрения практик безопасной разработки, Positive Technologies

➡️ Получить напоминания и ссылки на подключение — в боте.

Как мониторить сложные пайплайны

Думаю, вы встречались с задачей: надо получить алерт, когда сервис начнет 500-тить. Или когда latency вырастет за пределы 500 мс.

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

Вернёмся к тому, как следить за сложными пайплайнами.

➡️ Простое решение — алерты на длину очереди. Работает в простых ситуациях, но фиксированный threshold — неудобно и может алертить даже тогда, когда проблем нет.

➡️ А что лучше?
Мониторить то, что действительно важно — сколько времени данные проводят в пайплайне. Сравниваешь метку времени инджеста пачки данных в начало и когда они вышли в конце — вот и время обработки. Если данные идут непрерывным потоком, этого достаточно. Если же бывают паузы, добавляешь heartbeat сообщения, чтобы заполнить очередь (код пайплайнов должен уметь правильно обработать, а это ой как нетривиально добавить, если заранее об этом не подумать). Ещё это можно назвать синтетическим тестом, который проверяет, что вся инфраструктура пайплайна в целом как-то работает.

А что если процессинг реально долгий? Был тормоз на входе — алерт прилетит сильно позже, когда сообщение доедет до конца пайплайна. И тут возвращаемся уже к загруженности очередей. Но не просто к больше чем 100500 сообщений в очереди, а в условиях, если она растёт! В PromQL это что-то типа deriv(my_awesome_kafka_queue_size[30m]) > 0 — то есть производная от скорости роста длины очереди.

🐈 Чувак, а где же здесь про кубер?
😏 А ничо тот факт, что сейчас пайплайны крутятся в кубере?) Да ещё и с автоскейлингом, как мы любим, чтобы экономить средства, изображая finops.

#kubнапальцах

Сколько реально нужно времени, чтобы найти нормальное место работы?

И закинул старик невод в море и стал ждать…
Мне вот интересно, сколько вы искали своё место работы? В последние годы рынок изменился, давайте пройдёмся по самому длинному ожиданию в период, скажем, после 2023г⬇️