Kubernetes

У обратного прокси очень простая функция - он ставится перед приложением (или группой приложений), и служит посредником между пользователем и сервисом.

Как упомянуто выше, обратный прокси маршрутизирует пользовательские запросы на соответствующий сервер (при условии, конечно, что вы используете несколько серверов). На этом месте те, кто использует один сервер с одним экземпляром приложения, вполне справедливо зададутся вопросом, имеет ли вообще смысл внедрять обратный прокси-сервер. Ответ: да, смысл есть.
Обратный прокси будет полезен и в инсталляциях с одним сервером, за счёт предоставления таких своих преимуществ как: ограничение скорости, IP-фильтрация и контроль доступа, аутентификация, проверка запросов и кэширование.

Ingress контроллер

Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).

Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.

Чтобы лучше понять принцип работы, давайте сделаем шаг назад и попробуем разобраться, что такое Ingress.

Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.

Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.

Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).

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

• предоставления нескольких служб под одним DNS-именем

• реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами

• реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами

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

• включения ограничения скорости для ваших приложения

Заключение

Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.

Также, пожалуйста, сделайте мне одолжение и мысленно дополните каждый из следующих пунктов словом “обычно”. Каждая ситуация уникальна, и то, что я не сталкивался с тем, что (например) использование Git является плохой идеей, не означает, что такого случая не существует. “Только Ситхи всё возводят в абсолют”, и т.д.

Итак! Пройдя через всё это — вот как я бы начал все сначала, если бы мог.

Coding (параметры? да я их еле знаю!)

Никаких конфигов, зашитых в код. Если ваш сервис по какой-либо причине не может загрузить конфигурацию при запуске, он должен просто аварийно завершиться — этот случай гораздо проще диагностировать, чем результат того, что инстанс выполнил старый код, потому что никто не вспомнил о том, что нужно удалить строку config.get(enable_cool_new_thing, false).

Чрезвычайно строгие настройки RPC. Я говорю о нуле (или МОЖЕТ БЫТЬ одной) повторных попыток и таймауте, в 3 раза превышающем p⁹⁹. Здесь мы стремимся к предсказуемости, и многократные повторные попытки или длительные таймауты в качестве быстрого решения проблемы в работе сервиса превратятся в недельное расследование и головную боль через год. Исправьте неисправный сервис!

Никогда не отказывайтесь от локального тестирования. Это значительно сокращает время цикла разработки, чем необходимость полагаться (и возиться с этим) на CI или удаленные рабочие среды. Контейнеризация локальной тестовой среды может упростить управление зависимостями и обеспечить их переносимость между машинами.

Избегайте использования состояния как чумы. Управление сервисом с сохранением состояния (stateful) значительно сложнее, чем без сохранения состояния. Существует много хороших управляемых баз данных и кэшей, просто используйте один из них!

Merging (там, куда мы идем — тесты не нужны)

Используйте Git. Используйте его для всего — инфраструктуры, конфигов, кода, дашбордов, графиков дежурств. Ваш репозиторий Git — это источник истины, который можно восстановить на определенный момент времени.

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

Уделяйте приоритетное внимание тестам в реальных условиях. Самый ценный тест, который занимает меньше всего времени, — это просто применение вашего изменения на стейджинге (или, еще лучше, на проде!) и демонстрация того, что оно делает то, что вы хотели, и не ломает всё. На втором месте по эффективности находятся интеграционные тесты, а юнит-тесты идут последними — то есть, “только если у вас есть на них время”.

При изменениях в инфраструктуре делайте планы максимально ясными и очевидными. Это может означать “положить Terraform Plan как коммент к пуллреквесту”, так же сделайте с diff helm. Существуют отличные инструменты, позволяющие убедиться, что изменения, которые, по вашему мнению, вы вносите, являются теми изменениями, которые вы вносите на самом деле, поэтому убедитесь, что они находятся в центре внимания.

При внесении изменений в код делайте регрессии максимально очевидными. Журналы ошибок, использование ЦП и частота ошибочных запросов являются отличными сигналами, позволяющими выявить около 90% плохих версий и работают для практически любого сервиса (полностью универсальны). Так что не отбрасывайте их!

Deploying (no sleep til prod)

Используйте Docker. Это отраслевой стандарт не просто так — разбор зависимостей в средах с такими инструментами, как Chef или Ansible, всегда проигрывает этой приятной автономности.

Развертывайте всё и всегда. Каждый день, который проходит без вашего деплоя, увеличивает вероятность того, что он на самом деле был незаметно сломан (в результате чьего-то изменения, обновления зависимостей, удаления стороннего API), и через две недели будет очень трудно выяснить, что и где пошло не так.

Проверяйте развертывания по мере их выполнения. Можете ли вы создать полностью поврежденный образ и успешно разлить его на все машины? Почему? Это можно исправить несколькими способами, включая canary/shadow развертывания или даже просто хорошими readiness проверками.

Включите ограничение на “мгновенное” развертывание конфигов. Это может показаться нелогичным (“мгновенное” часто означает “сломать все сразу и быстро”), но возможность отключить проблемную функцию или заблокировать IP менее чем за 5 минут с лихвой компенсирует повышенный риск. Это позволяет всё делать быстро, но управлять этим нужно осторожно!

Operating (my god, it’s full of pods)

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

Используйте Helm. Или какой-то другой инструмент для управления манифестами Kubernetes, я не привередлив — главное, чтобы вы никогда не использовали прямые команды kubectl apply, edit или delete. Жизненный цикл ресурсов должен быть доступен в системе контроля версий.

Избегайте операторов и CRD (Custom Resource Definition). Как уже упоминалось выше, я люблю Kubernetes, но для очень многих разработчиков он очень сложен, и пользовательские операторы резко уходят в область “Что это за херня?”, что создает ему сложную репутацию. Пусть все будет просто.

Запускайте по 3 экземпляра всего. Как и с резервными копиями, два экземпляра — это один, а один — не существует :) Кроме того, убедитесь (действительно проверьте на проде), что 2 из 3 “штук” могут справиться с полной нагрузкой самостоятельно — в противном случае у вас на самом деле нет такой устойчивости к сбоям, как вы думаете.

Структурированные логи — это неотъемлемая часть. Вместе с идентификаторами трассировки они позволяют вам пройти 90% пути к APM (application performance monitoring), но при гораздо меньших затратах и усилиях со стороны разработчиков.

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

Да, они определенными костылями добились того, что трафик идет только на один из них, но выглядит это настолько "надежно", что совать это в прод - я бы не рискнул.

А что думаете вы?

containers:

- name: nginx-hello

image: nginxdemos/hello

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

name: nginx-app-service

spec:

type: NodePort

ports:

- port: 80

targetPort: 80

protocol: TCP

selector:

app: nginx-hello

в выводе команды kubectl get service получаю:

nginx-app-service NodePort 10.108.20.23 <none> 80:30438/TCP

Если кто знает, подскажите пожалуйста, почему кубер назначил мне порт 30438 по которому я могу достучатся до nginx из вне и могу ли я как то повлиять и назначить тот порт, который я сам хочу? Например хочу запустить в ноде какой нибудь контейнер и стучаться в него из внешней сети при наличии белого ip.

Прошу не кидаться какашками и не отправлять читать мануалы, но если хочется, то кидайтесь и отправляйте конечно)

ps: Если кто-то посоветует литературу или ресурсы по куберу для тупых, напишите пожалуйста.