16 RKE2 #
Consulte la documentación oficial de RKE2.
RKE2 es una distribución de Kubernetes totalmente compatible que se centra en la seguridad y el cumplimiento normativo:
Proporcionando valores predeterminados y opciones de configuración que permiten a los clústeres superar la prueba CIS Kubernetes Benchmark v1.6 o v1.23 con una intervención mínima por parte del operador
Habilitando la conformidad con FIPS 140-2
Escaneando regularmente los componentes en busca de CVE mediante trivy en el proceso de creación de RKE2
RKE2 lanza los componentes del plano de control como pods estáticos, gestionados por kubelet. El entorno de ejecución del contenedor integrado es containerd.
Nota: RKE2 también se conoce como RKE Government cuando se emplea en otro caso de uso y en el sector al que se dirige.
16.1 RKE2 frente a K3s #
K3s es una distribución de Kubernetes totalmente compatible y ligera, centrada en Edge, IoT y ARM, optimizada para que su uso sea sencillo y para entornos con recursos limitados.
RKE2 combina lo mejor de la versión 1.x de RKE (en adelante, RKE1) y de K3s.
De K3s, hereda la facilidad de uso, la simplicidad de funcionamiento y el modelo de despliegue.
De RKE1, hereda una estrecha alineación con la versión original de Kubernetes. En algunos aspectos, K3s se ha desviado de la versión original de Kubernetes con el fin de optimizar los despliegues periféricos; pero RKE1 y RKE2 pueden mantenerse estrechamente alineados con dicha versión original.
16.2 ¿Cómo se usa RK2 en SUSE Edge? #
RKE2 es una pieza fundamental de la pila de SUSE Edge. Se sitúa sobre SUSE Linux Micro (Capítulo 9, SUSE Linux Micro) y proporciona una interfaz de Kubernetes estándar necesaria para desplegar cargas de trabajo de Edge.
16.3 Prácticas recomendadas #
16.3.1 Instalación #
La forma recomendada de instalar RKE2 como parte de la pila de SUSE Edge es utilizando Edge Image Builder (EIB). Consulte la documentación de EIB (Capítulo 11, Edge Image Builder) para obtener más detalles sobre cómo hacerlo.
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 servidores o la configuración de los agentes, cubriendo todos los casos de uso de Edge.
También se usa e instala para otros casos de uso relacionados con Metal3. En ellos, la versión de RK2 de proveedor de Cluster API despliega automáticamente RKE2 en los clústeres que se aprovisionan con Metal3 utilizando la pila de Edge.
En esos casos, la configuración de RKE2 debe aplicarse en las diferentes CRD
involucradas. Un ejemplo de cómo proporcionar una CNI diferente utilizando
la CRD RKE2ControlPlane sería el siguiente:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
name: single-node-cluster
namespace: default
spec:
serverConfig:
cni: calico
cniMultusEnable: true
...Para obtener más información sobre los casos de uso de Metal3, consulte el Capítulo 10, Metal3.
16.3.2 High Availability #
Para los despliegues de HA (High Availability, alta disponibilidad), EIB despliega y configura automáticamente MetalLB (Capítulo 19, MetalLB) y el operador Endpoint Copier Operator (Capítulo 20, Endpoint Copier Operator) para exponer externamente el punto final de la API de RKE2.
16.3.3 Redes #
La pila de SUSE Edge admite Cilium y Calico, siendo Cilium su CNI por defecto. El metacomplemento Multus también se puede usar si los pods requieren varias interfaces de red. RKE2 por sí mismo admite una gama más amplia de opciones de CNI.
16.3.4 Almacenamiento #
RKE2 no proporciona ninguna clase ni operador de almacenamiento persistente. Para clústeres que abarquen varios nodos, se recomienda utilizar SUSE Storage (Capítulo 17, SUSE Storage).