Utilizando um serviço para expor seu aplicativo

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.

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)

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.