Além disso, invocar o seguinte no contêiner de caixa de ferramentas mostra que não há um dispositivo de ponte do Linux chamado cbr0:
As regras de iptables que facilitam o encaminhamento dentro do cluster variam de um cenário para outro. É importante ter essa distinção em mente durante a solução detalhada de problemas relacionados à conectividade.
Por padrão, cada pod tem acesso não filtrado a todos os outros pods em execução em todos os nós do cluster, mas é possível limitar o acesso entre os pods. O Kubernetes regularmente derruba e recria os pods. Isso acontece quando um pool de nós é atualizado, ao alterar a configuração declarativa do pod ou ao alterar a imagem de um contêiner ou quando um nó fica indisponível. Portanto, o endereço IP de um pod é um detalhe de implementação e não é recomendável confiar neles. O Kubernetes fornece endereços IP estáveis usando Serviços.
No Kubernetes, você pode atribuir pares arbitrários de valores-chave denominados rótulos a qualquer recurso do Kubernetes. O Kubernetes usa rótulos para agrupar vários pods relacionados em uma unidade lógica denominada Serviço. Um Serviço tem portas e um endereço IP estáveis e fornece balanceamento de carga entre o conjunto de pods com rótulos correspondentes a todos os definidos no seletor de rótulos durante a criação do Serviço.
Observação: os Serviços no Kubernetes não têm relação alguma com os Serviços no Docker. Um Serviço do Docker está mais próximo de um pod do Kubernetes.
O diagrama a seguir mostra dois Serviços separados, cada um composto por vários pods. Cada um dos pods no diagrama tem o rótulo app=demo, mas os outros rótulos são diferentes. O "front-end" do Serviço corresponde a todos os pods com app=demo e component=frontend, enquanto os "usuários" do Serviço correspondem a todos os pods com app=demo e component=users. Como o pod cliente não corresponde exatamente ao seletor do Serviço, ele não faz parte de nenhum dos Serviços. Porém, ele pode se comunicar com qualquer um dos Serviços porque é executado no mesmo cluster.
O Kubernetes atribui um endereço IP estável e confiável a cada Serviço recém-criado, o ClusterIP, do pool de endereços IP de Serviço disponíveis no cluster. O Kubernetes também atribui um nome de host ao ClusterIP. Para isso, ele adiciona uma entrada DNS (em inglês). O ClusterIP e o nome do host são exclusivos dentro do cluster e não são alterados durante todo o ciclo de vida do Serviço. O Kubernetes apenas libera o ClusterIP e o nome do host se o Serviço for excluído da configuração do cluster. Para alcançar um pod íntegro, execute seu aplicativo usando o ClusterIP ou o nome do host do Serviço.
À primeira vista, um Serviço pode parecer um ponto único de falha para seus aplicativos. No entanto, o Kubernetes distribui o tráfego do modo mais uniforme possível em todo o conjunto de pods, sendo executado em muitos nós, para que um cluster possa resistir a uma interrupção que afeta um ou mais (mas não todos os) nós.
O Kubernetes gerencia a conectividade entre pods e serviços usando o componente kube-proxy. Por padrão, ele é implantado como um pod estático em cada nó. Qualquer Cluster do GKE que execute a versão 1.16 ou posterior terá um DaemonSet kube-proxy. Isso selecionará apenas os nós que estiverem executando uma versão do GKE entre 1.16.0 e 1.16.8-gke.13. Se o cluster não tiver nenhum nó executando essas versões, é esperado que esse DaemonSet mostre 0 pods.
kube-proxy não é um proxy alinhado, e sim um controlador de balanceamento de carga baseado em saída. Ele vigia o servidor da API Kubernetes e mapeia continuamente o ClusterIP para pods íntegros adicionando e removendo regras NAT de destino (DNAT, na sigla em inglês) do subsistema iptables do nó. Quando um contêiner em execução em um pod envia tráfego para o ClusterIP de um serviço, o nó seleciona um pod aleatoriamente e roteia o tráfego para esse pod.