New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init-container #12
Comments
Sure, i think entrypoint should first check if it is inside init-container, if so exit(0). Otherwise exit(1). |
Until this feature is not implemented. Please use COMMAND="echo Done". |
Dear @PiotrProkop, |
…s#12) Signed-off-by: DTadrzak <daniel.tadrzak@intel.com>
Trivial fix according to discussion about init-containers (#12)
Merged. |
Closing due to #13 . |
I'd like to use kubernetes-entrypoint in a k8s init-container instead of embededing it in directly into each regular container. This allows unmodified containers to be used, and also allows you to restrict k8s service tokens to just the init container, enhancing security.
I think this would work well, but the current implementation in kubernetes-entrypoint.go looks to fail if command is empty:
if comm = env.SplitEnvToList("COMMAND", " "); len(comm) == 0 {
logger.Error.Printf("COMMAND env is empty")
os.Exit(1)
}
Can a feature be added to allow it to simply os.Exit(0) after deps are resolved when set so it can be used as an init-container?
The text was updated successfully, but these errors were encountered: