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. Consegui esse IP executando ping no nome de domínio.
3) Eu configurei umCluster Kubernetes na AWS com kops.
4) Eu tenho um serviço de gateway cujos endpoints atingem microsserviços dentro da infraestrutura k8s.
Este serviço é do tipo LoadBalancer, onde loadBalancerIPé igual ao IP estático acima.
O problema:
Com a configuração acima, o serviço não consegue criar com arquivos Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.
Então vou ler o que parecem ser recursos muito bons sobreEntrada K8s(Também) e umServiço de proxy reverso Nginx. (E este no final) (Também este).
Meu errotambém já foi perguntado antese, novamente, a resposta parece colocar outra camada entre meu gateway de API e o mundo exterior.
Depois de ler muito sobre os controladores Nginx Ingress, estou muito confuso.
Minhas perguntas
a) Existe uma razão maior para ter outra camada entre o gateway e o mundo exterior além da compatibilidade?
b) O que tentei funcionaria no Google Cloud Platform (este é um problema específico de 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 tantas maneiras de fazer isso, qual é o melhor (e mais fácil) método atual?
EDITAR:
Implementei a opção 1 da resposta de Jonah. Aqui estão as configurações caso alguém queira copiar e colar.
serviço de gateway.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) Tipo A(IPv 4)
4) Alias yes
5) Selecione o destino do Alias que corresponde ao endpoint externo do serviço. ( kubectl describe services gateway-service | grep LoadBalancer)
Responder1
Existem cinco peças distintas de automação de infraestrutura potencialmente em jogo:
- atribuição de ip para nó
- nome DNS para mapeamento IP
- balanceamento de carga para mapeamento de membros
- IP do serviço Kubernetes para mapeamento de membro do pod e, às vezes, para balanceador de carga
- entrada do Kubernetes
Alguns deles podem dirigir alguns dos outros. Eles não necessariamente jogam bem juntos e podem competir entre si.
Eu realmente não olhei para o tempo de execução do kubernetes da Amazon, mas fora isso, para fazer a coisa simples que você deseja, estou ciente de pelo menos três opções:
- começando no kubernetes, crie um serviço type=LoadBalancer para que ele crie um ELB. Isso lhe dará um nome de domínio exclusivo no 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, pois mantém os serviços atualizados com pod ips. Existem algumas limitações em relação ao balanceamento de solicitações das camadas 4 e 7.
- comece a partir de um ELB, adicione nós EC2 k8s como membros do ELB e execute o ingresso como um daemonset. há muitas variantes sobre isso, mas isso significa que a responsabilidade de garantir que a adesão ao ELB seja 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.
- começando no kubernetes, use uma ferramenta chamada route53-mapper para conduzir a configuração do route53 a partir de anotações nos recursos de serviço.
https://github.com/kubernetes/kops/tree/master/addons/route53-mapper
Esta é uma versão mais simples da primeira, incluindo TLS, mas parece um pouco insano usá-la para TLS porque parece exigir a manutenção de 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 exterior além da compatibilidade?
Não há nenhum requisito, esta abordagem é a solução para que ELB e k8s possuam automação. Geralmente, não se quer proprietários de automação concorrentes.
O que tentei funcionaria no Google Cloud Platform (este é um problema específico de implantação da AWS)
A automação gcloud é diferente e seus balanceadores de carga podem receber ips, porque possui alocação de IP gerenciada separadamente. Então, até certo ponto, este é 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. Uma é uma abstração, a outra é concreta.
Kubernetes Ingress é a abstração que pode ser implementada de muitas maneiras diferentes. O ingresso compreende recursos de ingresso, um controlador e um proxy que faz a configuração. O controlador observa o cluster em busca de alterações nos recursos de entrada, converte-as em configurações específicas do proxy e, em seguida, recarrega o proxy.
O controlador de ingresso nginx é uma implementação desse maquinário usando nginx. Existem muitos outros, usando haproxy e outros proxies.
Parece haver tantas maneiras de fazer isso. Qual é o melhor (e mais fácil) método atual?
Veja acima. Provavelmente também existem outras maneiras.