En esta página se explica cómo usar Config Controller de la mejor forma posible al operar servicios de alta disponibilidad o gestionar recursos en varias regiones. Google Cloud
Esta página está dirigida a administradores, arquitectos y operadores que gestionan 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 habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.
Config Controller se ejecuta en una sola región, por lo que puede tolerar el fallo de una zona de disponibilidad, pero si falla toda una región, Config Controller pierde la disponibilidad. Hay dos estrategias diferentes para hacer frente a los fallos regionales, y tu elección depende de lo que harías si falla una región:
Si quieres hacer cambios en la configuración en respuesta a un fallo regional, crea una segunda instancia de Config Controller.
Si no vas a hacer cambios en la configuración, usa una sola instancia de Config Controller.
Entender los casos de error
Config Controller usa un clúster de GKE regional. Aunque el clúster regional puede tolerar el fallo de una sola zona de una región, el clúster deja de estar disponible si fallan varias zonas de la región.
Si falla tu instancia de Config Controller, tus recursos Google Cloud se mantendrán en su estado actual. Sin embargo, aunque tus aplicaciones sigan ejecutándose, no podrás cambiar su configuración cuando Config Controller no esté disponible. Esto se aplica a los recursos de la misma región y a los recursos de otras regiones que estés gestionando desde Config Controller en la región no disponible.
Como no puedes volver a configurar los recursos de la misma región, si un fallo regional afecta a los recursos de la región de Config Controller, no podrás repararlos. Google Cloud
Como tampoco puedes reconfigurar los recursos de otras regiones, un fallo en una región ha afectado a tu capacidad para hacer cambios en otra.
También pueden darse otros casos de fallo. Por ejemplo, si configuras Config Sync para extraer datos de un proveedor de Git externo, debes tener en cuenta los modos de fallo de ese proveedor de Git. Es posible que no puedas hacer cambios en la configuración porque no puedes enviar cambios a ese proveedor de Git. O bien, si Config Sync no puede leer de Git, los cambios de Git no se aplican al clúster y, por lo tanto, Config Connector no los aplica. Sin embargo, el fallo regional suele ser el escenario más importante, ya que otros escenarios de fallo no suelen estar correlacionados con el fallo del controlador de configuración.
Usar un solo clúster para la disponibilidad regional
En muchos casos, no tendrás que realizar ninguna reconfiguración si falla una región. En ese caso, puedes aceptar que un fallo regional provoque que tu plano de control de configuración no esté disponible.
Por ejemplo, si solo operas en una región, es posible que no puedas hacer ninguna reconfiguración útil si esa región falla. Del mismo modo, si tienes una base de datos con un único punto de fallo en una sola región, es posible que no puedas recuperarla hasta que se recupere esa región. En el caso de las aplicaciones que no necesitan la disponibilidad más alta, esta situación puede ser una solución razonable en comparación con el coste y la complejidad.
Si la instancia de Config Controller se encuentra en la misma región, el destino es compartido: Config Controller estará disponible mientras lo esté tu región principal. También puede ser una buena opción ubicar la instancia de Config Controller en una región diferente. Aunque ahora tienes que pensar en posibles fallos en dos regiones, evitas el fallo correlacionado de tu plano de control de configuración con el fallo de tu región principal.
Por otro lado, si tienes una configuración redundante multirregional, es posible que tu sistema se desvíe automáticamente de las regiones con errores. En este caso, tampoco te interesará hacer una reconfiguración si falla una región. En este caso, puedes elegir una sola instancia de Config Controller.
Conmutar por error manualmente a una segunda instancia de Config Controller
Si una región falla, puede que quieras hacer alguna reconfiguración para solucionar el problema. También puedes seguir configurando recursos en otras regiones, aunque tu instancia de Config Controller se encuentre en una región con errores. En este caso, te recomendamos que uses una segunda instancia de Config Controller en otra región.
Aunque no se recomienda, se pueden ejecutar dos instancias de Config Controller con configuraciones idénticas. Ambas instancias compiten para leer del mismo repositorio de Git y aplicar los mismos cambios a Google Cloud. Sin embargo, hay muchos casos límite que hacen que esta configuración no sea fiable. Las dos instancias de Config Controller observan el repositorio de Git en momentos ligeramente diferentes, por lo que pueden intentar aplicar versiones ligeramente diferentes de tu configuración de Google Cloud . Varios escritores activos para Google Cloud aumentar las probabilidades de que alcances las cuotas o los límites de frecuencia. Un pequeño número de recursos de Config Connector tampoco son idempotentes y requieren más atención, como se explica en el resto de esta sección. Por lo tanto, no recomendamos tener dos clústeres de Config Controller que estén reconciliando activamente.
En su lugar, te recomendamos que, si falla la región en la que se ejecuta tu Config Controller, ejecutes otro Config Controller en una segunda región. La nueva instancia de Config Controller debe configurarse de forma idéntica a la primera, leyendo del mismo repositorio de Git. En este caso, puede ser útil preparar una secuencia de comandos para mostrar y configurar tu instancia de Config Controller. Cuando creas tu nueva instancia de Config Controller, Config Sync lee y aplica el estado deseado de Git a Kubernetes. Config Connector sincroniza el estado deseado con Google Cloud.
En esta situación, hay dos cosas que debes tener en cuenta:
Si el primer clúster de Config Controller sigue en ejecución o empieza a ejecutarse cuando se recupera la primera región, puede que intente aplicar el estado antiguo a Google Cloud. Si puedes detener el clúster de Config Controller de la primera región antes de iniciar un segundo clúster de Config Controller, puedes evitar este posible conflicto.
No todos los recursos de Config Connector se pueden volver a aplicar sin problemas desde Git. Para ver la lista de recursos que requieren un tratamiento especial, consulta Recursos con restricciones de adquisición. En concreto, recomendamos tener cuidado con los recursos de
Foldery evitar los recursos deIAMServiceAccountKey(por ejemplo, usar la federación de identidades de carga de trabajo de GKE para GKE).
Una instancia de Config Controller por región
Si quieres evitar que una instancia de Config Controller de una región afecte a otra, también puedes ejecutar una instancia de Config Controller por región, donde cada instancia de Config Controller gestione los recursos de esa región.
Esta configuración funciona, pero no es una de las opciones que recomendamos por los siguientes motivos:
Algunos recursos abarcan varias regiones (como Cloud DNS), por lo que esta estrategia es limitada.
Por lo general, si tienes un clúster de Config Controller en la misma región, se produce el problema de fallo correlacionado: quieres reconfigurar los recursos exactamente cuando un fallo regional afecte a Config Controller en esa región.
Tienes que dividir los recursos de Config Connector por región.
Config Controller no está disponible en todas las regiones.
Configurar recursos Google Cloud directamente
En circunstancias excepcionales, puedes hacer cambios directamente en los Google Cloud recursos subyacentes sin pasar por Git ni Config Connector. Config Connector intenta corregir cualquier "desviación", por lo que, si tu instancia de Config Controller sigue en ejecución, Config Connector considera que cualquier cambio que hagas manualmente es una "desviación" e intenta deshacerlo.
Sin embargo, si detienes tu instancia de Config Controller o si la región está sin conexión, esta puede ser una medida provisional útil.
Cuando se recupere tu instancia de Config Controller, es probable que Config Connector intente deshacer los cambios manuales. Para evitarlo, puedes hacer los cambios correspondientes en Git por cada cambio que hagas manualmente.