https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/5080-ordered-namespace-deletion#proposal

Как-то упустил, но с 1.33
В альфе появилась фича OrderedNamespaceDeletion. То есть сперва удаляют поды, а уже потом остальные ресурсы. Позволяет избежать проблем с финалайзером и с тем, что удаляются нетворкполиси, и на какое-то время поды становятся не защищенными.

https://engx.space/global/en/blog/kubernetes-the-good-the-bad-the-truly-awful
Почему-то большинство статей с критикой кубернетеса похожи на Орнитомим - беззубого динозавтра. Все сводится обычно к too complex и multi-tenancy. Если первое - слабый наброс. То второе - правдиво, но уже скучно. Мир принял, что в этом вопросе в кубе нужны костылища.
Критикуешь предлагай? Попробую сам накинуть:
1. Статик полиси и в частности full-pcpus-only - это что-то очень странное. Например full-pcpus-only многих вводит в конфуз, так как не удаляет CPU ядра из DefaultCPUSet, а меняет алгоритм выбора ядер и дает некие слабые "гарантии", что у контейнера будут использоваться одни и теже ядра в рамках жизни контейнера. То есть это никакой не пининг ядер под ваш контейнер. Еще более простым языком - от cpu троттлинга не спасёт. Сам KEP ставил своей целью помочь CNF, HFT, ML/AI. Но из-за этой его "особенности", на сколько мне известно и из моего опыта его не юзают. (Но если есть валидные примеры где оно помогает в проде, мне интересны, уверен, такие есть, просто я о них не знаю).
2. ETCD и List вызов. Понятно, что etcd и куб идут рука об руку все эти годы. Понятно, что выбор etcd на ранних этапах разумен. Но все таки большие ограничения в кубе - это в etcd. Оно и понятно, вряд-ли в coreos когда ее пилилм, думали что БД которая планировалась как сторадж для метаданных, будет упираться в 8 гигов данных, вельюсах в 1,5 мегабайта или ... сложные селеты по лейблам. Более подробно об этой боли тут. Если коротко: etcd настолько простая, что весь поиск по лейблам за нее делает api-server, и из-за этого операция List, даже если вы указываете лейбл, становится дорогой. Из-за этой же особенности etcd и архитектуры api-server появилась проблема со stale reads которую проде пофиксили, но не совсем.
3. Кажется на развитие statefulset api вообще забили. Ограничения в ordered при апгрейдах, имьютебл поле volumeClaimTemplates. Хорошо есть advanced statefulset от kruise, который решает эти многолетние боли в core апи куба в стейтфулсете.
4. Шардирование операторов. По-сути его нету. Сейчас единственный нормальный способ шардироваться - это вотчить ресурсы по опреденным лейблам/неймспесам. Но на этом все. Была попытка у kruise, у gardener несколько вариантов, но в core на это пока не обращают внимание.
5. Не секрет, что service api, довольно переизбыточное api, с которым работают многие компоненты, и которое непонятно уже за что отвечает. И это не моё мнение, а мейнтейнера. Но если бы это было только в этом проблема. Гибкости роутинга трафика можно сказать нету. Выставлять разные виды балансировки в кубе по-сути может только kube-router, но ценой отсутствия preserve source ip. Распределять трафик по зонам, это скорее набор костылей, в частности Topology Aware Routing, где Expected ratio = sum of vCPU of nodes this zone / sum of vCPU cores of all nodes in cluster. А реализацию PreferZone, описаную в kep 2433 таки не завезли. Нет возможности сделать failover с interaltraficpolicy: local на cluster. Хотя обсужения идут ни один год. Ну и постоянные переименовывания ресурсов в этом api тоже помогают запутаться.
На этом я наверное все. Тоже недостаточно, но мне кажется чуть больше технической боли, чем в подобных статьях

https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/5311-relaxed-validation-for-service-names#summary

Неожиданно, c 1.36 хотят сделать allowing Service names to start with a digit. Я даже не знаю, как к этому относиться, наверное это норм :)

https://matduggan.com/what-would-a-kubernetes-2-0-look-like/

Ещё один взгляд, что было бы хорошо в куб 2.0 сделать. Кроме очевидной замены etcd, я ни с чем не согласен. Особенно мне странно читать про HCL и ещё один пакетный менеджер. Но всё же мысли озвучены

https://news.ycombinator.com/item?id=44317825

Ну вот уже пошли решения (относительно популярные), с использованием nri https://koordinator.sh/docs/designs/nri-mode-resource-management

Конктрено тут патчинг environment variables, policies и qos как в рантайме, так и до запуска контейнеров

Ещё один контроллер терраформа, от .... лего :)
https://github.com/LEGO/kube-tf-reconciler

Кажется, не многие знают, что даже после завершения работы initcontainers , requests все ещё учитываются при шедулинге. Наверное ещё меньше, почему принято такое решение. Если интересно, то вот обсуждение, почему было так сделано https://github.com/kubernetes/kubernetes/issues/124282

