logging-operator VS kubexit

Learn about how the Logging operator (CNCF Sandbox project) enables multi-tenant scenarios:

Banzai moved it out into a dedicated kube-logging organization on Github, at https://github.com/kube-logging/logging-operator 4.0 released a few weeks ago.

Shameless plug, I recommend you give a shot to https://github.com/banzaicloud/logging-operator - I am one of the maintainers.

Logging Operator Helm Chart - https://github.com/banzaicloud/logging-operator

There is even whole projects setup to solve the horrible nature that is efk / elk. See https://github.com/banzaicloud/logging-operator

How does this compare to/differ from the Banzai Logging operator?

- How to run ? Kubernetes has design flaws - common stuff like kubexit or secrets/configmap reloaders, are nowhere to be documented. HPA+Keda is not a complete answer to horizontal scaling, and Knative KPA has some downsides regarding it's obsolete observability stack... VPA recommender mode can do a lot of weird things, and should be wrapped up in a separate controller.

I use a normal container together with a graveyard lifecycle strategy similar to https://github.com/karlkfi/kubexit but a simple custom setup instead. I do this because I have to terminate a cloudsql proxy sidecar after the migration is run. Essentially its just a script that adds a lifecycle-terminated file to a shared volume which when added, a trap command activates to let the sidecar kill itself and the job completes.

At my last place we used https://github.com/karlkfi/kubexit, so the sidecar process would exit when the main process did