Reconstruir GKE sin reemitir certificados
Un ensayo de reconstrucción real expuso fallas que la revisión de código no detectó y luego permitió reconstruir tres clusters sin consumir la cuota de emisión de certificados.
El ensayo adoptó 49 de 49 certificados sin reemitir. Es una prueba de recuperación, no un SLA de tiempo de recuperación en producción.
Contribución de un vistazo
- Mi responsabilidad
- Ensayo de reconstrucción, reparaciones de bootstrap/teardown y verificaciones de recuperación de certificados y GitOps.
- Alcance
- Un ensayo completo seguido de su reutilización para reconstruir tres entornos durante la renumeración de la red.
- Colaboración y límites
- Fui responsable del procedimiento de infraestructura y su validación; la recuperación de las aplicaciones se verificó a través del estado de GitOps.
- Resultado
- El ensayo adoptó 49/49 certificados TLS sin ninguna reemisión y restauró 35 aplicaciones de ArgoCD.
El problema
Rangos de red superpuestos impedían la conectividad privada entre una plataforma más nueva y los servicios heredados. Algunos rangos de direcciones de GKE son inmutables, por lo que el cambio exigía reconstruir los clusters. Una reconstrucción que reemitiera en silencio cada certificado TLS podía agotar una cuota de emisión semanal compartida antes de que la plataforma estuviera saludable.
Mi contribución
Ejecuté un ensayo de reconstrucción destructivo en un entorno aislado, corregí fallas en los scripts de bootstrap y teardown, y verifiqué la adopción de certificados, las direcciones reservadas del balanceador de carga y la recuperación de GitOps. Luego usé ese proceso para reconstruir tres entornos como parte de la renumeración de la red.
El orden de la recuperación importa
Restauré los Secrets de TLS antes de recrear los recursos Certificate. Eso permitió que cert-manager adoptara los certificados existentes en lugar de solicitar reemplazos. Las direcciones externas reservadas se preservaron de forma independiente de la subred antigua, de modo que reemplazar el cluster no exigió cambiar los registros DNS asociados.
Ejecutar el proceso expuso defectos que una revisión estática no había detectado: una guarda rechazaba el estado creado por el paso anterior, la ausencia de ciertos resource kinds rompía una eliminación que de otro modo sería idempotente, y eliminar External Secrets Operator antes de que sus finalizers terminaran podía provocar un deadlock en el teardown. Corregí el orden del ciclo de vida y verifiqué el estado resultante del cluster.
Resultados y medición
El ensayo reportó 49 certificados encontrados, 49 adoptados, cero reemitidos y ninguno quedó sin estar listo. Pasaron a Ready en unos 20 segundos; ese es el tiempo hasta quedar Ready del certificado, no la duración de la reconstrucción completa. La cuota de emisión de certificados se mantuvo en el mismo valor antes y después. La identidad del node cambió, lo que confirma que se trataba de un cluster nuevo y no de un reinicio del antiguo.
Posteriormente, el método permitió reconstruir tres clusters durante la renumeración de la red sin consumir cuota de emisión adicional. Luego se activó el peering privado y se comprobó con una prueba de conectividad de antes/después. Esto no establece un RTO de producción ni una garantía de recuperación ante desastres para toda la empresa.
Lo que repetiría
Un plan de recuperación se vuelve creíble cuando sus pasos destructivos se han ejecutado de verdad. Preserva los recursos que portan la identidad, pon a prueba el orden de restauración y valida las aplicaciones recuperadas antes de dar por reconstruida la plataforma.
Trabajo relacionado: la base de Terraform y Shared VPC y la migración escalonada de workloads.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Reemitir certificados es más sencillo que restaurarlos, pero pone en riesgo las cuotas de emisión. Restaurar primero el estado de TLS permite que el controlador adopte la identidad existente.
Contrapartida
Un ensayo demuestra la ruta de recuperación probada; no establece un SLA de tiempo de recuperación en producción.
Lo que mejoraría a continuación
Próxima mejora: programar ensayos repetidos, registrar los tiempos de recuperación y probar la recuperación cuando falte una de las dependencias preservadas.