TGViewer
Channel Public Channel
Кубернетичек

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

@k8sjust

Subscribers
1.07K
Photos
14
Videos
0
Links
234
Recent Posts 20 shown
Post #255 941
Перестал писать в этот канал, потому что писать стало нечего :)

Канал, который был создан шутки ради для своих в одном душевном чатике, немного расширился на большую аудиторию. В канале писались вещи, которые автор узнавал в ходе работы или любопытства. Своими руками и временем. Но, в последнее время, мои знания проигрывают умению находить информацию у LLM. Последним гвоздем в гроб была информация, что SyncPeriod не обновляет кэш с kube apiserver. Он лишь инициирует локальный replay объектов из кэша обработчикам событий. К API серверу обращаются только начальный LIST и последующие WATCH, а повторный LIST происходит лишь при восстановлении после ошибок WATCH.``
И изменения эти произошли еще в момент, когда уже работал с кубом, но ещё не писал контроллеры - в 2019 году. А я все время доказывал обратное, что есть релист и от спайков не уйти. Хотя мог бы проверить информацию сам, но это было затратно на чтение кода.

Не знаю, что будет дальше с каналом. Оставлю записи как есть. Заниматься пересказыванием того, что нашло мне LLM - я точно не хочу. Все и без меня это могут сделать, немного потратив свои токены. Писать об ИИ тоже. Об этом уже есть 100500+ каналов. И по качеству лучше.
  • 😢 33
  • 🫡 29
  • ❤ 9
  • 👍 2
Post #254 1.64K
https://kubernetes.io/docs/reference/instrumentation/understand-psi-metrics/

Тем временем, psi метрики перешли в ga в версии 1.36 (в бете с версии 1.34). Да еще и сделали их неотключаемыми.

Если кто не знает что это и зачем, можно почитать тут https://t.me/troubleperf/73
Kubernetes Understand Pressure Stall Information (PSI) Metrics Detailed explanation of Pressure Stall Information (PSI) metrics and how to use them to identify resource pressure in Kubernetes.
  • 👍 14
Post #253 1.93K
https://t.me/ittales/699

Автор этой базы разработчик k0smotron. А вообще, еще было решение когда взяли архитектуру loki/mimir/thanos и других греческих богов и решили сделать на этом etcd-compatible решение с храненим в s3 - https://github.com/nadrama-com/netsy. Но T4 без gossip протоколов и сложной архитектуры, и с jensen тестами, branching лизами и тп. Моё почтение Алексею.
Telegram ITTales :(){ :|:& };: Мне тут закинули интересный проект - T4. По сути это такой git с S3-бэкендом и фронтендом в виде etcd. Снаружи всё выглядит как обычный etcd-compatible datastore, а внутри вместо привычного "храним состояние" - просто поток изменений, который складывается…
  • ❤ 8
  • 🤔 2
  • 👍 1
Post #252 1.88K
Тут вышла статья 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
Medium The Challenge of ConfigMap rollouts in Kubernetes Kubernetes does not roll out changes to ConfigMaps automatically. This discusses the history of the issue and the two prevailing solutions.
  • 👍 3
  • 🔥 2
Post #251 1.58K
Так как автор блога начинал свою карьеру грузчиком мороженного в телекоме, то левым глазом он посматривает, что там в этом телекоме происходит интересного. Про 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 и автоматизации сети, тем более современной сети. Не знаю, насколько он выстрелит или нет. Но поглядим. По крайней мере, коммиты и релизы в проекте есть.
Techspective: A Unique Perspective on Technology Network Functions Virtualization Has Over-Promised and Under-Delivered | Techspective: A Unique Perspective on Technology TechSpective — In-depth analysis, news, and expert commentary on cybersecurity, AI, and enterprise technology. Featuring the TechSpective Podcast and contributor insights from industry veterans.
  • 🔥 4
  • ❤ 2
  • ❤‍🔥 1
Post #250 1.47K
Меня в таких историях https://blog.zwindler.fr/en/2026/02/26/kyverno-killed-my-api-server.-again./ интересует вот что: многие компании разделяют администрирование кластеров Kubernetes по компонентам - условно, Kyverno и Cilium NetworkPolicy за ИБ-командой, control plane и CNI за кубовыми админами, CSI за командой хранилищ.

Как они траблшутят в момент обновления кластера, когда что-то идёт не так? Насколько дольше растягивается инцидент из-за такого разделения? Мол ИБ-команда говорит "наш Kyverno работает штатно", кубовые админы говорят "апи-сервер падает из вебхука в Kyverno". И главное - бывало ли так, что после инцидента кто-то описывал постмортеме "так жить тяжело, надо менять подход"?

