Service quick start - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Conceitos principais

Service

Acessar pods diretamente logo após a criação pode causar problemas:

Controladores, como o Deployment, podem encerrar e recriar pods a qualquer momento, tornando o acesso direto não confiável.
O endereço IP de um pod é atribuído dinamicamente na inicialização e não pode ser previsto antecipadamente.
Uma aplicação geralmente consiste em vários pods executando a mesma imagem, o que torna impraticável acessar cada pod individualmente.

Para resolver esses problemas, o Kubernetes fornece o objeto Service, que oferece aos pods uma interface de rede estável e um endereço IP persistente. O Service usa um seletor de rótulos para identificar um grupo de pods de destino e distribui o tráfego entre eles por meio de balanceamento de carga. Essa abordagem resolve as questões de acesso direto aos pods e garante alta disponibilidade e eficiência à sua aplicação.

Endpoint

No Kubernetes, um endpoint é um recurso essencial usado pelo Service para descoberta de serviços. Ele rastreia alterações nos pods correspondentes ao seletor do Service em tempo real. Quando um pod é excluído ou recriado e seu endereço IP muda, o recurso de endpoint atualiza imediatamente sua lista de endereços IP e portas dos pods. Isso garante que o Service sempre direcione o tráfego para pods ativos e íntegros.

IPVS

O IPVS é um balanceador de carga baseado no recurso Linux Virtual Server (LVS) do kernel Linux. Ele gerencia o tráfego do Service criando um IP virtual que distribui solicitações para os pods de backend.

Ao criar um Service no Kubernetes, o kube-proxy configure regras na tabela IPVS. Essas regras defina como o tráfego é encaminhado do IP virtual do nó para os pods de backend. Visualize a tabela de roteamento e as regras atuais do IPVS em um nó do cluster usando o comando ipvsadm.

Importante

Se a ferramenta ipvsadm não estiver instalada, execute o comando sudo yum install ipvsadm para instalá-la.

iptables

O iptables funciona com um conjunto de tabelas e cadeias configuráveis. Cada cadeia contém regras que controlam o fluxo de pacotes de rede.

Ao criar um Service no Kubernetes, o kube-proxy adiciona regras correspondentes ao iptables. Essas regras usam o seletor de rótulos do Service para encaminhar pacotes aos pods corretos. Visualize a tabela nat e as regras atuais do iptables em um nó do cluster usando o comando iptables -t nat -L.

nftables

O nftables é a estrutura de filtragem de pacotes de última geração no kernel Linux, projetada para substituir o iptables. Ele utiliza um conjunto unificado de regras e um mecanismo de correspondência de pacotes mais eficiente para gerenciar regras de tráfego de rede.

Ao criar um Service em um cluster Kubernetes, o kube-proxy usa a API do nftables para criar tabelas e cadeias que gerenciam as regras de encaminhamento de tráfego do Service. Visualize todas as regras ativas e estruturas de tabelas do nftables em um nó do cluster usando o comando nft list ruleset.

Tipos de Service

Importante

Se a versão do Cloud Controller Manager for v2.5.0 ou posterior, o uso de uma instância CLB para criar um Service no console torna-se um recurso restrito à lista de permissões, compatível apenas com pagamento conforme o uso. Para criar um Service do tipo CLB no console, envie uma solicitação na página Quota Center.

Nome	Descrição	Casos de uso	Faturamento
ClusterIP	Tipo padrão de Service. Um Service ClusterIP recebe um endereço IP virtual acessível apenas internamente no cluster.	Ideal para serviços que precisam se comunicar apenas dentro do mesmo cluster. Por exemplo, se um pod de aplicação frontend precisar acessar um banco de dados backend no mesmo cluster, exponha o banco de dados como um Service ClusterIP.	Gratuito.
NodePort	Um Service NodePort abre uma porta específica em todos os nós do cluster. Acesse o Service fora do cluster via `<NodeIP>:<NodePort>`. Esse mecanismo opera principalmente na Camada 4 (Camada de Transporte) do modelo OSI.	Adequado para expor um serviço à internet durante desenvolvimento, testes ou para outras aplicações de baixo tráfego. Por exemplo, use um Service NodePort para implantar e depurar uma aplicação web em ambiente de teste. Diferentemente de um Service LoadBalancer, ele não fornece balanceamento de carga entre nós. O tráfego é enviado para apenas um nó, o que pode facilmente se tornar um gargalo de recursos.	Gratuito. Para habilitar o acesso à internet pública, associe um EIP ao nó. Para mais informações sobre faturamento de EIP, consulte Visão geral do faturamento.
LoadBalancer	Um Service LoadBalancer estende o tipo NodePort provisionando um balanceador de carga externo que distribui o tráfego entre os pods do cluster. O Service fornece automaticamente um endereço IP externo para acesso dos clientes. Suporta gerenciamento de tráfego tanto na Camada 4 (tcp/udp) quanto na Camada 7 (HTTP/https).	Indicado para aplicações em nuvem pública que exigem um ponto de entrada externo estável e fácil de gerenciar. Por exemplo, serviços públicos em ambiente de produção que precisam ser acessados pela internet e devem lidar com grandes volumes de tráfego externo com alta disponibilidade, como aplicações web ou serviços de API. Importante Para comunicação intracluster, utilize sempre um Service `ClusterIP`. Este é o método mais estável, eficiente e arquitetonicamente correto. Em contrapartida, acessar um Service do tipo `LoadBalancer` de dentro do mesmo cluster pode resultar em comportamento inconsistente. Sua disponibilidade é afetada por múltiplos fatores, incluindo: A implementação específica do LoadBalancer pelo provedor de nuvem. O plugin de rede CNI utilizado pelo cluster (como Flannel, Terway-Eniip ou Cilium). O modo de operação (iptables, IPVS ou nftables) e a versão do `kube-proxy`. A configuração de `externalTrafficPolicy` do Service (`Cluster` ou `Local`). Portanto, acessar um IP de LoadBalancer de dentro do cluster pode variar significativamente ou até falhar em diferentes ambientes e versões do Kubernetes. Cenário de exemplo: Flannel + IPVS + externalTrafficPolicy=Local Considere um cluster que usa o plugin de rede CNI Flannel onde um Service `LoadBalancer` está configurado com `externalTrafficPolicy: Local`. Se uma solicitação for enviada ao IP externo do LoadBalancer a partir de um nó que não possui um pod de backend correspondente: Versão do Kubernetes < 1.24: A solicitação não será encaminhada corretamente e o acesso falhará. Versão do Kubernetes ≥ 1.24: O `kube-proxy` pode reverter do comportamento `Local` para `Cluster` para suportar acesso intracluster. A solicitação será encaminhada com sucesso para um pod de backend em outro nó.	Para informações sobre taxas de instâncias de balanceamento de carga, consulte Visão geral do faturamento do CLB Regras de faturamento do NLB.
Headless Service	Um Headless Service não possui endereço IP virtual. Uma consulta DNS pelo nome do serviço retorna uma lista de endereços IP dos pods em vez de um único IP de serviço. Isso permite descobrir e conectar-se diretamente a pods específicos.	Recomendado para aplicações que precisam se comunicar diretamente com pods de backend específicos, sem passar por um proxy ou balanceador de carga. Por exemplo, ao implantar uma aplicação com estado, como um serviço de banco de dados ClickHouse, utilize um Headless Service. Isso permite que os pods da aplicação acessem diretamente cada pod do ClickHouse, equilibrando leituras de dados ou realizando gravações direcionadas para melhorar a eficiência do processamento de dados.	Gratuito.
ExternalName	Um Service ExternalName mapeia um nome de serviço interno para um nome de domínio externo. Isso permite que os pods dentro do cluster acessem o domínio externo usando o nome do serviço interno.	Mais indicado quando um cluster precisa acessar um serviço exposto sob um nome de domínio público. Por exemplo, se seus pods de aplicação precisarem acessar um domínio de banco de dados externo, use um Service ExternalName para mapear o domínio a um nome de serviço interno, permitindo acesso direto de dentro do cluster.	Gratuito.

Funcionamento

ClusterIP

Criação e alocação

Ao criar um Service ClusterIP em um cluster ACK, o plano de controle atribui a ele um endereço IP virtual (ClusterIP) acessível apenas internamente no cluster.
Encaminhamento de tráfego

Ao acessar o ClusterIP, o kube-proxy intercepta o tráfego e o encaminha para um pod de backend usando um algoritmo de agendamento round-robin.
Descoberta de serviço

Quando um Service ClusterIP é criado, o CoreDNS registra um registro DNS para ele, permitindo que o serviço seja resolvido e acessado pelo nome. O formato é service-name.namespace.svc.cluster.local:port, por exemplo, nginx.default.svc.cluster.local:80.
Rótulos de pod e rastreamento de endpoints

