Доброго времени суток, дорогой читатель!

Последние несколько лет в решении бизнес задач прогрессирует тренд использования Искусственного Интеллекта. Перед специалистами, отвечающими за инфраструктуру встают вопросы о том, какие решения они могут предложить ML-специалистам для закрытия их потребностей в отказоустойчивой и гибкой инфраструктуре с учетом специфических потребностей сферы ML. В том числе растет число инструментов и фич, которые они предоставляют, и многие задаются вопросом: как собрать свой MLOps-стек, чтобы он был удобный, (желательно) бесплатный и закрывал большинство распространенных потребностей.

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

Несколько больших нод или много маленьких?

Управление Kubernetes-кластером - это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь - это обеспечение стабильной и отказоустойчивой работы приложений.

Как site-reliability и DevOps инженерам вам нужно иметь в виду потребности приложений, которые будут запускаться в кластере, и учитывать различные факторы при его проектировании.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших - это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Kubernetes - это движок оркестрации контейнеров с открытым исходным кодом для автоматического развертывания, масштабирования и управления контейнеризированными приложениями. Под (Pod) – это базовое понятие при проектировании приложений в Kubernetes. Kubernetes оперирует подами, а не контейнерами, при этом поды включают в себя контейнеры. Под может содержать в себе описания одного или нескольких контейнеров, монтируемых разделов, IP-адресов и настроек того, как контейнеры должны работать внутри пода.

Под, содержащий один контейнер, относится к одно-контейнерным подам и это самый распространенный вариант их использования в Kubernetes. Под, который содержит несколько связанных контейнеров, относится к мульти-контейнерным подам. Есть несколько паттернов для мульти-контейнерных подов и один из них — это паттерн sidecar. В этом посте мы на примере проекта детально рассмотрим этот паттерн.

Один из самых частых вопросов, которые мне задают как консультанту это: “В чем разница между liveness и readiness пробами?”. Следующий самый частый вопрос: “Какие из них нужны моему приложению?”.

Любой, кто пробовал за Duck Duck Go-ить этот вопрос знает, что на него непросто найти ответ в интернете. В этой статье, надеюсь, я смогу помочь вам ответить на эти вопросы самостоятельно. Я поделюсь своим мнением о том, каким образом лучше использовать liveness и readiness пробы в приложениях развернутых в Red Hat OpenShift. И я предлагаю не строгий алгоритм, а, скорее, общую схему, которую вы можете использовать для принятия своих собственных архитектурных решений.

Доброго времени суток, читатель!

Вот мы и подошли к заключительной части цикла статей о Канареечных релизах в Kubernetes и методах их реализации. Желаю приятного чтения и надеюсь, что данный цикл был для вас полезным.

Использование решения Jenkins X для выполнения Canary деплоя в кластере Kubernetes

В этом цикле:

1. Canary Deployment через GitlabCI + GitOps/Manual Approach
2. Canary Deployment через Argo Rollouts
3. Canary Deployment с Istio
4. (эта статья)

Что мы будем делать здесь?

Мы создадим Jenkins X k8s кластер и тестовое приложение на Python шаг за шагом. Вы можете повторять по примеру, либо просто читать, смотреть иллюстрации и результаты для получения представления о взаимодействии JenkinsX+Flagger+Istio сanary deployment и решить для себя, стоит ли эта связка более глубокого изучения.

Использование Istio+Kiali для запуска и визуализации Canary деплоя

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. Canary Deployment в Kubernetes #2: Argo Rollouts
3. (эта статья)
4. Canary Deployment с Jenkins-X, Istio и Flagger

Мы будем использовать k8s-нативный контроллер развертывания Argo Rollouts и GitlabCI для запуска Canary деплоя в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. (Эта статья)
3. Canary Deployment using Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

Мы будем использовать Gitlab CI и ручной GitOps для внедрения и использования Canary-деплоя в Kubernetes

Статьи из этого цикла:

1. (эта статья)
2. Canary Deployment при помощи ArgoCI
3. Canary Deployment при помощи Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

Выполнять Canary-деплой мы будем руками через GitOps и создание/изменение основных ресурсов Kubernetes. Эта статья предназначена в первую очередь для знакомства с тем, как работает в Kubernetes Canary деплой, так как есть более эффективные способы автоматизации, которые мы рассмотрим в следующих статьях.

Доброго времени суток, читатель!

22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).

Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:

Практически каждый инженер, практикующий DevOps, в какой-то момент сталкивается с задачей настройки правил доступа для своих проектов. В данной статье мы рассмотрим примеры настройки сетевых политик Kubernetes-кластера, в котором используется плагин Calico и осветим некоторые интересные моменты. Предполагаем, что у вас уже имеется кластер k8s, где в качестве сетевого плагина используется Calico.

Отслеживание соединений (“conntrack”) является основной функцией сетевого стека ядра Linux. Она позволяет ядру отслеживать все логические сетевые соединения или потоки и тем самым идентифицировать все пакеты, которые составляют каждый поток, чтобы их можно было последовательно обрабатывать вместе.

Защита pod’а от выселения при помощи Pod Disruption Budgets в Kubernetes

Это четвертая и заключительная часть нашего пути (прим. пер. — ссылка на первую статью) для достижения нулевого времени простоя при обновлении Kubernetes-кластера. В предыдущих двух частях мы фокусировались на том, как корректно выключить существующие pod’ы в кластере. Мы описали как использовать хуки preStop для корректного выключения pod’ов и почему важно добавлять задержку в процесс удаления, чтобы подождать, пока процесс удаления pod’а применится для всего кластера. Это поможет в отключении одного pod’а, но не защитит нас от выключения настолько большого количества pod’ов, что наш сервис не сможет функционировать. В этой статье мы будем использовать PodDisruptionBudgets (или PDB), для уменьшения этого риска.

Задержка выключения pod’а в Kubernetes

Это третья часть нашего пути (прим. пер. — ссылка на первую статью) к достижению нулевого времени простоя при обновлении Kubernetes-кластера. Во второй части мы сокращали время простоя, которое возникло из-за принудительного завершения работающих в pod’ах приложений, завершая их корректно при помощи lifecycle hooks. Однако, мы так же узнали, что pod может продолжать принимать трафик после того, как приложение в нем начало завершение работы. То есть клиент может получить ошибку, потому что его запрос будет направлен на pod, который больше не может обслуживать трафик. В идеале, мы бы хотели, чтобы pod’ы перестали принимать трафик сразу после начала выселения. Чтобы уменьшить риск простоя, нам сначала нужно понять, почему это происходит.

Корректное завершение работы контейнеров в Kubernetes

Это вторая часть нашего пути (прим. пер. — ссылка на первую статью) к достижению нулевого времени простоя при обновлении Kubernetes-кластера. В первой части мы изложили проблемы и задачи, возникающие при выполнении операции drain для нод в кластере. В этом посте мы расскажем, как решить одну из таких проблем: корректно завершить работу pod’ов.

Процесс обновления для вашего Kubernetes-кластера

В какой-то момент при использовании кластера Kubernetes возникает потребность в обновлении работающих нод. Оно может включать в себя обновления пакетов, обновление ядра или развертывание новых образов виртуальных машин. В терминологии Kubernetes это называется "Voluntary Disruption".