Kubernetes — изучаем паттерн Sidecar
Объяснение паттерна Sidecar на примере
Под, содержащий один контейнер, относится к одно-контейнерным подам и это самый распространенный вариант их использования в Kubernetes. Под, который содержит несколько связанных контейнеров, относится к мульти-контейнерным подам. Есть несколько паттернов для мульти-контейнерных подов и один из них — это паттерн sidecar. В этом посте мы на примере проекта детально рассмотрим этот паттерн.
Что такое контейнер Sidecar
Другие паттерны
Пример
Тестируем с объектом Deployment
Как настроить ресурсные ограничения Resource Limits
Когда мы должны использовать этот паттерн
Заключение
Что такое Sidecar-контейнер
Sidecar-контейнер — это контейнер, который должен быть запущен рядом с основным контейнером внутри пода. Этот паттерн нужен для расширения и улучшения функциональности основного приложения без внесения в него изменений. Сейчас мы знаем, что технология контейнеризации позволяет собирать все зависимости, чтобы мы могли запустить приложение где угодно. Контейнер делает только одну вещь и делает её хорошо.
Представьте, что у вас есть под с одним контейнером, который очень хорошо работает, и вы бы хотели добавить какой-то функционал к этому контейнеру, не внося в него изменений. Как тогда можно добавить или расширить для него какие-то функции? Паттерн Sidecar может помочь именно в такой ситуации.
На диаграмме выше видно, как вы можете создать любое количество Sidecar контейнеров и ваш основной контейнер будет успешно с ними взаимодействовать. Все контейнеры работают параллельно и полный функционал будет доступен только если каждый из контейнеров успешно запущен. В большинстве случаев sidecar-контейнеры просты и легковесны и потребляют намного меньше ресурсов чем основной контейнер.
Другие паттерны
Вот некоторые другие паттерны, которые можно использовать для повседневной работы в Kubernetes:
Пример проекта
Здесь пример проекта, который вы можете скопировать и запустить на своих мощностях. Предварительно вам нужно установить Minikube.
Давайте запустим простой проект, чтобы понять как работает этот паттерн. Здесь под, в котором есть основной и sidecar контейнеры. Основной контейнер это Nginx, слушающий на порту 80, который отдает страницу index.html из volume, примонтированного в location workdir. И sidecar-контейнер с образом busybox, который пишет лог с timestamp в тот же самый файл. Так как sidecar-контейнер и основной контейнер запущены параллельно, Nginx будет показывать новую информацию каждый раз, когда вы делаете обращение через браузер.
Вы можете установить curl и сделать запрос на localhost, чтобы проверить ответ сервера.
Тестирование Sidecar Container
Тестирование с объектом Deployment
Давайте создадим сущность deployment с тем же определением подов и 5 репликами. Я создал service с типом порта NodePort, чтобы мы могли получить доступ к deployment через браузер. Поды создаются динамически и поддержкой заданного состояния всегда занимается deployment controller, поэтому у вас не может быть одного статического IP для доступа к поду, вместо этого вам нужно создать сущность service, которая будет открывать определенный порт во внешний мир. Внутри кластера service перенаправляет запросы извне на 80 порт контейнеров с соответствующими селекторами (тут много изменений оригинального текста). Вы увидите как это работает через некоторое время.
Deployment
Теперь давайте посмотрим на приведенный ниже deployment, в котором мы определили один основной контейнер и два sidecar-контейнера. Все контейнеры работают параллельно. Два sidecar-контейнера пишут лог в директорию /var/log. Основной контейнер с Nginx будет отдавать эти файлы, когда мы будем подключаться к порту 80. Вы увидите это в действии через некоторое время.
И выполним следующие команды, чтобы протестировать deployment.
deployment в действии
На диаграмме выше вы можете видеть 5 подов, запущенных на разных IP-адресах и service, связывающие порты 32123 и 80. Вы можете получить доступ к этому deployment из браузера через IP ворке-ноды Kubernetes 192.168.64.2 и через порт сервиса 32123:
Вы также можете протестировать под следующими командами:
Паттерн Sidecar в действии
Как настроить ограничения ресурсов
Настроить ограничения ресурсов очень важно, если речь идет о sidecar-контейнерах. Главное, что нам нужно понять, это то, что все контейнеры работают параллельно, поэтому при настройке ограничений ресурсов для пода вы должны это учитывать.
Суммировать все ограничения ресурсов для основных контейнеров, а также для дополнительных контейнеров (поскольку все контейнеры работают параллельно).
Когда нам нужно использовать этот паттерн
Вот несколько сценариев, в которых вы можете использовать этот паттерн:
Всегда, когда вы хотите дополнить функционал уже существующего единичного контейнера без внесения в него изменений
Вы можете использовать этот контейнер для синхронизации кода основного контейнера с кодом на git-сервере используя pull.(You can use this pattern to synchronize the main container code with the git server pull.)
Вы можете использовать этот контейнер, чтобы отправлять логи основного контейнера на внешний сервер.
Вы можете использовать этот контейнер для задач, связанных с установлением сети (network-related tasks.).
Под, который содержит один контейнер, относится к одно-контейнерному поду и это самый распространенный шаблон его использования.
Под, содержащий несколько взаимосвязанных контейнеров, относится к мульти-контейнерному поду.
Sidecar-контейнер запускается параллельно с основным контейнером. Поэтому вам нужно учитывать ограничения ресурсов для sidecar-контейнера прежде, чем вы задаете запросы/ограничения ресурсов для пода.
Контейнер с приложением и Sidecar-контейнер запускаются параллельно, что значит, что они будут работать в одно и то же время. Поэтому вам нужно суммировать все запросы/ограничения ресурсов для контейнеров, прежде чем задавать запросы/ограничения ресурсов для подов.
Вам нужно настроить health checks для sidecar-контейнеров так же, как и для основных контейнеров, что бы быть уверенными, что они в порядке.
Все поды, порожденные deployment не имеют статического IP-адреса, поэтому вам нужно создать сущность service, чтобы дать к ним доступ из внешнего мира.
Сущность service перенаправляет трафик внутри кластера с внешних портов на порты контейнера в соответствии с выбранными селекторами.
Заключение
Знать проверенные временем паттерны в kubernetes полезно. Убедитесь, что все ваши sidecar-контейнеры достаточно просты и малы, потому что вам нужно будет просуммировать все запросы и ограничения ресурсов прежде чем задавать их для пода в целом. Также нужно быть уверенным, что Sidecar-контейнеры “здоровы”, настроив health checks. Помните об этих моментах, когда добавляете функционал в основной контейнер или используйте отдельный контейнер.
Серия постов по Istio Service Mesh
Мы начинаем серию постов, в которой продемонстрируем некоторые из множества возможностей сервисной сетки Istio Service Mesh в сочетании с Red Hat OpenShift и Kubernetes.
Часть первая, сегодняшняя:
Инструментарий мониторинга и управления Istio – все необходимое для координации микросервисов в сервисной сетке service mesh.
Что такое сервисная сетка Istio
Сервисная сетка реализует для группы сервисов такие функции, как мониторинг трафика, контроль доступа, обнаружение, безопасность, отказоустойчивость и другие полезные вещи. Istio позволяет сделать все это без малейших изменений в коде самих сервисов. В чем секрет волшебства? Istio цепляет к каждому сервису свой прокси в виде sidecar-контейнера (sidecar – мотоциклетная коляска), после чего весь трафик к этому сервису идет через прокси, который, руководствуясь заданными политиками, решает как, когда и должен ли вообще этот трафик дойти до сервиса. Istio также дает возможность реализовать продвинутые техники DevOps, такие как canary deployments, circuit breakers, fault injection и многие другие.
Как Istio работает с контейнерами и Kubernetes
Сервисная сетка Istio – это sidecar’ная реализация всего того, что требуется для создания и управления микросервисами: мониторинг, трассировка, circuit breakers, маршрутизация, балансировка нагрузки, fault injection, повторы, тайм-ауты, зеркалирование, контроль доступа, ограничение скорости и многое другое. И хотя сегодня есть масса библиотек, чтобы реализовать эти функции непосредственно в коде, с Istio вы можете получить все то же самое, ничего не меняя в своем коде.
Согласно sidecar’ной модели, Istio выполняется в Linux-контейнере, который располагается в одном Kubernetes-pod’е с контролируемым сервисом и внедряет (inject) и извлекает (extract) функциональность и информацию согласно заданной конфигурации. Подчеркнем, это ваша собственная конфигурация, и она живет вне вашего кода. Поэтому код становится гораздое проще и короче.
Что еще важно, операционная составляющая микросервисов при этом оказывается никак не связана с самим кодом, а значит их эксплуатацию можно спокойно передать ИТ-специалистам. В самом деле, почему разработчик должен отвечать за circuit breaker’ы и fault injection? Реагировать – да, но обрабатывать их и создавать? Если убрать всё этого из кода, программисты смогут полностью сосредоточиться на прикладном функционале. Да и сам код станет короче и проще.
Сервисная сетка
Istio, реализующий функции управления микросервисами вне их кода – это и есть концепция сервисной сетки Service Mesh. Иначе говоря, это скоординированная группа из одного или нескольких бинарников, которые образуют сетку сетевых функций.
Как Istio работает с микросервисами
Вот как выглядит работа sidecar-контейенров с связке с Kubernetes и Minishift с высоты птичьего полета: запускаете экземпляр Minishift, создаете проект для Istio (назовем его «istio-system»), устанавливаете и запускаете все связанные с Istio компоненты. Затем, по мере создания проектов и pod’ов, добавляете конфигурационные сведения в свои deployment’’ы, и ваши pod’ы начинают использовать Istio. Упрощенно диаграмма выглядит так:
Теперь можно изменять настройки Istio, чтобы, например, организовать fault injection, поддержку Canary Deployment или другие возможности Istio – и все это совершенно не трогая код самих приложений. Допустим, вы хотите перенаправить весь веб-трафик от пользователей своего крупнейшего клиента (Foo Corporation) на новую версию сайта. Для этого достаточно создать правило маршрутизации Istio, которое будет искать @foocorporation.com в идентификаторе пользователя и выполнять соответствующее перенаправление. Для всех остальных пользователей ничего не изменится. А вы тем временем будете спокойно тестировать новую версию сайта. И заметьте, для этого совершенно не надо привлекать разработчиков.
И дорого за это придется заплатить?
Отнюдь. Istio работает довольно быстро, он написан на Go и создает совсем небольшой оверхед. Кроме того, возможный проигрыш в онлайн-производительности компенсируется приростом производительности труда разработчиков. По крайней мере, в теории: не забывайте, что время разработчиков стоит дорого. Что касается затрат на ПО, то Istio – это софт с открытым кодом, поэтому получить и использовать его можно бесплатно.
Освойте сами
Команда Red Hat Developer Experience Team разработала углубленное практическое руководство по Istio (на английском). Оно работает на Linux, MacOS и Windows, а код представлен в вариантах на Java и Node.js.
10 интерактивных занятий по Istio
Блок 1 — Для начинающих
Введение в Istio
30 минут
Знакомимся с Service Mesh, учимся устанавливать Istio в Kubernetes кластере OpenShift.
Начать
Развертывание микросервисов в Istio
30 минут
Используем Istio, чтобы развернуть три микросервиса с Spring Boot и Vert.x.
Начать
Блок 2 – средний уровень
Мониторинг и трассировка в Istio
60 минут
Изучаем встроенные средства мониторинга Istio, настраиваемые метрики, а также OpenTracing через Prometheus и Grafana.
Начать
Простая маршрутизация в Istio
60 минут
Учимся управлять маршрутизацией в Istio с помощью простых правил.
Начать
Расширенные правила маршрутизации
60 минут
Знакомимся с умной маршрутизацией в Istio, управлением доступом, балансировкой нагрузки и ограничением скорости.
Начать
Блок 3 – опытный пользователь
Fault Injection в Istio
60 минут
Изучаем сценарии обработки отказов в распределенных приложений, создавая ошибки HTTP и сетевые задержки, учимся применять хаос-инжиниринга для восстановления среды.
Начать
Circuit Breaker в Istio
30 минут
Устанавливаем Siege для стресс-тестирования сайтов и учимся обеспечить отказоустойчивость бэкенда с помощью повторов, circuit breaker и pool ejection.
Начать
Egress и Istio
10 минут
Используем маршруты Egress для создания правил взаимодействия внутренних сервисов с внешними API и сервисами.
Начать
Istio и Kiali
15 минут
Учимся использовать Kiali для получения общей картины сервисной сетки и изучения потоков запросов и данных.
Начать
Mutual TLS в Istio
15 минут
Создаем Istio Gateway и VirtualService, затем подробно изучаем mutual TLS (mTLS) и его настройки.
Начать
Блок 3.1 — Глубокое погружение: Istio Service Mesh для микросервисов
Серия статей по сервисным сеткам и Istio
Попробуйте сами
Эта серия постов не ставит целью обеспечить глубокое погружение в мир Istio. Мы просто хотим познакомить вас с самой концепцией и, может быть, вдохновить самостоятельно попробовать Istio. Это можно сделать совершенно бесплатно, и Red Hat предоставляет все необходимые инструменты, чтобы начать осваивать OpenShift, Kubernetes, Linux-контейнеры и Istio, а именно: Red Hat Developer OpenShift Container Platform, наше руководство по Istio и другие ресурсы на нашем микро-сайте по Service Mesh. Не стоит откладывать, начните прямо сегодня!
Правила маршрутизации Istio: направляем сервис-запросы туда, куда нужно
OpenShift и Kubernetes прекрасно справляются с тем, чтобы обращения к микросервисам маршрутизировались к нужным pod’ам. В этом и есть одна из целей существования Kubernetes – маршрутизация и балансировка нагрузки. А что, если вам нужна более тонкая и изощренная маршрутизация? Например, чтобы одновременно использовать две версии микросервиса. Как здесь помогут правила маршрутизации Istio Route Rules?
Правила маршрутизации – это правила, которые, собственно, задают выбор маршрута. При любом уровне сложности системы общий принцип работы этих правил остается простым: запросы маршрутизируются на основе определенных параметров и значений заголовков HTTP.
Посмотрим на примерах:
Kubernetes умолчанию: тривиальное «50 на 50»
В нашем примере мы покажем, как одновременно использовать в OpenShift две версии микросервиса, назовем их v1 и v2. Каждая версия запускается в собственном pod’е Kubernetes, и по умолчанию здесь работает равномерно сбалансированная циклическая маршрутизация (evenly balanced round robin routing). Каждый pod получает свою долю запросов по числу его экземпляров микросервиса, иначе говоря, реплик. Istio же позволяет поменять этот баланс вручную.
Допустим, мы развернули на OpenShift две версии нашего рекомендационного сервиса, recommendation-v1 и recommendation-v2.
На рис. 1 видно, что, когда каждый сервис представлен в одном экземпляре, запросы равномерно чередуются между ними: 1-2-1-2-… Именно так маршрутизация Kubernetes работает по умолчанию:
Взвешенное распределение между версиями
Игнор версии с помощью Istio
Istio позволяет легко изменить распределение запросов нужным нам образом. Например, отправлять весь трафик только на recommendation-v1 с помощью следующего yaml-файла Istio:
Здесь надо обратить внимание вот на что: pod’ы выбираются согласно меткам. В нашем примере используется метка v1. Параметр «weight: 100» означает, что 100% трафика будет маршрутизироваться на все pod’ы сервиса, у которых есть метка v1.
Директивное распределение между версиями (Canary Deployment)
Далее, используя параметр weight, можно направлять трафик к обоим pod’ам, игнорируя количество экземпляров микросервисов, запущенных в каждом из них. Например, здесь мы директивно направляем 90% трафика на v1 и 10% – на v2:
Отдельная маршрутизация мобильных пользователей
В заключение покажем, как принудительно маршрутизировать трафик мобильных пользователей на сервис v2, а всех остальных – на v1. Для этого мы помощью регулярных выражений анализируем значение user-agent в заголовке запроса:
Теперь ваша очередь
Пример с регулярными выражениями для анализа заголовков должен мотивировать вас на поиск собственных вариантов применения правил маршрутизации Istio. Тем более что возможности здесь открываются весьма обширные, поскольку значения заголовков можно формировать в исходном коде приложений.
И помните, что Ops, а не Dev
Всё, что мы показали в примерах выше, делается без малейших изменений в исходном коде, ну за исключением тех случаев, когда надо формировать особые заголовки запросов. Istio пригодится как разработчикам, которые, например, смогут применять его на этапе тестировании, так и специалистам по эксплуатации ИТ-систем, которым он сильно поможет в продакшне.
Так что повторим лейтмотив этой серии постов: вам не надо ничего менять в своем коде. Не нужно собирать новые образы или запускать новые контейнеры. Все это реализуется вне кода.
Включите воображение
Только представьте, какие перспективы открывает анализ заголовков с помощью регулярных выражений. Хотите перенаправлять вашего крупнейшего клиента на специальную версию своих микросервисов? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Инъекция секретов из Vault в поды используя сайдкары Kubernetes
Совет: HashiCorp Learn также имеет постоянно обновляемое руководство по инъекции секретов в Kubernetes Pods через Vault Helm Sidecar. Посетите эту страницу для ознакомления с самыми последними шагами и примерами кода.
Мы рады объявить о новой интеграции Kubernetes, которая позволяет приложениям без встроенной в HashiCorp Vault нативной логики использовать статические и динамические секреты, получаемые из Vault. Она основана на новом инструменте под названием vault-k8s, который использует Kubernetes Mutating Admission Webhook для перехвата и дополнения специально аннотированной конфигурации подов для инъекции секретов с помощью Init и Sidecar контейнеров.
Приложениям нужно заботиться только о получении секрета по определённому пути в файловой системе, а не об управлении токенами, подключении к внешнему API или другим механизмам прямого взаимодействия с Vault.
Вот несколько поддерживаемых вариантов использования:
Только Init контейнер для предварительного заполнения секретов до начала выполнения приложения. Например, job для резервного копирования, которое выполняется по регулярному расписанию и нуждается во входных секретах только в момент старта.
Init и Sidecar. Init контейнер для получения секретов перед запуском приложения, и контейнер Sidecar, который запускается вместе с вашим приложением для поддержания секретов в актуальном состоянии (sidecar периодически проверяет, чтобы убедиться, что секреты актуальны). Например, веб приложение, использующее динамические секреты для подключения к базе данных с истекающим сроком аренды.
Аутентификация пода через сервисную учетную запись Kubernetes для соблюдения Vault Policy. Например, вы, вероятно, захотите ограничить Pod только доступом к секретам, которые им нужны для корректной работы. Это также должно помочь в аудите использования секретов каждым приложением.
Гибкие возможности форматирования вывода с использованием шаблона Vault Agent, встроенного в consul-template. Например, получение секретных данных из Vault для создания строки соединения с базой данных, или адаптация вывода под уже существующие форматы конфигурационных файлов и т.д.
Нашей неизменной целью является расширение поддержки Kubernetes и предоставление вам различных вариантов использования Vault для безопасного внедрения секретов в ваш рабочий процесс. Вы можете узнать больше о нашем мышлении здесь, прочитав статью в блоге What’s Next for Vault and Kubernetes.
Видео гайд
Чтобы посмотреть видео демонстрацию того, как секреты Vault внедряются в поды Kubernetes с помощью init и sidecar контейнеров, пожалуйста, посмотрите видео ниже. Мы рассмотрим начальную установку Vault-k8s с помощью Vault Helm Chart и рассмотрим три примера использования (добавление аннотаций, форматирование вывода и фоновые задачи). Видео должно помочь расширить ваше понимание того, как это работает на практике.
Как это работает
Helm Chart, с включенной функцией инъекции, запускает Vault, вместе со службой vault-k8s, и регистрирует себя в Kubernetes как Mutating Admission Webhook (привязанный к определенному namespace). На схеме ниже показано, как webhook vault-k8s используются для перехвата и изменения конфигурации пода при выполнении запроса Kubernetes API.
Схема, вдохновленная путеводителем по Kubernetes Admission Controllers.
Вы можете выбрать каждое приложение для инъекции секретов Vault, используя специально заданные аннотации в конфигурации пода. Затем, когда webhook vault-k8s обнаруживает эти специфические аннотации, он переписывает описание пода на основе того, что было запрошено (с помощью ваших заданных аннотаций). Думайте об этих аннотациях как о параметрах настройки того, как вы хотите, чтобы секреты были представлены внутри контейнеров вашего приложения. Вы можете использовать выбранный namespace, определённым образом задавать аннотации, и учетные записи служб Kubernetes Service Accounts, привязанные к Vault Policy, это дает вам тонкий контроль над тем, куда и какие секреты внедряются без ущерба для безопасности.
Итак, как выглядят эти специфические Vault аннотации к подам? Вы можете посмотреть документацию с детальной информацией, но мы рассмотрим несколько примеров ниже, которые должны дать вам хорошее представление о том, как выглядят аннотации в Vault. Вы можете использовать команду kubectl patch для применения аннотаций к существующему объекту Pod, они будут перехвачены службой webhook vault-k8s, которая затем добавит правильные контейнеры init и sidecar вместе с запрошенными секретами (если у вас есть доступ, основанный на учетной записи Service Account и связанной с ней Vault Policy).
Например, вышеприведенные аннотации при применении указывают vault-k8s внедрить init и sidecar контейнеры в указанный Pod, получить secret/helloworld секрет из Vault, и записать эти данные в /vault/secrets/helloworld, если у роли «myapp» есть доступ к этим данным.
Инъекция секретов в действии
В этом разделе мы пройдём вместе через процесс внедрения секретов чтобы понять, как работать с vault-k8s на двух примерах. Как упоминалось выше, рекомендуемым методом установки является официальный Vault Helm Chart. Чарт, с включенной функцией инжекции агента Sidecar, запускает Vault, веб-сервис инжектора webhook vault-k8s и настраивает Kubernetes Mutating Admission Webhook.
Перед установкой Vault, убедитесь, что поддержка инжекторов включена в файле Vault Helm Chart values.yaml.
Далее настроим тестовый namespace, зададим ему текущий контекст и установим Vault с помощью Helm Chart.
Далее, подключаемся к Vault и настраиваем политику под названием «app» для тестирования. Это очень нестрогая политика, и в производственном окружении вы разумеется захотите больше ограничивать ее, но она служит в качестве примера, пока мы играем с этим функционалом.
Далее нам нужно настроить метод Vault Kubernetes Auth и прикрепить только что созданную политику к учетной записи service account нашего приложеня (мы создадим приложение через минуту).
Ниже пример конфигурационного файла app.yaml для запуска демонстрационного приложения. Тут создаётя простой контейнер с веб-сервисом, используемый для наших тестов. Мы также определяем учетную запись Service Account, которую мы можем затем привязать к Vault Policy, созданную нами ранее. Это позволяет вам указать каждый секрет, к которому приложению разрешен доступ.
Теперь давайте запустим наше тестовое приложение и создадим учетную запись service account. Мы также можем проверить, что в /vault/secrets нет секретов.
Теперь патч для аннотаций, который мы можем применить к конфигурации pod нашего приложения, работающего на примере, который устанавливает определенные аннотации для введения нашего секрета/секретного хранилища.
И давайте применим наш патч с аннотациями.
Если все пойдет правильно, то теперь вы должны увидеть tmpfs mount в /vault/secrets и helloworld секрет содержащийся там. Здесь произошло следующее: когда мы применили патч, наш webhook vault-k8s перехватил и изменил описание Pod, включив в него Init-контейнер для предварительного размещения нашего секрета, а также Vault Agent Sidecar для синхронизации этих секретных данных на протяжении всего жизненного цикла нашего приложения.
Однако, если бы вы на самом деле запустили это, вы бы заметили, что данные в /vault/secrets/helloworld не отформатированы, а являются просто Go структурированным экспортом нашего секрета. Это может быть проблематично, так как вы почти наверняка хотите, чтобы выходные данные были отформатированы определенным образом, для использования вашим приложением. Каким будет решение этой проблемы?
Вы можете отформатировать ваши секретные данные, используя шаблоны Vault Agent Templates, что очень полезно для решения различных задач по форматированию вывода. В следующем примере мы разберем наши секретные данные в строку соединения postgresql. Шаблоны могут быть очень удобны и должны подходить для различных случаев использования, когда вам нужно соответствовать используемым форматам конфигурации, поднимать соединения к БД (как показано ниже) и т.д.
Далее, как и раньше, мы применяем патч аннотаций.
Теперь выход выглядит вот так:
В приведенных выше примерах был рассмотрен довольно схема работы инъекции секрета в запущенное приложение, не имеющее встроенной нативной логики работы с Vault. Приложениям нужно только заниматься поиском файла с секретом по определённому пути, вот и все.
Следующие шаги
Репозиторий vault-k8s теперь доступен на GitHub. Чтобы узнать больше, пожалуйста, читайте документацию Agent Sidecar Injector и посмотрите наш вебинар Injecting Vault Secrets Into Kubernetes Pods via a Sidecar. Вам также доступен новый гайд опубликованный на страницах HashiCorp Learn и новый блог нашей команды Инженерных Решений, которые еще глубже погружаются в использование инъекций.
Кроме того, если вам нравится заниматься подобными вещами, возможно, вам тоже будет интересно поработать в HashiCorp, мы принимаем на работу!
От переводчика:
В дальнейшем планирую перевести следующие статьи, надеюсь они так-же будут полезными:
