Entendendo o balanceamento de carga para apps por meio da descoberta de serviços do Kubernetes

A descoberta de serviço do Kubernetes fornece apps com uma conexão de rede por meio de serviços de rede e de um proxy local do Kubernetes.

Todos os pods que são implementados em um nó do trabalhador são designados a um endereço IP privado no intervalo 172.30.0.0/16 e são roteados somente entre os nós do trabalhador. Para evitar conflitos, não use esse intervalo de IPs em quaisquer nós que se comunicam com os nós do trabalhador. Os nós do trabalhador e os pods podem se comunicar com segurança na rede privada usando endereços IP privados. No entanto, quando um pod trava ou um nó do trabalhador precisa ser recriado, um novo endereço IP privado é designado.

Em vez de tentar rastrear a mudança de endereços IP privados para apps que devem estar altamente disponíveis, é possível usar recursos de descoberta de serviço integrados do Kubernetes para expor apps como serviços. Um serviço do Kubernetes agrupa um conjunto de pods e fornece uma conexão de rede para esses pods. O serviço seleciona os pods de destino que roteia o tráfego para via etiquetas.

Um serviço fornece conectividade entre seus pods de app e outros serviços no cluster sem expor o endereço IP privado real de cada pod. Um endereço IP dentro do cluster é designado aos serviços, o clusterIP, que é acessível somente dentro do cluster. Esse endereço IP é vinculado ao serviço por seu tempo de vida inteiro e não muda enquanto o serviço existe. Os serviços recebem um IP de um dos 65.000 IPs no intervalo 172.21.0.0/16.

Para evitar conflitos, não use esse intervalo de IPs em quaisquer nós que se comunicam com os nós do trabalhador. Uma entrada de consulta de DNS também é criada para o serviço e armazenada no componente kube-dns do cluster. A entrada de DNS contém o nome do serviço, o namespace no qual o serviço foi criado e o link para o endereço IP no cluster designado.

Se você estiver planejando a conexão de seu cluster com redes no local por meio da IBM Cloud ou de um serviço de VPN, poderão ocorrer conflitos de sub-rede com o intervalo padrão 172.30.0.0/16 para os pods e o intervalo 172.21.0.0/16 para os serviços. É possível evitar conflitos de sub-rede ao criar um cluster, especificando um CIDR de sub-rede personalizado para os pods na opção “ --pod-subnet ” e um CIDR de sub-rede personalizado para os serviços na opção “ --service-subnet ”.

Para fornecer balanceamento de carga básico de todo o tráfego de rede TCP e UDP para serviços, um proxy de rede local Kubernetes, kube-proxy, é executado como um daemon em cada nó do trabalhador no espaço de nomes kube-system. O kube-proxy usa regras de Iptables, um recurso de kernel Linux, para direcionar solicitações igualmente para o pod atrás de um serviço, independentemente dos endereços IP no cluster dos pods e do nó do trabalhador no qual eles estão implementados.

Por exemplo, apps dentro do cluster podem acessar um pod atrás de um serviço de cluster usando o IP dentro do cluster do serviço ou enviando uma solicitação para o nome do serviço. Quando você usa o nome do serviço, o kube-proxy consulta o nome no provedor DNS do cluster e roteia a solicitação para o endereço IP dentro do cluster do serviço.

Se você usar um serviço que forneça tanto um endereço IP de cluster interno quanto um endereço IP externo, os clientes fora do cluster poderão enviar solicitações para o endereço IP público ou privado do serviço. O kube-proxy encaminha as solicitações para o endereço IP no cluster do serviço e balanceadores de carga entre os pods de app atrás do serviço.

Entendendo os tipos de serviço do Kubernetes

O Kubernetes suporta quatro tipos básicos de serviços de rede: ClusterIP, NodePort, LoadBalancer e Ingress. Os serviços ClusterIP tornam seus apps acessíveis internamente para permitir a comunicação apenas entre pods no cluster. Os serviços NodePort, LoadBalancer e Ingress tornam seus apps externamente acessíveis por meio da internet pública ou de uma rede privada.

