🐰 Как решить проблему высокой связанности сервисов с помощью событийно-ориентированной архитектуры и RabbitMQ

В этой статье я расскажу, как оптимизировать сложную систему микросервисов через брокер сообщений, в данном случае RabbitMQ. Мы рассмотрим вариант решения проблемы высокой связанности между сервисами через переход на событийно-ориентированную архитектуру (EDA).

Читать статью

Назовите продвинутые команды Docker

Наиболее важные из них:

docker -version: узнать установленную версию Docker;
docker ps: перечислить все запущенные контейнеры вместе с дополнительной информацией о них;
docker ps -a: перечислить все контейнеры, включая остановленные, вместе с дополнительной информацией о них;
docker exec: войти в контейнер и выполнить в нем команду;
docker build: собрать образ из Dockerfile;
docker rm: удалить контейнер с указанным идентификатором;
docker rmi: удалить образ с указанным идентификатором;
docker info: получить расширенную информацию об установленном Docker, например, сколько запущено контейнеров, образов, версию ядра, доступную оперативную память и т.п.;
docker cp: сохранить файл из контейнера в локальную систему;
docker history: показать историю образа с указанным именем.

Расскажите о командах systemd для управления Docker

Для запуска Docker многие дистрибутивы Linux используют systemd. Для запуска сервисов используется команда systemctl. Если ее нет, следует использовать команду service.

$ sudo systemctl start docker
$ sudo service docker start

Чтобы добавить сервис в автозагрузку, либо убрать его:

$ sudo systemctl enable docker
$ sudo systemctl disable docker

Для проверки параметров запуска сервиса и их изменения:

$ sudo systemctl edit docker

Просмотра связанных с сервисом журналов:

$ journalctl -u docker

Какие типы монтирования доступны в Docker?

Bind mount: подключаются к любой точке файловой системы сервера;
Volume mount: управляются Docker и хранятся как часть файловой системы сервера;
tmpfs mount: хранятся в оперативной памяти сервера, поэтому никогда не пишутся на реальную файловую систему сервера.

Назовите инструменты Ansible

Вот список различных инструментов, которые вы можете упомянуть во время собеседования с разработчиком:

Ansible Galaxy: веб-сайт Galaxy позволяет вам находить роли в сообществе и делиться ими, чтобы сэкономить ваше время.

Ansible Tower: инструмент командной строки (также с графическим компонентом), предоставляющий дополнительные функциональные возможности.

Visual Studio Code: разработанный Microsoft редактор кода с поддержкой YAML и Ansible посредством расширений.

Atom: текстовый редактор с открытым исходным кодом для отслеживания изменений проекта, полезный для интеграции с файлами YAML.

Расскажите о балансировщиках нагрузки в Kubernetes.

В Kubernetes балансировщик нагрузки — это компонент, который распределяет входящий сетевой трафик между несколькими экземплярами приложения, работающего в кластере. Балансировщик нагрузки отправляет подключения к одному серверу в пуле на основе алгоритма определения следующего сервера и отправляет новые подключения к следующему доступному серверу. Этот алгоритм идеален там, где виртуальные машины требуют значимых затрат, например в размещенных средах. Некоторые из стратегий, используемых для балансировки нагрузки, — это циклический перебор, бесконечность сеансов и хеширование IP.

Что делает kube-scheduler?

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

Перечислите некоторые меры безопасности, которые вы можете предпринять при использовании Kubernetes.

Вот некоторые меры безопасности, которые мы можем принять:

✍🏻 Ограничить доступ к ETCD
✍🏻 Внедрить сегментацию сети
✍🏻 Определить квоту источника
✍🏻 Обеспечьте ограниченный доступ к узлам Kubernetes

Что будет если на сервере LA = 100?

Вероятно, что на сервере будет наблюдаться замедленная работа сервисов, но если параметр LA равен количеству ядер в системе или количеству потоков в системе, то данная нагрузка является нормальной.

