# Utilizando um serviço para expor seu aplicativo > Aprenda sobre Services no Kubernetes. > Entenda como rótulos (labels) e seletores (selectors) relacionam-se aos Services. > Exponha uma aplicação externamente ao cluster Kubernetes. --- LLMS index: [llms.txt](/llms.txt) ---

Objetivos

  • Aprenda sobre Services no Kubernetes
  • Entenda como rótulos (labels) e seletores (selectors) relacionam-se aos Services
  • Exponha uma aplicação externamente ao cluster Kubernetes usando um Service

Visão Geral dos Services no Kubernetes

Pods do Kubernetes são efêmeros. Na verdade, Pods possuem um ciclo de vida. Quando um nó de processamento morre, os Pods executados no nó também são perdidos. A partir disso, o ReplicaSet pode dinamicamente retornar o cluster ao estado desejado através da criação de novos Pods para manter sua aplicação em execução. Como outro exemplo, considere um backend de processamento de imagens com 3 réplicas. Estas réplicas são permutáveis; o sistema front-end não deveria se importar com as réplicas backend ou ainda se um Pod foi perdido ou recriado. Dito isso, cada Pod em um cluster Kubernetes tem um endereço IP único, incluindo Pods que estejam rodando no mesmo nó, então há necessidade de ter uma forma de reconciliar automaticamente mudanças entre Pods de modo que sua aplicação continue funcionando.

Um objeto Service no Kubernetes é uma abstração que define um conjunto lógico de Pods e uma política pela qual acessá-los. Serviços permitem um baixo acoplamento entre os Pods dependentes. Um serviço é definido usando YAML ou JSON, como todos os manifestos de objetos Kubernetes. O conjunto de Pods selecionados por um Service é geralmente determinado por um seletor de rótulos (veja abaixo o motivo pelo qual você poderia desejar um Service que não inclui um seletor (selector) na especificação (spec)).

Embora cada Pod tenha um endereço IP único, estes IPs não são expostos externamente ao cluster sem um objeto Service. Objetos Service permitem que suas aplicações recebam tráfego. Services podem ser expostos de formas diferentes especificando um tipo (campo type) na especificação do serviço (campo spec):

  • ClusterIP (padrão) - Expõe o serviço sob um endereço IP interno no cluster. Este tipo de serviço é acessível somente dentro do cluster.
  • NodePort - Expõe o serviço sob a mesma porta em cada nó selecionado no cluster usando NAT. Torna o serviço acessível externamente ao cluster usando o endereço <NodeIP>:<NodePort>. É um superconjunto do tipo ClusterIP.
  • LoadBalancer - Cria um balanceador de carga externo no provedor de nuvem atual (se suportado) e atribui um endereço IP fixo e externo para o serviço. É um superconjunto do tipo NodePort.
  • ExternalName - Mapeia o Service para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro DNS do tipo CNAME com o seu valor. Nenhum tipo de proxy é configurado. Este tipo requer a versão 1.7 ou mais recente do kube-dns, ou o CoreDNS versão 0.0.8 ou superior.

Mais informações sobre diferentes tipos de Services podem ser encontradas no tutorial Utilizando IP de origem. Veja também Conectando aplicações com serviços.

Adicionalmente, note que existem alguns casos de uso com serviços que envolvem a ausência de um selector no campo spec. Services criados sem selector também não criarão objetos Endpoints correspondentes. Isto permite que usuários mapeiem manualmente um serviço a endpoints específicos. Outro motivo pelo qual seletores podem estar ausentes é que você esteja utilizando estritamente type: ExternalName.

Resumo

  • Exposição de Pods ao tráfego externo
  • Balanceamento de carga de tráfego entre múltiplos Pods
  • Utilização de rótulos (labels)

Um objeto Service do Kubernetes é uma camada de abstração que define um conjunto lógico de Pods e habilita a exposição ao tráfego externo, balanceamento de carga e descoberta de serviço para esses Pods.


Serviços e Rótulos

Um Service roteia tráfego entre um conjunto de Pods. Service é a abstração que permite Pods morrerem e se replicarem no Kubernetes sem impactar sua aplicação. A descoberta e o roteamento entre Pods dependentes (tal como componentes frontend e backend dentro de uma aplicação) são controlados por Services do Kubernetes.

