En los ejemplos de esta página, se muestran algunas situaciones hipotéticas en las que se ilustran algunos de los conceptos y las prácticas recomendadas de nuestras guías. Antes de leer esta guía, debes familiarizarte con los conceptos en Introducción a las flotas y Prácticas recomendadas y requisitos de las flotas.
Ejemplo 1: Flotas con recursos de producción, etapa de pruebas y desarrollo
En este primer ejemplo, hay cuatro clústeres. Dos clústeres son para la producción (en dos regiones para redundancia), otro es para la etapa de pruebas y las pruebas y el último es para el desarrollo. Un equipo de plataforma es propietario y administra todos los clústeres de manera central. En este ejemplo simple, hay dos servicios: frontend y backend. Sin embargo, las situaciones más complejas pueden tener una mayor cantidad de servicios y clústeres.
Enfoque 1: Flotas distintas para la producción, la etapa de pruebas y el desarrollo
Un enfoque posible a fin de aprovechar las flotas es crear flotas separadas para los recursos de producción, etapa de pruebas y desarrollo.
Para hacerlo, creamos tres proyectos host de flotas distintos y colocamos recursos en esos proyectos o, en el caso de nuestro clúster de desarrollo local, registramos el clúster en el proyecto example-dev. No tuvimos que abordar muchas inquietudes de la similitud de espacio de nombres y de servicio debido al nivel de detalle de este ejemplo, pero nos aseguramos de que los espacios de nombres de los clústeres prod-east y prod-west estén bien normalizados.
La ventaja de este enfoque es que tenemos un aislamiento sólido entre cada una de las flotas. La desventaja principal de este enfoque es que debemos administrar tres flotas diferentes, lo que hace más difícil alcanzar la coherencia entre la producción, la etapa de pruebas y el desarrollo. Para los equipos de desarrollo, es más difícil desarrollar con servicios en etapas de pruebas.
Enfoque 2: Una flota para todos los recursos
En este enfoque, creamos una flota única para todos los recursos.
Para hacer esto, podemos dejar los recursos en el proyecto example y crear la flota en ese proyecto. Podríamos haber separado los recursos de producción y de etapa de pruebas si los colocábamos en otros proyectos host de flota y aprovechábamos la VPC compartida, pero elegimos no hacerlo a fin de mantener la simpleza en este ejemplo.
En este enfoque, debemos asegurarnos de que nuestros espacios de nombres y servicios estén normalizados en toda la flota. Por ejemplo, cambiamos el nombre de nuestro frontend genérico a frontend-prod y frontend-staging en los clústeres de producción y etapa de pruebas, respectivamente. Por último, si bien podemos conservar los nombres originales de nuestros espacios de nombres de desarrollo, proporcionamos nombres más claros (como frontend-dev-alice) para indicar que son espacios de nombres de desarrollo.
Con este enfoque, intercambiamos el aislamiento para facilitar la administración. Dependemos de la autorización de la malla de servicios para evitar la comunicación no deseada entre servicios, pero podemos administrar con facilidad el sistema general con una flota única. Esta disposición nos permite aplicar políticas en todos los recursos, lo que da la confianza de que el desarrollo se ve y se siente muy parecido a la producción.
Enfoque 3: Flotas distintas para producción y no producción
En este enfoque, tomamos un punto intermedio en el que se combinan los recursos de etapa de pruebas y desarrollo en una flota de no producción y se coloca a la producción en una flota distinta.
Para hacerlo, creamos dos proyectos host de flota, uno destinado a producción y otro a no producción. También colocamos nuestros recursos directamente en esos proyectos, con el clúster local dev registrado en nuestra flota de no producción. Debemos normalizar los espacios de nombres y servicios entre nuestros recursos de etapa de pruebas y desarrollo para brindar mayor claridad. Por ejemplo, cambiamos el nombre de frontend por frontend-staging en el clúster de etapa de pruebas.
La ventaja es que la producción está bien aislada de la no producción. Por ejemplo, podemos habilitar los servicios de desarrollo para que se comuniquen con los servicios de etapa de pruebas, de modo que el frontend de la desarrolladora Alice pueda comunicarse con un backend en etapa de pruebas mientras ella desarrolla su servicio.
Resumen
Cada uno de los enfoques descritos en el Ejemplo 1 es válido. La elección que tu organización dependerá del aislamiento en comparación con la coherencia (y la facilidad de administración). En otras palabras, cuánto aislamiento se necesita entre los diferentes tipos de recursos en comparación con la cantidad de coherencia que se necesita entre ellos. Es más fácil lograr una mayor coherencia con menos cantidad de flotas. El tercer enfoque se ofrece como un equilibrio posible, lo que mantiene la producción aislada por completo, a la vez que los desarrolladores pueden trabajar con los servicios en etapa de pruebas.
Ejemplo 2: Flotas con distintos propietarios de recursos
Para este ejemplo, tenemos dos equipos: equipo A y equipo B. Estos equipos son propietarios y administran sus propios clústeres, y ambos usaron los espacios de nombres frontend y backend para los servicios que producen. Sin embargo, ni el frontend ni el backend del equipo A son los mismos que los de equipo B. Los dos equipos quieren crear una malla de servicios para que sus servicios puedan interactuar.
Sin que haya una intervención, no hay manera de que estos clústeres formen parte de la misma malla. Un buen punto de partida es transferir la propiedad de los clústeres a un equipo de plataforma central para establecer confianza entre ellos. De forma alternativa, si el equipo A y el equipo B confían entre sí, también pueden coordinarse para formar esta confianza.
El siguiente paso es normalizar el uso del espacio de nombres para que frontend y backend ya no se sobrecarguen en los clústeres de estos dos equipos. Una vez hecho esto, pueden establecer una flota única sobre todos los recursos y crear su malla de servicios.
Si no se puede establecer este nivel de confianza, el equipo A y el equipo B deben formar dos flotas separadas que usen dos proyectos host de flotas diferentes. La desventaja de este enfoque es que ahora deben aprovechar la federación de malla, que es más difícil de administrar que una sola malla. El beneficio es que ningún equipo necesita normalizar los espacios de nombres y los servicios implementados, y solo es posible la comunicación explícita y autorizada de forma específica.
