Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Lanzando Kubernetes en Nuevos Nodos en un Proveedor de Infraestructura

Cuando creas un cluster RKE2 utilizando una configuración de máquina en Rancher, cada grupo de máquinas resultante se muestra en una nueva pestaña Grupos de máquinas. Puedes ver los grupos de máquinas haciendo lo siguiente:

  1. Haz clic en ☰ > Gestión de clusters.

  2. Haz clic en el nombre del cluster RKE2.

SUSE® Rancher Prime: RKE2 Clusters

Rancher v2.6 introduce el aprovisionamiento para clusters RKE2 directamente desde la interfaz de usuario de Rancher. RKE2, también conocido como RKE Government, es una distribución de Kubernetes totalmente conforme que se centra en la seguridad y el cumplimiento de las normativas en EE. UU. Gobierno federal de Estados Unidos.

Para las plantillas de cluster RKE2, consulta esta página para información adicional.

Roles de Nodo

La CLI de RKE2 expone dos roles, server y agent, que representan los roles de nodo de Kubernetes etcd + controlplane y worker respectivamente. Con la integración de RKE2 en Rancher v2.6, los grupos de nodos de RKE2 pueden representar asignaciones de roles más detalladas de modo que los roles etcd y controlplane pueden ser representados.

La misma funcionalidad de usar nodos etcd, controlplane y worker es posible en la CLI de RKE2 utilizando flags y etiquetado de nodos para controlar dónde se programaron las cargas de trabajo y el maestro de Kubernetes. La razón por la que esos roles no se implementaron como roles de primera clase en la CLI de RKE2 es que RKE2 se conceptualiza como un conjunto de bloques de construcción en bruto que se aprovechan mejor a través de un sistema de orquestación como Rancher.

En nuestra arquitectura de cluster recomendada, describimos cuántos nodos de cada rol deberían tener los clusters:

  • Al menos tres nodos con el rol etcd para sobrevivir a la pérdida de un nodo

  • Al menos dos nodos con el rol controlplane para alta disponibilidad de componentes maestros

  • Al menos dos nodos con el rol worker para la reprogramación de cargas de trabajo en caso de fallo de un nodo