Alguns meses atrás, escrevi um artigo sobre o controlador Kubernetes Nginx Ingress , que ocupa o segundo lugar em popularidade neste blog. Seu tema principal é o uso do Kubernetes Ingress para implantações locais. No entanto, a maioria dos usuários usa o Kubernetes na nuvem da AWS e nos serviços de nuvem pública de outros fornecedores. No entanto, o problema é que a AWS cria um novo ELB (Elastic Load Balancer) para cada serviço do tipo LoadBalancer. Isso pode ser muito caro. Se você usar o Kubernetes Ingress, precisará de apenas um ELB.
Como isso funciona?
Para uma melhor compreensão, darei alguns diagramas. Sem um controlador Ingress, um balanceador ELB clássico separado será criado para cada serviço fornecido:
Ao usar o Ingress, você precisará de apenas um desses balanceadores ELB, direcionando todas as solicitações para proxies do Ingress em execução no cluster:
Considere o custo do Classic Load Balancer:
Você precisa pagar por cada hora completa ou incompleta do balanceador de carga Classic Load Balancer e por cada gigabyte de dados transferidos com ele.
Isso significa que, ao usar um cluster na região leste dos EUA, você terá que pagar aproximadamente US $ 18,25 por cada serviço prestado. Você também precisa pagar por cada gigabyte de dados processados. O Ingress permite reduzir os custos da AWS com um grande número de serviços. Obviamente, para garantir alta disponibilidade, você pode usar várias réplicas do pod de proxy do Ingress.
Implantar o Nginx Ingress
Há um grande número de opções disponíveis para o controlador Ingress, por exemplo, Traefik , Voyager (para HAProxy), Contour (para Envoy ) ou até mesmo o controlador Ingress AWS ALB (versão alfa), que é um pouco diferente do restante. Neste post, eu olho para o controlador Ingress Nginx , agora o mais comum. Diferentemente do artigo anterior sobre o controlador Ingress Nginx , desta vez eu uso o Helm para implantação:
cat > values.yaml <<EOF controller: replicaCount: 2 config: use-proxy-protocol: "true" service: annotations: service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*' EOF helm install --name ingress \ --namespace ingress \ -f values.yaml \ stable/nginx-ingress
Nota Há um problema no Helm que os booleanos não são analisados como seqüências de caracteres ao usar o argumento set. Portanto, criei um arquivo com valores e não --set valores padrão por meio --set e --set-string .
Verificar a lareira O Ingress exibe dois serviços, o controlador e o lado do servidor por padrão:
kubectl get pod -n ingress --selector=app=nginx-ingress NAME READY STATUS RESTARTS AGE ingress-nginx-ingress-controller-8689c87db7-jlwxv 1/1 Running 0 5m ingress-nginx-ingress-controller-8689c87db7-kv859 1/1 Running 0 5m ingress-nginx-ingress-default-backend-5f5888cc9b-jdjrp 1/1 Running 0 5m
Alguns pontos devem ser explicados aqui. Como todas as solicitações serão processadas no controlador do Ingress, é desejável ter pelo menos duas de suas réplicas. Este é essencialmente um servidor proxy interno. O controlador usa o backend padrão para rotear recursos inexistentes do Ingress. O lado do servidor é bastante simples por padrão. Para obter os endereços IP de origem no log de proxy do Ingress, ativei o protocolo proxy para Nginx e ELB usando as duas configurações a seguir:
--set controller.service.annotations."service\\.beta\\.kubernetes\\.io/aws-load-balancer-proxy-protocol"='*' \ --set-string controller.config.use-proxy-protocol=true \
O protocolo de conexão proxy foi projetado para comunicar servidores proxy sem perder dados do cliente.
E como bônus, agora você pode facilmente obter o DNS automático. Primeiro, crie um registro DNS A usando metacaracteres, como *.test.example.com , que apontará para o controlador Ingress ELB. O endereço ELB pode ser obtido usando este comando:
kubectl get svc ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' -n ingress a00950ebcfd0411e740ee0207cf10ce8-1089949860.eu-west-1.elb.amazonaws.com
Em seguida, ao criar o ponto de entrada do Ingress com o host site1.test.example.com , site1.test.example.com pode inserir imediatamente essa linha no navegador. O DNS resolverá o nome sem configuração adicional. Usar um registro DNS com metacaracteres não é uma boa ideia, mas funciona. Para configurar o DNS em detalhes, você pode usar o DNS externo para o Kubernetes.
Conclusão
O uso do controlador Ingress realmente ajuda a alcançar um nível mais alto de automação. Mas lembre-se de que, se falhar, todos os seus pontos de extremidade externos também falharão! No próximo artigo, mostrarei como configurar a atualização e instalação automáticas de certificados SSL usando o Let's Encrypt. Depois disso, você pode usar o DNS automático com pontos de extremidade SSL por padrão. Acompanhe as novidades.