14 RKE2 #
Consulte a documentação oficial do RKE2.
O RKE2 é uma distribuição Kubernetes totalmente compatível que se dedica à segurança e conformidade por meio de:
Fornecimento de padrões e opções de configuração que permitem que os clusters cumpram o CIS Kubernetes Benchmark v1.6 ou v1.23 com um mínimo de intervenção do operador
Habilitação da conformidade com FIPS 140-2
Verificando regularmente os componentes em busca de CVEs usando trivy no pipeline de build do RKE2
O RKE2 inicia os componentes do plano de controle como pods estáticos, gerenciados pelo kubelet. O tempo de execução do contêiner incorporado é o containerd.
Nota: O RKE2 também é conhecido como RKE Government para transmitir outro caso de uso e setor que ele atende atualmente.
14.1 RKE2 vs K3s #
O K3s é uma distribuição Kubernetes totalmente compatível e leve, focada em Edge, IoT, ARM - otimizada para facilidade de uso e ambientes com recursos limitados.
O RKE2 combina o melhor dos dois mundos da versão 1.x do RKE (doravante denominada RKE1) e do K3s.
Do K3s, ele herda a usabilidade, a facilidade de operação e o modelo de implantação.
Do RKE1, ele herda o alinhamento próximo com o Kubernetes upstream. Em alguns pontos, o K3s divergiu do Kubernetes upstream para otimizar implantações de edge, mas o RKE1 e o RKE2 podem permanecer estreitamente alinhados com o upstream.
14.2 Como o SUSE Telco Cloud usa o RKE2? #
O RKE2 é uma peça fundamental da pilha SUSE Telco Cloud. Ele fica sobre o SUSE Linux Micro (Capítulo 10, SUSE Linux Micro), fornecendo uma interface Kubernetes padrão necessária para implantar cargas de trabalho de Edge.
14.3 Melhores práticas #
14.3.1 Instalação #
A maneira recomendada de instalar o RKE2 como parte da pilha SUSE Telco Cloud é usando o Edge Image Builder (EIB). Consulte a documentação do EIB (Capítulo 12, Edge Image Builder) para obter mais detalhes sobre como configurá-lo para implantar o RKE2.
O EIB é flexível o suficiente para suportar qualquer parâmetro exigido pelo RKE2, como especificar a versão do RKE2, a configuração dos servidores ou dos agentes, cobrindo todos os casos de uso de Edge.
Para outros casos de uso envolvendo o Metal3, o RKE2 também está sendo usado e instalado. Nesses casos específicos, o Cluster API Provider RKE2 implanta automaticamente o RKE2 em clusters que estão sendo provisionados com o Metal3 usando a Edge Stack.
Nesses casos, a configuração do RKE2 deve ser aplicada nos diferentes CRDs envolvidos. Um exemplo de como fornecer um CNI diferente usando o RKE2ControlPlane CRD é o seguinte:
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
name: single-node-cluster
namespace: default
spec:
serverConfig:
cni: calico
cniMultusEnable: true
...Para mais informações sobre os casos de uso do Metal3, consulte Capítulo 11, Metal3.
14.3.2 Alta disponibilidade #
Para implantações de HA, o EIB implanta e configura automaticamente o MetalLB (Capítulo 17, MetalLB) e o Endpoint Copier Operator (Capítulo 18, Operador Endpoint Copier) para expor o endpoint da API do RKE2 externamente.
14.3.3 Projeto de Rede #
A pilha SUSE Telco Cloud oferece suporte ao Cilium, Calico, com o Cilium como seu CNI padrão. O meta-plugin Multus também pode ser usado quando os pods exigem múltiplas interfaces de rede. O RKE2 independente oferece suporte a uma gama mais ampla de opções de CNI.
14.3.4 Armazenamento #
O RKE2 não fornece nenhum tipo de classe de armazenamento persistente ou operadores. Para clusters que abrangem vários nós, recomenda-se usar o SUSE Storage (Capítulo 15, SUSE Storage).