Services relacionam um conjunto de Pods usando rótulos e seletores, uma primitiva de agrupamento que permite operações lógicas sobre objetos do Kubernetes. Rótulos são pares chave/valor anexados à objetos e podem ser usados de diversas formas:

  • Designar objetos para desenvolvimento, teste e produção
  • Adicionar tags de versão
  • Classificar um objeto usando tags


Rótulos podem ser anexados aos objetos no momento de sua criação ou posteriormente. Eles podem ser modificados a qualquer momento. Vamos expor nossa aplicação usando um Service e aplicar alguns rótulos.


Crie um novo Service

Vamos verificar que nossa aplicação está rodando. Utilizaremos o comando kubectl get e procuraremos por Pods existentes:

kubectl get pods

Se não houver Pods rodando, isso significa que o ambiente interativo ainda está recarregando o estado anterior. Por favor, aguarde alguns instantes e liste os Pods novamente. Você poderá prosseguir assim que vir um Pod rodando.

A seguir, vamos listar os Services existentes no momento no nosso cluster:

kubectl get services

Temos um Service chamado kubernetes que é criado por padrão quando o minikube inicializa o cluster. Para criar um novo Service e expô-lo para tráfego externo utilizaremos o comando expose com o tipo NodePort.

kubectl expose deployment/kubernetes-bootcamp --type=NodePort --port 8080

Vamos rodar novamente o subcomando get services:

kubectl get services

Temos agora um Service chamado kubernetes-bootcamp rodando. Aqui vemos que o Service recebeu um ClusterIP único, uma porta interna e um IP externo (o IP do nó).

Para descobrir qual porta foi aberta externamente (para o Service com tipo NodePort) iremos rodar o subcomando describe service:

kubectl describe services/kubernetes-bootcamp

Crie uma variável de ambiente chamada NODE_PORT que armazena o número da porta do nó:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Agora podemos verificar que a aplicação está exposta externamente ao cluster utilizando curl, o endereço IP do nó e a porta exposta externamente:

curl http://"$(minikube ip):$NODE_PORT"

E receberemos uma resposta do servidor. O Service está exposto.

Passo 2: Utilizando rótulos (labels)

O Deployment criou automaticamente um rótulo para o nosso Pod. Com o subcomando describe deployment você pode ver o nome (a chave) deste rótulo:

kubectl describe deployment

Vamos utilizar este rótulo para filtrar nossa lista de Pods. Utilizaremos o comando kubectl get pods com o parâmetro -l, seguido dos valores dos rótulos:

kubectl get pods -l app=kubernetes-bootcamp

Você pode fazer o mesmo para listar os Services existentes:

kubectl get services -l app=kubernetes-bootcamp

Obtenha o nome do Pod e armazene-o na variável de ambiente POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo "Name of the Pod: $POD_NAME"

Para aplicar um novo rótulo podemos utilizar o subcomando label, seguido pelo tipo de objeto, nome do objeto e o novo rótulo:

kubectl label pods "$POD_NAME" version=v1

Este comando aplicará um novo rótulo no Pod (nós fixamos a versão da aplicação ao Pod) e podemos verificar com o comando describe pod:

kubectl describe pods "$POD_NAME"

Vemos aqui que o rótulo está agora vinculado ao nosso Pod. E agora podemos pesquisar a lista de Pods utilizando o novo label:

kubectl get pods -l version=v1

E vemos o Pod.

Removendo um Service

Para remover um Service você pode utilizar o subcomando delete service. Rótulos também podem ser utilizados aqui:

kubectl delete service -l app=kubernetes-bootcamp

Confirme que o Service foi removido com sucesso:

kubectl get services

Isto confirma que nosso Service foi removido. Para confirmar que a rota não está mais exposta, você pode disparar uma requisição para o endereço IP e porta previamente expostos através do comando curl:

curl http://"$(minikube ip):$NODE_PORT"

Isto prova que a aplicação não está mais acessível de fora do cluster. Você pode confirmar que a aplicação ainda está rodando com um curl de dentro do Pod:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

Vemos aqui que a aplicação ainda está rodando. Isto se deve ao fato de que o Deployment está gerenciando a aplicação. Para encerrar a aplicação, você precisaria remover o Deployment também.

Assim que você finalizar este tutorial, vá para Executando Múltiplas Instâncias do seu Aplicativo.