Кубернетичек

https://kubernetes.io/docs/reference/instrumentation/understand-psi-metrics/ Тем временем, psi метрики перешли в ga в версии 1.36 (в бете с версии 1.34). Да еще и сделали их неотключаемыми. Если кто не знает что это и зачем, можно почитать тут https://t.me/troubleperf/73

https://t.me/ittales/699 Автор этой базы разработчик k0smotron. А вообще, еще было решение когда взяли архитектуру loki/mimir/thanos и других греческих богов и решили сделать на этой etcd-campatable решение с храненим в s3 - https://github.com/nadrama-com/netsy. Но без gossip протоколов и сложной архитектуры, и с jensen тестами, branching лизами и тп. Моё почтение Алексею.

Тут вышла статья https://itnext.io/the-challenge-of-configmap-rollouts-in-kubernetes-1431398c0866 от Brian Grant (одного из оригинальных архитекторов Kubernetes). Статья как статья - ничего особенного, казалось бы, кроме ишью https://github.com/kubernetes/kubernetes/issues/22368. Даже представить не мог, что это может болеть у кого-то ещё в мире, где помимо решений из статьи есть kind: PodTemplate, который можно использовать как версионирование апгрейдов со ссылками на старые Secret/ConfigMap. Да и свой оператор для таких вещей можно быстро написать. Однако, видимо, да - болит. Хотя идея с ownerReferences тоже кажется хорошей: https://github.com/kubernetes/kubernetes/issues/22368#issuecomment-3690555284

Так как автор блога начинал свою карьеру грузчиком мороженного в телекоме, то левым глазом он посматривает, что там в этом телекоме происходит интересного. Про SRv6 меня тема не сильно интересует: драфтов много, решения разных вендоров не совместимы (или не совсем совместимы), и скорее всего решение от Cisco победит, как всегда. В конечном счёте мне кажется, что SRv6 займёт нишевую позицию - вроде как хайп был, а мейнстримом так и не стал (примерно как OpenDaylight и SR-MPLS в своё время). В общем, это скучно, тем более канал про Kubernetes. Но начнём немного издалека. В 2017 году AT&T приобрела у Brocade Vyatta, vRouter и связанные патенты. Планы были космические. В те годы было очень много разговоров про автоматизацию сети, сетевики ненужны, VNF и SD-WAN. И планы были грандиозные - виртуализировать 75% сети к 2020 году. VNF (Virtual Network Function) - это сетевая функция (firewall, NAT, load balancer, роутер и т.д.), реализованная как ПО, запущенное на виртуалках, вместо классического железа. Цель понятна - меньше денег на железо, быстрее катить, масштабировать и тп. А уже 2021 году AT&T продала Vyatta, заявив, что они «смогли» виртуализировать те самые 75%. Зачем такой «успешный успех» продавать - непонятно. Хотя если посмотреть на статью несколькими годами ранее https://techspective.net/2019/06/21/network-functions-virtualization-has-overpromised-and-under-delivered/, то кажется понятным почему. Но как это касается Kubernetes? А собственно, контейнеры, Kubernetes и CNI API - оказался гораздо более удобным и главное понятным там, где нужна была «виртуализация» сети. Ну и Kubernetes стал де-факто стандартом индустрии. Единая платформа, которую все просто используют. Чего не получилось ни у кого из предыдущих попыток (забегая вперёд, мне кажется, коммерческие dev-платформы ждёт такая же судьба по той же причине). То есть NFV погубило то, что ее концепции появились чуть раньше чем выстрелил cloud native подход и что каждый вендор реализовывал их по-своему - совместимость была плохой, а VNF по сути воспроизводили проблемы железа в софтверной обёртке. И когда коммерческие решения начали появляться, сам подход уже оказался устаревшим. Между классическими VNF и сегодняшним днём была целая эпоха тяжёлых оркестраторов - ONAP, OSM и прочих MANO-систем, которые тоже не стали историей успеха. Но концепция переродилась в проект Nephio -https://github.com/nephio-project/nephio. Инициатива пошла от Google Cloud, потом подтянулись другие крупные ребята. Вместе они пытаются сделать Kubernetes-native фреймворк для автоматизации 5G-сетей с современным походом (в презентациях очень много слов про GitOps). Кажется, в мире телекома это сейчас самый интересный проект на стыке Kubernetes и автоматизации сети, тем более современной сети. Не знаю, насколько он выстрелит или нет. Но поглядим. По крайней мере, коммиты и релизы в проекте есть.

Меня в таких историях https://blog.zwindler.fr/en/2026/02/26/kyverno-killed-my-api-server.-again. интересует вот что: многие компании разделяют администрирование кластеров Kubernetes по компонентам - условно, Kyverno и Cilium NetworkPolicy за ИБ-командой, control plane и CNI за кубовыми админами, CSI за командой хранилищ. Как они траблшутят в момент обновления кластера, когда что-то идёт не так? Насколько дольше растягивается инцидент из-за такого разделения? Мол ИБ-команда говорит "наш Kyverno работает штатно", кубовые админы говорят "апи-сервер падает из вебхука в Kyverno". И главное - бывало ли так, что после инцидента кто-то описывал постмортеме "так жить тяжело, надо менять подход"? Спрашивал об этом людей на конференциях - внятного ответа так и не получил.

