Il modo migliore per eseguire attività di migrazione una tantum in un cluster di Kubernetes

Question

Ho migrazioni di database che vorrei eseguire prima di distribuire una nuova versione della mia app in un cluster Kubernetes. Voglio che queste migrazioni vengano eseguite automaticamente come parte di una pipeline di fornitura continua. La migrazione verrà incapsulata come immagine del contenitore. Qual è il miglior meccanismo per raggiungere questo obiettivo?

Requisiti per una soluzione:

• essere in grado di determinare se un errore si è verificato in modo che non ci successivamente tenta di distribuire una nuova versione dell'app nel cluster.
• rinunciare se una migrazione non riesce - non continuare a riprovare.
• accedere ai registri per diagnosticare le migrazioni non riuscite.

ho dato per scontato che la funzionalità di Lavoro in kubernetes renderebbe questo facile, ma ci sembra essere un paio di sfide:

• kubernetes volontà repeatedly re-run containers whose processes terminate with a non-zero exit code, anche se il lavoro ha una restartPolicy di never.
• blocco in attesa del risultato di un lavoro in coda-up sembra richiedere script arrotolate a mano

Sarebbe utilizzando "baccelli nude" essere un approccio migliore? Se è così, come potrebbe funzionare?

Answer 1

Si potrebbe provare a fare entrambi i lavori di migrazione e di app indipendenti l'uno dall'altro nel modo seguente:

• Avere il ritorno processo di migrazione con successo anche quando la migrazione non è riuscita. Tenere un record di consumo della macchina da qualche parte di ciò che è stato il risultato della migrazione. Questo può essere fatto esplicitamente (scrivendo, ad esempio, la versione più recente dello schema in qualche campo della tabella del database) o implicitamente (assumendo, ad esempio, che sia stato creato un campo specifico durante un processo di migrazione riuscito). Il processo di migrazione restituirà un codice di errore solo se non è riuscito per motivi tecnici (a causa della mancata disponibilità del database a cui deve essere applicata la migrazione). In questo modo, puoi eseguire le migrazioni tramite Kubernetes Jobs e affidarti alla sua capacità di correre fino al completamento.
• Creata la nuova versione dell'app in modo che possa funzionare con il database sia in fase di pre e post migrazione. Ciò significa che dipende dai requisiti aziendali: l'app può diventare inattiva fino al completamento della migrazione oppure può restituire risultati diversi ai client in base alla fase corrente. Il punto chiave qui è che l'app elabora il risultato della migrazione che i lavori di migrazione hanno prodotto in precedenza e agisce di conseguenza senza terminare erroneamente.

Combinando questi due approcci di progettazione, si dovrebbe essere in grado di sviluppare ed eseguire i lavori di migrazione e l'app indipendentemente l'uno dall'altro e non è necessario introdurre alcun accoppiamento temporale.

Se questa idea è davvero ragionevole da implementare dipende da dettagli più specifici del tuo caso, come la complessità degli sforzi di migrazione del database. L'alternativa, come hai detto, consiste nel distribuire semplicemente i pod non gestiti nel cluster che esegue la migrazione. Ciò richiede un po 'più di cablaggio in quanto sarà necessario controllare regolarmente il risultato e distinguere tra esiti positivi e non riusciti.