14 RKE2 #
Consulte la documentación oficial de RKE2.
RKE2 es una distribución de Kubernetes totalmente conforme que se centra en la seguridad y el cumplimiento mediante:
Proporcionando opciones predeterminadas y de configuración que permiten a los clústeres pasar el benchmark CIS de Kubernetes v1.6 o v1.23 con una mínima intervención del operador
Habilitando el cumplimiento de FIPS 140-2
Analizando periódicamente los componentes en busca de CVEs mediante trivy en la canalización de compilación de RKE2
RKE2 lanza los componentes del plano de control como pods estáticos, gestionados por kubelet. El entorno de ejecución de contenedor integrado es containerd.
Nota: RKE2 también se conoce como RKE Government para transmitir otro caso de uso y sector al que se dirige actualmente.
14.1 RKE2 vs K3s #
K3s es una distribución de Kubernetes totalmente conforme y ligera, centrada en Edge, IoT y en la familia de arquitecturas ARM, optimizada para facilitar su uso y para entornos con recursos limitados
RKE2 combina lo mejor de ambos mundos de la versión 1.x de RKE (en adelante denominada RKE1) y K3s.
De K3s, hereda la facilidad de uso, la sencillez de funcionamiento y el modelo de despliegue.
De RKE1, hereda una estrecha alineación con Kubernetes upstream. En algunos aspectos, K3s se ha desviado de Kubernetes upstream para optimizar despliegues en edge, pero RKE1 y RKE2 pueden mantenerse estrechamente alineados con upstream
14.2 ¿Cómo utiliza SUSE Telco Cloud RKE2? #
RKE2 es una pieza fundamental de la pila SUSE Telco Cloud. Se asienta sobre SUSE Linux Micro (Capítulo 10, SUSE Linux Micro), proporcionando una interfaz de Kubernetes estándar necesaria para desplegar cargas de trabajo de Edge.
14.3 Prácticas recomendadas #
14.3.1 Instalación #
La forma recomendada de instalar RKE2 como parte de la pila SUSE Telco Cloud es mediante el uso de Edge Image Builder (EIB). Consulte la documentación de EIB (Capítulo 12, Edge Image Builder) para obtener más detalles sobre cómo configurarlo para desplegar RKE2.
EIB es lo suficientemente flexible como para admitir cualquier parámetro requerido por RKE2, como especificar la versión de RKE2, la configuración de los servidores o de los agentes, cubriendo todos los casos de uso de Edge.
Para otros casos de uso que involucran a Metal3, RKE2 también se está utilizando e instalando. En esos casos particulares, el Cluster API Provider RKE2 despliega automáticamente RKE2 en los clústeres que se están aprovisionando con Metal3 utilizando la pila Edge.
En esos casos, la configuración de RKE2 debe aplicarse en los diferentes CRDs involucrados. Un ejemplo de cómo proporcionar una CNI diferente utilizando el CRD RKE2ControlPlane es el siguiente:
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
name: single-node-cluster
namespace: default
spec:
serverConfig:
cni: calico
cniMultusEnable: true
...Para más información sobre los casos de uso de Metal3, consulte Capítulo 11, Metal3.
14.3.2 Gran disponibilidad #
Para despliegues de alta disponibilidad, EIB despliega y configura automáticamente MetalLB (Capítulo 17, MetalLB) y el Endpoint Copier Operator (Capítulo 18, Operador de Endpoint Copier) para exponer el punto de conexión de la API de RKE2 externamente.
14.3.3 Conectividad #
La pila SUSE Telco Cloud admite Cilium, Calico, siendo Cilium su CNI predeterminado. También se puede utilizar el metaplugin Multus cuando los pods requieran múltiples interfaces de red. RKE2 independiente admite una gama más amplia de opciones de CNI.
14.3.4 Almacenamiento #
RKE2 no proporciona ningún tipo de clase de almacenamiento persistente ni operadores. Para clústeres que abarcan varios nodos, se recomienda utilizar SUSE Storage (Capítulo 15, SUSE Storage).