En esta página, se muestra cómo usar el controlador de configuración de la mejor manera cuando se operan servicios con alta disponibilidad o se administran recursos en varias regiones de Google Cloud.
Esta página está destinada a administradores, arquitectos y operadores que administran el ciclo de vida de la infraestructura tecnológica subyacente y planifican la capacidad y las necesidades de infraestructura. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE Enterprise.
El controlador de configuración se ejecuta en una sola región, por lo que puede tolerar la falla de una zona de disponibilidad, pero no estará disponible si toda una región falla. Existen dos estrategias diferentes para lidiar con la falla regional, y tu elección depende de lo que harías si una región falla:
Si modificarías la configuración en respuesta a una falla regional, crea una segunda instancia del controlador de configuración.
Si no realizarías cambios de configuración, usa una sola instancia del controlador de configuración.
Comprende las situaciones de las fallas
El controlador de configuración usa un clúster de GKE regional. Aunque el clúster regional puede tolerar la falla de una sola zona en una región, deja de estar disponible si fallan varias zonas en la región.
Si tu instancia de Config Controler falla, tus recursos existentes de Google Cloud permanecerán en su estado actual. Sin embargo, aunque tus aplicaciones aún están en ejecución, no puedes cambiar su configuración si el controlador de configuración no está disponible. Esto se aplica a los recursos en la misma región y a los recursos en otras regiones que administras desde el controlador de configuración en la región no disponible.
Debido a que no puedes volver a configurar los recursos en la misma región, si una falla regional afecta los recursos existentes de Google Cloud en la región del controlador de configuración, no podrás reparar esos recursos.
Además, debido a que no puedes volver a configurar los recursos en otras regiones, una falla en una región ahora ha afectado tu capacidad de realizar cambios en otra región.
También son posibles otras situaciones de falla. Por ejemplo, si configuras el Sincronizador de configuración para que extraiga de un proveedor de Git externo, debes considerar los modos de falla de ese proveedor de Git. Es posible que no puedas realizar cambios de configuración porque no puedes enviar cambios a ese proveedor de Git. O bien, si el Sincronizador de configuración no puede leer desde Git, entonces los cambios de Git no se aplican al clúster, por lo que Config Connector no los aplica. Sin embargo, la falla regional suele ser la situación de falla más importante, ya que otras situaciones de falla no suelen estar relacionadas con la falla del controlador de configuración.
Usa un solo clúster para la disponibilidad regional
En muchas situaciones, no realizarías ninguna reconfiguración si una región falla. En ese caso, podrías aceptar que una falla regional anule la disponibilidad del plano de control de la configuración.
Por ejemplo, si operas en una sola región, es posible que no haya ninguna reconfiguración útil que puedas aplicar si falla esa región. Del mismo modo, si tienes una base de datos de un punto único de fallo en una sola región, es posible que no puedas recuperarte hasta que esa región se recupere. En el caso de las aplicaciones que no necesitan la más alta disponibilidad, esta situación puede ser una compensación razonable para el costo y la complejidad.
Ubicar la instancia del controlador de configuración en la misma región hace que tengan el mismo destino: el controlador de configuración está disponible siempre que tu región principal esté disponible. Ubicar la instancia de Config Connector en una región diferente también puede ser una buena opción. Aunque ahora debes pensar en posibles fallas en dos regiones, evitas la falla correlacionada del plano de control de configuración con la falla de la región principal.
De forma alternativa, si tienes una configuración multirregional redundante, tu sistema puede alejarse automáticamente de las regiones con errores. Aquí también es posible que no quieras volver a configurar si una región falla. En este caso, puedes elegir una sola instancia del controlador de configuración.
Conmutación por error manual a una segunda instancia del controlador de configuración
Te recomendamos realizar una reconfiguración si una región falla para poder solucionar el error. También puedes continuar con la configuración de recursos en otras regiones, incluso si tu instancia del controlador de configuración se encuentra en una región con errores. En este caso, recomendamos usar una segunda instancia del controlador de configuración en una segunda región.
Aunque no se recomienda, dos instancias de Config Connector pueden ejecutarse con opciones de configuración idénticas. Ambas competirán por leer desde el mismo repositorio de Git y aplicar los mismos cambios a Google Cloud. Sin embargo, varios casos extremos hacen que esta configuración no sea confiable. Las dos instancias de controlador de configuración observarán el repositorio de Git en momentos un poco diferentes. podrían intentar aplicar versiones ligeramente diferentes de tu configuración de Google Cloud. Si hay varios escritores activos en Google Cloud, es más probable que encuentres cuotas o límites de frecuencia. Una pequeña cantidad de recursos del Config Connector también no es idempotente y necesita especial atención como se explica a continuación. Por lo tanto, recomendamos no tener dos clústeres del controlador de configuración conciliando de forma activa.
En cambio, recomendamos que, si la región que ejecuta el controlador de configuración falla, ejecutes otra instancia de este en una segunda región. La instancia nueva de Config Connector debe configurarse de forma idéntica a la primera, que lea desde el mismo repositorio de Git. Preparar una secuencia de comandos para abrir y configurar la instancia del controlador de configuración puede ser útil en este caso. Cuando creas la instancia nueva del controlador de configuración, el Sincronizador de configuración lee y aplica el estado deseado de Git a Kubernetes; Config Connector sincroniza el estado deseado con Google Cloud.
Debes tener en cuenta dos aspectos en esta situación:
Si el primer clúster del controlador de configuración sigue en ejecución o comienza a ejecutarse cuando se recupera la primera región, es posible que intente aplicar el estado anterior a Google Cloud. Si puedes detener el clúster de Config Connector en la primera región antes de iniciar un segundo clúster de Config Connector, puedes evitar este conflicto potencial.
No todos los recursos de Config Connector se pueden volver a aplicar sin problemas desde Git. Para obtener la lista de recursos que necesitan un cuidado especial, consulta recursos con restricciones para la adquisición. En particular, recomendamos tener cuidado con los recursos
Foldery evitar los recursosIAMServiceAccountKey(por ejemplo, mejor usa la federación de identidades para cargas de trabajo de GKE).
Una instancia de controlador de configuración por región
Si deseas evitar una instancia del controlador de configuración en una región que afecta a otra región, también puedes considerar ejecutar una instancia de Config Connector por región, en la que cada instancia de Config Connector administra los recursos en esa región.
Esta configuración es viable, pero no es una de nuestras opciones recomendadas por los siguientes motivos:
Algunos recursos abarcan varias regiones (como Cloud DNS), lo que hace que esta estrategia sea limitada.
Por lo general, tener un clúster del controlador de configuración en la misma región afecta el problema de falla correlacionada: debes volver a configurar los recursos con exactitud cuando una falla regional afecta al controlador de configuración en esa región.
Tendrás que dividir tus recursos de Config Connector por región.
Por el momento, Config Connector no está disponible en todas las regiones.
Configura recursos de Google Cloud directamente
En circunstancias excepcionales, puedes realizar cambios directamente en los recursos subyacentes de Google Cloud, sin pasar por Git o Config Connector. Config Connector intenta solucionar cualquier “desvío”, por lo que si la instancia del controlador de configuración aún se está ejecutando, Config Connector considera que los cambios que realizas de forma manual son “desvíos” y trata de revertirlos.
Sin embargo, si detienes la instancia dConfig Connector o si la región está sin conexión, esta puede ser una medida útil para la brecha.
Cuando tu instancia del controlador de configuración se recupera, es probable que Config Connector intente revertir los cambios manuales. A fin de evitar esta situación, puedes realizar los cambios correspondientes en Git para cualquier modificación que realices de forma manual.