#kubernetes #namespaces #azure-aks
#kubernetes #пространства имен #azure-aks
Вопрос:
У нас есть запрос на предоставление определенных модулей в среде AKS в Интернет для стороннего использования.
В настоящее время у нас есть частный кластер AKS с управляемым стандартным балансировщиком нагрузки SKU, использующим расширенную сеть Azure (в основном Calico), где каждый модуль получает свой собственный частный IP-адрес из IP-пространства виртуальной сети. Все частные IP-адреса в настоящее время проходят через брандмауэр по определяемому пользователем маршруту, чтобы выйти в Интернет, и наоборот. Трафик между маршрутами on prem через VPN-соединение через виртуальную глобальную сеть Azure. Я не хочу изменять какое-либо существующее поведение маршрутизации, если это не необходимо на 100%.
Мой вопрос в том, как вы предоставляете доступ к конкретным модулям существующего частного кластера AKS из Интернета? Весь кластер не обязательно должен быть доступен для Интернета. Проблема, которую я предвижу, заключается в том, что эфемерные модули и постоянно меняющиеся IP-адреса делают невозможным простое подключение к брандмауэрам. Я также думал о том, чтобы просто создать новый кластер AKS с общедоступным балансировщиком нагрузки. Проблема здесь, однако, заключается в безопасности, поскольку она все равно должна проходить через брандмауэры и, вероятно, может с существующими пользовательскими маршрутами
Каков рекомендуемый способ настройки архитектуры, в которой определенные модули в AKS могут быть доступны через Интернет, при этом позволяя этим модулям получать доступ к модулям через частную сеть. Я хочу избежать выставления всех модулей в Интернет
Комментарии:
1. Вы можете предоставлять свои развертывания в виде сервисов, таких как NodePort или LoadBalancer
2. У вас есть пример? Не знаком с ними или с тем, что они делают
Ответ №1:
Есть несколько опций, которые вы можете использовать, чтобы предоставить вашему приложению доступ к
вне вашей сети, например: Сервис:
NodePort: Предоставляет сервис на IP-адресе каждого узла на статическом порту (theNodePort).ClusterIPАвтоматически создается служба, к которойNodePortнаправляется служба. Вы сможете связатьсяNodePortсо службой из-за пределов кластера, запросив<NodeIP>:<NodePort>.LoadBalancer: Предоставляет доступ к службе извне с помощью балансировщика нагрузки облачного провайдера.NodePortиClusterIPавтоматически создаются службы, к которым направляется внешний балансировщик нагрузки.
Кроме того, есть еще один вариант, который использует an ingress , IMO, это лучший способ выставить HTTP-приложения извне, потому что можно создавать правила по пути и хосту и дает вам гораздо большую гибкость, чем сервисы. Для входа поддерживается только HTTP / HTTPS, если вам нужен TCP, перейдите к службам
Я бы порекомендовал вам взглянуть на эти ссылки, чтобы глубоко понять, как работают сервисы и вход:
Комментарии:
1. Как это учитывает необходимый NAT, который должен выполняться на брандмауэре? Привязывают ли входные контроллеры статический IP-адрес к нужному модулю независимо от того, изменяет ли модуль IP-адреса? Возможно, эти брандмауэры также могут использовать NAT по полному доменному имени DNS
2. Если вы используете nginx-ingress, он создаст балансировщик нагрузки и привяжет внешний ip-адрес к службе nginx-ingress, они будут перенаправлять трафик для нужной службы, о nat, ваши узлы должны иметь доступ к Интернету, поэтому вам необходимо настроить службу NAT для всех узлов.
Ответ №2:
Разверните входной контроллер nginx и привяжите службу ingress controller к общедоступному балансировщику нагрузки. Определите правила входа для служб kubernetes, к которым вы хотите получить доступ из Интернета. Обратите внимание, что контроллер ingress позволяет использовать точку входа для служб, работающих внутри kubernetes
Ответ №3:
Несколько лет спустя и захотел обновить.
Мы успешно внедрили масштабируемую опцию входа в наш частный кластер AKS, используя NGINX в качестве входа. Основной поток был
Общедоступный IP-адрес> NAT для интерфейса частного IP-адреса NGINX > Правила пути NGINX, которые указывают на ваш модуль / службу
Взяв URL-адрес в качестве примера для микросервиса www.example.com/service1 , общедоступная запись DNS, которую вы создаете, — это то, что разрешает www.example.com к общедоступному IP-адресу, который вы будете привязывать к частному IP-адресу NGINX. Затем правила, которые вы создаете в NGINX, берут определенный путь / service1 URL-адреса и используют его для маршрутизации к конкретной службе, на которую вы указали. Он ведет себя так же, как переключение URL в других балансировщиках нагрузки. Это действительно все, что NGINX делает для вас. В синтаксисе NGINX это включает в себя указание имени хоста (URL) и связанного правила с внутренним путем и именем службы. Имя службы в этом примере service1 , а путь / указан, потому что service1 находится сразу за корнем.
Что-то вроде этого экономит затраты за счет использования меньшего количества общедоступных IP-адресов. Например, вы можете использовать поддомен для простого NAT-трафика в отдельную тестовую среду. www.test.example.com и www.example.com может указывать на отдельные общедоступные IP-адреса, которые вы можете использовать для разделения кластеров AKS, работающих под управлением NGINX. Таким образом, ваши правила NGINX могут быть идентичными, потому что он ищет только /service1, который, надеюсь, вы отразили в тестовой и рабочей средах.
Много способов сделать это, но несколько рекомендаций из извлеченных уроков
- используйте поддомены для разделения нескольких сред
- стандартизируйте свой частный интерфейсный IP-адрес NGINX в разных средах (например, сделайте так, чтобы все они заканчивались на .100
- создайте стандартный входной шаблон NGINX, в котором вам действительно нужно только изменить ServiceName. Ваше имя хоста должно быть статичным в среде
- попросите своих разработчиков включить это и развернуть свои микросервисы с помощью helm, а не полагаться на команду инфраструктуры для обновления служб NGINX. Своего рода поражение менталитета devops и прирост скорости