Kubernetes Ingress глазами новичка
Ingress это базовый тип ресурса в кубертенесе. Если просто объявить объект типа Ingress в кубернетисе то ничего не произойдет.
Что бы этот ресурс начал работу в кластере кубернетиса должен быть установлен Ingress Controller, который настроит реверсивный прокси в соответствии с Ingress объектом.
Ingress Controller состоит из 2х компонентов — реверсивного прокси и контроллера который общается с API сервером кубернетеса. Реверсивный прокси слушает входящий трафик на портах которые указаны в настройках (обычно в настройках по умолчанию указан только порт 80). Контроллер может быть как отдельным демоном (как в nginx), так и встроенным в прокси (как в traefik).
Не все клауд провайдеры кубернетеса предустанавливают Ingress Controller по умолчанию.
Контроллеры могут запускаться либо как DaemonSet либо как Deployment. DaemonSet идеально использовать как единственный Ingress Controller, что бы реверсивное прокси слушало на всех IP адресах воркеров. Deployment отлично подходит если перед Ingress контроллером стоит балансировщик — от провайдера кубернетиса (GKE, AKS), MetalLB если онпремис или обычный haproxy/nginx установленный на сервере (требутеся ручная настройка). При этой установке возможно установить несколько Ingress Controller.
Как входящий трафик попадает на Ingress Controller
Во всех случаях реверс прокси в Ingress Controller слушает порты где ожидает http/https соединения.
Трафик на этоти порты может попасть тремя путями:
NodePort
Ставить Ingress Controller на NodePort без LoadBalancer имеет мало смысла, так как URL будет включать порт который указан в NodePort http://domain.example.org:32200/.
Для этого варианта лучше использовать Deployments. Это позволит проще скейлить количество подов ответственных за входящий трафик, прописывать им nodeAffinity и запускать несколько ingress controller (например для production и staging).
HostPort
При использовании HostPort порт пробрасывается с хоста где запущен под в этот самый Pod. LoadBalancer на вход не нужен, но для работы сайта в DNS нужно указывать что адрес домена находится на всех узлах.
Пример конфигурации DNS для 3х воркеров:
Для этой установки лучше всего использовать DaemonSet т.к. он позволяет запустить не более одного Pod на хосте. Deployment возможен, но имеет мало смысла т.к. надо прописывать affinity что бы не назначилось 2 Pod на один хост, иначе будет конфликт по портам.
Host network
При запуске Ingress Controller в общей сети с хостом не требуется никаких пробросов портов, но в этом случае все порты которые открыты в Pod будут доступны из интернета. Для запуска лучше использовать DaemonSet. Причины такие же как и с HostPort — что бы избежать конфликта портов.
Что выбрать
Если есть LoadBalancer на входе — NodePort, если нет — HostPort + DNS Round Robin. Для экспериментов можно попробовать Host network, но это не безопасно.
Kubernetes NodePort vs LoadBalancer vs Ingress? Когда и что использовать?
Недавно меня спросили, в чем разница между NodePorts, LoadBalancers и Ingress. Все это разные способы получить внешний трафик в кластер. Давайте посмотрим, чем они отличаются, и когда использовать каждый из них.
Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Я не углубляюсь в технические детали. Если хотите подробностей, обратитесь к официальной документации.
ClusterIP
ClusterIP — сервис Kubernetes по умолчанию. Он обеспечивает сервис внутри кластера, к которому могут обращаться другие приложения внутри кластера. Внешнего доступа нет.
YAML для сервиса ClusterIP выглядит следующим образом:
С чего я заговорил о сервисе ClusterIP, если к нему нельзя получить доступ из интернета? Способ есть: с помощью прокси-сервера Kubernetes!
Запускаем прокси-сервер Kubernetes:
Теперь можно выполнять навигацию по API Kubernetes для доступа к этому сервису, используя схему:
Используем этот адрес для доступа к вышеуказанному сервису:
Когда использовать?
Существует несколько сценариев использования прокси-сервера Kubernetes для доступа к сервисам.
Отладка сервисов или подключение к ним напрямую с ноутбука с другими целями
Разрешение внутреннего трафика, отображение внутренних панелей и т. д
Поскольку этот метод требует запуска kubectl в качестве аутентифицированного пользователя, не следует использовать его для предоставления доступа к сервису в интернете или для продакшен-сервисов.
NodePort
Сервис NodePort — самый примитивный способ направить внешний трафик в сервис. NodePort, как следует из названия, открывает указанный порт для всех Nodes (виртуальных машин), и трафик на этот порт перенаправляется сервису.
YAML для службы NodePort выглядит так:
По сути, сервис NodePort имеет два отличия от обычного сервиса ClusterIP. Во-первых, тип NodePort. Существует дополнительный порт, называемый nodePort, который указывает, какой порт открыть на узлах. Если мы не укажем этот порт, он выберет случайный. В большинстве случаев дайте Kubernetes самому выбрать порт. Как говорит thockin, с выбором портов все не так просто.
Когда использовать?
Метод имеет множество недостатков:
На порт садится только один сервис
Доступны только порты 30000–32767
Если IP-адрес узла/виртуальной машины изменяется, придется разбираться
По этим причинам я не рекомендую использовать этот метод в продакшн, чтобы напрямую предоставлять доступ к сервису. Но если постоянная доступность сервиса вам безразлична, а уровень затрат — нет, этот метод для вас. Хороший пример такого приложения — демка или временная затычка.
LoadBalancer
Сервис LoadBalancer — стандартный способ предоставления сервиса в интернете. На GKE он развернет Network Load Balancer, который предоставит IP адрес. Этот IP адрес будет направлять весь трафик на сервис.
Когда использовать?
Если вы хотите раскрыть сервис напрямую, это метод по умолчанию. Весь трафик указанного порта будет направлен на сервис. Нет фильтрации, нет маршрутизации и т.д. Это означает, что мы можем направить на сервис такие виды трафика как HTTP, TCP, UDP, Websockets, gRPC и тому подобное.
! Но есть один недостаток. Каждому сервису, который мы раскрываем с помощью LoadBalancer, нужен свой IP-адрес, что может влететь в копеечку.
Ingress
В отличие от приведенных примеров, Ingress сам по себе не сервис. Он стоит перед несколькими сервисами и действует как «интеллектуальный маршрутизатор» или точка вхождения в кластер.
Есть разные типы контроллеров Ingress с богатыми возможностями.
Контроллер GKE по умолчанию запускает HTTP(S) Load Balancer. Вам одновременно будет доступна маршрутизация в бекенд сервисы на основе путей и субдоменов. Например, все на foo.yourdomain.com отправляем в сервис foo, а путь yourdomain.com/bar/ со всеми вложениями — в сервис bar.
YAML для объекта Ingress на GKE с L7 HTTP Load Balancer выглядит следующим образом:
Когда использовать?
С одной стороны, Ingress — один из лучших способов раскрыть сервисы. С другой стороны — один из самых сложных. Существует множество контроллеров Ingress: Google Cloud Load Balancer, Nginx, Contour, Istio и прочие. Есть и плагины для Ingress-контроллеров, такие как cert-manager, который автоматически предоставляет SSL-сертификаты для сервисов.
Ingress хорош при раскрытии нескольких сервисов на одном IP-адресе, когда все сервисы используют общий протокол L7 (обычно HTTP). Используя встроенную интеграцию GCP, вы платите только за один балансировщик нагрузки. А поскольку Ingress «умный», вы из коробки получаете множество функций (например, SSL, Auth, Routing и т.д.)
За диаграммы спасибо Ahmet Alp Balkan.
Это не самая технически точная диаграмма, но она хорошо иллюстрирует работу NodePort.
Работа с vlan на коммутаторах D-Link | Часть 1: 802.1Q
Часть 1: 802.1Q VLAN
Сегодня хотелось бы разобрать работу с vlan на коммутаторах Dlink.
Если вы еще не находитесь в CLI коммутатора, предлагаю ознакомится тем как это осуществить в разделе «Подключение к CLI» — ТУТ
Список доступных команд
Вланы могут создавать только пользователи с правами администратора и оператора.
Cоздание Vlan
Обязательно должен быть указан vlan id.
Формат: create vlan tag
Параметры:
— имя создаваемого влана. Может содержать до 32х символов.
— vlan id или таг влана. Может быть в диапазоне от 2 до 4094.
type 1q_vlan advertisement — параметр разрешающий анонсировать влан основанный на стандарте 802.1Q по протоколу GVRP. Использовать не рекомендуется, т.к. на разных моделях коммутаторов может вести себя непредсказуемо.
Массовое создание Vlan по ID
Метод используется для создания нескольких VLAN одновременно. Уникальное имя VLAN будет назначаться автоматически (например VLAN10). Назначение имени VLAN основано на следующем правиле: «VLAN»+ID. Например, для VLAN ID 100 имя VLAN будет VLAN100. Если это имя VLAN конфликтует с именем существующего VLAN, то оно будет переименовано. Происходит это на следующим образом: “VLAN”+идентификатор+”ALT”+счетчик совпадений. Например, если конфликт является вторым, то имя будет VLAN100ALT2.
Формат: create vlan vlanid
Параметры:
— количество вланов (VID) для создания.
Удаление Vlan
Формат: delete vlan
Пример:
Массовое удаление Vlan по ID
Формат: delete vlan vlanid
Пример:
Конфигурирование Vlan
| advertisement [enable | disable]>
Параметры:
add [tagged | untagged | forbidden] | delete] — Назначит порт Тегированным |Не тегированным | Запрещенным. forbidden (Запрещенный) указывает на то, что порт не сможет присоединиться к влану ни при каких условиях, кроме ручного добавления. Примером автоматического присоединения портов является протокол GVRP.
delete — удаление портов из влана
advertisement [enable | disable] — включение/отключение анонсирования влана в сеть. Используется протоколом GVRP
GVRP и Ingress Checking
Ingress Checking — «проверка попадания» фрейма в набор VID, ассоцирированных с портом. Если Ingress Checking включен, то при поступлении в порт коммутатора фрейма, производится сравнение VID фрейма с набором идентификаторов VID, ассоциированных с портом (включая PVID порта). Если нет совпадения, то фрейм отбрасывается. Т.е. на порт принимаются только фреймы с идентификаторами VLAN ID, для которых данный порт является выходным. Если же Ingress Checking выключен, то никакой проверки не производится.
Формат: config port_vlan [
Параметр:
gvrp_state [enable | disable] — Включает или отключает GVRP для портов, указанных в списке
ingress_checking [enable | disable] — включение/отключение функции Ingress Checking
acceptable_frame [tagged_only | admit_all] — Разрешить только тегированный трафик на порту или весь.
Команды просмотра Show
show vlan — Отображение информации о всех vlan, включая параметры и настройки.
show vlan ports 6 — отображает информацию о vlan на требуемом порту.
show vlan vlanid 1 — отображает информацию о требуемом vlan по его ID
show port_vlan — отображения атрибутов VLAN yна портах на коммутатора
PVID auto assign
PVID — указывать на то, каким тегом будет помечен трафик поступивший от хоста на порт коммутатора.
Пример:
Порт 16 — транковый порт. На него приходит несколько вланов. В том числе vlan2
Порт 1 — порт доступа (Access/Untagged). За ним располагается хост. Например абонент.
1. На коммутатор в порт 16, приходит тегированный фрейм. Коммутатор проверяет ARP таблицу и видит, что абонент доступен через порт 1.
2. Порт 1 работает в режиме Untagged, поэтому с фрейма снимается метка влана (его принадлежность к данному влану). После этого фрейм становится нетегированным.
3. Так как порт настроен как Untagged, то когда фрейм от абонента приходит на порт 1 коммутатора, в нём проставляется тег соответствующий PVIDу, который указывает какому VLAN’у принадлежит этот фрейм. В данном случае проставляется тег с VLAN’ом 2.
Для абонента фреймы остаются нетегированными. Операция тегирования, которую выполняют коммутаторы абсолютно прозрачна. Хосты ничего не знают о тегах и получают обычные фреймы.
PVID auto assign используется для включения автоматического назначения PVID. Когда назначается VLAN X untagged, PVID этого порта будет назначен VLAN X. PVID будет автоматически обновляться на последний добавленный untagged vlan. Когда untagged порт удаляется, PVID порта будет назначается на «default VLAN» или предыдущий.
Значение по умолчанию включено.
Пример:
Проверка автоматического сопоставления PVID
show pvid auto_assign
Асимметричные VLAN
Суть данной технологии в том, что бы предоставить доступ с одного влана в другой, не используя маршрутизацию. Например абоненты разных сегментов сети не имея доступ друг к другу могли подключаться к требуемому серверу или интернет шлюзу.
Настройка GVRP
GVRP (GARP VLAN Registration Protocol) служит для передачи между устройствами информации о vlan, используемых на данном отрезке сети. При использовании в сети большого количества устройств, добавление в сеть нового vlan часто влечет за собой перенастройку всех устройств, через которые должен проходить новый vlan. В сети провайдера, особенно при применении схемы vlan-per-customer, это может создавать огромную головную боль. Использование протокола GVRP позволяет избежать перенастройки оборудования каждый раз при изменении vlan в сети.
nni_bpdu_addr [dot1d | dot1ad] — Используется для определения адреса протокола BPDU для GVRP в узле предоставления услуг. Он может использовать адрес GVRP 802.1d, адрес GVRP поставщика услуг 802.1ad или пользовательский multicast адрес. Диапазон определенного пользователем адреса: 0180C2000000 — 0180C2FFFFFF.
Пример:
Пример настройки GVRP
Схема подключения
На коммутаторах №2 и №3:
Напоминаю, что ключ advertisement при создании vlan говорит коммутатору о том, что этот vlan необходимо анонсировать соседним устройствам.
Ingress-контроллер: что это и как выбрать
Kubernetes — достаточно сложная для понимания вещь, даже сами авторы это признают. В этой статье мы попытаемся простым языком объяснить, что такое Ingress-контроллер и для чего он нужен.
Начнем с того, что в Kubernetes есть целых два типа сущностей. Первый — сам Ingress, некоторый набор правил, позволяющий трафику извне достичь сервисов внутри кластера. Второй — Ingress-контроллер, представляющий собой ни что иное, как pod с запущенным приложением-контроллером. Здесь стоит оговориться, что отдельно эти два типа сущностей бесполезны.
На ум приходит аналогия с автомобилем. Ingress — это как автомобиль со снятым двигателем, а Ingress-контроллер — тот самый двигатель. Так что если вы создадите Ingress без установленного контроллера, то само собой ничего работать не будет.
Работая вместе, Ingress и Ingress-контроллер позволяют создать единую точку входа для трафика и выполняют одновременно роль прокси и балансировщика нагрузки, работая на 7 уровне сетевой модели OSI.
Итак, основная задача выбора Ingress-контроллера лишь в том, какое именно приложение будет разруливать весь трафик. В идеале различные Ingress-контроллеры должны работать одинаково по спецификации, но на практике все же есть различия. Возвращаясь к автомобильной аналогии, двигатели бывают разного типа: атмосферные, компрессорные, турбированные и даже электрические.
Важно понимать, что Ingress-контроллер не отменяет необходимость во внешнем балансировщике нагрузки, он лишь добавляет дополнительный уровень маршрутизации и большую гибкость в распределении трафика.
Какие существуют Ingress-контроллеры
Условно все Ingress-контроллеры можно поделить на две группы.
Первая группа — специфичные приложения, рассчитанные на работу с трафиком каких-либо экосистем, например, Citrix ingress controller. Эта штука предназначена для работы с Citrix ADC — комплексным решением по доставке приложений для исполнения на bare-metal, а также внутри контейнеров и виртуальных машин.
Точно такое же специфичное решение — AKS Application Gateway Ingress Controller. Его назначение — балансирование рабочих нагрузок, размещенных в Azure, о чем нам намекают в названии AKS (Azure Kubernetes Service). Многие крупные провайдеры облачной инфраструктуры создают свои решения и предлагают их в рамках использования определенной экосистемы. Например, F5 BIG-IP Container Ingress Services for Kubernetes создавался для работы с виртуальными серверами F5 BIG-IP.
Переходим ко второй группе, где у нас находятся универсальные Ingress-контроллеры. Их достаточно много, но можно выделить несколько, базирующихся на одном и том же ПО, например, на Envoy:
Особняком стоят Ingress-контроллеры, заточенные под использование в паре с определенным ПО:
Все перечислять не будем. Из вышесказанного можно сделать однозначный вывод о том, что вопрос выбора Ingress-контроллера может быть решен, если какое-либо ПО уже есть и оно готово к рабочим нагрузкам соответствующего контроллера.
Взглянем чуть более детально, какие контроллеры чаще всего используют.
Наиболее используемый Ingress-контроллер
Прежде чем набивать шишки, всегда проще посмотреть на чужой опыт и сделать выводы. На момент написания этой статьи в подавляющем большинстве источников на роль Ingress-контроллера рекомендуют использовать nginx-ingress. Причина проста: разработкой и поддержкой этого контроллера занимаются разработчики Kubernetes. Длительный опыт использования, а также масса документации и учебных материалов играют существенную роль в «боевой» эксплуатации. Так что вряд ли вы столкнетесь с нерешаемыми проблемами.
Дабы исключить всякую путаницу: существует еще и NGINX Ingress для Kubernetes, продукт от NGINX Inc (ныне компания поглощена F5 Networks). В отличие от nginx-ingress у этого продукта есть еще и платная версия, реализованная на NGINX Plus.
Чуть меньшую популярность завоевал HAProxy Ingress. Достаточно производительный и гибкий, с понятной документацией и обширным комьюнити в Slack и на StackOverflow, этот контроллер однозначно заслуживает внимания. Определенную долю рынка занимает Traefik Kubernetes Ingress и Kong для Kubernetes, также основанный на NGINX.
Критерии выбора
Прежде чем сделать выбор, стоит задать несколько важных вопросов:
Эти простые вопросы позволят сходу отсечь варианты, когда наличие дополнительных возможностей потребует больших вложений, но эти возможности не будут востребованы.
Следующий вопрос, который важен для принятия решения, — о производительности. Получить на него ответ можно будет либо эмпирическим путем, либо основываясь на уже существующих научных исследованиях.
В качестве примера приведем научную публикацию «Исследование производительности различных имплементаций Ingress-контроллеров в кластере Kubernetes», основанную на проведенных исследованиях в Белорусском государственном университете информатики и радиоэлектроники (Шуляк А.В., Савенко А.Г.). Получившиеся выводы весьма интересны и показательны. Выяснились следующие факты:
Заключение
Процесс выбора Ingress-контроллера в большинстве случаев зависит от решаемых задач и требований к поддержке дополнительных функций. Практически все существующие контроллеры способны решать простые задачи, так что выбор можно сделать в пользу наиболее простого и хорошо задокументированного варианта.
Если же у вас высоконагруженные системы, следует большее внимание уделить производительности решения, а также наличию коммерческой поддержки. Так вы минимизируете возможные простои и не будете тратить время на глубокое погружение в особенности используемой системы.
Настройка распределенной трассировки в Kubernetes с OpenTracing, Jaeger и Ingress-NGINX
В эпоху, когда крупные компании используют более 500 микросервисов одновременно, важно иметь возможность быстро выяснить, из-за чего произошел сбой или снизилась производительность. Без специализированных инструментов это может быть похоже на поиск иголки в стоге сена.
В качестве примера мы будем использовать приложение Meow-Micro, специально созданное для этой статьи. Но вы можете развернуть собственные приложения, если захотите.
Что нам потребуется?
В этом руководстве предполагается, что вы понимаете код, написанный на Go, умеете использовать Ingress-nginx и знаете, как работают основные объекты Kubernetes, такие как Service и Deployment.
Если вы хотите освежить знания, воспользуйтесь этими материалами:
Запуск Kubernetes в Docker Desktop
Начнём с установки Docker Desktop, который позволяет не только запускать контейнеры, но и создать локальный кластер Kubernetes.
После установки Docker Desktop выполните следующие действия, чтобы создать кластер Kubernetes:
Нажмите на иконку Preferences
2. Выберете вкладку Kubernetes, установите флажок Enable Kubernetes и нажмите кнопку Apply & Restart
3. В появившемся окне нажмите кнопку Install и дождитесь пока установка завершится
4. Выберите пункт Kubernetes в панели задач
5. В контекстном меню выберите docker-desktop
6. Проверьте, что вы подключены к нужному кластеру
Установка Ingress-NGINX Controller
1. Воспользуйтесь командой из официального руководства для установки Ingress-NGINX Controller.
2. Проверьте, что установка Ingress Сontroller прошла успешно. Pods должны быть запущены и находятся в статусе Ready.
Важно: Если Pod находится в статусе Pending из-за нехватки ресурсов CPU/Memory, вы можете добавить ресурсы вашему кластеру в настройках Docker Desktop.
Установка Jaeger и настройка Ingress Controller
1. Вначале склонируйте репозиторий meow-micro, этот проект мы будем использовать во всех примерах.
2. В репозитории вы найдёте манифесты для jaeger-all-in-one. Установим Jaeger из этих манифестов.
3. Убедимся, что Jaeger запущен и готов к работе.
4. Пришло время настроить совместную работу Ingress-NGINX and Jaeger, для этого необходимо добавить параметры enable-opentracing и jaeger-collector-host в ingress-nginx-controller ConfigMap. В параметре jaeger-collector-host указываем имя сервиса Jaeger.
5. Убедимся, что в настройках Ingress Controller включен и настроен opentracing.
Jaeger и Ingress Controller успешно установлены и настроены. Самое время развернуть наши микросервисы!
Разворачиваем тестовое приложение
Подробная информация об использовании REST и GRPC с GoLang:
Тестовое приложение также содержит несколько дополнительных инструментов:
tracing.go
Получает параметры для настройки Jaeger из окружения, в котором запускается Helm для установки meow-client and meow-server.
client.go
Span — базовый элемент распределенной трассировки. Представляет собой описание некоего рабочего процесса (например, запроса к базе данных). Span’ы обычно содержат ссылки на другие span’ы, что позволяет объединять множество span’ов в Trace.
Trace — визуализация жизни запроса в процессе его перемещения по распределенной системе.
Подробную информацию о понятиях trace и span можно посмотреть в официальной документации.
Установка тестового приложения
Установить Helm v3 можно на любую операционную систему, например на macOS с помощью brew. Теперь мы готовы развернуть микросервисы в нашем кластере.
Воспользуемся Makefile из репозитория, чтобы развернуть тестовое приложение в кластере Kubernetes.
Проверим, что Pods обоих сервисов запустились и работают.
Просмотр данных трассировки
А теперь самое интересное! Взглянем на трассировку.
Откройте консоль Jaeger, указав в браузере адрес http://localhost:8081.
2. Отправим запрос нашему приложению.
4. Нажмите кнопку Find Traces.
5. Отобразятся все трассировки для nginx. Каждую из них можно развернуть, чтобы получить больше информации.
6. Теперь вы можете отслеживать, сколько времени занял каждый запрос.
И выводить дополнительную информацию по каждому запросу.
Не смотря на то, что этот небольшой пример даёт представление о том, что такое распределенная трассировка, увидеть всю её мощь можно только на реальных приложениях под нагрузкой.
Другие системы трассировки
Мы рассмотрели как использовать Jaeger для трассировки запросов Ingress-Nginx. Для этих целей можно также использовать Zipkin или DataDog.