https://github.com/kubernetes-sigs/multicluster-runtime Клевый проект. Я немного его тестирую. Пока не принято решение, что лучше для нашего проекта: один контроллер пер кластер, и один большой оркестратор на все. Или волбще - гибрид. Проект уже довольно в рабочем состоянии. Но, если брать его сейчас, то нужно быть готовым в след релизе что-то переписывать :) У openkruise было похожее решение, но в него перестали контрибьють уже несколько лет назад.

Люблю openkruise. Он меня уже столько раз выручал. Вот и сейчас, есть задача, чтобы не менялась топология у подов без надобности, нужно чтобы они шедулились на туже ноду, где были (по возможности). И пока я думал, делать это через mutation webhook или писать свой шедуллер, решил глянуть, а не реализрвали ли это уже разработчики алибаба клауд (да, я ленивый человек, если можно не просить ллм писать самому, то этого не делаю). И да, за меня все это уже придумали и реализовали https://openkruise.io/docs/next/user-manuals/persistentpodstate. Просто бери, и ставь аннотацию в advanced statefulset.

Я прикалывался над этим проектом. Не думал, что там может быть что-то серьезное с таким замахом. Оказалось, этот проект идет под крылом китайского аналога Google Summer of Code, только называется он - RISC-V Rust for Cloud Native. Под этим же крылом выпустили https://github.com/rustfs/rustfs, например. Можно было бы подумать, что они это делают, потому что официально разработчики куба не поддерживает RISC-V архитектуру. Но вон, scaleway - вполне собрали бинари и говорят можно пробоваить https://www.scaleway.com/en/docs/elastic-metal/how-to/kubernetes-on-riscv/ (не знаю, насколько это распрастраненное решение). Пызы: вообще, я переодически поглядываю, что там происходит с проектом. Слишком уж он амюициозный. И пока пишут. Так вот, спонсор данного поста, вот этот парень на скрине. А точнее его коммит https://github.com/rk8s-dev/rk8s/commit/a58c9bfa6e926aec598c6642354d4f0b2ed58d71

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

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/fluxcd/helm-controller/pull/1365 Продолжение истории)

Пятничный пост не в пятницу. О вечном споре fluxcd vs argocd. Последние два года работаю с fluxcd. До этого долго деплоился с argocd. В целом мне флюкс нравится, за счет более простой логики, читаемого кода и бережному отношению к kube-apiserver. Но есть вещь от которой не очедь удобно порой. (Было две, но мне кажется одну они поправили, и, возможно, но это не точно, мой контроллер был триггером для этого). Так вот, речь про поведении driftDetection. У driftDetection в helm-controller есть несколько полблем: 1) если driftDetection: warn и есть ресурс в dependsOn то он задеплоил релиз и он может уйдти в статус notReady, и депенсОн не пойдет. Потому что статус helmRelease будет notReady. При этом сам ресус успешно заедплоится. 2)случиться это может если в хельме есть поле которого нет в спеке ресурса. Но опять же, релиз даст задеплоть. Это происходит из-за плохо написаного хельма. С одной стороны это хорошее поведение. С другой - не совсем ожидаеное 3) если русурс был изменен через patch или kubectl edit, то будет запись об этом в managedField. И...helm-controller не будет детектить изменения. Считая что так и надо @lllamnyp предположил, что логичное поведение с 3 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) изменения которые флюкс детектит, выводятся только в дебаг логах контроллера. Сам он только пишет, братан, у тебя n changed detected, разбирайся как знаешь. Инструментов для вывода информации нету для этого. К слову клишку оказалось написать не сложно, нужно просто скопипастить эту часть кода с, внезапно, ... argocd 🫠

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

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

https://github.com/ydb-platform/ydb/pull/16101 В семействе etcd api-compatable прибыл и ydb

http://github.com/bchess/k8s-1m Ну, почему бы и да Ps: single instance с in-memory etcd без постинга лиз и ивентов, а целом, удивился, что не стал лизы и ивенты в отделный етцд, ну да ладно.

https://github.com/fluxcd/flux2/issues/5446#issuecomment-3077427423 В 2.7 версии флаксе.

https://github.com/rk8s-dev/rk8s Это конечно, был вопрос времени :)

https://kubernetes.io/blog/2025/09/04/kubernetes-v1-34-introducing-psi-metrics-beta/ Я хотел написать про psi, но погуглил, кажется вот в этих постах написали более интересно, чем сделал бы я. https://t.me/azalio_tech/5 https://t.me/troubleperf/73 То есть теперь нативно можно получать более подробную информацию о том, как ваши поды контейнеры процессы контролируемые кубом "страдают" от нехватки ресурсов, и страдают ли.

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