A tabela a seguir compara os recursos de cada tipo de serviço de rede.

* Um certificado SSL para balanceamento de carga HTTPS é fornecido por comandos ibmcloud ks nlb-dns. Em clusters clássicos, esses comandos são suportados apenas para NLBs públicos.

NodePort

Quando você expõe aplicativos com um NodePort serviço, um endereço de porta de serviço ( NodePort ) no intervalo de 30000 a 32767 e um endereço IP interno do cluster são atribuídos ao serviço. Para acessar o serviço de fora do cluster, utilize o endereço IP público ou privado de qualquer nó de trabalho e o endereço NodePort no formato <IP_address>:<nodeport>. No entanto, os endereços IP públicos e privados do nó do trabalhador não são permanentes. Quando um nó do trabalhador é removido ou recriado, um novo endereço IP público e um privado são designados ao nó do trabalhador.

NodePorts são ideais para testar o acesso público ou privado ou fornecer acesso apenas por um curto período de tempo. Nota: como os nós do trabalhador em clusters de VPC não têm um endereço IP público, só será possível acessar um app através de um NodePort se você estiver conectado à rede privada VPC, como por meio de uma conexão VPN.

LoadBalancer

O tipo de serviço LoadBalancer é implementado de forma diferente, dependendo do provedor de infraestrutura de seu cluster.

Serviços do LoadBalancer em clusters clássicos

Infraestrutura clássica

Balanceador de carga de rede(NLB). Cada cluster padrão é provisionado com quatro endereços IP públicos e privados móveis que podem ser usados para criar um balanceador de carga de rede TCP/UDP (NLB) de camada 4 para seu app. É possível customizar seu NLB expondo qualquer porta necessária ao seu app. Os endereços IP público e privado móveis que são designados ao NLB são permanentes e não mudam quando um nó do trabalhador é recriado no cluster. É possível criar um subdomínio para seu app que registra os endereços IP do NLB público com uma entrada DNS. Também é possível ativar monitores de verificação de funcionamento nos IPs do NLB para cada subdomínio.

Serviços do LoadBalancer em clusters VPC

Nuvem Privada Virtual

Balanceador de carga para VPC. Ao criar um serviço LoadBalancer do Kubernetes para um app em seu cluster, um balanceador de carga do VPC de camada 7 é criado automaticamente em seu VPC fora de seu cluster. O balanceador de carga do VPC é multizonal e roteia solicitações para seu app por meio dos NodePorts privados que são abertos automaticamente em seus nós do trabalhador. Por padrão, o balanceador de carga também é criado com um nome do host que pode ser usado para acessar seu app.

Ingress

Exponha vários aplicativos em um cluster configurando o roteamento com o balanceador de carga de aplicativos (ALB) do Ingress. O ALB usa um ponto de entrada público ou privado protegido e exclusivo, um subdomínio do Ingress, para rotear as solicitações recebidas para seus apps. É possível usar um subdomínio para expor diversos apps em seu cluster como serviços. O Ingresso consiste em três componentes:

• O recurso de Ingresso define as regras de como rotear e balancear a carga de solicitações recebidas para um app.
• O ALB atende às solicitações de serviço HTTP, HTTPS ou TCP recebidas. Ele encaminha as solicitações em pods dos apps com base nas regras que você definiu no recurso de Ingresso.
• O balanceador de carga multizona (MZLB) para clusters clássicos ou o balanceador de carga do VPC para clusters VPC manipula todas as solicitações recebidas para seus apps e balanceia a carga delas entre os ALBs nas diversas zonas. Ele também permite verificações de funcionamento para os endereços IP públicos do Ingress.

Planejando o balanceamento de carga externa pública

Exponha publicamente um app em seu cluster para a Internet.

Nos clusters clássicos, é possível conectar nós do trabalhador a uma VLAN pública. A VLAN pública determina o endereço IP público que é designado a cada nó do trabalhador, que fornece a cada nó do trabalhador uma interface de rede pública. Os serviços de rede pública se conectam a essa interface de rede pública, fornecendo ao seu app um endereço IP público e, opcionalmente, uma URL pública.

