Introdução
Nos laboratórios anteriores, você aprendeu que os Pods são criados e removidos continuamente. Se um Pod falhar e outro for criado para substituí-lo, o novo Pod receberá um endereço IP completamente diferente. Imagine tentar ligar para um amigo cujo número de telefone muda toda vez que ele desliga!
Para resolver esse problema, o Kubernetes usa um Service.
Um Service fornece uma identidade de rede estável para uma carga de trabalho, mesmo que os Pods responsáveis por ela mudem. Essa separação entre o ciclo de vida dos Pods e o endpoint do Service é um conceito fundamental de networking no Kubernetes.
Este é um dos modelos mentais mais importantes do networking do Kubernetes: os Pods devem poder ser substituídos, mas os clientes ainda precisam de um endereço confiável. Um Service resolve essa diferença ficando à frente dos Pods, que podem mudar, e apresentando um nome estável e um IP virtual.
Neste laboratório, você vai:
- Criar um Service para fornecer um endereço estável à sua aplicação.
- Aprender como o Service sabe para quais Pods encaminhar as solicitações (usando Selectors).
- Acessar sua aplicação de fora do cluster usando um tipo específico de Service chamado NodePort.
Criar o YAML do Service
Nesta etapa, você criará um arquivo de configuração para um Service. Usaremos um tipo específico chamado NodePort.
Um Service do tipo NodePort abre uma porta específica em cada Node (servidor) do cluster. É como abrir uma porta específica da sua casa para permitir a entrada de pessoas de fora.
O NodePort é fácil de entender porque faz um mapeamento direto para uma porta em cada Node, mas normalmente não é o desenho final usado em produção para tráfego público. Em ambientes maiores, o NodePort costuma ficar atrás de um balanceador de carga da nuvem ou de uma camada de ingress. Aqui, ele é útil porque torna o caminho da rede visível para iniciantes.
Crie um arquivo chamado service.yaml no diretório do seu projeto:
nano service.yaml
Cole o conteúdo a seguir. Observe a parte selector: vamos deixá-la intencionalmente como app: unknown por enquanto, para mostrar como ela funciona.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
- port: 80 ## The port the Service exposes internally
targetPort: 80 ## The port the container is listening on
nodePort: 30008 ## The static door we are opening to the outside
selector:
app: unknown ## This needs to match your Pod's label
Salve e saia (Ctrl+X, Y, Enter).
Esse arquivo define um Service chamado my-service. Ele escuta na porta 30008 (o nodePort). Todo tráfego que chegar a essa porta será encaminhado para Pods com o label app: unknown (que atualmente não existem!).
Corrigir o Selector
Um Service usa um Selector para encontrar os Pods para os quais deve encaminhar o tráfego. Ele funciona como uma etiqueta de endereço. Se o endereço no envelope (o Selector do Service) não corresponder ao endereço da casa (o label do Pod), a correspondência não será encontrada.
Labels e selectors aparecem em todo o Kubernetes, não apenas em Services. Eles são um dos principais mecanismos de agrupamento da plataforma. Em vez de fixar nomes exatos de Pods, os recursos do Kubernetes normalmente encontram objetos relacionados comparando labels. Isso mantém o sistema flexível quando os Pods são recriados.
Na etapa de configuração, iniciamos automaticamente uma aplicação web para você. Vamos encontrar sua “etiqueta de endereço”.
Execute este comando para ver os labels dos Pods em execução:
kubectl get pods --show-labels
Você deverá ver algo parecido com: web-app-xxxxx ... app=web-app
O label é app=web-app. No entanto, nosso Service está procurando por app: unknown. Vamos corrigir isso.
Edite o arquivo service.yaml:
nano service.yaml
Altere a seção selector para corresponder ao label do seu Pod:
selector:
app: web-app
Salve e saia. Agora o Service sabe exatamente para onde enviar o tráfego.
Aplicar e verificar
Agora que o endereço está correto, vamos ativar o Service.
Quando você aplica esse manifesto, o Kubernetes cria um objeto Service e configura regras internas de networking para que as solicitações que chegam ao Service possam ser encaminhadas para os endpoints dos Pods correspondentes. O ponto importante é que o próprio Service não executa sua aplicação. Ele é uma abstração de rede posicionada à frente dos Pods da aplicação.
Aplique a configuração ao cluster:
kubectl apply -f service.yaml
Você deverá ver: service/my-service created.
Para confirmar que o Service está ativo e funcionando, consulte a lista de Services:
kubectl get svc my-service
Você verá:
- NAME: my-service
- TYPE: NodePort
- PORT(S): 80:30008/TCP
Isso confirma que seu “número de telefone” está ativo e aguardando chamadas na porta 30008.
Acessar a aplicação
Agora chegou o momento da verdade. Será que conseguimos acessar a aplicação de “fora” (pelo seu terminal)?
A aplicação está exposta na porta 30008 do Node do Kubernetes.
Há três portas envolvidas, e iniciantes costumam confundi-las. O nodePort é a porta aberta externamente no Node, o port é a porta exposta pela abstração do Service, e o targetPort é a porta dentro do container que realmente fornece a aplicação. Manter essas funções distintas evitará confusão mais adiante.
Primeiro, obtenha o endereço IP do Node do Minikube:
minikube ip
Suponha que o endereço seja 192.168.49.2. O endereço completo da sua aplicação será http://192.168.49.2:30008.
Podemos usar curl para acessar esse endereço e verificar se a aplicação está respondendo:
curl http://$(minikube ip):30008
Você deverá ver o código HTML da página "Welcome to nginx!".
Isso confirma o caminho completo da solicitação:
- Você acessou a porta externa do Node (
30008). - O Service recebeu a solicitação.
- Ele verificou seu Selector (
app: web-app). - Ele encaminhou a solicitação para um dos Pods que correspondem a esse label.
- O Pod respondeu com a página web.
Resumo
Neste laboratório, você resolveu o problema dos endereços IP de Pods que desaparecem usando um Service.
Você conseguiu:
- Criar um Service do tipo NodePort (
service.yaml) para abrir uma porta de acesso à sua aplicação. - Configurar um Selector para informar ao Service quais Pods ele deve gerenciar.
- Acessar sua aplicação em execução de fora do cluster usando seu endereço estável.
Os Services são a ligação que mantém as aplicações Kubernetes integradas, permitindo que diferentes partes do sistema se comuniquem de forma confiável.