Um Service usa um seletor de rótulos para identificar seus pods de backend.

O plano de controle monitora continuamente as alterações nos pods. Quando pods correspondentes ao seletor de rótulos do Service são adicionados, atualizados ou removidos, o plano de controle atualiza o endpoint.

NodePort

Criação e alocação

Ao criar um Service NodePort, o cluster abre uma porta (a NodePort) em seus nós para permitir acesso externo.
Encaminhamento de tráfego

O kube-proxy escuta na NodePort, escolhida automaticamente de um intervalo padrão de 30000-32767. Ele roteia solicitações externas para o ClusterIP, que então as encaminha para os pods de backend.
Acesso externo

Acesse o Service externamente usando o endereço IP do nó e a porta estática (NodePort) no formato <NodeIP>:<NodePort>.

LoadBalancer

Criação e alocação

Ao criar um Service LoadBalancer, o plano de controle interage automaticamente com o serviço de balanceamento de carga para criar uma instância de balanceador de carga destinada a lidar com o tráfego. Para mais informações, consulte Usar uma instância existente do Server Load Balancer para expor uma aplicação e Expor uma aplicação com um Service LoadBalancer provisionado automaticamente.
Encaminhamento de tráfego

Quando o tráfego externo atinge o IP externo da instância do balanceador de carga, ele é roteado para a porta nos nós. Em seguida, o kube-proxy encaminha o tráfego para os pods de backend.
Configuração de rota e verificação de integridade

O balanceador de carga configura automaticamente portas de listener e realiza verificações de integridade para garantir que o tráfego seja roteado apenas para pods íntegros.

Política de tráfego externo

Os Services LoadBalancer e NodePort possuem uma configuração externalTrafficPolicy que controla como o tráfego externo é roteado. O comportamento dessa configuração difere entre clusters que usam os plugins de rede Terway-Eniip e Flannel.

Nota

Faça login no ACK console. Na página Clusters, clique em no nome do seu cluster. Na aba Basic Information, visualize o plugin de rede CNI que seu cluster utiliza.

Plugin de rede Flannel

Item	Local	Cluster
Anexação de servidor backend	Apenas nós que hospedam pods de backend são adicionados como servidores backend ao balanceador de carga.	Todos os nós do cluster são adicionados como servidores backend ao balanceador de carga.
Cota de balanceador de carga	Consome menos recursos de cota do balanceador de carga. Para mais informações, consulte Limites de cota.	Consome uma grande quantidade de recursos de cota do balanceador de carga, pois todos os nós do cluster são anexados como backends. Para mais informações, consulte Limites de cota.
Acesso intracluster ao Service	Apenas nós que hospedam pods de backend para o Service podem acessá-lo.	Qualquer nó no cluster pode acessar o Service.
Balanceamento de carga de pods	O balanceamento de carga entre pods é desativado por padrão. Para ativar o balanceamento de carga, defina o agendador como WRR adicionando a anotação `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` ao Service.	O balanceamento de carga entre pods é ativado por padrão.
Preservação de IP de origem	Suportado.	Não suportado.
Persistência de sessão	Suportado.	Não suportado.
Casos de uso	Aplicações que precisam preservar o endereço IP original do cliente, como para logs baseados no IP de origem.	Quando alta disponibilidade de serviço é necessária e a preservação do IP de origem não é uma preocupação, como em grandes clusters de aplicações web.

Plugin de rede Terway-Eniip

Item	Local	Cluster
Anexação de servidor backend	Os pods são adicionados diretamente ao balanceador de carga como servidores backend.
Cota de balanceador de carga	Consome menos recursos de cota do balanceador de carga porque apenas os pods da aplicação são anexados. Para mais informações, consulte Limites de cota.
Acesso intracluster ao Service	Ao acessar o Service de dentro do cluster, o tráfego passa pelo kube-proxy no nó e está sujeito ao `externalTrafficPolicy`. Como resultado, apenas nós que hospedam pods de backend para o Service podem acessá-lo.	Qualquer nó no cluster pode acessar o Service.
Balanceamento de carga de pods	O balanceamento de carga entre pods é ativado por padrão.
Preservação de IP de origem	Suportado.
Persistência de sessão	Suportado.

Notas de uso

Antes de usar o recurso de balanceamento de carga do Service, revise as considerações relevantes. Para mais informações, consulte Considerações para configurar o balanceamento de carga do Service.

Container Service for Kubernetes:Service quick start