Kubernetes Services

Se aprofundar no vasto universo do Kubernetes significa também entender a importância dos Services. Neste post, vamos explorar este componente crucial, desvendando suas nuances e fornecendo exemplos práticos para consolidar o conhecimento.

O Que São Services no Kubernetes?

Antes de começarmos, é essencial compreender a função dos Services. Eles atuam como uma abstração que permite a comunicação entre diferentes componentes ou módulos de uma aplicação, independentemente da localização dos pods. Imagine o Service como um elo vital na rede de comunicação do seu cluster Kubernetes.

Considere os componentes de uma aplicação determinada aplicação:

• Um módulo de frontend (Frontend Web App) disponibilizado para os usuários acessarem a aplicação em um navegador Web;
• Um módulo de backend (Backend API App) que fornece APIs REST para o módulo de frontend;
• Um Banco de Dados externo ao Cluster Kubernetes, que fornece a persistência dos dados da aplicação;

Neste cenário, para exemplificar os tipos de serviços, o módulo frontend está sendo exposto para os usuários através de um serviço do tipo NodePort. O módulo de backend não precisa estar acessível fora do cluster, por isso, ele está sendo exposto através de um serviço do tipo ClusterIP, já o Banco de Dados, por estar fora do cluster, está sendo referenciado através de um serviço do tipo ExternalName.

Quais São os Tipos de Services no Kubernetes?

Ao criar um Service, é essencial entender os diferentes tipos de Service disponíveis, como ClusterIP, NodePort, LoadBalancer e ExternalName. Cada tipo oferece benefícios específicos, desde a comunicação interna no cluster até a exposição de serviços para o mundo externo.

A seguir, vamos dar uma olhada em cada um dos tipos de serviços disponíveis no Kubernetes.

ClusterIP Service

Serviços do tipo ClusterIP, são úteis para comunicação entre Pods dentro do mesmo cluster Kubernetes. Eles expõe o serviço em um IP estático interno do cluster. Quando uma requisição é efetuada para este IP, o serviço redirecionará o tráfego para um dos Pods associados a este serviço. Esta é uma característica muito importante, por que se existir mais de um Pod associado ao serviço, o serviço irá efetuar automaticamente o balanceamento de carga entre os pods, evitando que apenas um dos pods disponíveis fique sobrecarregado, por responder a todas as requisições.

Principais características do serviço ClusterIP

• Comunicação entre Pods dentro do mesmo Cluster.
• Balanceamento de Carga entre o Serviço e os Pods.
• Não são acessíveis fora do Cluster.

O arquivo .yaml de exemplo abaixo, descreve um objeto Pod e um objeto Service ClusterIP:

apiVersion: v1
kind: Pod
metadata:
  name: backend-api-app
  labels:
    app.kubernetes.io/name: backend-api-app
spec:
  containers:
  - name: app
    image: backend-api-app:stable
    ports:
      - containerPort: 80
        name: http-web-port
---
apiVersion: v1
kind: Service
metadata:
  name: backend-api-app-svc
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: backend-api-app
  ports:
    - port: 80
      targetPort: 80
       

O exemplo acima cria um Service chamado backend-api-app-svc que roteia o tráfego para a porta 80 dos Pods que possuem a label app.kubernetes.io/name: backend-api-app.

Explicando os campos mais importantes da definição do serviço

• O campo kind especifica o tipo de objeto do Kubernetes que está sendo definido.
• O campo name especifica o nome do serviço.
• O campo type especifica o tipo do serviço.
• O campo selector especifica um rótulo (label) que definie quais pods devem ser expostos pelo serviço. Neste caso, este serviço irá redirecionar o tráfego que ele receber, efetuando o devido balanceamento de carga, para todos os Pods que possuírem o label “app.kubernetes.io/name” com o valor “backend-api-app”.
• O campo port define a porta que o serviço deve expor, para que outros serviços ou Ingresses possam referenciá-lo para ter acesso à aplicação.
• O campo targetPort é o elo de ligação entre o serviço e a aplicação. A porta definida nesse campo, deve ser a porta exposta pelo contêiner da aplicação no Pod, para acesso à aplicação. Você pode definir tanto o número da porta quanto o nome da porta definida no contêiner. Definir o nome da porta traz maior flexibilidade, pois permite que a porta do pod seja alterada, sem quebrar o serviço que mapeia o pod.

Um serviço pode mapear qualquer porta de entrada (port) para a porta de destino (targetPort) na aplicação . Por padrão e por conveniência, o campo targetPort é definido para o mesmo valor definido no campo port.

Quando o tipo do serviço não for especificado, por padrão o Kubernetes definirá o serviço como sendo do tipo ClusterIP.

NodePort Service

O Serviço NodePort é utilizado para expor uma aplicação para clientes externos, ou seja, para tráfego proveniente de requisições externas ao cluster.

Ao criar um serviço NodePort, o Kubernetes irá selecionar um número de porta dentro do intervalo de 30.000 até 32.767 e irá abrir a porta selecionada em todos os Worker Nodes do cluster.

Todo tráfego que chegar no endereço IP do Worker Node mais a porta que foi aberta, será redirecionado para o serviço NodePort que abriu a porta e o serviço se encarregará de enviar o tráfego para um Pod vinculado ao serviço.

Principais características do serviço NodePort:

• Habilita a comunicação entre Clientes Externos e Aplicações existentes no Cluster.
• Não há distribuição de tráfego entre os Nodes.
• Balanceamento de Carga entre o Serviço e os Pods.

O arquivo .yaml de exemplo abaixo, descreve um objeto Service NodePort:

apiVersion: v1
kind: Service
metadata:
  name: frontend-web-app-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: frontend-web-app
  ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30001

