Подключите доменное имя 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 Ingress (Также) и Сервис обратного прокси Nginx. (И этот в конце) (Также этот).

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

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

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

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

шлюз-service.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)

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

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

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

Я на самом деле не смотрел на среду выполнения Amazon kubernetes, но помимо этого, для выполнения простых вещей, которые вы хотите сделать, я знаю как минимум 3 варианта:

начиная с кубернетов, создайте сервис type = LoadBalancer, чтобы он создавал ELB. Это даст вам уникальное доменное имя, для которого вы можете сделать запись CNAME в route53, чтобы сопоставить свой субдомен. Членство в ELB будет обновляться с использованием той же автоматизации, что и для обновления сервисов с помощью модулей. Существуют некоторые ограничения в отношении балансировки запросов уровней 4 и 7.
начните с ELB, добавьте узлы k8s EC2 в качестве членов ELB и запустите ingress как набор демонов. на этот счет есть много вариантов, но это означает, что ответственность за обеспечение правильного членства в 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 - это абстракция, которую можно реализовать разными способами. Входящие ресурсы включают входящие ресурсы, контроллер и прокси-сервер, который принимает конфигурацию. Контроллер следит за кластером на предмет входящих изменений ресурсов, переводит их в конфигурацию, специфичную для прокси, а затем перезагружает прокси.

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

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

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