То, что не удалось (по крайней мере в публичной плоскости, ссылка на мой пост об этом в реплае) OVH, удалось реализовать clever cloud. Etcd api-compatable поверх foundationdb. Технической информации мало, но очень интересно. То есть ребята сделали тоже, что гуггл со своим spanner.
Вообще, попытки прикрутить api etcd к foundationdb прям впечатляют своей частотой. Вот еще один эксперимент который неразвился во что-то большее https://github.com/PierreZ/fdb-etcd. Это уже больше чем я видел попыток с другими бд.
Но я думал, что скорее появятся новости про замену etcd в кубе с использованием xline-kv https://github.com/xline-kv/Xline (там где стреляют ограничения etcd) Тем более она попроще foundationdb. Но за два года таких статей мне не попадалось. Да и в целом, проект кажется не очень выстрелил.

Если у user или sa есть права на создание ролей в кубе, но в создаваемой роли навесить права, которых у данного user или sa нету, то куб не даст их назначить. Это часть RBAC privilege escalation prevention. Но так как я не ИБ и рубрику вредные советы люблю, то
есть два verbs которые позволяют это обойти: escalate и bind.

https://kubernetes.io/docs/concepts/security/rbac-good-practices/#escalate-verb

30 сентября 2025 должен произойти релиз kubernetes in action. Second edition. В 2018 году, когда я только начал изучать кубернетес, вышло первое издание этой замечательной книги. Когда ее прочитал, ко мне пришло представление как этот ваш кубирнтес работает. С выходом первой книги часть апи изменилось, часть нет, например мало что поменялось в структуре стейтфулсета. Только поведение самого контроллера, он на момент выхода книги, ещё занимался шедулингом подов. Куб и из не очень простой системы, стал еще сложнее. Но концепция и взаимодействие компонетов не сильно. Думаю, для новичков с кубом, второе издание будет так же полезным, как и когда-то первое.

Все, 65к нод не модно. Eks говорит, мы предоставляем кластера со 100к нод https://aws.amazon.com/blogs/containers/under-the-hood-amazon-eks-ultra-scale-clusters/. Для этого нужно: использовать tmpfs, шардировать ключи (разделить кластера etcd по ключам в kube api), пенести транзакционную модель на кастомный плагин, дождать изменений в кубе 1.31 и 1.33 с констистентным чтением и стриминг пакетов, поправить индексацию в популярных куб контроллер. И вуаля)

Немного про хуки выполняемые кубелетом и их гарантии. Я в целом всегда их избегал. Но однажды появилась идея, выводить реплику из кластера приложения не через оператора, а с использованием preStop (кстати, даже есть действие sleep у него https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3960-pod-lifecycle-sleep-action/README.md). Планировали это сделать ненадолго. Но если зайдет - то нет ничего постоянного чем что-то временное. Но не в этот раз.
Первый случай, хук не отработает если кубелет упал, или удалили ресурс ноды из куба. Второй - иногда могут быть приседания с deletionGracePeriodSeconds, если хук может выполняться долго (не наш случай, но хозяйке на заметку). Третий - была бага у кубелета, когда он просто не выполнял его (сходу не нашел ишью к посту, но тут на доверии же?)). Четвёртый - https://github.com/kubernetes/kubernetes/issues/129907.

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

Судя по тредам этот кеп https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset, которому уже почти 6 лет, имеет шансы перейти в бету в этом году (в 1.34 его не будет, но в 1.35, кто знает). Для пользователей kruise controller она уже доступна несколько лет как. К слову.

https://github.com/cloudnativelabs/kube-router/issues/1715

kube-router - один из простых и надёжных cni, похоже потихоньку умирает. К этому шло, за последние годы фич не появлялось, только фиксы. Да и весь проект живёт, по-сути, на плечах одного человека.

https://github.com/external-secrets/external-secrets/issues/5084
Тут ещё про ESO скинули. Я им не пользуюсь, но проект очень популярный.

https://t.me/ittales/674
Я понимаю, после стольких насмешек сидеро над ссш, им религия не позволит добавить его к себе в ось.
Решение классное с точки зрения инженерной смекалки. Когда есть набор ограничений, а что-то делать нужно.
Но осущестлять подключение через nc для дебага, напоминает анекдот про то, что ёжики плачут, колются, но продолжают есть кактус :)

Не то, чтобы я плохо относился бы к kubespray. Скорее никак, но это выглядит крайней забавно https://github.com/kubean-io/kubean/blob/7db0f824e9acd58c882c94600092c0c1c394dfe8/pkg/util/entrypoint/entrypoint.go#L135

Оператор запускающий kubespray в виде кубернетес джоб

И является частью cncf
https://www.cncf.io/projects/kubean/

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 минут - пагинация начинает работать с кешом. Пока не понял до конца откуда эта магия появляется. Не сильно глубоко копал (может кто знает ответ?). Но довольно неприятный момент.