GKE en Bare Metal admite varios modelos de implementación para satisfacer diferentes necesidades de disponibilidad, aislamiento y huella de recursos. En esta página, se definen los conceptos que comparten todos los modelos de implementación y se describe cada modelo.
Clústeres de usuarios
Un clúster de usuario es un clúster de Kubernetes que ejecuta tus cargas de trabajo alojadas en contenedores. Consiste en nodos del plano de control y nodos trabajadores. GKE en Bare Metal admite uno o más clústeres de usuario. Los clústeres de usuario deben contener uno o más nodos trabajadores que ejecutan cargas de trabajo de usuario.
Clústeres de administrador
Un clúster de administrador es un clúster de Kubernetes que administra uno o más clústeres de usuarios. Tu clúster de administrador puede realizar las siguientes tareas:
- Crear clústeres de usuario
- Cambiar a una versión superior de clústeres de usuario
- Actualizar clústeres de usuario
- Borrar clústeres de usuario
Para crear un clúster de usuario, su clúster de administrador configura los componentes de Anthos en equipos físicos en el plano de control y los nodos trabajadores del clúster de usuario. El clúster de administrador solo tiene nodos del plano de control porque los componentes de GKE en Bare Metal se ejecutan en los nodos del plano de control.
Tu clúster de administrador contiene los siguientes tipos de datos sensibles:
- Credenciales de SSH: Se usan para habilitar la instalación remota.
- Claves de cuenta de servicio de Google Cloud: se usan para acceder a funciones como Container Registry
Para proteger los datos sensibles, restringe el acceso a tu clúster de administrador.
Alta disponibilidad
Puedes ejecutar clústeres de usuario o administrador en modo de alta disponibilidad (HA). Este modo requiere tres o más nodos del plano de control (número impar) que se ejecutan en tu clúster. Si ejecutas un clúster en modo sin HA, tu clúster necesita solo un nodo del plano de control.
Si quieres evitar un punto único de fallo, usa el modo de HA para implementaciones de producción. Usa el modo sin alta disponibilidad para entornos no esenciales, por ejemplo, un entorno de pruebas en el que puedes volver a crear el clúster si falla el nodo del plano de control único. Un clúster de usuario con alta disponibilidad debe tener dos o más nodos trabajadores en caso de que falle un nodo trabajador.
Cuando actualizas tus clústeres, una implementación de alta disponibilidad también reduce el riesgo de que el clúster sea inaccesible si hay un error.
Modelos de implementación
GKE en Bare Metal admite los siguientes modelos de implementación para cumplir con diferentes requisitos:
- Implementación del clúster de usuario y administrador
- Implementación de clústeres híbridos
- Implementación de clústeres independiente
Implementación del clúster de administrador y de usuario
Usa este modelo de implementación si tienes varios clústeres en el mismo centro de datos que deseas administrar desde un lugar centralizado y para implementaciones más grandes que necesitan aislamiento entre diferentes equipos o entre cargas de trabajo de desarrollo y producción.
Este modelo de implementación consta de los siguientes clústeres:
- Un clúster de administrador: el punto de administración central que proporciona una API para administrar clústeres de usuarios. Tu clúster de administrador solo ejecuta componentes de administración.
- Uno o más clústeres de usuario: contienen los nodos del plano de control y los nodos trabajadores, que ejecutan las cargas de trabajo del usuario.
Este modelo cumple con los siguientes requisitos:
- Proporciona un plano de control centralizado y una API para administrar los ciclos de vida de los clústeres de tus usuarios.
- Proporciona aislamiento entre los diferentes equipos.
- Proporciona aislamiento entre las cargas de trabajo de desarrollo y producción.
- No es necesario compartir credenciales SSH y claves de cuenta de servicio con los propietarios del clúster.
- Puedes integrar tu implementación en tus propios planos de control
Huella
Una implementación de clúster de administrador y de usuario requiere los siguientes nodos:
Clúster de administrador
- Un nodo de plano de control para instancias sin HA
- Tres o más nodos de plano de control para HA
Clústeres de usuario: Puedes configurar la alta disponibilidad para cada clúster de usuario de manera independiente.
Nodos de plano de control:
- Un nodo de plano de control para instancias sin HA
- Tres o más nodos de plano de control para HA
Nodos trabajadores:
- Uno o más nodos trabajadores para instancias sin HA
- Dos o más nodos trabajadores para HA
Implementación de clúster híbrido
Este modelo de implementación es una implementación especializada para varios clústeres. Un clúster híbrido es un clúster de administrador que puede ejecutar cargas de trabajo del usuario. Tu clúster híbrido aún administra clústeres de usuario adicionales.
Características de este modelo:
- La asignación de un conjunto de máquinas para un clúster de administrador suele ser un desperdicio, ya que los clústeres de administrador usan relativamente pocos recursos. La implementación del clúster híbrido te permite recuperar la capacidad sin usar en esas máquinas, ya que te permite ejecutar las cargas de trabajo del usuario dentro del clúster de administrador.
- El clúster de administrador contiene datos sensibles, como credenciales SSH (que usa el clúster de administrador para administrar clústeres de usuario en máquinas remotas) y claves de cuenta de servicio de Google Cloud (que usa el clúster de administrador para acceder a los servicios de Google Cloud, como Cloud Storage). Las implementaciones de clúster híbrido ejecutan cargas de trabajo del usuario dentro del clúster de administrador y esto podría exponer los datos sensibles del clúster de administrador a las cargas de trabajo del usuario.
Huella
Una implementación de clúster híbrido requiere los siguientes nodos:
Clúster híbrido
Nodos de plano de control:
- Un nodo de plano de control para instancias sin HA
- Tres o más nodos de plano de control para HA
Nodos trabajadores:
- Uno o más nodos trabajadores para instancias sin HA
- Dos o más nodos trabajadores para HA, según el tipo de carga de trabajo
Clústeres de usuario: Puedes configurar la alta disponibilidad para cada clúster de usuario de manera independiente.
Nodos de plano de control:
- Un nodo de plano de control para instancias sin HA
- Tres o más nodos de plano de control para HA
Nodos trabajadores:
- Uno o más nodos trabajadores para instancias sin HA
- Dos o más nodos trabajadores para HA
Implementación del clúster independiente
Este modelo de implementación tiene un solo clúster que funciona como un clúster de usuario y como un clúster de administrador.
Este modelo tiene las siguientes ventajas:
- No se necesita un clúster de administrador separado
- Admite el perfil perimetral, que redujo significativamente los requisitos de recursos del sistema y se recomienda para dispositivos perimetrales con restricciones de recursos altas.
Este modelo tiene algunas compensaciones de seguridad, ya que las cargas de trabajo se ejecutan en un clúster con los siguientes datos sensibles:
- Credenciales SSH
- Claves de cuenta de servicio de Google Cloud
Usa este modelo si cumples con cualquiera de las siguientes condiciones:
- Administras cada clúster de forma independiente.
- Tienes una cantidad pequeña de nodos trabajadores.
- Admites un solo equipo.
- Ejecutas un solo tipo de carga de trabajo.
Este modelo funciona bien en las siguientes situaciones:
- Cada clúster se administra de forma independiente con diferentes claves SSH y credenciales de Google Cloud
- Clústeres que se ejecutan en particiones aisladas de la red, como zonas desmilitarizadas (DMZ)
- Clústeres que se ejecutan en ubicaciones perimetrales
Huella
Una implementación de clúster independiente requiere los siguientes nodos:
Nodos de plano de control:
- Un nodo de plano de control para instancias sin HA
- Tres o más nodos de plano de control para HA
Nodos trabajadores:
- Uno o más nodos trabajadores para instancias sin HA
- Dos o más nodos trabajadores para HA