¿Gestiona clústeres de Kubernetes con distintos proveedores de nube?

Gestione clústeres de Kubernetes en varias nubes y en sus instalaciones desde un único plano de control soberano ubicado en la UE. Simplifique las operaciones, refuerce la seguridad y permita que su equipo de plataformas dedique más tiempo a innovar.
Ilustración de nombres de dominio

Gestione clústeres heterogéneos como un único conjunto bajo una gobernanza común

La gestión multinube de Kubernetes resulta más eficaz cuando los equipos de ingeniería administran los clústeres distribuidos como un conjunto, en lugar de gestionarlos en entornos aislados. Un modelo de control compartido permite gestionar varios clústeres de Kubernetes en todos los entornos sin renunciar a las opciones de infraestructura específicas de cada uno. La gestión de políticas como código establece una referencia común para configurar aplicaciones, aplicar controles de cumplimiento normativo y definir reglas de gestión de recursos. 

Los equipos pueden revisar los cambios en Git, utilizar GitOps para aplicar configuraciones aprobadas y consultar la documentación compartida antes del despliegue. Este enfoque es compatible con AKS y otros entornos Kubernetes sin exigir las mismas soluciones de almacenamiento, redes o registros de contenedores. La gobernanza centralizada uniformiza los criterios, no todos los componentes técnicos. Un equipo puede elegir un sistema de almacenamiento por motivos de residencia de los datos y otro optar por una solución distinta para mejorar el rendimiento. Ambos aplican las mismas políticas y siguen procesos comunes de revisión del código y cumplimiento normativo en todos los clústeres.
[object Object]

Soberanía gestionada sin dependencia de un proveedor

OVHcloud Managed Rancher Service facilita la gestión centralizada y sujeta a políticas de los clústeres de Kubernetes
22eb325c-c26f-45a3-9ad3-523fec8ad7b9_ite_df983f40.svg
Un único servicio gestionado en la UE
1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg
Conexiones exclusivamente salientes
22eb325c-c26f-45a3-9ad3-523fec8ad7b9_ite_1cbdf381.svg
Libertad para cambiar de solución

Diseñe la gobernanza para una arquitectura de cargas de trabajo distribuidas

Managed Rancher Service (MRS) aloja Rancher Manager en la infraestructura de OVHcloud, por lo que su equipo ya no tiene que encargarse de administrarlo. Esta distinción arquitectónica es importante: OVHcloud no gestiona directamente sus clústeres de GKE, EKS o AKS. El componente alojado en OVHcloud es Rancher Manager, en la región de la UE que usted elija; un agente ligero de Rancher, que solo establece conexiones salientes, se ejecuta en cada uno de sus clústeres, independientemente de dónde estén ubicados, y envía información al Manager. Sus clústeres actuales de GKE, EKS, AKS o sus instalaciones permanecen donde están, en sus cuentas y bajo su responsabilidad. MRS ofrece a su organización un único punto desde el que visualizar, controlar y gobernar todos los clústeres. Es una solución práctica para cualquier empresa que utilice Kubernetes en varias regiones o con más de un proveedor de nube.

Todos los tipos de clústeres —gestionados en la nube, autogestionados o nativos de OVHcloud— se muestran en la misma interfaz de Rancher, utilizan las mismas API y pueden aprovisionarse con los mismos recursos de Terraform. Si también necesita un repositorio compartido de imágenes de contenedores, OVHcloud Managed Private Registry ofrece un registro basado en Harbor desde el que todos los clústeres pueden descargar imágenes, independientemente de la nube o región donde se ejecuten.

Organice los clústeres según responsabilidades bien definidas

Defina una función una sola vez en Rancher Manager y aplíquela a todos los clústeres —gestionados en la nube, autogestionados o nativos de OVHcloud—, sin tener que reproducir la misma política de acceso en tres o cuatro consolas distintas. Todas las concesiones y revocaciones de acceso, así como los cambios de permisos, quedan registrados en una única pista de auditoría coherente. Esta es la diferencia entre completar una revisión de accesos en una tarde o necesitar una semana para cotejar exportaciones de distintos proveedores. Esta es la base operativa que permite a una organización en crecimiento mantener el cumplimiento normativo bajo control a medida que aumenta el número de clústeres.

