Запись в 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