Каким образом мы можем улучшить стабильность работы приложения в k8s?

Прежде всего необходимо описать probe для контейнеров в PODе, а также указать ресурсы запросов / лимиты. Затем целесообразно описать антиаффинити для PODов наших приложений, чтобы упростить обработку сбоев на конкретных узлах.

Если в нашем кластере работают как продуктовые, так и тестовые среды, хорошей практикой будет указать node selector и taints/tolerations, чтобы запускать продуктовые приложения на отдельных узлах.

Если нет возможности выделить узлы под продакшн или мы можем выделить особо важные (ядреные) сервисы в рамках продакшн, рекомендуется установить priority classes для них. Также стоит описать бюджет нарушения работы POD для особо важных приложений. В случае использования многопользовательской модели (multitenant) в пространствах имен пользователей следует указывать resourceQuotas и limitRanges.

Можем ли мы опубликовать приложение, работающее по бинарному протоколу, например postgresql, через ingress?

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

Если нам всё равно нужно описывать Kubernetes service для публикации ingress, то зачем нам ingress?

Преимущество использования ingress-контроллера заключается в том, что после его настройки мы можем направлять трафик ко всем нашим приложениям внутри кластера k8s, которые работают по протоколу HTTP и используют маршрутизацию на основе URL/locations, HTTP headers и cookie. Кроме того, при необходимости мы можем использовать несколько ingress-контроллеров в кластере, разделяя их по ingress class.

Какие существуют хорошие практики для создания проб?

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

Пробы должны быть легкими и не нагружать инфраструктуру приложения, а также не запускаться слишком часто. Им следует избегать проверки функционала, зависящего от внешних сервисов, чтобы избежать каскадных сбоев. Особенно внимательно нужно относиться к liveness-пробам, которые могут вызвать дополнительные проблемы, особенно в периоды высокой нагрузки. Рекомендуется выделить отдельный пул воркеров для прохождения liveness-пробы. Для readiness-пробы лучше создавать сквозные проверки, например, проверять только location nginx, который проксирует php-fpm, одним запросом проверяя оба сервиса.

Допустим, у нас postgresql в кластере k8s, и разработчики просят к ней доступ. Каким образом мы можем решить этот вопрос?

В первую очередь, мы можем развернуть в кластере веб-интерфейс для работы с базой данных, например, pgAdmin, и опубликовать его через ingress для разработчиков.

Также возможен вариант использования инструмента, который позволит разработчикам получить доступ к кластеру, например, Kubernetes Dashboard или Lens, с возможностью выполнения команд в POD и доступом к базе через утилиту командной строки.

Если разработчикам требуется прямой сетевой доступ к базе данных (например, для использования своего любимого инструмента для работы с БД), мы можем создать аккаунт для разработчиков в кластере и использовать kubectl proxy для публикации порта базы данных на локальной машине разработчика. Также можно установить сервер VPN в кластере.

В конечном итоге, можно опубликовать базу данных через Kubernetes Service или Ingress, но в этом случае необходимо обеспечить защиту соединения с базой данных (пользователи, доступы) и использовать шифрование протокола.

Что такое priority classes?

Этот механизм в Kubernetes позволяет определить приоритет PODов для наших процессов. Например, если у нас есть продакшн и тестовые окружения в одном кластере Kubernetes, мы можем установить более высокий приоритет для PODов продакшн с помощью priority class. Таким образом, если возникнет нехватка ресурсов на узле, в первую очередь будут удалены PODы тестовых окружений.

Что такое POD eviction?

Этот механизм позволяет удалить ноду от избыточных PODов. Существуют evict'ы по ресурсам (когда нода не имеет достаточно памяти, дискового пространства или PID для процессов) и вызов API - когда мы запускаем kubectl drain node.

Каким образом мы можем вывести ноду из работы для обслуживания?

Мы можем остановить запуск PODов на узле с помощью команды kubectl cordon и высвободить узел от PODов при помощи команды kubectl drain.