Мы видели много инфраструктур и встречали самые разные способы доставки секретов в приложения, развёрнутые в кластерах Kubernetes. Но ни один из этих способов не был одновременно удобным и по-настоящему безопасным. В статье расскажем про существующие варианты, посмотрим на их плюсы и минусы и поделимся тем, как мы решали задачу доставки секретов в Deckhouse Kubernetes Platform. 

После ухода HashiCorp с российского рынка многие компании стоят перед выбором: переехать на Community-редакцию Vault и дорабатывать её под свои потребности или купить готовый продукт, где многие фичи доступны «из коробки» и есть поддержка от разработчиков.

В этом году мы добавили в свой менеджер секретов Deckhouse Stronghold привычный пользователям Vault функционал: от пространств имён до автоматических бэкапов и репликации KV-хранилищ. В статье сравниваем реализацию этих возможностей в обоих продуктах и делимся ближайшими планами по развитию Stronghold.

Представьте, что у вас есть Vault и нужно перенести данные из него в другое хранилище. Например, из одного закрытого контура в другой на обычной флешке. Или из одного backend storage в другой. Причём перенести нужно безопасно, не расшифровывая данные в процессе и не раскрывая секреты. В этой статье мы расскажем, как решаем такие задачи в Deckhouse Stronghold — нашем решении для управления жизненным циклом секретов.

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры. 

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется. 

Звучит как фантастика?

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

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

Мы уже как-то рассказывали о базе данных KeyDB — форке Redis, разработка которого началась в 2019 году. Проект распространяется под свободной лицензией BSD, и у него уже почти 6k звезд на GitHub. Авторы в свое время столкнулись с проблемами производительности оригинала и пошли хардкорным путём: взяли всё в свои руки и привнесли много нового как в части многопоточности, так и в других областях.

В статье делимся еще одним положительным опытом замены Redis на KeyDB.