O exemplo acima cria um Service chamado frontend-web-app-svc que roteia o tráfego para Pods que possuem a label app.kubernetes.io/name: frontend-web-app.

Explicando os campos mais importantes da definição do serviço

• O campo kind especifica o tipo de objeto do Kubernetes que está sendo definido.
• O campo name especifica o nome do serviço.
• O campo type especifica o tipo do serviço.
• O campo selector especifica um rótulo (label) que definie quais pods devem ser expostos pelo serviço. Neste caso, este serviço irá redirecionar o tráfego que ele receber, efetuando o devido balanceamento de carga, para todos os Pods que possuírem o label “app.kubernetes.io/name” com o valor “backend-api-app”.
• O campo port define a porta que o serviço deve expor, para que outros serviços ou Ingresses possam referenciá-lo para ter acesso à aplicação.
• O campo targetPort é o elo de ligação entre o serviço e a aplicação. A porta definida nesse campo, deve ser a porta exposta pelo contêiner da aplicação no Pod, para acesso à aplicação. Você pode definir tanto o número da porta quanto o nome da porta definida no contêiner. Definir o nome da porta traz maior flexibilidade, pois permite que a porta do pod seja alterada, sem quebrar o serviço que mapeia o pod.
• O campo nodePort diz ao Kubernetes qual porta deve ser aberta nos Nodes Worker do Cluster, para receber o tráfego das requisições que chegarem de fora do cluste, tornando o serviço acessível ao mundo externo.

LoadBalancer Service

O Serviço LoadBalancer é outro tipo de serviço útil para expor uma aplicação para o mundo externo, porém, ele só funciona quando você está executando o Kubernetes em uma plataforma de Cloud que suporta este tipo de serviço.

Quando você cria um serviço LoadBalancer, o Kubernetes detecta qual é o provedor de cloud onde o cluster está sendo executado e se encarrega de criar um balanceador de carga adequado, de acordo com o provedor de cloud detectado.

O Balanceador de carga fornecerá um IP acessível externamente, e enviará o tráfego para a porta correta nos Nodes do Cluster e posteriormente encaminhará o tráfego para o Pod.

Principais características do serviço LoadBalancer:

• Habilita a comunicação entre Clientes Externos e Aplicações existentes no Cluster.
• Há balanceamento de carga entre os Nodes através do Load Balancer.
• Balanceamento de Carga entre o Serviço e os Pods.

O arquivo .yaml de exemplo abaixo, descreve um objeto Service LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: frontend-web-app-svc
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: frontend-web-app
  ports:
    - name: http
      port: 80
      targetPort: 80

O Serviço descrito acima possui o nome frontend-web-app-svc e está configurado para redirecionar o tráfego recebido na porta 80, para a targetPort: 80 dos Pods rotulados com label: app.kubernetes.io/name: frontend-web-app.

ExternalName Service

Services ExternalName, diferente dos serviços vistos anteriormente, servem para referenciarmos um serviço/aplicação que está sendo executada fora do cluster Kubernetes, como um Banco de Dados por exemplo.

Suponha que uma aplicação Backend que está executando em um Pod dentro do cluster, precise acessar um Banco de Dados externo acessível através de um nome DNS db-prod.dominioxyz.com para consultar e persistir dados.

Neste cenário, você pode criar um serviço ExternalName chamado “db-prod-svc“, e mapear este serviço para o DNS db-prod.dominioxyz.com.

O arquivo .yaml de exemplo abaixo, descreve um objeto Service ExternalName:

apiVersion: v1
kind: Service
metadata:
  name: db-prod-svc
spec:
  type: ExternalName
  externalName: db-prod.dominioxyz.com

O campo externalName define o endereço DNS do serviço externo que este serviço irá referenciar.

Quando uma aplicação quiser se conectar ao Banco de dados, ela enviará a requisição para o nome local do serviço db-prod-svc. Em seguida, o Kubernetes vai procurar “db-prod-svc” no serviço ExternalName e verá que ele tem um nome externo de “db-prod.dominioxyz.com”.

O Kubernetes vai usar então o DNS para resolver o nome externo para um endereço IP e encaminhará a solicitação para o serviço externo apropriado fora do cluster Kubernetes.

Se o provedor de serviços mudar para um novo endereço IP ou obter um novo nome de domínio, você poderá simplesmente atualizar a definição do serviço ExternalName para apontar para o novo local.
O Kubernetes cuidará da resolução DNS do novo endereço para que a aplicação possa continuar acessando o serviço externo usando o mesmo nome local.

Principais características do serviço ExternalName:

• Habilita a comunicação Aplicações existentes no Cluster e Serviços existentes fora do Cluster.
• Ajuda a reduzir o acoplamento entre as aplicações e detalhes de serviços externos.
• Permite alterar referências a recursos externos, sem ter que alterar o código da aplicação.

Conclusão

No Kubernetes, os Services atuam como uma abstração que permite a comunicação entre diferentes componentes ou módulos de uma aplicação, independentemente da localização dos pods, permitindo uma comunicação confiável dentro dos cluster e entre o cluster e recursos, serviços e clientes externos.

Depois de conhecer os Services, você pode dar o próximo passo e começar a explorar recursos de rede mais sofisticados como o Kubernetes Ingress. Ele simplifica e aprimora o roteamento de tráfego externo para serviços dentro do cluster Kubernetes.

Se você quiser saber mais sobre Kubernetes, não deixe de conferir o Curso de Kubernetes que eu criei especialmente para quem está começando a aprender esta tecnologia. É um curso repleto de informações valiosas e exemplos práticos que você poderá aplicar e ir para o próximo nível em Kubernetes.