https://isovalent.com/blog/post/isovalent-load-balancer/

Так вот почему фичи по ингресс гейтвею в опенсорсе у cilium просели. :) Не осуждаю, это вполне логичное решение. Особенно с ростом количества компаний ориентированых на этот сегмент. Те же tetrate как пример.

https://github.com/nebius/helmrelease-trigger-operator

У fluxcd есть небольшой недостаток один - если изменить конфигмапу/секрет которые указаны в valueFrom - то флакс не заедеплоит его. Тут нужно ручное вмешательство. Данный оператор закрывает данный гап, в момент изменения конфигмапа, триггерит деплой helm контроллера флакса.
Кстати, у козистека есть похожая логика в их контроллере https://github.com/cozystack/cozystack/blob/main/internal/controller/system_helm_reconciler.go

https://github.com/kubernetes-sigs/controller-runtime/issues/3044

https://github.com/kubernetes-sigs/controller-runtime/issues/532

Прям неприятно был удивлён реализации пагинации с кешом контроллер рантайма. Оно как кот Шрёдингера.
И на скольких объектах я не экспериментировал, и сколько бы лимит не выставлял, получал Cached clients return incomplete object lists for paginated list calls. Стоило выкрутить CacheSyncTimeout (2 минут по-умолчанию) повыше, например на 5, 10 минут - пагинация начинает работать с кешом. Пока не понял до конца откуда эта магия появляется. Не сильно глубоко копал (может кто знает ответ?). Но довольно неприятный момент.

https://isovalent.com/blog/post/isovalent-load-balancer-technical-deep-dive/
Подъехали технические детали, и я немного ... разочарован.
Пока все современноеые человечество контроллеры, даже энтерпрайз, идут в gateway api, изовалент стало делать свой crd. Kind: LBVIP - это аналог Kind: Gateway в рамках которого через Gateway.Spec.Addresses можно назначит любой VIP адрес. Ну, сделали и сделали.
Если посмотреть на архитектуру, то там ничего такого, чего бы нельзя было бы сделать в условном cilium + envoy/istio gateway в community edition. Ну ладно, добавили ipip между tier'ами (хотя kube-router это и в режиме dsr делал 7 лет назад).
Ну и ipip это как-то не молодежно, вон флара использует Foo-Over-UDP https://blog.cloudflare.com/high-availability-load-balancers-with-maglev/.
То есть продают они оператор, который может настраивать балансировку между нодами разного назначения tier-1 l4 balancer, и tier-2 l7.

Пызы:
https://highload.ru/2017/abstracts/2946
Видео 2017 года. Что назыается найдите отличия (кроме того, что в статье используется кубернетес и ebpf).

https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/4988-snapshottable-api-server-cache/README.md#summary

В последнее время, все чаще разработчики закрывают старые болячки куба, сперва stale read через стримы пофиксили, теперь и проблему с пагинацией.

https://github.com/melgenek/f8n

Тут подвезли etcdshim для FoundationDB.
Не знаю насколько выживет это вариант, предыдущие варианты быстро забрасывались. Все ещё удивляет, что не tidb, tikv, cocroachdb - а именно foundationdb для скейлинга стораджа куба появляются чаще всего.

https://github.com/kubernetes/kubernetes/pull/127525
С 1.33 при static policy, процессы а подах теперь не будут попадать под cfs quotas. Останется подтюнить cpu manager чтобы изолировал не только кубовые процессы, но и системные- тогда заживём!

https://kubernetes.io/blog/2025/09/04/kubernetes-v1-34-introducing-psi-metrics-beta/

Я хотел написать про psi, но погуглил, кажется вот в этих постах написали более интересно, чем сделал бы я.
https://xn--r1a.website/azalio_tech/5
https://xn--r1a.website/troubleperf/73

То есть теперь нативно можно получать более подробную информацию о том, как ваши поды контейнеры процессы контролируемые кубом "страдают" от нехватки ресурсов, и страдают ли.

https://github.com/rk8s-dev/rk8s

Это конечно, был вопрос времени :)

https://github.com/fluxcd/flux2/issues/5446

С 2.7 версии, флакс теперь будет вотчить изменения вельюсов с секретов и конфигмапов

http://github.com/bchess/k8s-1m

Ну, почему бы и да

Ps: single instance с in-memory etcd без постинга лиз и ивентов, а целом, удивился, что не стал лизы и ивенты в отделный етцд выносить, ну да ладно.

https://github.com/ydb-platform/ydb/pull/16101

В семействе etcd api-compatible прибыл и ydb

https://github.com/kubernetes-sigs/agent-sandbox

Ну что, если кто-то хотел оперделять runtime через CR, то и такое придумали. С большей изоляцией. Надеюсь следующий щас нечто подобное сделают и для CNI без multus :)

