Conecte o nome do domínio AWS route53 ao serviço LoadBalancer do K8s

Question

O que estou tentando fazer
Crie um ambiente Kubernetes com um único serviço de gateway de API mapeado para um endereço DNS.

O que eu fiz:
1) Fui ao serviço AWS Route53 e criei um subdomínio.
2) Esse subdomínio parece ter um IP estático. Eu recebi esse IP pingando o nome do domínio.
3) Eu configurei um cluster do Kubernetes na AWS com kops .
4) Eu tenho um serviço de gateway cujos endpoints atingem microserviecs dentro da infraestrutura do k8s.
Este serviço é do tipo LoadBalancer , em que loadBalancerIP é igual ao IP estático acima.

O problema:
Com a configuração acima, o serviço falha ao criar com Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB .

Então eu vou ler o que parecem ser muito bons recursos sobre K8s Ingress ( Também ) e um serviço de proxy reverso Nginx . ( E este no fim ) ( Também este ).

Meu erro também foi perguntado antes , e novamente a resposta parece colocar outra camada entre o meu gateway de API e o mundo exterior.
Então, depois de ler muito sobre controladores Nginx Ingress, estou muito confuso.

Minhas perguntas
a) Existe uma razão maior para ter outra camada entre o gateway e o mundo externo além da compatibilidade?
b) O que tentei funcionar no Google Cloud Platform (este é um problema específico da implantação da AWS)
c) controlador de entrada Nginx ... Qual é a diferença entre um proxy reverso Nginx e o serviço Kubernetes Ingress? Porque para mim as palavras parecem ser usadas de forma intercambiável aqui.
d) Parece haver muitas maneiras de fazer isso, qual é o melhor método (e mais fácil) atual?

EDITAR:

Eu implementei a opção 1 da resposta de Jonah. Aqui estão as configurações no caso de alguém querer algo para copiar e colar.

gateway-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"

Em seguida, crie o subdomínio no AWS Route53:

1) Criar domínio
2) New Record Set
3) Digite A (IPv4)
4) Alias yes
5) Selecione o Alias desejado que corresponda ao terminal externo do Serviço. ( kubectl describe services gateway-service | grep LoadBalancer )

    

Answer 1

Existem cinco peças distintas de automação de infraestrutura potencialmente em jogo:

• ip para atribuição de nó
• nome do dns para o mapeamento de ip
• balanceamento de carga para o mapeamento de membros
• mapeamento de membros ip do serviço do kubernetes para o balanceador de carga
• entrada do kubernetes

Alguns deles podem dirigir alguns dos outros. Eles não necessariamente jogam bem juntos e podem competir uns com os outros.

Eu realmente não observei o tempo de execução do kubernetes da Amazon, mas fora disso, para fazer a coisa simples que você quer fazer, estou ciente de pelo menos três opções:

• a partir dos kubernetes, crie um tipo de serviço = LoadBalancer para criar um ELB. Isso fornecerá um nome de domínio exclusivo para o qual você pode criar um registro CNAME no route53 para mapear seu subdomínio. A associação ao ELB será atualizada usando automação semelhante, já que mantém os serviços atualizados com os ips do pod. Existem algumas limitações em torno do balanceamento de solicitação da camada 4 e da camada 7.
• inicie em um ELB, adicione nós do EC8 do k8s como membros do ELB e execute a entrada como um daemonset. Há muitas variantes sobre isso, mas isso significa que a responsabilidade de garantir que a associação no ELB esteja correta está vinculada ao gerenciamento de k8s no EC2, seja automatizado ou manual. Mas isso oferece outros pontos de controle sobre o roteamento de tráfego da camada 7.
• a partir de kubernetes, use uma ferramenta chamada route53-mapper para orientar a configuração de route53 a partir de anotações nos recursos de serviço.

link

Esta é uma versão mais simples do primeiro, incluindo o TLS, mas parece um pouco insano usá-lo para o TLS porque parece exigir manter os certificados em anotações de serviço, em vez de onde eles pertencem, em segredos.

Respostas:

Existe uma razão maior para ter outra camada entre o gateway e o mundo externo além da compatibilidade?

Não há exigência, esta abordagem está resolvendo ter ELB e k8 possuindo automação. Geralmente, não se deseja proprietários de automação concorrentes.

O que eu tentei funcionar no Google Cloud Platform (isso é um problema específico da implantação da AWS)

A automação do gcloud é diferente e seus balanceadores de carga podem receber ips, porque ela tem alocação de IP gerenciada separadamente. Então, até certo ponto, esse é um problema específico da AWS.

Controlador de entrada Nginx ... Qual é a diferença entre um proxy reverso Nginx e o serviço Kubernetes Ingress? Porque para mim as palavras parecem ser usadas de forma intercambiável aqui.

Eles são intercambiáveis. Um é uma abstração, o outro é concreto.

Kubernetes O Ingress é a abstração que pode ser implementada de muitas maneiras diferentes. O ingresso inclui recursos de ingresso, um controlador e um proxy que assume a configuração. O controlador observa o cluster em busca de alterações nos recursos de entrada, converte-as em configurações específicas de proxy e, em seguida, recarrega o proxy.

O controlador de entrada nginx é uma implementação deste maquinário usando nginx. Há muitos outros usando haproxy e outros proxies.

Parece haver muitas maneiras de fazer isso, qual é o melhor método atual (e mais fácil)?

Veja acima. Existem provavelmente outras formas também.