Em clusters VPC, os nós do trabalhador são conectados somente a sub-redes privadas do VPC. No entanto, ao criar serviços de rede pública, um balanceador de carga do VPC é criado automaticamente. O balanceador de carga do VPC pode rotear solicitações públicas para seu app fornecendo a ele uma URL pública. Quando um app é exposto publicamente, qualquer um que tenha a URL pública pode enviar uma solicitação para o app.

Quando um app é publicamente exposto, qualquer pessoa que tenha o endereço IP de serviço público ou a URL configurada para ele pode enviar uma solicitação para seu app. Por essa razão, exponha o mínimo de apps possível. Somente exponha um app para o público quando ele estiver pronto para aceitar o tráfego de clientes ou usuários externos da web.

A interface de rede pública para os nós do trabalhador é protegida por configurações de política de rede do Calico predefinidas que são configuradas em cada nó do trabalhador durante a criação do cluster. Por padrão, todo o tráfego de rede de saída é permitido para todos os nós do trabalhador. O tráfego de rede de entrada está bloqueado, exceto para algumas portas. Essas portas são abertas para que a IBM possa monitorar o tráfego de rede e instalar automaticamente as atualizações de segurança para o mestre do Kubernetes e para que as conexões possam ser estabelecidas para os serviços NodePort, LoadBalancer e Ingress. Para obter mais informações sobre essas políticas, incluindo como modificá-las, veja Políticas de rede.

Escolhendo um padrão de implementação para clusters clássicos

Para tornar um app disponível publicamente para a Internet em um cluster clássico, escolha um padrão de implementação de balanceamento de carga que use os serviços públicos NodePort, LoadBalancer ou Ingress. A tabela a seguir descreve cada padrão de implementação possível, o motivo de uso e como configurá-lo. Para obter informações básicas sobre os serviços de rede que esses padrões de implementação usam, consulte Entendendo os tipos de serviço do Kubernetes.

Escolhendo um padrão de implementação para clusters VPC

Para tornar um app disponível publicamente para a Internet em um cluster de VPC, escolha um padrão de implementação de balanceamento de carga que use os serviços públicos LoadBalancer ou Ingress. A tabela a seguir descreve cada padrão de implementação possível, o motivo de uso e como configurá-lo. Para obter informações básicas sobre os serviços de rede que esses padrões de implementação usam, consulte Entendendo os tipos de serviço do Kubernetes.

Planejando o balanceamento de carga externa privado

Exponha de forma privada um app em seu cluster somente para a rede privada.

Quando você implementa um app em um cluster Kubernetes no IBM Cloud Kubernetes Service, é possível que você deseje torná-lo acessível somente para usuários e serviços na mesma rede privada que seu cluster. O balanceamento de carga privado é ideal para tornar seu app disponível para solicitações de fora do cluster sem o expor ao público em geral. Também é possível usar o balanceamento de carga privado para testar o acesso, o roteamento de solicitação e outras configurações para seu app antes de ele ser exposto posteriormente para o público com serviços de rede pública.

Como exemplo, suponha que você criou um balanceador de carga privado para seu app. Esse balanceador de carga privado pode ser acessado por:

• Qualquer pod no mesmo cluster.
• Qualquer pod em qualquer cluster na mesma conta do IBM Cloud.
• Se você não estiver na conta do IBM Cloud, mas ainda estiver atrás do firewall da empresa, qualquer sistema por meio de uma conexão VPN com a sub-rede na qual o IP do balanceador de carga está.
• Se você estiver em uma conta IBM Cloud diferente, qualquer sistema por meio de uma conexão VPN com a sub-rede na qual o IP do balanceador de carga estiver.
• Em clusters clássicos, se você tiver o VRF ou o VLAN Spanning ativado, qualquer sistema que esteja conectado a qualquer uma das VLANs privadas na mesma conta do IBM Cloud.
• Em clusters VPC:
  • Se você permitir tráfego entre sub-redes de VPC, qualquer sistema na mesma VPC.
  • Se você permitir tráfego entre VPCs, qualquer sistema que tenha acesso à VPC em que o cluster está.