Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Networking Services

Esta página explica como o CoreDNS, o controlador de entrada Traefik, o controlador de política de rede e o controlador de balanceamento de carga ServiceLB funcionam dentro do K3s.

Consulte a página Opções de Rede de Instalação para detalhes sobre as opções de configuração do Flannel e seleção de backend, ou para saber como configurar sua própria CNI.

Para informações sobre quais portas precisam ser abertas para o K3s, consulte Requisitos de Rede.

CoreDNS

O CoreDNS é implantado automaticamente na inicialização do servidor. Para desativá-lo, configure todos os servidores no cluster com a opção --disable=coredns.

Se você não instalar o CoreDNS, precisará instalar um provedor de DNS de cluster por conta própria.

Controlador de Entrada Traefik

Traefik é um proxy reverso HTTP moderno e balanceador de carga feito para implantar microsserviços com facilidade. Ele simplifica a complexidade de rede ao projetar, implantar e executar aplicações.

O controlador de entrada Traefik implanta um Serviço LoadBalancer que usa as portas 80 e 443, anuncia os IPs Externos do Serviço LoadBalancer no Status dos recursos de Ingress que ele gerencia.

Por padrão, o ServiceLB usará todos os nós no cluster para hospedar o Serviço LoadBalancer do Traefik, o que significa que as portas 80 e 443 não estarão disponíveis para outros pods HostPort ou NodePort, e o Status dos recursos de Ingress mostrará os IPs dos nós de todos os membros do cluster.

Para restringir os nós usados pelo Traefik, e por extensão os IPs dos nós anunciados no Status de Ingress, você pode seguir as instruções na seção Controlando a Seleção de Nós do ServiceLB abaixo para limitar quais nós o ServiceLB opera, ou adicionando alguns nós a um pool de LoadBalancer e restringindo o Serviço Traefik a esse pool definindo rótulos correspondentes na configuração do HelmChartConfig do Traefik.

O Traefik é implantado por padrão ao iniciar o servidor. Os valores padrão do gráfico podem ser encontrados em /var/lib/rancher/k3s/server/manifests/traefik.yaml, mas este arquivo não deve ser editado manualmente, pois o K3s substitui o arquivo por padrões na inicialização. Em vez disso, você deve personalizar o Traefik criando um manifesto adicional HelmChartConfig em /var/lib/rancher/k3s/server/manifests. Para mais detalhes e um exemplo, veja Personalizando Componentes Empacotados com HelmChartConfig. Para mais informações sobre os possíveis valores de configuração, consulte values.yaml do Gráfico Helm do Traefik incluído com sua versão do K3s.

Para remover o Traefik do seu cluster, inicie todos os servidores com a flag --disable=traefik. Para mais informações, consulte Gerenciando Componentes Empacotados.

Para detalhes sobre a versão específica do Traefik incluída com o K3s, consulte as Notas de Lançamento para sua versão.

As versões do K3s a partir de 1.32 incluem o Traefik v3. Instalações existentes do Traefik v2 são automaticamente atualizadas para v3 quando o K3s é atualizado. O Traefik v3 deve ser compatível com a configuração do v2; consulte a documentação upstream de migração de v2 para v3 para mais informações.
As versões do K3s 1.21 até 1.31 incluem o Traefik v2, a menos que seja encontrada uma instalação existente do Traefik v1, caso em que o Traefik não sofre upgrade para v2.
As versões do K3s 1.20 e anteriores incluem o Traefik v1.

Controlador de Política de Rede

O K3s inclui um controlador de política de rede embutido. A implementação subjacente é a biblioteca do controlador netpol do kube-router (nenhuma outra funcionalidade do kube-router está presente) e pode ser encontrada aqui.

Para desativá-lo, inicie cada servidor com a flag --disable-network-policy.

As regras de iptables da política de rede não são removidas se a configuração do K3s for alterada para desativar o controlador de política de rede. Para limpar as regras de política de rede do kube-router configuradas após desativar o controlador de política de rede, use o script k3s-killall.sh, ou limpe-as usando iptables-save e iptables-restore. Esses passos devem ser executados manualmente em todos os nós do cluster.

iptables-save | grep -v KUBE-ROUTER | iptables-restore
ip6tables-save | grep -v KUBE-ROUTER | ip6tables-restore

Balanceador de Carga de Serviço

Qualquer controlador de LoadBalancer pode ser implantado no seu cluster K3s. Por padrão, o K3s fornece um balanceador de carga conhecido como ServiceLB (anteriormente Klipper LoadBalancer) que utiliza portas de host disponíveis.

O Kubernetes upstream permite que Serviços do tipo LoadBalancer sejam criados, mas não inclui uma implementação de balanceador de carga padrão, então esses serviços permanecerão pending até que um seja instalado. Muitos serviços hospedados requerem um provedor de nuvem como Amazon EC2 ou Microsoft Azure para oferecer uma implementação de balanceador de carga externo. Em contraste, o K3s ServiceLB torna possível usar Serviços LoadBalancer sem um provedor de nuvem ou qualquer configuração adicional.

Como o ServiceLB Funciona

O controlador ServiceLB observa os Serviços do Kubernetes com o campo spec.type definido como LoadBalancer.

Para cada Serviço LoadBalancer, um DaemonSet é criado no namespace kube-system. Esse DaemonSet, por sua vez, cria Pods ServiceLB com um prefixo svc-, em cada nó. Esses pods utilizam hostPort usando a porta do serviço, portanto, eles serão implantados apenas em nós que tenham essa porta disponível. Se não houver nós com essa porta disponível, o LB permanecerá Pendente. Observe que é possível expor vários Serviços no mesmo nó, desde que usem portas diferentes.

Quando o Pod ServiceLB é executado em um nó que tem um IP externo configurado, o IP externo do nó é inserido na lista de endereços do Serviço com status.loadBalancer.ingress e ipMode: VIP. Caso contrário, o IP interno do nó é utilizado.

Se o tráfego para o IP externo estiver sujeito a Tradução de Endereço de Rede (NAT) - por exemplo, em nuvem pública ao usar o IP público do nó como IP externo - o tráfego é roteado para o pod ServiceLB via hostPort. O pod então usa iptables para encaminhar o tráfego para o endereço e porta ClusterIP do Serviço. Se o tráfego não estiver sujeito a NAT e, em vez disso, chegar com um endereço de destino correspondente ao endereço do LoadBalancer, o tráfego é interceptado (normalmente pelas cadeias iptables do kube-proxy ou ipvs) e encaminhado para o endereço e porta ClusterIP do Serviço.

Uso

Crie um Serviço do tipo LoadBalancer no K3s.

Problema Conhecido

Se o tráfego externo atingir o nó usando um NAT (por exemplo, em nuvem pública) e você precisar de externalTrafficPolicy=local para fins como preservação do IP de origem do cliente, não defina a configuração k3s node-external-ip para nenhum dos nós, pois isso não funcionará corretamente.

Controlando a Seleção de Nós do ServiceLB

Adicionar o rótulo svccontroller.k3s.cattle.io/enablelb=true a um ou mais nós muda o controlador ServiceLB para o modo de lista de permissão, onde apenas nós com o rótulo são elegíveis para hospedar pods LoadBalancer. Nós que permanecerem sem rótulo serão excluídos do uso pelo ServiceLB.

Por padrão, os nós não são rotulados. Enquanto todos os nós permanecerem sem rótulo, todos os nós com portas disponíveis serão utilizados pelo ServiceLB.

Criando Pools de Nós do ServiceLB

Para selecionar um subconjunto específico de nós para hospedar pods para um LoadBalancer, adicione o rótulo enablelb aos nós desejados e defina valores de rótulo lbpool correspondentes nos Nós e Serviços. Por exemplo:

Rotule o Nó A e o Nó B com svccontroller.k3s.cattle.io/lbpool=pool1 e svccontroller.k3s.cattle.io/enablelb=true
Rotule o Nó C e o Nó D com svccontroller.k3s.cattle.io/lbpool=pool2 e svccontroller.k3s.cattle.io/enablelb=true
Crie um Serviço LoadBalancer na porta 443 com o rótulo svccontroller.k3s.cattle.io/lbpool=pool1. O DaemonSet para este serviço implanta apenas Pods no Nó A e no Nó B.
Crie outro Serviço LoadBalancer na porta 443 com o rótulo svccontroller.k3s.cattle.io/lbpool=pool2. O DaemonSet implantará apenas Pods no Nó C e no Nó D.

Desabilitando o ServiceLB

Para desabilitar o ServiceLB, configure todos os servidores no cluster com a flag --disable=servicelb.

Isso é necessário se você deseja executar um LB diferente, como o MetalLB.

Implantando um Gerenciador de Controlador de Nuvem Externo

O K3s fornece um Gerenciador de Controlador de Nuvem (CCM) embutido que faz o seguinte:

Hospeda o controlador de LoadBalancer Service Load Balancer.
Limpa a marcação node.cloudprovider.kubernetes.io/uninitialized.
Define os campos de endereço do nó com base nas flags --node-ip, --node-external-ip, --node-internal-dns e --node-external-dns.

Antes de implantar um CCM externo, você deve iniciar todos os servidores K3s com a flag --disable-cloud-controller para desabilitar o CCM embutido. Ao usar um CCM externo, os endereços dos nós serão fornecidos pelas APIs de metadados de instância do provedor de nuvem, em vez dos valores das flags do K3s.

Se você desabilitar o CCM incorporado e não implantar nem configurar adequadamente um substituto externo, os nós permanecerão com taint e não poderão ser agendados.