Жизненный цикл объекта в Kubernetes: путь от kubectl apply до полного удаления

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются ( первая — informer и кэш в controller-runtime ) и записываются ( вторая — Server-Side Apply, patch’и, managedFields ). Сегодня — про их жизненный цикл. Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один. В этой статье я постараюсь ответить, что происходит с объектом от его рождения до смерти. И отдельно поговорим про другое измерение — эволюцию его API-схемы.

https://habr.com/ru/companies/aenix/articles/1040618/

#kubernetes #controllerruntime #api #go #golang #open_sou #platform_engineering #devops #sre #cloud

Запись в Kubernetes: как контроллеры учились не перезаписывать друг друга

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime , informer’ы, Reflector , DeltaFIFO , почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись . Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально . На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas ), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply . Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает. Сегодня будем разбираться, какие механизмы в Kubernetes позволяют разным компонентам делить ответственность за части одного и того же объекта, не превращая запись в гонку — и как ими правильно пользоваться, когда оператор пишете вы сами. Добро пожаловать под кат.

https://habr.com/ru/companies/aenix/articles/1039282/

#kubernetes #controllerruntime #serversideapply #go #golang #apiserver

Как на самом деле устроен кэш в controller-runtime, и почему ваш оператор не кладёт apiserver

Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime : scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде. В этой статье разберём внутреннее устройство controller-runtime и на его примере увидим, какие архитектурные решения лежат в основе самого Kubernetes. Начнём с того, как контроллеры читают объекты из Kubernetes API. Есть распространённое заблуждение, что r.Get() в Reconcile ходит прямо в kube-apiserver , List() каждый раз смотрит «живую» картину мира, а после Update() можно сразу перечитать объект и увидеть свежее состояние. На практике всё наоборот: controller-runtime живёт на локальной копии данных через LIST+WATCH . Благодаря этому чтение в реконсайле обходится почти бесплатно и не нагружает control plane даже при сотнях вызовов в секунду — но ценой этой модели становится то, что оператор может внезапно съедать гигабайты памяти, делать скрытые O(n) -сканы и регулярно упираться в stale reads. Статья рассчитана на тех, кто уже писал операторы на Go с использованием controller-runtime , но хочет собрать целостную mental model, а не жить с набором частных наблюдений. Фокус будет на практических последствиях для production-кластеров: память, трафик, консистентность чтения и поведение реконсайла.

https://habr.com/ru/companies/aenix/articles/1031818/

#kubernetes #controllerruntime #go #golang