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.

Configurando a Infraestrutura para um Cluster Kubernetes de Alta Disponibilidade SUSE® Rancher Prime: RKE2

Este tutorial tem como objetivo ajudá-lo a provisionar a infraestrutura subjacente para um servidor de gerenciamento Rancher.

A infraestrutura recomendada para o cluster Kubernetes apenas com Rancher difere dependendo se o Rancher será instalado em um cluster Kubernetes RKE2, um cluster Kubernetes RKE ou em um único contêiner Docker.

Importante:

Esses nós devem estar na mesma região. Você pode colocar esses servidores em zonas de disponibilidade separadas (data center).

Para instalar o servidor de gerenciamento Rancher em um cluster RKE2 de alta disponibilidade, recomendamos configurar a seguinte infraestrutura:

  • Três nós Linux, tipicamente máquinas virtuais, no provedor de infraestrutura de sua escolha.

  • Um balanceador de carga para direcionar o tráfego para os nós.

  • Um registro DNS para mapear uma URL para o balanceador de carga. Isso se tornará a URL do servidor Rancher, e os clusters Kubernetes downstream precisarão acessá-la.

1. Configure os Nós Linux

Certifique-se de que seus nós atendam aos requisitos gerais de instalação para sistema operacional, tempo de execução do contêiner, hardware e rede.

Para um exemplo de uma maneira de configurar nós Linux, consulte este tutorial para configurar nós como instâncias na Amazon EC2.

2. Configure o Balanceador de Carga

Você também precisará configurar um balanceador de carga para direcionar o tráfego para a réplica do Rancher em todos os nós. Isso evitará que a falha de qualquer nó único interrompa as comunicações com o servidor de gerenciamento do Rancher.

Ingress-NGINX EOL: O controlador da comunidade ingress-nginx atingiu o fim do serviço (EOL) em março de 2026 e está descontinuado no RKE2 v1.36. As versões do RKE2 provisionadas pelo SUSE Rancher Prime continuarão a receber ingress-nginx suporte e correções de CVE (8+) durante todo o ciclo de vida do RKE2 v1.32, v1.33, v1.34, v1.35 e v1.36. Traefik é o caminho de migração recomendado para ambientes SUSE Rancher RKE2, é aconselhável migrar o mais rápido possível. Consulte Migrando do Ingress NGINX para Traefik em um Cluster RKE2 provisionado pelo Rancher para mais detalhes.

Quando o Kubernetes for configurado em uma etapa posterior, a ferramenta RKE2 implantará um controlador de Ingress Nginx. Esse controlador escutará nas portas 80 e 443 dos nós de trabalho, respondendo ao tráfego destinado a nomes de host específicos.

Quando o Rancher for instalado (também em uma etapa posterior), o sistema Rancher cria um recurso de Ingress. Esse Ingress informa ao controlador de Ingress Nginx para escutar o tráfego destinado ao nome de host do Rancher. O controlador de Ingress Nginx, ao receber tráfego destinado ao nome de host do Rancher, encaminhará esse tráfego para os pods do Rancher em execução no cluster.

Para sua implementação, considere se você deseja ou precisa usar um balanceador de carga de Camada 4 ou Camada 7:

  • Um balanceador de carga de camada 4 é a escolha mais simples das duas, na qual você está encaminhando tráfego TCP para seus nós. Recomendamos configurar seu balanceador de carga como um balanceador de Camada 4, encaminhando tráfego para as portas TCP/80 e TCP/443 para os nós do cluster de gerenciamento do Rancher. O controlador de Ingress no cluster redirecionará o tráfego HTTP para HTTPS e encerrará o SSL/TLS na porta TCP/443. O controlador de Ingress encaminhará o tráfego para a porta TCP/80 para o pod de Ingress na implantação do Rancher.

  • Um balanceador de carga de camada 7 é um pouco mais complicado, mas pode oferecer recursos que você pode querer. Por exemplo, um balanceador de carga de camada 7 é capaz de lidar com a terminação TLS no balanceador de carga, ao contrário do Rancher que faz a terminação TLS por conta própria. Isso pode ser benéfico se você quiser centralizar a terminação TLS em sua infraestrutura. O balanceamento de carga de camada 7 também oferece a capacidade de o seu balanceador de carga tomar decisões com base em atributos HTTP, como cookies, etc., que um balanceador de carga de camada 4 não consegue considerar. Se você decidir terminar o tráfego SSL/TLS em um balanceador de carga de camada 7, precisará usar a opção --set tls=external ao instalar o Rancher em um passo posterior. Para mais informações, consulte as opções do gráfico Helm do Rancher.

Para um exemplo mostrando como configurar um balanceador de carga NGINX, consulte esta página.

Para um guia de procedimentos para configurar um balanceador de carga de rede Amazon ELB, consulte esta página.

Não use este balanceador de carga (ou seja, o local Ingress do cluster) para balancear aplicações além do Rancher após a instalação. Compartilhar este Ingress com outras aplicações pode resultar em erros de websocket para o Rancher após recarregamentos de configuração do Ingress para outros apps. Recomendamos dedicar o local cluster ao Rancher e a nenhuma outra aplicação.

3. Configure o Registro DNS

Uma vez que você tenha configurado seu balanceador de carga, precisará criar um registro DNS para enviar tráfego a este balanceador de carga.

Dependendo do seu ambiente, isso pode ser um registro A apontando para o IP do balanceador de carga, ou pode ser um CNAME apontando para o nome do host do balanceador de carga. Em qualquer um dos casos, certifique-se de que este registro é o nome do host que você pretende que o Rancher responda.

Você precisará especificar este nome do host em um passo posterior ao instalar o Rancher, e não é possível alterá-lo depois. Certifique-se de que sua decisão é final.

Para um guia de procedimentos para configurar um registro DNS para direcionar o tráfego de domínio para um balanceador de carga Amazon ELB, consulte a documentação oficial da AWS.