В последнее время вообще нет времени и идей что сюда писать)

Как же хорошо, что есть другие люди, которые исследуют крутые штуки и пишут интересные статьи в этом вашем интернете.

Вот очень интересный разбор на тему: "Почему лимиты на CPU - это от лукавого и, возможно, уже стреляет вам в колено в ваших кластерах"

https://medium.com/@alexandru.lazarev/cpu-limits-in-kubernetes-why-your-pod-is-idle-but-still-throttled-a-deep-dive-into-what-really-136c0cdd62ff

Synology, (контора, которая делает очень популярные решения на рынке хранения данных) под очень благородным предлогом:

поскольку оценка состояния жестких дисков имеет важное значение как для личного, так и для профессионального использования, это создает необходимость использовать собственные или эквивалентные диски

По факты запрешает в своих новых решениях (Synology Plus) использовать диски не своего производства (ну или производства компаний-партнеров).

Как бы понятно, что компании, которые вибирают Synology, делают это не из соображения экономии, но диски у Synology, помимо того, что безумно дорогие, так еще и нифига не надежные.

Ну такое...

https://www.hardwareluxx.de/index.php/news/hardware/festplatten/65949-synology-weitet-den-zwang-zur-eignen-oder-zertifizierten-festplatte-auf-die-plus-modelle-aus.html

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

В чём проблема?
Когда у init-контейнеров указаны requests больше, чем у основных контейнеров в поде:
1️⃣ Распределение ресурсов в кластере работает некорректно.
2️⃣ Grafana врёт на графиках утилизации, игнорируя «прожорливые» init-контейнеры.

Представьте, что вас есть pod, у которого для initContainer'a в requests указано:

    resources:
      requests:
        cpu: 100m
        memory: 500Mi

А для обычного Container'a что-то типа:

    resources:
      requests:
        cpu: 20m
        memory: 50Mi

Получается для планирования контейнеров pod'a на ноды будут учитываться максимальные реквесты (реквесты initContainer'a) и эти же ресурсы будут "зажаты" pod'ом и Kubernetes Shceduler будет считать, что эти ресурсы недоступны для планирования) Хотя по факту основной контейнер не использует столько ресурсов)

Так же Metrics Server при сборе информации о потреблении, лимитов и реквестов ресурсов не учитывает, что указано в initContainer. То есть для такого pod'а kubelet "зажал" 100m и 500Mi, однако в метриках эти ресурсы будут считаться свободными)))

(Почитать про это можно тут)

Вы можете объективно заявить: "Какой дурак будет делать такие ресурсы для InitContainer'a". А я отвечу: "Да кто угодно, бл*ть". Вот например RabbitMQ оператор этим грешит. (Хотя ребята норм уже одобрили MR, чтобы пофиксить проблему)

P.S. В приложенных файлах небольшой Go-скриптец, который пробежится по всему Kubernetes кластеру, который у вас подключен в Kube Context, и подсветит все pod'ы, у которых initContainer реквестит больше, чем основной контейнер. У меня в самом жирном кластере нашлось 2462 таких pod'ов

3 часа назад в Kaniko прилетел последний коммит, который оповестил о похоронах продукта.

🧊 This project is archived and no longer developed or maintained. 🧊

Теперь только ансекьюрный dind.

Может у кого есть подходы, как запускать билды в контейнерах без привелегий? Я давно этим не занимался, даже интересно

Kubernetes Gateway API - новый стандарт обработки трафика в Kubernetes. (Замена Ingress в том числе).

Недавно появился очень наглядный Benchmark имплементаторов Gateway API
https://github.com/howardjohn/gateway-api-bench

Очень советую к изучению! Сам в продакшн среде использую Envoy Gateway. (Хотя и не замечал ошибок, про которые говорится в тестах)

https://github.com/minio/minio/issues/21714

А минио все. А минио больше не опенсорс