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 особо никому и не нужен. Ну, кроме куба :)

Я прикалывался над этим проектом. Не думал, что там может быть что-то серьезное с таким замахом. Оказалось, этот проект идет под крылом китайского аналога 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

Пызызы: в комментариях заметили, большая часть кода - вендоринг

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

https://github.com/kubernetes-sigs/multicluster-runtime

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