Estandarice la configuración sin renunciar a las particularidades de cada entorno

Si necesita crear nuevos clústeres en lugar de importar los existentes, utilice Rancher Manager, alojado en OVHcloud, para aprovisionar RKE2 —una distribución de Kubernetes apta para producción y reforzada conforme a los criterios de referencia del CIS— o k3s, una distribución ligera adecuada para despliegues en el perímetro de la red. Ambas pueden aprovisionarse en cualquier infraestructura con recursos de computación disponibles: servidores físicos locales, máquinas virtuales o instancias IaaS de cualquier proveedor de nube y región. Los procesos de aprovisionamiento, el control de acceso RBAC y la monitorización son idénticos en todas las nubes, independientemente de dónde se encuentre físicamente el clúster resultante.

Incorpore clústeres nuevos y existentes sin rediseñar las cargas de trabajo

RancherRKE2K3s
Si ya dispone de clústeres en Google, AWS, Azure o en su propio centro de datos, no necesita migrar nada. Basta con instalar el agente de Rancher en cada clúster existente. El agente establece una conexión exclusivamente saliente con Rancher Manager, alojado en OVHcloud, y el clúster se incorpora al conjunto en cuestión de minutos, sea cual sea su nube o región. No es necesario cambiar de plataforma ni interrumpir los despliegues, y tampoco se modifica la forma de desplegar las aplicaciones en ese clúster, tanto si se ejecuta en GCP, AWS, Azure como en sus propias instalaciones. 

Para las cargas de trabajo que requieran específicamente soberanía en la UE, añada un clúster nativo de OVHcloud al mismo conjunto. Los clústeres de OVHcloud Managed Kubernetes Service se registran en el mismo Rancher Manager que los clústeres importados y aprovisionados y disponen de las mismas funciones que estos: la misma interfaz, el mismo RBAC y los mismos flujos de GitOps. A diferencia de los clústeres alojados en nubes de terceros, OVHcloud gestiona íntegramente el plano de control de MKS. Es, por tanto, el único tipo de clúster de su infraestructura que no le exige asumir tareas operativas relacionadas con el plano de control, en la región de la UE que elija.
[object Object]
Incorporar a un nuevo ingeniero de plataformas se reduce a un único proceso de asignación de accesos, en lugar de seguir una lista de comprobación para cada clúster y nube. Además, las consultas al servicio de asistencia sobre quién puede acceder a cada recurso dejan de requerir largas investigaciones. Este único punto de control también simplifica las auditorías de cumplimiento normativo: desde un solo lugar puede demostrar quién tiene acceso a cada recurso y cuándo se concedió o revocó ese acceso.

Las actualizaciones de versión de Kubernetes se coordinan en todos los clústeres mediante parámetros configurables de capacidad adicional durante la actualización, en lugar de programar ventanas de mantenimiento manual independientes para cada clúster y nube. El aprovisionamiento, la actualización y la retirada de clústeres se gestionan desde la misma interfaz, las mismas API o los mismos recursos de Terraform. Así, el procedimiento operativo no cambia en función de la nube en la que se ejecute cada clúster, y puede consultar su estado sin cambiar de consola.

Rancher se integra con Prometheus y Grafana para gestionar grandes conjuntos de clústeres, con herramientas de monitorización y alertas homogéneas en todos ellos, en lugar de utilizar una solución de observabilidad distinta para cada nube. El almacenamiento de métricas y la agregación de registros se configuran del mismo modo en todos los clústeres. Además, se utilizan los mismos paneles de control, reglas de alerta y procedimientos de guardia tanto si la alerta procede de un clúster GKE como de uno RKE2 local o de un nodo MKS de OVHcloud. Así, los problemas de fiabilidad pueden abordarse de forma conjunta, sin tratarlos por separado en cada nube.
Incorporar a un nuevo ingeniero de plataformas se reduce a un único proceso de asignación de accesos, en lugar de seguir una lista de comprobación para cada clúster y nube. Además, las consultas al servicio de asistencia sobre quién puede acceder a cada recurso dejan de requerir largas investigaciones. Este único punto de control también simplifica las auditorías de cumplimiento normativo: desde un solo lugar puede demostrar quién tiene acceso a cada recurso y cuándo se concedió o revocó ese acceso.

