O modelo de rede do Kubernetes é construído a partir de várias partes:
Cada pod em um cluster recebe seu próprio endereço IP exclusivo em todo o cluster.
localhost.A rede de pods (também chamada de rede do cluster) gerencia a comunicação entre pods. Ela garante que (exceto por segmentação de rede intencional):
Todos os pods podem se comunicar com todos os outros pods, estejam eles no mesmo nó ou em nós diferentes. Os pods podem se comunicar entre si diretamente, sem o uso de proxies ou tradução de endereços (NAT).
No Windows, esta regra não se aplica a pods de rede do host.
Agentes em um nó (como daemons do sistema ou kubelet) podem se comunicar com todos os pods naquele nó.
A API de Service permite que você forneça um endereço IP ou hostname estável (de longa duração) para um serviço implementado por um ou mais pods de backend, onde os pods individuais que compõem o serviço podem mudar ao longo do tempo.
O Kubernetes gerencia automaticamente objetos EndpointSlice para fornecer informações sobre os pods atualmente oferecendo suporte a um Service.
Uma implementação de proxy de serviço monitora o conjunto de objetos Service e EndpointSlice, e programa a camada de dados para rotear o tráfego de serviço para seus backends, usando APIs do sistema operacional ou provedor de nuvem para interceptar ou reescrever pacotes.
A API de Gateway (ou sua predecessora, Ingress) permite que você torne Services acessíveis a clientes que estão fora do cluster.
type: LoadBalancer
da API Service, ao usar um Provedor de Nuvem compatível.NetworkPolicy é uma API embutida do Kubernetes que permite controlar o tráfego entre pods, ou entre pods e o mundo externo.
Em sistemas de contêineres mais antigos, não havia conectividade automática entre contêineres em hosts diferentes, e por isso era frequentemente necessário criar explicitamente links entre contêineres, ou mapear portas de contêineres para portas do host para torná-los acessíveis por contêineres em outros hosts. Isso não é necessário no Kubernetes; o modelo do Kubernetes é que os pods podem ser tratados de forma muito semelhante a VMs ou hosts físicos das perspectivas de alocação de portas, nomenclatura, descoberta de serviços, balanceamento de carga, configuração de aplicações e migração.
Apenas algumas partes deste modelo são implementadas pelo próprio Kubernetes. Para as outras partes, o Kubernetes define as APIs, mas a funcionalidade correspondente é fornecida por componentes externos, alguns dos quais são opcionais:
A configuração do namespace de rede do pod é gerenciada por software de nível de sistema que implementa a Interface de Agente de Execução de Contêiner.
A própria rede de pods é gerenciada por uma implementação de rede de pods. No Linux, a maioria dos agentes de execução de contêineres usa a Interface de Rede de Contêineres (CNI) para interagir com a implementação de rede de pods, então essas implementações são frequentemente chamadas de plugins CNI.
O Kubernetes fornece uma implementação padrão de proxy de serviço, chamada kube-proxy, mas algumas implementações de rede de pods usam seu próprio proxy de serviço que é mais fortemente integrado com o restante da implementação.
NetworkPolicy geralmente também é implementado pela implementação de rede de pods. (Algumas implementações de rede de pods mais simples não implementam NetworkPolicy, ou um administrador pode optar por configurar a rede de pods sem suporte a NetworkPolicy. Nestes casos, a API ainda estará presente, mas não terá efeito.)
Existem muitas implementações de Gateway API, algumas das quais são específicas para ambientes de nuvem particulares, algumas mais focadas em ambientes "bare metal", e outras mais genéricas.
O tutorial Conectando Aplicações com Services permite que você aprenda sobre Services e rede do Kubernetes com um exemplo prático.
Conectividade do Cluster explica como configurar a rede para o seu cluster, e também fornece uma visão geral das tecnologias envolvidas.
Disponibilize seu serviço de rede HTTP ou HTTPS usando um mecanismo de configuração com reconhecimento de protocolo, que entende conceitos da Web como URIs, nomes de host, caminhos e muito mais. O conceito Ingress permite mapear o tráfego para diferentes backends com base nas regras definidas por meio da API do Kubernetes.