DNS с внутренними балансировщиками нагрузки GKE - PullRequest
Новая
       38

DNS с внутренними балансировщиками нагрузки GKE

3 голосов
/ 25 апреля 2019

У меня есть два кластера kubernetes в GKE: один общедоступный, который обрабатывает взаимодействие с внешним миром, и один частный только для внутреннего использования.

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

Внутренний балансировщик нагрузки DNS доступен для обычных внутренних балансировщиков нагрузки, которые обслуживают виртуальные машины, и DNS будет иметь вид [SERVICE_LABEL].[FORWARDING_RULE_NAME].il4.[REGION].lb.[PROJECT_ID].internal, но есть ли что-то для внутренних балансировщиков нагрузки в GKE? Или есть обходной путь, который позволил бы мне выполнить нечто подобное?

Ответы [ 3 ]

1 голос
/ 25 апреля 2019

Я сомневаюсь, что маршрут «Внутренний балансировщик нагрузки DNS» работает, но вот некоторые обходные пути, которые приходят на ум:

1) Вход: в вашем общедоступном кластере сопоставьте все имена частных служб с входным контроллером в вашем частном кластере. Вход может направить запросы на имя хоста к правильному сервису.

2) Заготовленные домены: используйте какой-нибудь общий постфикс для ваших частных сервисов (например, * .private) и используйте частный кластер kube-dns для разрешения имен этих сервисов (см. https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/)

Пример: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"private": ["10.2.3.4"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

3) Не пробовал, но kEdge , кажется, еще одно решение для безопасной связи между кластерами: https://improbable.io/blog/introducing-kedge-a-fresh-approach-to-cross-cluster-communication

1 голос
/ 07 мая 2019

Этого можно добиться, назначив внутреннему балансировщику нагрузки ip CIDR рабочего узла. В GKE мы предоставляем три блока CIDR при создании кластера 1. Рабочий узел CIDR 2. Под сидр 3. Service Endpoint cidr (обычно используется loadbalancer). CIDR, который мы предоставляем для службы Pod sand, доступен только в Kubernetes. Следовательно его не видно снаружи.

Вместо использования ip конечной точки службы для внутреннего балансировщика нагрузки можно назначить ip из CIDR рабочего узла, который из подсети в VPC, поэтому ip виден между модулями разных кластеров.

Недостатком этого подхода является то, что вы потеряете один рабочий узел во время автомасштабирования.

1 голос
/ 25 апреля 2019

Никогда не слышал о встроенном DNS для балансировщиков нагрузки в GKE, но мы делаем это на самом деле довольно просто. У нас есть Внешний DNS Сервис Kubernetes, который управляет записями DNS для различных вещей, таких как балансировщики нагрузки и входы. Что вы можете сделать:

  1. Создать облачную DNS внутреннюю зону. Убедитесь, что вы интегрируете его с вашими VPC.
  2. Убедитесь, что ваша учетная запись службы узлов Kubernetes имеет разрешения администратора DNS (или суперширокого редактора).
  3. Установка внешнего DNS.
  4. Аннотируйте внутреннюю службу балансировки нагрузки с помощью external-dns.alpha.kubernetes.io/hostname=your.hostname.here
  5. Убедитесь, что DNS-запись создана и может быть разрешена в вашем VPC.
...