Тут в Nginx недельку назад приехал занимательный MR - https://github.com/nginx/nginx/pull/567

Суть его простая - добавить в дефолтные страницы ошибок Nginx переключение между светлым и темным режимом в соответствии с системными настройками.

Так вот. За эту веселую неделю этот MR закрывали уже раза 3. Потом переоткрывали и возвращались к обсуждению. Все начиналось более-менее лояльно, если не учитывать как "вызывающе" автор оформил сам MR, но в какой-то момент все скатилось в пассивную агрессию и личные оскорбления.

Люблю OpenSource ❤️

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

Do not tell me to stop. It's not your prerogative to tell me what to or not to do. Despite your interpretation, I'm not causing harm here.

No, I was planning on shutting up because you're rude and disrespectful. You seem hellbent on continuing that course.

And again, if you take one thing out of this conversation, it's that it is wholly inappropriate to tell a person who is attempting to have a civil discussion to stop or to gaslight them by telling them what they do or do not care about.

Долгое противостояние закончилось тем, что команда Nginx закрыла комментарии к PRу.

Эта битва была легендарной!

Учитывая страстный и жаркий характер этого обсуждения, мы решили закрыть комментарии к этому PR

2 дня назад Cloudflare представило AI Labyrinth — новый метод противодействия, который использует сгенерированный ИИ-контент для замедления, дезориентации и истощения ресурсов AI-краулеров и других ботов, игнорирующих директивы «не сканировать». При подключении функции Cloudflare автоматически развертывает набор связанных ИИ-сгенерированных страниц при обнаружении подозрительной активности ботов, без необходимости для клиентов создавать собственные правила.

AI Labyrinth доступен на добровольной основе для всех клиентов, включая пользователей бесплатного тарифа.

https://blog.cloudflare.com/ai-labyrinth/

У Ingress NGINX (который от сообщества Kuberenetes, а не от NGINX) вчера вышел релиз, на которой реально надо переезжать, т.к. он фиксит 5 жестких CVE, один их которых с рейтингом 9.8 (из 10. Это много. Очень)

В блоге Kuberentes есть небольшая статья на эту тему. Так же на Github есть репозиторий, где есть примеры как проэксплуатировать этот баг. (Там есть пара ошибок, но наглядко видно в чем проблема). Если вкратце - любой, у кого есть доступ к сетке pod'ов - есть возможность создавать ingress'ы. Причем обычные network policy вам не помогут, т.к. для создания ingress'а нужен доступ к namespace где развернут ingress-nginx, а все обычно дают фулл сетевой доступ к этому namespace.

Если вы, как и я, не можете по какой-то причине быстро обновить ingress-nginx есть пару лайфхаков, которые временно вас обезопасят:
1. Отключите validation webhook у ingress-nginx нафиг вообще. Именно через него эксплуатируется уязвимость.
2. Если не можете отключить - настройте networkpolicy, чтобы в namespace с ingress controller'ом нельзя было достучаться к Webhook port'у ни у кого, кроме kube-system (от туда Kuberentes API будет стучаться для валидации ресурсов)

#zvlb_musle #cve

Забавно, что F5 (компания, которая владеет NGINX) пришлось в блоге написать целую статью, что они не имеют никакого отношения к этим CVE и у них лапки :)

https://www.f5.com/company/blog/nginx/which-nginx-ingress-controllers-are-impacted-by-cve-2022-4886-cve-2023-5043-and-cve-2023-5044

Cloudflare не останавливается в радостях и интересностях для IT-сообщества.

Пару дней назад в своем блоге они представини новый tool - OPKSSH.

Мы уже давно привыкли на все системы подряд заходить используя OpenID Connect (OIDC). Причем это касается как корпоративных порталов, где используется внутренний SSO, так и всяких внешних систем, где вы можете авторизоваться с помощью, например, google-почты.

В общем теперь можно настроить аутентификацию по SSH на сервера с помощью OIDC. ОГОНЬ

#it_news #ssh #oidc

Flant выложил в OpenSource свой Prom++
На прошлой неделе Flant открыл исходный код своей внутренней разработки — Prom++ (GitHub). Подробный разбор продукта есть на Хабре (статья).

Коротко о главном:
Prom++ позиционируется как «улучшенный Prometheus» с в 7-8 раз меньшим потреблением ресурсов

Мои мысли вслух:

1. Двойственное отношение к продуктам Flant:
С одной стороны — их решения часто топовые.
С другой — почти все их «фишки» завязаны на коммерческий продукт Deckhouse. Хотелось бы видеть больше open-source-решений, которые можно использовать независимо.

Пример: их Log Shipper — отличная штука, но без Deckhouse не работает. Пришлось делать свой Vector Operator 😅. В идеале — коллаборация сообщества и Flant, но пока их модули развиваются только «внутри» их платформы.

2. Про Prom++:
- Лицензия Apache 2.0 — пока всё открыто.
- Но... (спойлер: есть подозрение, что бесплатный сыр может оказаться в мышеловке Deckhouse 🧀. Как мы недавно наблюдали что-то похожее с Grafana On Call). Однако тут я не уверен. Через пару-тройку лет увидим.

3. Сравнение с VictoriaMetrics:
Главная «киллер-фича» VictoriaMetrics — встроенная кластеризация. Prom++ её не предлагает, а для многих проектов масштабирование важнее экономии RAM.
Личный вывод: экономия памяти в 2-3 раза — это круто, но без горизонтального масштабирования для больших инсталляций VictoriaMetrics останется фаворитом.

P.S. Всё равно попробуем задеплоить Prom++ в нашем кластере и сравнить с VictoriaMetrics.

#zvlb_musle #Prometheus #VictoriaMetrics

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

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

Вот очень интересный разбор на тему: "Почему лимиты на 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

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