Ошибки в разработке неизбежны, но они помогают расти. Я Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наша команда придерживается простого принципа: не наступать на одни грабли дважды. Из каждой ошибки стараемся извлечь урок и больше её не повторять, а ещё лучше — учиться на ошибках других. Поэтому мы развиваем культуру открытого обсуждения ошибок и не закрываем глаза на возникающие сложности.

На первый взгляд, написание Kubernetes-операторов — технически сложная, но вполне понятная работа. Определил CRD, написал контроллер, настроил реконсиляцию — и вуаля, автоматизация работает. Но на практике ошибки могут быть не в коде, а в архитектуре, подходах и принятых допущениях — даже если основная логика реализована правильно.

Я уже рассказывал о подводных камнях и лучших практиках при разработке операторов Kubernetes: материал в трёх частях можно почитать тут, тут и тут. А в этой статье я собрал ошибки, которые часто встречались мне в реальных проектах при работе с Kubernetes-операторами. Расскажу, как мы их исправляли, какие выводы сделали и что теперь делаем иначе. Надеемся, наш опыт будет полезным для вас и поможет их не повторить.

Привет! Это снова Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наши операторы продолжают бороздить просторы K8s, а инсталляторы — разворачивать новые кластеры, и мы готовы поделиться с вами новыми полезностями.

В первой и второй частях мы уже о многом поговорили. Обсудили и базовые штуки, и принципы использования патчинга. В этой части детальнее поговорим про ошибки, как с ними можно и нужно работать, а как делать не стоит.

Привет, на связи Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Мы все так же пилим наш космолет и готовы поделиться с вами новыми полезными рекомендациями и предостеречь от ошибок при разработке операторов.

В первой части мы уже начали обсуждать разработку K8s-операторов. Сегодня поговорим о поведении  Reconcile и конфликтах обновлений. Рассмотрим возможные ошибки и обсудим тонкости, которые помогут их избежать.

Поехали!

Kubernetes-операторы давно стали привычным инструментом автоматизации и управления сложными системами. Однако на практике их поведение далеко не такое предсказуемое, как в примерах из документации. Небольшие отклонения в логике цикла согласования, обработке ошибок или обновлении статуса быстро превращаются в зацикливание, дублирование ресурсов и прочие сюрпризы, которые трудно отладить. Новичкам полезно понимать, почему так происходит, а опытным разработчикам — помнить, какие принципы стоит держать в голове при проектировании оператора.

Меня зовут Стас Иванкевич, я техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. В управляющий слой входят установщик кластера, консоль, API, другие компоненты и самое релевантное для этой статьи — наши многообразные операторы.

За последние несколько лет мы разработали целую пачку операторов — на один-два контроллера или сразу на множество. В ходе работы мы собрали и упорядочили лучшие практики, проверенные реальной эксплуатацией, а также подводные камни и типичные ошибки. И сегодня хотим поделиться нашей подборкой с вами.

Решение больших и сложных задач требует больших ресурсов — эта зависимость практически неизменна. Вместе с тем, не всегда оправданно пытаться «съесть слона целиком» — часто намного рациональнее разбить комплексную задачу на набор атомарных шагов и «осваивать» их постепенно. 

Меня зовут Станислав Иванкевич. Я старший программист в команде разработки DataMasters компании VK Tech. В этой статье я расскажу, как мы применили подход с декомпозицией при разработке своего mini-k8s для автоматизации создания и поддержки приложений в пользовательских кластерах Kubernetes.