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.

SUSE® Rancher Prime: RKE2 Referência de Configuração do Cluster

Esta seção abrange as opções de configuração disponíveis no Rancher para um cluster RKE2 Kubernetes novo ou existente.

Visão Geral

Você pode configurar as opções do Kubernetes de uma das duas maneiras a seguir:

Interface do Rancher: Use a interface do Rancher para selecionar opções que são comumente personalizadas ao configurar um cluster Kubernetes.
Arquivo de Configuração do Cluster: Em vez de usar a interface do Rancher para escolher opções do Kubernetes para o cluster, usuários avançados podem criar um arquivo de configuração RKE2. Usar um arquivo de configuração permite que você defina muitas opções adicionais disponíveis para uma instalação RKE2.

Editando clusters na Interface do Rancher

A interface do Rancher fornece duas maneiras de editar um cluster:

Com um formulário.
Com YAML.

Editando clusters com um Formulário

O formulário abrange as opções mais frequentemente necessárias para clusters.

Para editar seu cluster,

Clique em ☰ > Gerenciamento de Cluster.
Vá para o cluster que você deseja configurar e clique em ⋮ > Editar Configuração.

Editando Clusters em YAML

Para uma referência completa das opções configuráveis para clusters RKE2 em YAML, consulte a documentação do RKE2.

Para editar seu cluster em YAML:

Clique em ☰ > Gerenciamento de Cluster.
Vá para o cluster que você deseja configurar e clique em ⋮ > Editar como YAML.
Edite as opções do RKE sob a diretiva rkeConfig.

Opções de Configuração na Interface do Rancher

Configuração do Pool de Máquinas

Esta subseção abrange configurações genéricas de pool de máquinas. Para configurações específicas de provedores de infraestrutura, consulte o seguinte:

Nome do pool

O nome do pool de máquinas.

Contagem de Máquinas

O número de máquinas no pool.

Funções

Opção para atribuir funções de etcd, plano de controle e trabalhador aos nós.

Avançado

Substituição Automática

A quantidade de tempo que os nós podem ficar inacessíveis antes de serem automaticamente excluídos e substituídos.

Drenar Antes de Excluir

Habilita a drenagem dos nós, expulsando todos os pods antes que o nó seja excluído.

Rótulos de Nó do Kubernetes

Adicione rótulos aos nós para ajudar na organização e seleção de objetos.

Para detalhes sobre os requisitos de sintaxe de rótulos, consulte a documentação do Kubernetes.

Taints

Adicione taints aos nós, para evitar que pods sejam agendados ou executados nos nós, a menos que os pods tenham tolerâncias correspondentes.

Configuração do Cluster

Noções básicas

Kubernetes Version

A versão do Kubernetes instalada em seus nós de cluster.

Para detalhes sobre como atualizar ou reverter o Kubernetes, consulte Atualizando o Kubernetes.

Provedor de Rede de Contêiner

O Provedor de Rede que o cluster utiliza.

Após lançar o cluster, você não pode mudar seu provedor de rede. Portanto, escolha cuidadosamente qual provedor de rede deseja usar, pois o Kubernetes não permite a troca entre provedores de rede. Uma vez que um cluster é criado com um provedor de rede, mudar de provedores de rede exigiria que você desmontasse todo o cluster e todas as suas aplicações.

Por padrão, o Rancher é compatível com os seguintes provedores de rede:

Canal
Cilium*
Calico
Flannel
Multus
Ao usar isolamento de rede do projeto no Cilium CNI, é possível habilitar o roteamento de entrada entre nós. Clique na documentação do provedor de CNI para saber mais.

Para mais detalhes sobre os diferentes provedores de rede e como configurá-los, consulte nossa documentação do RKE2.

Ao usar cilium ou multus,cilium como seu provedor de interface de rede de contêiner, certifique-se de que a opção Habilitar Suporte a IPv6 também esteja habilitada.

Provedor de Nuvem

Você pode configurar um provedor de nuvem Kubernetes. Se você quiser usar volumes e armazenamento provisionados dinamicamente no Kubernetes, normalmente deve selecionar o provedor de nuvem específico para usá-lo. Por exemplo, se você quiser usar o Amazon EBS, precisará selecionar o aws provedor de nuvem.

Se o provedor de nuvem que você deseja usar não estiver listado como uma opção, precisará usar a opção de arquivo de configuração para configurar o provedor de nuvem. Por favor, consulte esta documentação sobre como configurar o provedor de nuvem.

Modelo de Configuração de Admissão de Segurança de Pod

O modelo de configuração de admissão de segurança de pod padrão para o cluster.

