Serviço

Nesta página, descrevemos os serviços do Kubernetes e seu uso no Google Kubernetes Engine. Para aprender a criar um serviço, consulte Como exibir aplicativos usando serviços.

O que é um serviço?

Um serviço agrupa um conjunto de endpoints do pod em um único recurso. É possível configurar várias maneiras de acessar o agrupamento. Por padrão, você recebe um endereço IP de cluster estável que os clientes dentro do cluster podem usar para contatar pods no serviço. Um cliente envia uma solicitação ao endereço IP estável e a solicitação é encaminhada a um dos pods no serviço.

Um serviço identifica seus pods membro com um seletor. Para que um pod seja membro do serviço, ele precisa ter todos os rótulos especificados no seletor. Um rótulo é um par de chave-valor arbitrário anexado a um objeto.

O manifesto de serviço a seguir tem um seletor que especifica dois rótulos. O campo selector informa que qualquer pod que tenha os rótulos app: metrics e department:engineering é um membro deste serviço.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: engineering
  ports:
  ...

Por que usar um serviço?

Em um cluster do Kubernetes, cada pod tem um endereço IP interno. Mas, em uma implantação, os pods vêm e vão, e seus endereços IP mudam. Portanto, não faz sentido usar os endereços IP do pod diretamente. Com um serviço, você recebe um endereço IP estável válido durante a vida útil do serviço, mesmo quando os endereços IP dos pods membro são alterados.

Um serviço também fornece balanceamento de carga. Os clientes chamam um endereço IP único e estável, e suas solicitações são balanceadas nos pods que são membros do serviço.

Tipos de serviços

Existem cinco tipos de serviços:

  • ClusterIP (padrão): os clientes internos enviam solicitações para um endereço IP interno estável.

  • NodePort: os clientes enviam solicitações para o endereço IP de um nó em um ou mais valores de nodePort especificados pelo serviço.

  • LoadBalancer: os clientes enviam solicitações para o endereço IP de um balanceador de carga de rede.

  • ExternalName: os clientes internos usam o nome DNS de um serviço como um alias para um nome DNS externo.

  • Sem comando: use um serviço sem comando quando você quiser agrupar um pod, mas não precisa de um endereço IP estável.

O tipo NodePort é uma extensão do tipo ClusterIP. Portanto, um serviço do tipo NodePort tem um endereço IP de cluster.

O tipo LoadBalancer é uma extensão do tipo NodePort. Portanto, um serviço do tipo LoadBalancer tem um endereço IP de cluster e um ou mais valores de nodePort.

Serviços do tipo ClusterIP

Quando você cria um serviço do tipo ClusterIP, o Kubernetes cria um endereço IP estável acessível a partir dos nós no cluster.

Veja aqui um manifesto de um serviço do tipo ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: my-cip-service
spec:
  selector:
    app: metrics
    department: sales
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

É possível criar o serviço usando kubectl apply -f [MANIFEST_FILE]. Depois de criar o serviço, use o kubectl get service para ver o endereço IP estável:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
my-cip-service   ClusterIP   10.11.247.213   none          80/TCP

Os clientes no cluster chamam o serviço usando o endereço IP do cluster e a porta TCP especificada no campo port do manifesto de serviço. A solicitação é encaminhada para um dos pods membro na porta TCP especificada no campo targetPort. Portanto, no exemplo anterior, um cliente chama o serviço em 10.11.247.213 na porta TCP 80. A solicitação é encaminhada a um dos pods membro na porta TCP 8080. Observe que o pod membro precisa ter um contêiner que esteja escutando a porta TCP 8080. Se nenhum contêiner estiver escutando a porta 8080, os clientes verão uma mensagem como "Falha ao conectar" ou "Este site não pode ser acessado".

Serviço do tipo NodePort

Quando você cria um serviço do tipo NodePort, o Kubernetes fornece um valor nodePort. Em seguida, o serviço pode ser acessado usando o endereço IP de qualquer nó com o valor nodePort.

Veja aqui um manifesto de um serviço do tipo NodePort:

apiVersion: v1
kind: Service
metadata:
  name: my-np-service
spec:
  selector:
    app: products
    department: sales
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Depois de criar o serviço, use kubectl get service -o yaml para visualizar sua especificação e ver o valor de nodePort.

spec:
  clusterIP: 10.11.254.114
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32675
    port: 80
    protocol: TCP
    targetPort: 8080

Os clientes externos chamam o serviço usando o endereço IP externo de um nó com a porta TCP especificada por nodePort. A solicitação é encaminhada a um dos pods membro na porta TCP especificada pelo campo targetPort.

Por exemplo, suponha que o endereço IP externo de um dos nós do cluster seja 203.0.113.2. Em seguida, no exemplo anterior, o cliente externo chama o serviço em 203.0.113.2 na porta TCP 32675. A solicitação é encaminhada a um dos pods membro na porta TCP 8080. O pod membro precisa ter um contêiner escutando a porta TCP 8080.

O tipo de serviço NodePort é uma extensão do tipo de serviço ClusterIP. Portanto, os clientes internos têm duas maneiras de chamar o serviço:

  • Usando clusterIP e port.
  • Usando o endereço IP interno de um nó e nodePort.

Para algumas configurações de cluster, o balanceador de carga HTTP(S) do Google Cloud usa um serviço do tipo NodePort. Para saber mais informações, consulte Como configurar o balanceamento de carga HTTP com a Entrada.

Observe que um balanceador de carga HTTP(S) é um servidor proxy e é fundamentalmente diferente do balanceador de carga de rede descrito neste tópico em Serviço do tipo LoadBalancer.

Serviços do tipo LoadBalancer

Quando você cria um serviço do tipo LoadBalancer, um controlador do Google Cloud ativa e configura um balanceador de carga de rede no projeto. Esse balanceador de carga tem um endereço IP estável que pode ser acessado de fora do seu projeto.

Observe que um balanceador de carga de rede não é um servidor proxy. Ele encaminha pacotes sem alterar os endereços IP de origem e destino.

Veja aqui um manifesto de um serviço do tipo LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: my-nlb-service
spec:
  selector:
    app: metrics
    department: engineering
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

Depois de criar o serviço, é possível usar kubectl get service -o yaml para visualizar sua especificação e ver o endereço IP externo estável:

spec:
  clusterIP: 10.11.242.115
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32676
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: metrics
    department: engineering
  sessionAffinity: None
  type: LoadBalancer
  status:
    loadBalancer:
      ingress:
      - ip: 203.0.113.100

Na saída, o endereço IP do balanceador de carga de rede aparece em loadBalancer:ingress:. Os clientes externos chamam o serviço usando o endereço IP do balanceador de carga e a porta TCP especificada por port. A solicitação é encaminhada a um dos pods membro na porta TCP especificada por targetPort. Portanto, no exemplo anterior, o cliente chama o serviço em 203.0.113.100 na porta TCP 80. A solicitação é encaminhada a um dos pods membro na porta TCP 8080. O pod membro precisa ter um contêiner escutando a porta TCP 8080.

O tipo de serviço LoadBalancer é uma extensão do tipo NodePort, que, por sua vez, é uma extensão do tipo ClusterIP.

Serviço do tipo ExternalName

Um serviço do tipo ExternalName fornece um alias interno para um nome DNS externo. Clientes internos fazem solicitações usando o nome DNS interno e as solicitações são redirecionadas para o nome externo.

Veja aqui um manifesto de um serviço do tipo ExternalName:

apiVersion: v1
kind: Service
metadata:
  name: my-xn-service
spec:
  type: ExternalName
  externalName: example.com

Quando você cria um serviço, o Kubernetes cria um nome DNS que os clientes internos podem usar para chamar o serviço. No exemplo anterior, o nome DNS é my-xn-service.default.svc.cluster.local. Quando um cliente interno faz uma solicitação para my-xn-service.default.svc.cluster.local, a solicitação é redirecionada para example.com.

O tipo de serviço ExternalName é totalmente diferente dos outros tipos de serviço. Na verdade, um serviço do tipo ExternalName não se ajusta à definição de serviço fornecida no início deste tópico. Um serviço do tipo ExternalName não está associado a um conjunto de pods e não tem um endereço IP estável. Em vez disso, um serviço do tipo ExternalName é um mapeamento de um nome DNS interno para um nome DNS externo.

Abstração de serviço

Um serviço é uma abstração, já que não é um processo que escuta interfaces de rede. Parte da abstração é implementada nas regras do iptables dos nós do cluster. De acordo com o tipo do serviço, outras partes da abstração são implementadas pelo balanceamento de carga de rede ou pelo balanceamento de carga HTTP(S).

Portas de serviço arbitrário

O valor do campo port em um manifesto de serviço é arbitrário. No entanto, o valor targetPort não é arbitrário. Cada pod membro precisa ter um contêiner escutando targetPort.

Veja um serviço do tipo LoadBalancer que tem um valor port de 50000:

apiVersion: v1
kind: Service
metadata:
  name: my-ap-service
spec:
  clusterIP: 10.11.241.93
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30641
    port: 50000
    protocol: TCP
    targetPort: 8080
  selector:
    app: parts
    department: engineering
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.200

Um cliente chama o serviço em 203.0.113.200 na porta TCP 50000. A solicitação é encaminhada a um dos pods membro na porta TCP 8080.

Várias portas

O campo ports de um serviço é uma matriz de objetos ServicePort. O objeto ServicePort tem estes campos:

  • name
  • protocol
  • port
  • targetPort
  • nodePort

Se você tiver mais de um ServicePort, cada ServicePort precisará ter um nome exclusivo.

Veja um serviço do tipo LoadBalancer que tem dois objetos ServicePort:

apiVersion: v1
kind: Service
metadata:
  name: my-tp-service
spec:
  clusterIP: 10.11.242.196
  externalTrafficPolicy: Cluster
  ports:
  - name: my-first-service-port
    nodePort: 31233
    port: 60000
    protocol: TCP
    targetPort: 50000
  - name: my-second-service-port
    nodePort: 31081
    port: 60001
    protocol: TCP
    targetPort: 8080
  selector:
    app: tests
    department: engineering
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.201

No exemplo anterior, se um cliente chama o serviço em 203.0.113.201 na porta TCP 60000, a solicitação é encaminhada a um pod membro na porta TCP 50000. Mas se um cliente chamar o serviço em 203.0.113.201 na porta TCP 60001, a solicitação será encaminhada a um pod membro na porta TCP 8080.

Cada pod membro precisa ter um contêiner escutando a porta TCP 50000 e um contêiner escutando a porta TCP 8080. É possível ter um contêiner único com duas threads ou dois contêineres em execução no mesmo pod.

Endpoints de serviço

Ao criar um serviço, o Kubernetes cria um objeto Endpoints com o mesmo nome. O Kubernetes usa o objeto Endpoints para rastrear quais pods são membros do serviço.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine