Ajustes e Melhores Práticas para SUSE Rancher Prime em Escala

As recomendações delineadas em recomendações gerais do Rancher são particularmente importantes em um contexto de alta escala.

Etcd é o banco de dados backend para Kubernetes e para Rancher. O banco de dados pode eventualmente encontrar limitações quanto ao número de um único tipo de recurso do Kubernetes que pode armazenar. Os limites exatos variam e dependem de vários fatores. No entanto, a experiência indica que problemas de desempenho frequentemente surgem uma vez que a contagem de objetos de um único tipo de recurso excede 60.000. Frequentemente, esse tipo é RoleBinding.

Isso é típico no Rancher, pois muitas operações criam novos objetos RoleBinding no cluster upstream como um efeito colateral.

Você pode reduzir o número de RoleBindings no cluster upstream das seguintes maneiras:

Se você tiver cinquenta ou mais usuários, deve configurar um provedor de autenticação externa. Isso é necessário para um melhor desempenho.

Após configurar a autenticação externa, certifique-se de atribuir permissões a grupos em vez de a usuários individuais. Isso ajuda a reduzir a contagem de objetos RoleBinding.

Prever quantos objetos RoleBinding uma configuração específica criará é complicado. No entanto, as seguintes considerações podem oferecer uma estimativa aproximada:

O Rancher utiliza dois recursos de aplicativo do Kubernetes: apps.projects.cattle.io e apps.cattle.cattle.io. Aplicativos legados, representados por apps.projects.cattle.io, foram introduzidos com a antiga interface do usuário do Cluster Manager e agora estão desatualizados. Aplicativos atuais, representados por apps.catalog.cattle.io, são encontrados na interface do usuário do Cluster Explorer para seu respectivo cluster. Apps Apps.cattle.cattle.io são preferíveis porque seus dados residem em downstream clusters, o que libera recursos no upstream cluster.

Você deve remover quaisquer aplicativos legados restantes que apareçam na interface do usuário do Cluster Manager e substituí-los por aplicativos na interface do usuário do Cluster Explorer. Crie quaisquer novos aplicativos apenas na interface do usuário do Cluster Explorer.

Um Endpoint de Cluster Autorizado (ACE) fornece acesso à API do Kubernetes de clusters RKE2 e K3s provisionados pelo Rancher. Quando habilitado, o ACE adiciona um contexto aos arquivos kubeconfig gerados para o cluster. O contexto utiliza um endpoint direto para o cluster, contornando assim o Rancher. Isso reduz a carga no Rancher para casos em que o acesso à API sem mediação é aceitável ou preferível. Veja Ponto de Extremidade de Cluster Autorizado para mais informações e instruções de configuração.

A maior parte da lógica do Rancher ocorre em manipuladores de evento. Esses manipuladores de evento são executados em um objeto sempre que o objeto é atualizado e quando o Rancher é iniciado. Além disso, eles são executados a cada 10 horas quando o Rancher sincroniza caches. Em configuração escalada, essas execuções agendadas têm altos custos de desempenho, pois cada manipulador é executado em cada objeto aplicável. No entanto, a execução agendada de manipuladores pode ser desativada com a variável de ambiente CATTLE_SYNC_ONLY_CHANGED_OBJECTS. Se picos de alocação de recursos forem observados a cada 10 horas, essa configuração pode ajudar.

O valor para CATTLE_SYNC_ONLY_CHANGED_OBJECTS pode ser uma lista separada por vírgulas das seguintes opções. Os valores referem-se a tipos de manipuladores e controladores (as estruturas que contêm e executam manipuladores). Adicionar os tipos de controlador à variável desativa aquele conjunto de controladores de executar seus manipuladores como parte da re-sincronização de cache.

Em resumo, se você notar picos de uso da CPU a cada 10 horas, adicione a variável de ambiente CATTLE_SYNC_ONLY_CHANGED_OBJECTS à sua implantação do Rancher (na lista spec.containers.env) com o valor mgmt,user.

Como o Rancher pode ser muito exigente em relação ao cluster upstream, especialmente em grande escala, você deve ter controle administrativo total sobre a configuração e os nós do cluster. Para identificar a causa raiz do consumo excessivo de recursos, utilize técnicas e ferramentas padrão de solução de problemas do Linux. Isso pode ajudar a distinguir se o Rancher, o Kubernetes ou os componentes do sistema operacional estão causando problemas.

Embora os serviços gerenciados de Kubernetes tornem mais fácil implantar e executar clusters de Kubernetes, eles são desencorajados para o cluster upstream em cenários de alta escala. Os serviços gerenciados de Kubernetes normalmente limitam o acesso à configuração e às informações sobre nós e serviços individuais.

Use o RKE2 para casos de uso em grande escala.

Para fornecer alta disponibilidade, o Kubernetes é projetado para executar nós e componentes de controle em diferentes zonas. No entanto, se os nós e os componentes do plano de controle estiverem localizados em zonas diferentes, o tráfego de rede pode ser mais lento.

O tráfego entre os componentes do Rancher e a API do Kubernetes é especialmente sensível à latência da rede, assim como o tráfego do etcd entre os nós.

Para melhorar o desempenho, execute todos os clusters de nós upstream no mesmo local. Em particular, certifique-se de que a latência entre os nós do etcd e o Rancher seja a mais baixa possível.

Você deve manter o cluster local do Kubernetes atualizado. Isso garantirá que seu cluster tenha todas as melhorias de desempenho e correções de bug disponíveis.

Etcd é o banco de dados backend para Kubernetes e para Rancher. Ele desempenha um papel muito importante no desempenho do Rancher.

Os dois principais gargalos para o desempenho do etcd são a velocidade do disco e a velocidade da rede. O etcd deve ser executado em nós dedicados com uma configuração de rede rápida e com SSDs que tenham altas operações de entrada/saída por segundo (IOPS). Para mais informações sobre o desempenho do etcd, consulte Desempenho lento do etcd (testes de desempenho e otimização) e Ajustando o etcd para grandes instalações. Informações sobre discos também podem ser encontradas nos Requisitos de Instalação.

É melhor executar o etcd em exatamente três nós, pois adicionar mais nós reduzirá a velocidade de operação. Isso pode ser contra-intuitivo para abordagens comuns de escalonamento, mas é devido aos mecanismos de replicação do etcd.

O desempenho do etcd também será negativamente afetado pela latência da rede entre os nós, pois isso tornará a comunicação de rede mais lenta. Os nós do etcd devem estar localizados junto com os nós do Rancher.

Em alta escala, o Rancher transfere mais dados do cluster upstream para os componentes da interface do usuário que estão sendo executados no navegador, e esses componentes também precisam realizar mais processamento.

Para melhor desempenho, certifique-se de que o host que executa o hardware atenda a esses requisitos: