How are processes spun up in Kubernetes, and why aren't they in a StatefulSet? #949
-
|
In #946 , it was asked: "Also it seems to me that each process is just spun up in a pod, instead of statefulset. This way the process can't be rescheduled into other pods, nor can it be 'retrieved' after its been killed easily." |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Some brief history: Kurtosis started as an ephemeral environment testing tool in CI, with the lifetime of enclaves and services being measured in minutes. In that world, persistence wasn't a problem - it was very unlikely that a Pod would die for any reason other than a problem with the user's code, and the only thing that mattered from the Pod was the logs which were retrievable via However, Kurtosis has since expanded to use in dev/prototyping and prod-like usecases that require long-lived, persistent environments. In these cases, Pod data persistence and rescheduling Pods that have gone down is much more important due to the long-lived nature, so we're working to upgrade Kurtosis to be able to handle these cases. Concretely, this is probably going to look like:
|
Beta Was this translation helpful? Give feedback.
Some brief history: Kurtosis started as an ephemeral environment testing tool in CI, with the lifetime of enclaves and services being measured in minutes. In that world, persistence wasn't a problem - it was very unlikely that a Pod would die for any reason other than a problem with the user's code, and the only thing that mattered from the Pod was the logs which were retrievable via
kurtosis service logsorkurtosis enclave dump(more history here).However, Kurtosis has since expanded to use in dev/prototyping and prod-like usecases that require long-lived, persistent environments. In these cases, Pod data persistence and rescheduling Pods that have gone down is much more important due …