Вы знали, что вышел 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 😌?

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