Спрашивал об этом людей на конференциях - внятного ответа так и не получил.
  • 👍 11
  • 🤔 4
Post #249 1.83K
https://github.com/kubernetes-sigs/multicluster-runtime

Клевый проект. Я немного его тестирую. Пока не принято решение, что лучше для нашего проекта: один контроллер пер кластер, и один большой оркестратор на все. Или волбще - гибрид. Проект уже довольно в рабочем состоянии. Но, если брать его сейчас, то нужно быть готовым в след релизе что-то переписывать :)
У openkruise было похожее решение, но в него перестали контрибьють уже несколько лет назад.
GitHub GitHub - kubernetes-sigs/multicluster-runtime: Library for multi-cluster controllers with controller-runtime Library for multi-cluster controllers with controller-runtime - kubernetes-sigs/multicluster-runtime
  • 👍 3
Post #248 1.91K
Люблю openkruise. Он меня уже столько раз выручал. Вот и сейчас, есть задача, чтобы не менялась топология у подов без надобности, нужно чтобы они шедулились на туже ноду, где были (по возможности). И пока я думал, делать это через mutation webhook или писать свой шедуллер, решил глянуть, а не реализрвали ли это уже разработчики алибаба клауд (да, я ленивый человек, если можно не просить ллм писать самому, то этого не делаю).
И да, за меня все это уже придумали и реализовали https://openkruise.io/docs/next/user-manuals/persistentpodstate. Просто бери, и ставь аннотацию в advanced statefulset.
openkruise.io PersistentPodState | OpenKruise FEATURE STATE: Kruise v1.2.0
  • 🔥 13
  • ❤ 1
Post #247 3.9K
Кубернетичек https://github.com/rk8s-dev/rk8s Это конечно, был вопрос времени :)
Я прикалывался над этим проектом. Не думал, что там может быть что-то серьезное с таким замахом. Оказалось, этот проект идет под крылом китайского аналога 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

Пызызы: в комментариях заметили, большая часть кода - вендоринг
  • 🔥 8
  • 😁 3
  • ❤ 1
  • 👍 1
Post #246 1.68K
Кубернетичек https://github.com/kubernetes/community/pull/7917 это конечно немного некрасиво со стороны SIG ETCD. Парни начали писать ETCD-operator, подали заявку в SIG - а затем такое https://github.com/kubernetes/community/pull/7917#issuecomment-2137708418
https://github.com/etcd-io/etcd-operator
https://github.com/aenix-io/etcd-operator

Вот уже больше года прошло с той, на мой вкус, некрасивой ситуации. Можно сравнить, что получилось. У одного продукта, контрибьютит один человек и минорно. У второго, по-сути двое и то же минорно. Да и в целом развивается ни шатко ни валко. После стартового запала, люди ожидаемо поотпадали и у официального варианта. Может я проспустил что-то, но mailing list практически пуст.
Наверное это логично, потому что etcd особо никому и не нужен. Ну, кроме куба :)
GitHub GitHub - etcd-io/etcd-operator: The official Kubernetes operator for etcd. The official Kubernetes operator for etcd. Contribute to etcd-io/etcd-operator development by creating an account on GitHub.
  • 👍 3
Post #245 3.11K
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/
VictoriaMetrics Container CPU Requests & Limits Explained with GOMAXPROCS Tuning When running Go apps in Kubernetes, default CPU thread scheduling can conflict with cgroup CPU limits. The runtime sees all host CPUs, but the container may only be allowed a fraction of one. This often leads to early throttling. Properly configuring GOMAXPROCS…
  • 👍 16
Post #244 1.37K
Кубернетичек Пятничный пост не в пятницу. О вечном споре fluxcd vs argocd. Последние два года работаю с FluxCD. До этого долго деплоился с ArgoCD. В целом, мне Флюкс нравится — за счёт более простой логики, читаемого кода и бережного отношения к kube-apiserver. Но есть…
https://github.com/fluxcd/helm-controller/pull/1365

Продолжение истории)
Пызы: Стефан, похоже одобряет
GitHub Add --override-manager flag for server-side apply drift detection by yozel · Pull Request #1365 · fluxcd/helm-controller This flag allows specifying field managers whose ownership should be transferred to the helm-controller before performing drift detection. When a disallowed field manager is detected on a managed r...
  • 🔥 1