Perfil de Conformidade do Trabalhador

Selecione um padrão de conformidade para validar a configuração do sistema.

Isolamento de Rede do Projeto

Se seu provedor de rede permitir isolamento de rede do projeto, você pode escolher habilitar ou desabilitar a comunicação entre projetos.

O isolamento de rede do projeto está disponível se você estiver usando qualquer plugin de rede RKE2 que suporte a aplicação de políticas de rede do Kubernetes, como o Canal.

CoreDNS

Por padrão, CoreDNS é instalado como o provedor de DNS padrão. Se o CoreDNS não estiver instalado, um provedor de DNS alternativo deve ser instalado por você mesmo. Consulte a documentação do RKE2 para configurações adicionais do CoreDNS.

Ingress

Ingress-NGINX
Traefik

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.

Esta é a opção de ingress legado para habilitar o Ingress-NGINX dentro do cluster. Consulte a documentação do RKE2 para opções de configuração adicionais.

Se você deseja expor suas aplicações em uma configuração de alta disponibilidade, e está hospedando seus nós com um provedor de nuvem que não possui um recurso nativo de balanceamento de carga, habilite esta opção para usar o Traefik Ingress dentro do cluster. Consulte a documentação do RKE2 para opções de configuração adicionais.

Servidor de Métricas

Opção para habilitar ou desabilitar o Servidor de Métricas.

Cada provedor de nuvem capaz de lançar um cluster usando RKE2 pode coletar métricas e monitorar seus nós do cluster. Habilite esta opção para visualizar suas métricas de nó no portal do seu provedor de nuvem.

Configuração de Complemento

Manifests adicionais do Kubernetes, gerenciados como um complemento, a serem aplicados ao cluster na inicialização. Consulte a documentação do RKE2 para detalhes.

Variáveis de Ambiente do Agente

Opção para definir variáveis de ambiente para agentes do Rancher. As variáveis de ambiente podem ser definidas usando pares de chave e valor. Consulte a documentação do RKE2 para mais detalhes.

etcd

Instantâneos Automáticos

Opção para habilitar ou desabilitar instantâneos recorrentes do etcd. Se habilitado, os usuários têm a opção de configurar a frequência dos instantâneos. Para detalhes, consulte a documentação do RKE2. Observe que com o RKE2, os instantâneos são armazenados em cada nó etcd. Isso varia do RKE1, que armazena apenas um instantâneo por cluster.

Métricas

Opção para escolher se deve expor métricas do etcd ao público ou apenas dentro do cluster.

Projeto de Rede

Cluster CIDR

CIDRs de rede IPv4 e/ou IPv6 a serem usados para IPs de pod (padrão: 10.42.0.0/16).

Valores de exemplo:

Somente IPv4: 10.42.0.0/16
Apenas IPv6: 2001:cafe:42::/56
Pilha dupla: 10.42.0.0/16,2001:cafe:42::/56

Para requisitos e limitações adicionais relacionados à rede dual-stack ou apenas IPv6, consulte os seguintes recursos:

Você deve configurar o Service CIDR quando criar o cluster pela primeira vez. Você não pode habilitar o Service CIDR em um cluster existente após ele ser iniciado.
Ao usar cilium ou multus,cilium como seu provedor de interface de rede de contêiner, certifique-se de que a opção Habilitar Suporte a IPv6 também esteja habilitada.

Service CIDR

CIDRs de rede IPv4/IPv6 a serem usados para IPs de serviço (padrão: 10.43.0.0/16).

Valores de exemplo:

Somente IPv4: 10.43.0.0/16
Apenas IPv6: 2001:cafe:43::/112
Pilha dupla: 10.43.0.0/16,2001:cafe:43::/112

Para requisitos e limitações adicionais relacionados à rede dual-stack ou apenas IPv6, consulte os seguintes recursos:

Você deve configurar o Service CIDR quando criar o cluster pela primeira vez. Você não pode habilitar o Service CIDR em um cluster existente após ele ser iniciado.
Ao usar cilium ou multus,cilium como seu provedor de interface de rede de contêiner, certifique-se de que a opção Habilitar Suporte a IPv6 também esteja habilitada.

Cluster DNS

IP de cluster IPv4 para o serviço coredns. Deve estar na sua faixa de service-cidr (padrão: 10.43.0.10).

Domínio do Cluster

Selecione o domínio para o cluster. O padrão é cluster.local.

Faixa de Portas do Serviço NodePort

Opção para alterar a faixa de portas que podem ser usadas para serviços NodePort. O padrão é 30000-32767.

Truncar Nomes de Host

Opção para truncar nomes de host para 15 caracteres ou menos. Você só pode definir este campo durante a criação inicial do cluster. Você não pode habilitar ou desabilitar o limite de 15 caracteres após a criação do cluster.

Esta configuração afeta apenas clusters provisionados por máquinas. Como clusters personalizados definem nomes de host durante seu próprio processo de criação de nós, que ocorre fora do Rancher, este campo não restringe o comprimento do nome de host do cluster personalizado.

Truncar nomes de host em um cluster melhora a compatibilidade com sistemas baseados em Windows. Embora o Kubernetes permita nomes de host com até 63 caracteres, sistemas que usam NetBIOS restringem os nomes de host a 15 caracteres ou menos.

Nomes Alternativos TLS

Adicione nomes de host ou endereços IPv4/IPv6 como Nomes Alternativos do Sujeito no certificado TLS do servidor.

Preferência de Pilha

Escolha a pilha de rede para o cluster. Esta opção afeta:

O endereço usado para sondagens de saúde e prontidão de componentes como Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager e kubelet.
A URL do servidor no authentication-token-webhook-config-file para o Ponto de Extremidade do Cluster Autorizado.
A configuração advertise-client-urls para etcd durante a restauração do instantâneo.

As opções são ipv4, ipv6, dual:

Quando definido como ipv4, o cluster usa 127.0.0.1
Quando definido como ipv6, o cluster usa [::1]
Quando definido como dual, o cluster usa localhost

A preferência de pilha deve corresponder à configuração de rede do cluster:

Defina como ipv4 para clusters apenas IPv4
Defina como ipv6 para clusters apenas IPv6
Defina como dual para clusters de pilha dupla

Garantir que a configuração do endereço de loopback esteja correta é fundamental para o provisionamento bem-sucedido do cluster. Para mais informações, consulte a página Requisitos do Nó.

Ponto de Extremidade do Cluster Autorizado

O Ponto de Extremidade do Cluster Autorizado pode ser usado para acessar diretamente o servidor API do Kubernetes, sem exigir comunicação através do Rancher.

Isso é habilitado por padrão em clusters Kubernetes lançados pelo Rancher, usando o IP do nó com o papel controlplane e os certificados autoassinados padrão do Kubernetes.

Para mais detalhes sobre como um endpoint de cluster autorizado funciona e por que é utilizado, consulte a seção de arquitetura.

Recomendamos o uso de um balanceador de carga com o endpoint de cluster autorizado. Para detalhes, consulte a seção de arquitetura recomendada.

Registros

Selecione o repositório de imagens para puxar imagens do Rancher. Para mais detalhes e opções de configuração, consulte a documentação do RKE2.

Estratégia de fazer upgrade

Concorrência do Plano de Controle

Selecione quantos nós podem fazer upgrade ao mesmo tempo. Pode ser um número fixo ou uma porcentagem.

Concorrência de Trabalhadores

Selecione quantos nós podem fazer upgrade ao mesmo tempo. Pode ser um número fixo ou uma porcentagem.

Drenar Nós (Plano de Controle)

Opção para remover todos os pods do nó antes de fazer upgrade.

Drenar Nós (Nós de Trabalho)

Opção para remover todos os pods do nó antes de fazer upgrade.

Avançado

Opção para definir opções do kubelet para diferentes nós. Para opções disponíveis, consulte a documentação do Kubernetes.

Referência do Arquivo de Configuração do Cluster

Editar clusters em YAML permite que você defina as opções disponíveis em uma instalação do RKE2, incluindo aquelas já listadas em Opções de Configuração na UI do Rancher, além de definir parâmetros específicos do Rancher.

Exemplo de Trecho de Arquivo de Configuração de Cluster

yaml apiVersion: provisioning.cattle.io/v1 kind: Especificação do cluster: cloudCredentialSecretName: cattle-global-data:cc-s879v kubernetesVersion: v1.25.12+rke2r1 localClusterAuthEndpoint: {} rkeConfig: additionalManifest: "" chartValues: rke2-calico: {} etcd: snapshotRetention: 5 snapshotScheduleCron: 0 */5 * * * machineGlobalConfig: cni: calico disable-kube-proxy: false etcd-expose-metrics: false arquivo de controle: null kube-apiserver-arg: - audit-policy-file=/etc/rancher/rke2/user-audit-policy.yaml - audit-log-path=/etc/rancher/rke2/user-audit.logs machinePools: - controlPlaneRole: true etcdRole: true machineConfigRef: kind: Amazonec2Config name: nc-test-pool1-pwl5h name: pool1 quantity: 1 unhealthyNodeTimeout: 0s workerRole: true machineSelectorConfig: - config: protect-kernel-defaults: false machineSelectorFiles: - fileSources: - configMap: name: '' secret: name: audit-policy items: - key: audit-policy path: /etc/rancher/rke2/user-audit-policy.yaml machineLabelSelector: matchLabels: rke.cattle.io/control-plane-role: 'true' registries: {} upgradeStrategy: controlPlaneConcurrency: "1" controlPlaneDrainOptions: deleteEmptyDirData: true enabled: true gracePeriod: -1 ignoreDaemonSets: true timeout: 120 workerConcurrency: "1" workerDrainOptions: deleteEmptyDirData: true enabled: true gracePeriod: -1 ignoreDaemonSets: true timeout: 120

additionalManifest

Especifique manifestos adicionais a serem entregues aos nós do plano de controle.

O valor é uma String e será colocado no caminho /var/lib/rancher/rke2/server/manifests/rancher/addons.yaml nos nós de destino.

Exemplo:

additionalManifest: |-
  apiVersion: v1
  kind: Namespace
  metadata:
    name: name-xxxx

Se você quiser personalizar gráficos do sistema, deve usar o campo chartValues conforme descrito abaixo.

Alternativas, como usar um HelmChartConfig para personalizar os gráficos do sistema via additionalManifest, podem causar comportamentos inesperados, devido a ter múltiplos HelmChartConfigs para o mesmo gráfico.

chartValues

Especifique os valores para os gráficos do sistema instalados pelo RKE2.

Para mais informações sobre como o RKE2 gerencia componentes empacotados, consulte documentação do RKE2.

Exemplo:

chartValues:
    chart-name:
        key: value

machineGlobalConfig

Especifique as configurações do RKE2. Qualquer alteração de configuração feita aqui se aplicará a todos os nós. As opções de configuração disponíveis na versão autônoma do RKE2 podem ser aplicadas aqui.

Exemplo:

machineGlobalConfig:
    etcd-arg:
        - key1=value1
        - key2=value2

Existem algumas opções de configuração que não podem ser alteradas ao provisionar via Rancher:

data-dir (pasta para manter o estado), que por padrão é /var/lib/rancher/rke2.

Para facilitar a colocação de arquivos nos nós com antecedência, o Rancher espera que os seguintes valores sejam incluídos na configuração, enquanto o RKE2 espera que os valores sejam inseridos como caminhos de arquivo:

arquivo-de-política-de-auditoria
cloud-provider-config
registro-privado

O Rancher entrega os arquivos para o caminho /var/lib/rancher/rke2/etc/config-files/<option> nos nós de destino e define as opções adequadas no servidor RKE2.

Exemplo:

apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
  rkeConfig:
    machineGlobalConfig:
      audit-policy-file:
        apiVersion: audit.k8s.io/v1
        kind: Policy
        rules:
        - level: RequestResponse
          resources:
          - group: ""
            resources:
            - pods

machineSelectorConfig

machineSelectorConfig é o mesmo que machineGlobalConfig, exceto que um seletor de rótulo pode ser especificado com a configuração. A configuração será aplicada apenas aos nós que correspondem ao seletor de rótulo fornecido.

Várias entradas de config são permitidas, cada uma especificando seu próprio machineLabelSelector. Um usuário pode especificar matchExpressions, matchLabels, ambos ou nenhum. Omitir a seção machineLabelSelector deste campo tem o mesmo efeito que colocar a configuração na seção machineGlobalConfig.

Exemplo:

machineSelectorConfig
  - config:
      config-key: config-value
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

machineSelectorFiles

Este recurso está disponível no Rancher v2.7.2 e versões posteriores.

Entregar arquivos aos nós, para que os arquivos possam estar disponíveis antes de iniciar os processos do servidor ou do agente RKE2. O conteúdo do arquivo é recuperado de um segredo ou de um configmap. Os nós de destino são filtrados pelo machineLabelSelector.

Exemplo:

machineSelectorFiles:
  - fileSources:
      - secret:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-secret-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2
  - fileSources:
      - configMap:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-configmap-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

O segredo ou configmap deve atender aos seguintes requisitos:

Deve estar no namespace fleet-default onde o objeto Cluster existe.
Deve ter a anotação rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2, que permite que os clusters de destino o utilizem.

O Rancher Dashboard fornece um formulário fácil de usar para criar o segredo ou configmap.

Exemplo:

apiVersion: v1
data:
  audit-policy: >-
    IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
kind: Secret
metadata:
  annotations:
    rke.cattle.io/object-authorized-for-clusters: cluster1
  name: name1
  namespace: fleet-default