Используйте контроллер входящего трафика, чтобы отменить действие ранее принятых антишаблонов.
Анти-шаблон – это решение проблемы с высоким риском, которое обычно неэффективно. На первый взгляд такие решения кажутся подходящими и эффективными. Однако любые выгоды от этих паттернов, как правило, краткосрочны, а последствия показывают, что анти-паттерны приносят больше проблем, чем пользы.
Когда разработчик принимает анти-шаблон, обычно у него есть намерение вернуться и сделать его должным образом в будущем, если на пути не возникнут более насущные потребности (а они всегда мешают). Отклонение от лучших практик проектирования создает технический долг, который рано или поздно приходится оплачивать — либо временем и усилиями на рефакторинг, либо деньгами из-за недоступности системы.
В мире Kubernetes существуют антишаблоны. Решения оркестратора контейнеров, в частности Kubernetes, используются с учетом облачных рабочих нагрузок и лучше всего работают при использовании определенных шаблонов проектирования.
В этой статье мы рассмотрим некоторые распространенные анти-шаблоны Kubernetes, некоторые шаблоны проектирования, которые можно использовать вместо них, и то, как использование входного контроллера может помочь реализовать рекомендуемые шаблоны проектирования.
Примеры антипаттернов
Облачные рабочие нагрузки, особенно те, которые выполняются в Kubernetes, предполагают эластичность (например, горизонтальное масштабирование), отказоустойчивость и сильно разнородные среды для удобства обслуживания и отладки. Небрежная разработка новых распределенных систем или миграция устаревших систем в Kubernetes может привести к нескольким анти-паттернам. Вот некоторые анти-шаблоны, о которых вам следует знать:
1. Отсутствие медицинских осмотров
Проверка работоспособности позволяет проверить состояние службы. Это помогает оценить ключевую информацию, такую как доступность службы, системные показатели или доступные подключения к базе данных. Служба может сообщать о своем состоянии через конечные точки работоспособности, такие как healthz, livez или readyz.
Kubernetes поддерживает проверки контейнеров, а именно livenessProbe, readinessProbe и startupProbe, которые позволяют отслеживать службы и предпринимать действия в случае успеха проверки. Службы без мониторинга работоспособности не могут использовать многие функции, которые могут автоматически предоставляться решениями Orchestrator.
2. Не использовать голубую, зеленую или канареечную модели развертывания
Большинство владельцев приложений предпочитают нулевое время простоя для развертывания изменений. Это необходимо для большинства критически важных приложений. Kubernetes позволяет определить стратегии развертывания Recreate и RollingUpdate. Recreate уничтожит все поды перед созданием новых, а RollingUpdate будет обновлять поды последовательно и позволит настроить maxUnavailable и maxSurge для управления процессом.
Хотя эти стратегии развертывания могут использоваться во многих случаях, они также имеют ограничения. Например, Recreate вызывает простои, а RollingUpdate может затруднить откат. Ни один из этих методов не позволяет быстро экспериментировать и получать отзывы о новых версиях ваших сервисов.
Сине-зеленое развертывание — это модель развертывания, при которой создаются копии вашего сервиса – старая версия – синяя, а новая – зеленая – при этом обе службы работают параллельно. Как только вы убедитесь, что новая версия (зеленая) готова к выпуску, вы можете направить весь производственный трафик на новую версию, сохраняя при этом старую версию (синюю) в рабочем состоянии. В случае возникновения проблем вы можете быстро перенаправить трафик обратно на предыдущую версию, предотвращая неудовлетворенность пользователей или простои. Через некоторое время, когда все работает как положено, вы можете удалить старую версию своего сервиса.
Развертывание Canary — это метод, который направляет трафик в новую службу только для подмножества пользователей. Этот паттерн позволяет внедрять новую версию вашего сервиса в продакшн, при этом вы внимательно следите за его поведением. В случае успеха вы можете предоставить новую версию большему количеству пользователей, в конечном итоге переведя всех на новую версию кода.
Оба метода необходимы в облачных средах, поскольку они повышают надежность обслуживания и позволяют быстро экспериментировать и разрабатывать.
3. Не использовать автоматические выключатели
Службы, работающие в кластере Kubernetes, взаимодействуют друг с другом посредством удаленных вызовов. Поскольку эти службы нередко работают на разных машинах, эти удаленные вызовы более подвержены сбоям или зависанию. Это может привести к таким проблемам, как каскадные сбои.
В электронике автоматический выключатель представляет собой выключатель, предназначенный для защиты электрической цепи от повреждения. Избыток электрического тока через автоматический выключатель приведет к разрыву цепи, что предотвратит перегрузку или короткое замыкание. Целью автоматического выключателя является предотвращение выхода из строя после выявления неисправности. Точно так же в программном обеспечении прерыватель цепи отслеживает службы на предмет сбоев и, будучи идентифицированным, предотвращает дальнейшие обращения к нему. Это позволяет системам справляться со сбоями и направлять запросы к работоспособным экземплярам той же службы.
Без таких механизмов кластер Kubernetes, на котором запущено распределенное сервисное приложение, будет подвержен сбоям.
4. Недостаточное количество показателей
Наблюдаемость является ключом к пониманию поведения системы, а эффективная наблюдаемость зависит от правильного набора метрик. Метрики предоставляют фрагменты информации, когда вы хотите знать: что делают ваши службы, насколько хорошо они работают, почему что-то пошло не так и, возможно, как отладить проблему. В сложных распределенных системах метрики в сочетании с другими формами наблюдаемости (такими как трассировки) позволяют вам целостно понять ваши системы через единую панель.
Отсутствие ключевых показателей серьезно ограничит вашу способность понять, как работают ваши услуги и работают ли они на желаемом уровне. По мере увеличения сложности вашей системы необходимо собирать больше точек данных с большего количества конечных точек.
Используйте входящий контроллер
Kong Ingress Controller (KIC) — это реализация Ingress для Kubernetes. Он позволяет настраивать маршрутизацию, проверку работоспособности и балансировку нагрузки, а также поддерживает различные плагины, обеспечивающие расширенную функциональность.
KIC может помочь справиться с антипаттернами, о которых мы говорили выше.
Проверки здоровья
KIC можно настроить для пассивных проверок работоспособности и активных проверок работоспособности. Пассивные проверки работоспособности будут отслеживать ваши службы при каждом запросе и, при определенном количестве сбоев, будут закрывать запросы к неисправным модулям. Активные проверки работоспособности будут периодически отслеживать сервисы через заданные промежутки времени, помечая неисправные поды как недоступные.
Пассивные и активные проверки работоспособности повысят надежность вашей системы за счет проведения регулярных проверок работоспособности и принятия упреждающих мер. KIC будет использовать информацию из проверок работоспособности для эффективной маршрутизации запросов к работоспособным репликам службы.
Синее, зеленое или канареечное развертывание
Обзоры кода и тестирование могут только дать вам уверенность в том, что ваши сервисы будут работать правильно. Однако вы не можете протестировать каждый вариант использования или граничное условие. Кроме того, многие ошибки обнаруживаются только тогда, когда код находится в свободном доступе, и ваше приложение начинает принимать реальный пользовательский трафик.
Сине-зеленое и канареечное развертывание снижают риск развертывания, обеспечивая быстрый откат и уменьшая влияние нежелательных результатов.
Развернув как старую, так и новую версии вашего сервиса за KIC, вы можете легко направить трафик на новую версию и при необходимости вернуться к предыдущей версии. Точно так же использование плагина Canary Release позволяет поэтапно внедрять новые изменения.
Автоматические выключатели
Вы можете настроить KIC с проверками, которые будут контролировать работу сервиса. На основе результатов он может помечать неработоспособные или не отвечающие реплики службы как недоступные, предотвращая направление любых дальнейших запросов к этим репликам службы. Вместо этого последующие запросы будут направляться на работоспособные копии службы. После исправления исходную реплику службы можно вернуть в оперативный режим.
Метрики
KIC легко интегрируется с Prometheus и Grafana — двумя стандартными отраслевыми решениями для мониторинга — что дает вам представление о том, как ваши сервисы реагируют на трафик. Более того, доступ к этим метрикам не требует каких-либо сервисных инструментов. Метрики Prometheus могут быть выставлены для сервисных запросов и обновлений конфигурации.
Заключение
Реструктуризация целых решений Kubernetes отнимает много времени и не всегда оправдана. Используя входной контроллер, вы сможете свести на нет последствия ранее принятых анти-шаблонов, заменив их реализацией, которая соответствует передовым практикам проектирования Kubernetes.