Post #243 1.54K
Пятничный пост не в пятницу. О вечном споре 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 🫠
GitHub Revoke kubectl managed fields ownership by stefanprodan · Pull Request #527 · fluxcd/kustomize-controller This PR enforces Flux ownership of Kubernetes objects' fields that were applied on the cluster outside of the declared desired state. In addition, metadata annotations and labels removed fr...
  • ❤ 14
Post #242 1.28K
После одного инцидента на проде в 2018 году на балансировщике, я запомнил одну вещь - tcp стек неймспейса наследуется от компилированого ядра, а не настроек ядра на хосте. И так я жил все эти годы и был доволен как слон. Но недавно красиво посрамлен сетевиками (а кем же еще?). Потому что оказывается, есть и исключения:
https://github.com/torvalds/linux/commit/356d1833b638bd465672aefeb71def3ab93fc17d
Как видите, коммит из 2017 года. Через год я смотрел код ядра и глаз не запал на это. Смотрел старую версию ядра! Так вот, tcp_wmem и tcp_rmen в network namespace наследуются от настроек ядра на хосте.
GitHub tcp: Namespace-ify sysctl_tcp_rmem and sysctl_tcp_wmem · torvalds/linux@356d183 Note that when a new netns is created, it inherits its sysctl_tcp_rmem and sysctl_tcp_wmem from initial netns. This change is needed so that we can refine TCP rcvbuf autotuning, to take RTT into c...
  • 🤯 7
  • 👍 5
Post #241 1.23K
https://github.com/kubernetes-sigs/agent-sandbox

Ну что, если кто-то хотел оперделять runtime через CR, то и такое придумали. С большей изоляцией. Надеюсь следующий щас нечто подобное сделают и для CNI без multus :)
GitHub GitHub - kubernetes-sigs/agent-sandbox: agent-sandbox enables easy management of isolated, stateful, singleton workloads, ideal… agent-sandbox enables easy management of isolated, stateful, singleton workloads, ideal for use cases like AI agent runtimes and reinforcement learning (RL). - kubernetes-sigs/agent-sandbox
Post #240 1.72K
Кубернетичек То, что не удалось (по крайней мере в публичной плоскости, ссылка на мой пост об этом в реплае) OVH, удалось реализовать clever cloud. Etcd api-compatable поверх foundationdb. Технической информации мало, но очень интересно. То есть ребята сделали тоже, что…
https://github.com/ydb-platform/ydb/pull/16101

В семействе etcd api-compatible прибыл и ydb
  • 👍 13
Post #239 2.54K
http://github.com/bchess/k8s-1m

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

Ps: single instance с in-memory etcd без постинга лиз и ивентов, а целом, удивился, что не стал лизы и ивенты в отделный етцд выносить, ну да ладно.
GitHub GitHub - bchess/k8s-1m: Run Kubernetes with a million nodes Run Kubernetes with a million nodes. Contribute to bchess/k8s-1m development by creating an account on GitHub.
  • 👍 1
Post #238 2.42K
Кубернетичек https://github.com/nebius/helmrelease-trigger-operator У fluxcd есть небольшой недостаток один - если изменить конфигмапу/секрет которые указаны в valueFrom - то флакс не заедеплоит его. Тут нужно ручное вмешательство. Данный оператор закрывает данный гап…
https://github.com/fluxcd/flux2/issues/5446

С 2.7 версии, флакс теперь будет вотчить изменения вельюсов с секретов и конфигмапов
GitHub Watch ConfigMaps/Secrets referenced in Flux reconcilers · Issue #5446 · fluxcd/flux2 xref: fluxcd/helm-controller#1086 Both the Kustomization and HelmRelease APIs have fields for referencing ConfigMaps and Secrets containing values used for templating, i.e. that have a direct impac...
  • 🎉 4
  • 😁 1
Post #237 2.57K
Post #236 4.31K
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

То есть теперь нативно можно получать более подробную информацию о том, как ваши поды контейнеры процессы контролируемые кубом "страдают" от нехватки ресурсов, и страдают ли.
Kubernetes Kubernetes v1.34: PSI Metrics for Kubernetes Graduates to Beta As Kubernetes clusters grow in size and complexity, understanding the health and performance of individual nodes becomes increasingly critical. We are excited to announce that as of Kubernetes v1.34, Pressure Stall Information (PSI) Metrics has graduated…
  • 👍 9
  • 🔥 5
  • ❤ 2
Older posts →

About this channel

How can I read @k8sjust without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Кубернетичек: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Кубернетичек have?
Кубернетичек (@k8sjust) has 1.07K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Кубернетичек know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →