Подключите доменное имя AWS route53 к службе K8s LoadBalancer

Подключите доменное имя AWS route53 к службе K8s LoadBalancer

Что я пытаюсь сделать
Создайте среду Kubernetes с единой службой шлюза API, сопоставленной с адресом DNS.

Что я наделал:
1) Я зашел на сервис AWS Route53 и создал поддомен.
2) У этого поддомена, похоже, статический IP. Я получил этот IP, пропинговав доменное имя.
3) Я настроилКластер Kubernetes на AWS с kops.
4) У меня есть шлюзовая служба, конечные точки которой попадают в микросервисы в инфраструктуре k8s.
Эта служба имеет тип LoadBalancer, где loadBalancerIPравен статическому IP сверху.

Проблема:
При указанной выше настройке служба не сможет создать Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.

Итак, я начинаю читать, как мне кажется, довольно хорошие ресурсы оK8s Ингресс(Также) иСлужба обратного прокси-сервера Nginx. (И это в конце) (Также этот).

Моя ошибкатакже спрашивали раньше, и снова ответ, похоже, ставит еще один слой между моим шлюзом API и внешним миром.
Затем, после прочтения большого количества информации о контроллерах Nginx Ingress, я действительно запутался.

Мои вопросы
a) Есть ли более веская причина иметь еще один уровень между шлюзом и внешним миром, помимо совместимости?
b) Будет ли то, что я попробовал, работать в Google Cloud Platform (является ли это проблемой, характерной для развертывания AWS)
c) Контроллер входящего трафика Nginx... В чем разница между обратным прокси-сервером Nginx и службой Kubernetes Ingress? Потому что мне кажется, что эти слова здесь взаимозаменяемы.
d) Кажется, что существует так много способов сделать это, какой из них на данный момент является лучшим (и самым простым)?

РЕДАКТИРОВАТЬ:

Я реализовал вариант-1 ответа Ионы. Вот конфиги на случай, если кто-то захочет что-то скопировать и вставить.

шлюз-сервис.yaml:

apiVersion: v1
kind: Service
metadata:
  name: gateway-service
spec:
  ports:
    - name: "gateway"
      port: 80
      targetPort: 5000
  selector:
    app: "gateway"
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: "gateway"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: "gateway"
    spec:
      containers:
        - image: <account_nr>.dkr.ecr.us-east-1.amazonaws.com/gateway
          imagePullPolicy: Always
          name: "gateway"
          ports:
            - containerPort: 5000
              protocol: "TCP"

Затем создайте поддомен в AWS Route53:

1) Создать домен
2) New Record Set
3) Тип A(IPv 4)
4) Псевдоним yes
5) Выберите целевой псевдоним, который соответствует внешней конечной точке сервиса. ( kubectl describe services gateway-service | grep LoadBalancer)

решение1

Потенциально задействованы пять различных аспектов автоматизации инфраструктуры:

  • назначение IP-адреса узлу
  • сопоставление имени dns с ip
  • балансировка нагрузки для сопоставления членов
  • сопоставление IP-адреса службы Kubernetes с членом пода, а иногда и с балансировщиком нагрузки
  • kubernetes входящий

Некоторые из них могут управлять некоторыми другими. Они не обязательно все хорошо работают вместе и могут конкурировать друг с другом.

Я на самом деле не изучал среду выполнения Kubernetes от Amazon, но помимо нее, для выполнения простой задачи, которую вы хотите сделать, я знаю как минимум о трех вариантах:

  • начиная с kubernetes, создайте тип службы = LoadBalancer, чтобы он создал ELB. Это даст вам уникальное доменное имя, для которого вы можете сделать запись CNAME в route53, чтобы сопоставить с ним ваш поддомен. Членство в ELB будет обновляться с использованием аналогичной автоматизации, которая поддерживает обновления служб с помощью IP-адресов пода. Существуют некоторые ограничения относительно балансировки запросов уровня 4 и уровня 7.
  • начните с ELB, добавьте узлы k8s EC2 в качестве членов ELB и запустите ingress как daemonset. есть много вариантов этого, но это означает, что ответственность за обеспечение корректного членства в ELB связана с управлением k8s на EC2, как автоматическим, так и ручным. Но это предлагает другие точки контроля над маршрутизацией трафика уровня 7.
  • начиная с Kubernetes, используйте инструмент route53-mapper для управления конфигурацией route53 из аннотаций на ресурсах службы.

https://github.com/kubernetes/kops/tree/master/addons/route53-mapper

Это более простая версия первой, включающая TLS, но использование ее для TLS кажется немного безумным, поскольку она требует хранения сертификатов в служебных аннотациях, а не там, где им и положено, в секретах.

Ответы:

Есть ли более веская причина иметь еще один уровень между шлюзом и внешним миром, помимо совместимости?

Нет никаких требований, этот подход решает проблему наличия как ELB, так и k8s, владеющих автоматизацией. Как правило, не хочется конкурирующих владельцев автоматизации.

Будет ли то, что я попробовал, работать в Google Cloud Platform (это проблема, связанная с развертыванием AWS)?

Автоматизация gcloud отличается, и ее балансировщикам нагрузки можно назначать ip-адреса, поскольку у нее есть отдельно управляемое распределение ip-адресов. Так что в какой-то степени это проблема, специфичная для AWS.

Контроллер входящего трафика Nginx... В чем разница между обратным прокси-сервером Nginx и службой Kubernetes Ingress? Мне кажется, что эти слова здесь взаимозаменяемы.

Они взаимозаменяемы. Одно — абстракция, другое — конкретно.

Kubernetes Ingress — это абстракция, которая может быть реализована множеством различных способов. Ingress включает в себя ресурсы Ingress, контроллер и прокси, который принимает конфигурацию. Контроллер отслеживает изменения ресурсов Ingress в кластере, транслирует их в конфигурацию, специфичную для прокси, а затем перезагружает прокси.

Контроллер входящего трафика nginx — это реализация этой машины с использованием nginx. Есть много других, использующих haproxy и другие прокси.

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

См. выше. Вероятно, есть и другие способы.

Связанный контент