Aplique de forma coherente las configuraciones aprobadas con Rancher Fleet

Conserve las definiciones de despliegue en Git

Defina las aplicaciones una única vez en un repositorio de Git, sin mantener un flujo de GitOps independiente por nube: la gestión se basa en cambios revisados y aprobados, no en modificaciones puntuales desde la consola.

Seleccione los grupos de clústeres adecuados

La sincronización de paquetes se dirige mediante selectores de etiquetas: por ejemplo, a todos los clústeres de producción de la UE o a todos los entornos de preproducción, independientemente de la nube, en lugar de desplegar los cambios en todos los clústeres a la vez.

Respete los límites operativos

La misma gobernanza se aplica tanto al aislamiento de las cargas de trabajo como a las políticas de los espacios de nombres, de modo que las mismas reglas se cumplen en todas partes, no solo en los clústeres que su equipo supervisa con mayor frecuencia.

Detecte y corrija las desviaciones

Fleet detecta de forma continua las diferencias entre la configuración declarada en Git y la configuración real, y las corrige automáticamente en todos los clústeres seleccionados, sin recurrir a herramientas específicas de cada nube.

Automatice todas las etapas del ciclo de vida de los clústeres

TerraformAPIInterfaz de usuario
Esta coherencia permite convertir la gestión del ciclo de vida de los clústeres, antes una tarea manual recurrente y propensa a errores, en un proceso automatizado y repetible que su equipo puede ejecutar siempre de la misma manera. Así se elimina un nivel de complejidad que, de otro modo, aumentaría linealmente con cada despliegue complejo en varias regiones, desde el desarrollo inicial hasta la puesta en producción, y su equipo puede gestionar todos los clústeres eficazmente sin que la plantilla tenga que crecer en la misma proporción.
[object Object]

Construya un modelo operativo basado en cuatro pilares

Operaciones de aplicaciones

Azure Arc es un producto de Microsoft diseñado para extender el plano de control de Azure a otros entornos. Google Anthos hace lo mismo con GCP, mientras que AWS EKS Anywhere se basa en las herramientas y las licencias de AWS. Todas son opciones sólidas si prevé concentrar sus clústeres en las regiones de un solo gran proveedor de nube. Sin embargo, cada una vincula el plano de gestión y, en cierta medida, los procesos operativos a un único proveedor, por lo que se centran en la nube y no en los clústeres. Rancher y, por extensión, MRS se diseñaron desde el principio para ser independientes del proveedor de nube: gestionan cualquier clúster conforme a los estándares de la CNCF con las mismas prestaciones, sin favorecer ninguna nube en el producto ni en su arquitectura.

Gobernanza adaptada a las funciones de cada usuario

Si ya utiliza Rancher en su propia infraestructura, el software subyacente es idéntico: MRS no lo sustituye por otro, sino que le libera de la carga operativa de administrarlo, y las prácticas recomendadas para gestionar el propio Manager pasan a ser responsabilidad de OVHcloud. La configuración de alta disponibilidad, el almacén de datos subyacente, la renovación de certificados y las versiones trimestrales de Rancher dejan de ser tareas pendientes de su equipo y pasan a estar a cargo de OVHcloud. Conserva la misma interfaz, las mismas API, todas las funcionalidades y el mismo catálogo de Fleet que ya conoce.

Para los equipos que estudian OpenShift Advanced Cluster Management como alternativa: ACM presupone el uso de clústeres de OpenShift o compatibles con OCP, mientras que Rancher gestiona cualquier distribución de Kubernetes conforme a la CNCF, con independencia del lugar en que se aprovisione, y sigue un modelo de precios distinto: OpenShift cobra licencias por núcleo, mientras que Rancher es de código abierto y el precio de MRS se calcula por clúster gestionado.

Monitorización y registros

