https://github.com/vaticyai/syncpocalypse
This repository simulates a one-time database migration/backup: Pod stuck on CrashLoopBackoff and no body cares.
https://github.com/vaticyai/syncpocalypse
crashloopbackoff golang job k8s simulation
Last synced: about 1 year ago
JSON representation
This repository simulates a one-time database migration/backup: Pod stuck on CrashLoopBackoff and no body cares.
- Host: GitHub
- URL: https://github.com/vaticyai/syncpocalypse
- Owner: vaticyai
- Created: 2024-10-21T06:18:46.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-10-21T11:37:12.000Z (over 1 year ago)
- Last Synced: 2025-02-07T08:15:15.946Z (over 1 year ago)
- Topics: crashloopbackoff, golang, job, k8s, simulation
- Language: Go
- Homepage:
- Size: 11.7 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# `Pod` stuck on `CrashLoopBackoff` and no body cares
**Scenario:** One-Time Database Migration/Backup `Job`
Imagine you have a Kubernetes `Job` that performs a one-time database migration or backup.
The `Job` is supposed to copy data from a source to a destination
(e.g., migrate or backup database files to a persistent storage volume).
On its first run, the `Job` completes successfully,
migrating all the necessary data to the destination directory.
However, the next time the `Job` is triggered (intentionally or accidentally),
it finds that all files already exist in the destination directory (the same files are already backed up).
Now the `Job` cannot copy the files as they already exist,
it crashed.
Kubernetes tries to restart the `Job`, which leads to the `Pod` repeatedly crashing and entering the `CrashLoopBackOff` state.