Opções avançadas e configuração

Por padrão, os certificados no RKE2 expiram em 12 meses.

Se os certificados estiverem expirados ou tiverem menos de 90 dias restantes antes de expirarem, os certificados são rotacionados quando o RKE2 é reiniciado.

Os certificados também podem ser rotacionados manualmente. Para fazer isso, é melhor parar o processo rke2-server, rotacionar os certificados e, em seguida, iniciar o processo novamente:

Para renovar os certificados do agente, reinicie o rke2-agent nos nós do agente. Os certificados do agente são renovados toda vez que o agente é iniciado.

Também é possível rotacionar um serviço individual passando a flag --service, por exemplo: rke2 certificate rotate --service api-server. Consulte Gerenciamento de Certificados para mais detalhes.

Qualquer arquivo encontrado em /var/lib/rancher/rke2/server/manifests será automaticamente implantado no Kubernetes de maneira semelhante a kubectl apply.

Para informações sobre a implantação de charts do Helm usando o diretório, consulte a seção sobre Helm.

O RKE2 gerará um arquivo de configuração para o containerd em /var/lib/rancher/rke2/agent/etc/containerd/config.toml, usando valores específicos para a configuração atual do cluster e do nó.

Para personalização avançada, você pode criar um modelo de configuração do containerd no mesmo diretório:

O containerd 2.0 é compatível com versões anteriores de configuração, e o RKE2 continuará a renderizar a configuração da versão 2 legada a partir de config.toml.tmpl se config-v3.toml.tmpl não for encontrado.

O arquivo de modelo é renderizado na configuração do containerd usando a biblioteca text/template. Consulte ContainerdConfigTemplateV3 e ContainerdConfigTemplate em templates.go para o conteúdo do modelo padrão. O modelo é executado com uma estrutura ContainerdConfig como seu valor dot (argumento de dados).

Se você estiver executando o RKE2 em um ambiente que só possui conectividade externa através de um proxy HTTP, pode configurar suas configurações de proxy no serviço systemd do RKE2. Essas configurações de proxy serão então usadas no RKE2 e passadas para o containerd e kubelet incorporados, bem como para os pods estáticos do plano de controle, etcd e kube-proxy.

Adicione as variáveis necessárias HTTP_PROXY, HTTPS_PROXY e NO_PROXY ao arquivo de ambiente do seu serviço systemd, geralmente:

O RKE2 adicionará automaticamente os intervalos de IP internos de Pod e Serviço do cluster e o domínio DNS do cluster à lista de entradas NO_PROXY. Você deve garantir que os intervalos de endereços IP utilizados pelos próprios nós do Kubernetes (ou seja, os IPs públicos e privados dos nós) estejam incluídos na lista NO_PROXY, ou que os nós possam ser alcançados através do proxy.

Se você deseja configurar as configurações de proxy para o containerd sem afetar o RKE2 e o Kubelet, pode prefixar as variáveis com CONTAINERD_:

Os agentes RKE2 podem ser configurados com as opções node-label e node-taint que adicionam um rótulo e um taint ao kubelet. As duas opções apenas adicionam rótulos e/ou taints no momento do registro e podem ser adicionadas apenas uma vez, não podendo ser removidas depois disso através de comandos rke2.

Se você quiser alterar rótulos e taints de nó após o registro do nó, deve usar kubectl. Consulte a documentação oficial do Kubernetes para detalhes sobre como adicionar taints e rótulos de nó.

Os nós agentes são registrados por meio de uma conexão websocket iniciada pelo processo rke2 agent, e a conexão é mantida por um balanceador de carga do lado do cliente que opera como parte do processo do agente.

Os agentes se registram no servidor usando a parte secreta do cluster do token de junção, juntamente com uma senha específica do nó gerada aleatoriamente, que é armazenada no agente em /etc/rancher/node/password. O servidor armazenará as senhas para nós individuais como segredos do Kubernetes, e quaisquer tentativas subsequentes devem usar a mesma senha. Os segredos de senha do nó são armazenados no namespace kube-system com nomes usando o modelo <host>.node-password.rke2. Esses segredos são excluídos quando o nó correspondente do Kubernetes é deletado.

Se o diretório /etc/rancher/node de um agente for removido, o arquivo de senha deve ser recriado para o agente antes da inicialização, ou a entrada removida do servidor ou do cluster Kubernetes (dependendo da versão do RKE2).

O script de instalação fornece unidades para systemd, mas não habilita ou inicia o serviço por padrão.

Ao executar com systemd, os logs serão criados em /var/log/syslog e visualizados usando journalctl -u rke2-server ou journalctl -u rke2-agent.

Um exemplo de instalação com o script de instalação:

Os charts do servidor incluídos com rke2 implantados durante a inicialização do cluster podem ser desabilitados e substituídos por alternativas. Um caso de uso comum é substituir o chart rke2-ingress-nginx incluído por uma alternativa.

Para desabilitar qualquer um dos gráficos do sistema incluídos, defina o parâmetro disable no arquivo de configuração antes da inicialização. Um exemplo de desabilitar todos os gráficos do sistema disponíveis é:

Em regiões públicas da AWS, para garantir que o RKE2 esteja habilitado para a nuvem e capaz de auto-provisionar certos recursos da nuvem, configure o RKE2 com:

Ao instalar o RKE2 em regiões classificadas (como SC2S ou C2S), há alguns pré-requisitos adicionais a serem observados para garantir que o RKE2 saiba como e onde se comunicar de forma segura com os endpoints apropriados da AWS:

As seguintes opções estão disponíveis sob o subcomando server para o RKE2. As opções permitem especificar requisições e limites de CPU para os componentes do plano de controle dentro do RKE2.

Os valores são uma lista delimitada por vírgulas de [controlplane-component]-(cpu|memory)=[desired-value]. Os valores possíveis para controlplane-component são:

Assim, um exemplo de configuração pode ser assim:

Os valores de unidade para CPU/memória são idênticos às unidades de recursos do Kubernetes (Veja: Limites de Recursos no Kubernetes).

As seguintes opções estão disponíveis sob o subcomando server para o RKE2. Essas opções especificam a montagem de diretórios do sistema de arquivos do nó no componente de pod estático que corresponde ao nome prefixado.

As seguintes opções de configuração estão disponíveis para o subcomando server do RKE2. Essas opções especificam variáveis de ambiente adicionais em formato padrão, ou seja, KEY=VALUE para o componente de pod estático que corresponde ao nome prefixado.

Várias variáveis de ambiente podem ser especificadas para o mesmo componente passando os valores das flags como um array no arquivo de configuração.