Phenquestions
- Um aplicativo implantado em um cluster do Kubernetes é executado como pods de coleta.
- Os pods são essencialmente contêineres programados em vários nós.
- Os nós podem ser servidores físicos ou VMs oferecidos pelo seu provedor de hospedagem. Obviamente, você também pode usar o Kubernetes em um servidor local, se desejar.
- Cada pod tem um endereço IP exclusivo.
- Seu aplicativo é dividido em muitos subcomponentes, geralmente chamados de microsserviços.
- Para cada microsserviço do seu aplicativo, tem um serviço correspondente no Kubernetes.
- No contexto do Kubernetes, um Serviço expõe uma coleção de pods para o resto do cluster como uma única abstração. Um único IP virtual.
- Isso ajuda um serviço de seu aplicativo a se comunicar com outro serviço. É uma abstração que permite endereçar uma coleção de pods, em vez de especificar o endereço IP de um pod, toda vez que você quiser falar com ele.
- Um serviço Kubernetes também atua como um balanceador de carga para todos os pods que ele representa. O tráfego é distribuído uniformemente em todos os nós.
Até agora tudo bem. Cada serviço pode falar com outro serviço. Essa comunicação é possível em todo o cluster do Kubernetes
Serviços de exposição
“Se uma árvore cai em uma floresta e ninguém está por perto para ouvir, ela faz algum som?”
Em uma observação semelhante, se seu aplicativo não atender a uma finalidade fora do cluster Kubernetes, realmente importa se o cluster foi bem construído ou não? Provavelmente não.
Para dar um exemplo concreto, digamos que temos um aplicativo da web clássico composto de um front-end escrito em Nodejs e um back-end escrito em Python que usa banco de dados MySQL. Você implanta dois serviços correspondentes em seu cluster Kubernetes.
Você faz um Dockerfile especificando como empacotar o software de front-end em um contêiner e, da mesma forma, empacota seu back-end. Em seguida, no cluster Kubernetes, você implantará dois serviços, cada um executando um conjunto de pods por trás dele. O serviço da web pode se comunicar com o cluster de banco de dados e vice-versa.
No entanto, o Kubernetes não expõe nenhum desses serviços (que são endpoint HTTP essenciais) para o resto do mundo. Conforme declarado nos documentos oficiais:
“Presume-se que os serviços tenham IPs virtuais roteáveis apenas na rede de cluster”
Isso é perfeitamente razoável do ponto de vista de segurança, seus serviços podem se comunicar entre si, mas o cluster não permite que entidades externas falem diretamente com os serviços. Por exemplo, apenas o seu front-end da web pode se comunicar com o serviço de banco de dados e ninguém mais pode enviar solicitações ao serviço de banco de dados.
O problema surge quando olhamos para o caso de uso de um serviço de front-end. Ele precisa ser exposto ao resto do público para que os usuários finais possam usar seu aplicativo. Exporemos esses serviços usando o Kubernetes Ingress.
Entrada do Kubernetes
A entrada expõe as rotas HTTP e HTTPS de fora do cluster para serviços dentro do cluster. Você pode controlar as regras de roteamento definindo o recurso de entrada do Kubernetes. Mas faz muito mais do que isso. Expor um único serviço pode ser alcançado usando várias outras alternativas, como NodePort ou balanceadores de carga, mas essas instalações não têm recursos sofisticados o suficiente para um aplicativo da web moderno.
Recursos como expor vários aplicativos em um único IP, definir rotas, etc.
Então, vamos entender esses recursos no restante do artigo:
Entrada de serviço única
Esta é a versão mais simples de expor um único serviço como um front-end da web com um IP (ou um nome de domínio) e portas HTTP e HTTPS padrão (i.e, 80 e 443).
Fanout Único
Esta é uma configuração de entrada que permite permitir o tráfego de entrada para um único IP e encaminhá-lo para vários serviços.
Isso consiste de:
- Um recurso de entrada consiste em um nome de host foo.bar.com
- Uma lista de caminhos onde o tráfego será roteado como foo.bar.com / admin foo.bar.com / home foo.bar.com / sso
Fanout único é o caso em que um único IP é usado para vários serviços. Os serviços podem estar em caminhos diferentes no URI, como foo.bar.com / admin pode ser um serviço para administradores e foo.bar.com / home pode ser o serviço que gera a página inicial de cada usuário.
A porta de entrada sempre será 80 ou 443, mas a porta onde os serviços estão sendo executados (dentro do cluster) pode ser um pouco diferente.
Esse tipo de entrada nos ajuda a minimizar o número de balanceadores de carga no cluster, uma vez que funciona essencialmente como um.
Hospedagem Virtual Baseada em Nome
Os endereços IP públicos são finitos. Eles também são bastante caros. A ideia de hospedagem virtual baseada em nome é mais antiga do que o Kubernetes. A essência disso é que você aponta os registros DNS para diferentes sites como ww1.exemplo.com e ww2.exemplo.com para o mesmo endereço IP. O servidor em execução nesse endereço IP verá a solicitação de entrada e se o nome do host mencionado na solicitação for ww1.exemplo.com, então, ele serve esse site para você, e se ww2.exemplo.com é solicitado, então isso é servido.
No contexto do Kubernetes, podemos executar dois serviços em execução, digamos, na porta 80 e expor os dois em um único endereço IP usando uma entrada também da porta 80. No ponto de entrada, o tráfego de ww1.exemplo.com será separado do tráfego para ww2.exemplo.com. Daí o termo hospedagem virtual baseada em nome.
Conclusão
O Ingress no Kubernetes é bastante sofisticado para ser abordado em uma única postagem. Há uma variedade de casos de uso para ele e uma variedade de controladores de entrada que adicionarão a funcionalidade de entrada ao seu cluster. Eu recomendaria começar com Nginx Ingress Controller.
Para mais detalhes e especificações você também pode seguir a documentação oficial.