После одного инцидента на проде в 2018 году на балансировщике, я запомнил одну вещь - tcp стек неймспейса наследуется от компилированого ядра, а не настроек ядра на хосте. И так я жил все эти годы и был доволен как слон. Но недавно красиво посрамлен сетевиками (а кем же еще?). Потому что оказывается, есть и исключения:
https://github.com/torvalds/linux/commit/356d1833b638bd465672aefeb71def3ab93fc17d
Как видите, коммит из 2017 года. Через год я смотрел код ядра и глаз не запал на это. Смотрел старую версию ядра! Так вот, tcp_wmem и tcp_rmen в network namespace наследуются от настроек ядра на хосте.

Пятничный пост не в пятницу. О вечном споре fluxcd vs argocd.

Последние два года работаю с FluxCD. До этого долго деплоился с ArgoCD. В целом, мне Флюкс нравится — за счёт более простой логики, читаемого кода и бережного отношения к kube-apiserver. Но есть вещь, из-за которой порой не очень удобно. (Было две, но, мне кажется, одну они поправили, и, возможно — но это не точно — мой контроллер был триггером для этого.) Так вот, речь про поведение driftDetection.

У driftDetection в helm-controller есть несколько проблем:

1. Если driftDetection: warn и есть ресурс в dependsOn, то он задеплоит релиз, и он может уйти в статус NotReady, и dependsOn не пойдёт. Потому что статус HelmRelease будет NotReady. При этом сам ресурс успешно задеплоится.

2. Случиться это может, если в чарте Helm есть поле, которого нет в спеке ресурса. Но опять же, релиз даст задеплоить. Это происходит из-за плохо написанного чарта. С одной стороны, это хорошее поведение. С другой — не совсем ожидаемое.

3. Если ресурс был изменён через patch или kubectl edit, то будет запись об этом в managedField. И… helm-controller не будет детектить изменения, считая, что так и надо.
@lllamnyp предположил, что это логичное поведение для three-way merge.

Benefits of the three-way merge:
Smarter Upgrades: Helm 3 can intelligently merge changes from the new chart while preserving manual modifications made to the live state, preventing unintended overwrites.

Но у kustomize-controller совершенно другое поведение в этом месте: https://github.com/fluxcd/kustomize-controller/pull/527

То есть Флюкс как будто своего не придумывает, а мимикрирует под подкапотные инструменты. Но с другой стороны, если у тебя есть два контроллера с разным поведением detection — это прям неочевидное поведение, и тут, возможно, небольшой недостаток продукта.

4. Изменения, которые Флюкс детектит, выводятся только в debug-логах контроллера. Сам он только пишет: «Братан, у тебя n changes detected, разбирайся как знаешь». Инструментов для вывода информации для этого нет.

К слову, клишку оказалось написать несложно — нужно просто скопипастить эту часть кода с, внезапно… ArgoCD 🫠

https://github.com/fluxcd/helm-controller/pull/1365

Продолжение истории)
Пызы: Стефан, похоже одобряет

https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs/

Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта cpu weight для cgroupv2, которую хотят дополнительно разжевать https://github.com/kubernetes/website/pull/52793/files.

Но есть нюанс (не в претензию к статье, она отличная)

What's this static policy about?
With static, Kubernetes can give certain containers exclusive access to CPU cores ... Nothing else would be allowed to run on those cores. That's really useful for apps that don't play well with CPU sharing or need strong cache locality

Это не совсем так. cpu manager обеспечивает изоляцию только между pod'ами kubernetes, а не между всеми процессами в ОС. Системные процессы могут и будут селиться на данные cpu.

https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy

This policy manages a shared pool of CPUs that initially contains all CPUs in the node.... This
shared pool is the set of CPUs on which any containers in BestEffort and Burstable pods run. Containers in Guaranteed pods with fractional CPU requests also run on CPUs in the shared pool.

Вообще непонятно, зачем так сложно писать в доке. Я сам пропустил это, пока на практике не столкнулся, что "эксклюзивность" не эксклюзивная в рамках всей ноды. И даже не всех контейнеров, а только которые контролирует kubernetes. Лишь когда перечитывал доку с какого-то раза, обратил внимание на shared pool.

У Datadog это упомянули, кстати, тоже можно почитать, но на мой вкус она не так интересно читается https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/

https://github.com/etcd-io/etcd-operator
https://github.com/aenix-io/etcd-operator

Вот уже больше года прошло с той, на мой вкус, некрасивой ситуации. Можно сравнить, что получилось. У одного продукта, контрибьютит один человек и минорно. У второго, по-сути двое и то же минорно. Да и в целом развивается ни шатко ни валко. После стартового запала, люди ожидаемо поотпадали и у официального варианта. Может я проспустил что-то, но mailing list практически пуст.
Наверное это логично, потому что etcd особо никому и не нужен. Ну, кроме куба :)