En este documento, se proporcionan recomendaciones para fragmentar el uso de Config Controller. La fragmentación es el proceso de dividir los recursos de Google Cloud administrados por el controlador de configuración en varios espacios de nombres, clústeres o proyectos.
La fragmentación ofrece los siguientes beneficios:
- Reduce el impacto de los cambios: Si un solo fragmento deja de funcionar, los demás fragmentos no se ven afectados.
- Te ayuda a administrar la seguridad: Cada fragmento puede tener configuraciones de IAM y RBAC específicas. Los atacantes maliciosos que vulneran un fragmento no pueden acceder a otros fragmentos. Una configuración incorrecta en un fragmento no puede afectar a otros fragmentos.
- Mejor escalabilidad: Un solo fragmento puede tener cuellos de botella de escalabilidad, como la cantidad de objetos administrados o las cuotas de la API. Tener varios fragmentos aumenta la escalabilidad general del uso de tu controlador de configuración.
Usa la fragmentación con el controlador de configuración
Existen varias formas de implementar la fragmentación. El mejor enfoque para ti dependerá de tus necesidades y requisitos específicos.
Fragmentación de modelos
Existen dos modelos de fragmentación principales:
- Por líneas de negocio o equipos de aplicaciones: Por lo general, este modelo se usa cuando diferentes equipos usan Config Controller. En este modelo, cada equipo tiene su propio fragmento.
- Por entorno: Por lo general, este modelo se usa cuando se usa Config Controller en diferentes entornos. Por ejemplo, puedes tener un fragmento para tu entorno de desarrollo, un fragmento para tu entorno de QA y un fragmento para tu entorno de producción.
Minimiza la necesidad de referencias entre fragmentos
Cuando fragmentes el uso de Config Controller, debes minimizar la necesidad de referencias entre fragmentos. Las referencias entre fragmentos pueden hacer que tu configuración sea más compleja y difícil de administrar. Consulta Referencia de recursos entre instancias para obtener más detalles.
Mecanismos de fragmentación
Existen tres mecanismos de fragmentación principales:
- Por espacio de nombres: Puedes crear espacios de nombres adicionales y configurar Config Connector para administrar recursos en esos espacios de nombres.
- Por instancias de Config Controller: Puedes crear varias instancias de Config Controller en un proyecto de Google Cloud.
- Por proyectos: Puedes crear varias instancias de Config Controller en varios proyectos de Google Cloud. Este mecanismo ayuda a abordar los problemas de cuota de la API si tienes cuellos de botella de cuota con un solo proyecto. Consulta Cómo dividir tus recursos en varios proyectos para obtener más detalles.
Advertencias a la hora de implementar la fragmentación
Cuando implementes el fragmentación para el uso de Config Controller, existen algunos posibles problemas que debes tener en cuenta y planificar para mitigarlos.
Referencias de recursos en varias instancias
Uno de los desafíos de la fragmentación del controlador de configuración es lidiar con las referencias de recursos entre instancias. Por ejemplo, un equipo de plataforma podría crear proyectos en una instancia y, luego, los equipos de apps podrían crear recursos que hagan referencia a esos proyectos en otras instancias. Esto puede generar problemas como los siguientes:
- Mayor complejidad: Administrar referencias de recursos en varios clústeres puede hacer que tu configuración sea más compleja y difícil de administrar.
- Mayor riesgo: Si se borra un recurso en un fragmento, los recursos de otros fragmentos aún pueden hacer referencia a él. Esto puede provocar comportamientos inesperados y pérdida de datos.
- Degradación del rendimiento: Las referencias de recursos entre clústeres pueden aumentar la latencia de los cambios de configuración.
Existen algunas formas de solucionar el problema de las referencias cruzadas:
- Fragmentar de manera tal que no se necesite ninguna referencia entre los fragmentos. Para esto, se podría usar la fragmentación por entornos o por equipos.
- Usar referencias externas. Esto significa que el objeto al que se hace referencia en realidad no es administrado por Config Controller. Esta puede ser una buena opción si el objeto no cambia con frecuencia.
- Tener el mismo objeto disponible en todos los fragmentos. Esta es una opción más compleja, pero puede ser la mejor si el objeto cambia con frecuencia.
Los objetos deben compartir la misma fuente de información para evitar conflictos de conciliación entre estos objetos en diferentes fragmentos. Debes establecer la política de prevención de conflictos en
none
para estos objetos.
Es importante considerar cuidadosamente las ventajas y desventajas de cada enfoque antes de elegir uno.
Cuotas de API
La fragmentación podría aumentar tus cuotas de API. Debes tener en cuenta esto y planificar según corresponda. Consulta Administra los límites de cuota de la API para conocer las prácticas recomendadas sobre cómo administrar los límites de cuota de la API.
¿Qué sigue?
- Obtén más información sobre la escalabilidad de Config Controller.