Las mismas herramientas de Prometheus y Grafana, paneles de control, reglas de alerta y procedimientos de guardia se utilizan en todos los clústeres, tanto si la alerta procede de un clúster GKE como de uno RKE2 local o de un nodo MKS de OVHcloud. Así, las incidencias de fiabilidad se abordan de manera conjunta, no por separado para cada nube.

Soberanía y portabilidad

Rancher se distribuye bajo la licencia Apache 2.0, y las distribuciones RKE2 y k3s que permite aprovisionar son proyectos de la CNCF. MRS no utiliza una versión derivada propietaria ni añade una capa de gestión cerrada: ofrece el mismo Rancher Manager de código abierto, alojado y administrado por OVHcloud. Si en algún momento decide volver a gestionar Rancher en sus instalaciones, puede hacerlo alojando por su cuenta el mismo proyecto de código abierto, sin migrar a otra herramienta ni tener que modificar la configuración de los clústeres o la estructura de los flujos de GitOps.

Tanto Azure Arc como Google Anthos canalizan los datos de gestión de los clústeres —topología, RBAC y estado de las aplicaciones— a través de infraestructuras de Microsoft o Google ubicadas en Estados Unidos, por lo que esos datos quedan sujetos a la jurisdicción estadounidense, incluso aunque todos los nodos de trabajo se encuentren en un centro de datos o región de la UE. OVHcloud Managed Rancher Service aloja Rancher Manager en infraestructuras europeas, sin una empresa matriz estadounidense. De este modo, los datos de gestión de sus clústeres nunca pasan por un gran proveedor estadounidense de nube y, además, se reduce la dependencia de un único proveedor para las cargas de trabajo críticas. Así, las organizaciones de sectores regulados —sanidad, servicios financieros y sector público— disponen de una alternativa sometida a la jurisdicción de la UE sin renunciar a los clústeres que ya utilizan en otras infraestructuras.

Adopte una gobernanza centralizada sin migraciones que interrumpan sus operaciones

Gestionar clústeres multinube es una decisión arquitectónica, no una compra de autoservicio. El diseño adecuado del plano de control depende del número de nubes y centros de datos que utilice, los requisitos de cumplimiento normativo aplicables y la estructura de sus flujos de GitOps, controles de acceso y políticas de red actuales. A las organizaciones con operaciones complejas en varios clústeres les conviene analizar estos aspectos antes de elegir una arquitectura. Consulte a un arquitecto de soluciones de OVHcloud: recibirá asesoramiento gratuito durante 30 minutos y una recomendación arquitectónica específica para sus clústeres. 

Si desea comprobar antes si la solución se adapta a sus necesidades, cree un clúster de Kubernetes gratuito en OVHcloud. La modalidad MKS Free es gratuita, no exige tarjeta de crédito y está disponible en las 14 regiones, de modo que puede incorporar OVHcloud a sus clústeres actuales sin coste y comprobar cómo aparece en Rancher Manager junto a los demás clústeres. Este clúster se ejecuta dentro de su proyecto actual de OVHcloud Public Cloud, junto con cualquier otro recurso de Public Cloud que ya utilice su equipo, y se registra en Rancher Manager igual que los demás clústeres, con el mismo RBAC, las mismas funciones de Fleet GitOps y la misma monitorización. Para cargas de trabajo de producción, MKS Standard funciona en tres zonas de disponibilidad de París, con un SLA del 99,99 %. 

Para conocer mejor el papel de la gestión multiclúster dentro de las herramientas de contenedores de OVHcloud, el centro de orquestación de contenedores ofrece una visión completa, desde Managed Kubernetes para un solo clúster hasta la gestión de todos los clústeres con Rancher.
[object Object]
Evalúe un plano de control soberano para su infraestructura de Kubernetes
Descubra cómo OVHcloud Managed Rancher Service puede ayudarle a gestionar sus clústeres multinube y locales. Nuestros especialistas pueden analizar su arquitectura actual, sus prioridades de soberanía, su modelo de gobernanza y sus requisitos de incorporación de clústeres, y ayudarle a valorar si un plano de control gestionado encaja en sus necesidades. Presente su inventario de clústeres, sus limitaciones operativas y su modelo de responsabilidades previsto en una demostración centrada en sus necesidades.
Comenzar