DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
(I have just stared learning kubernetes, so apologies if my question sounds silly)
In my cluster I am running some pods that execute some batch operations and expose a webUI to keep track of the overall progress.
To access the webUI I am currently using a port-forward, but I was wondering
Is there any way to get a disposable ingress that is tied to the container lifecycle, in such a way that it is automatically created when the pod is started, and deleted whenever the pod terminates?
Is there any way to get a disposable ingress that is tied to the container lifecycle, in such a way that it is automatically created when the pod is started, and deleted whenever the pod terminates?
Is there a way? Absolutely, but be aware that's for sure not how kubernetes thinks about the world, so you are going to be fighting uphill trying to maintain a system like that. With that said:
This part I have done, extensively, and works as advertised
The way most people manage groups of related resources is via helm, which in your case would create the Job as well as the Ingress resource for it. When the Job has finished (a process that helm, itself, does not meddle in), you can remove all grouped resources in one shot via helm uninstall which will delete the Job and its associated Ingress.
I believe it may be possible to hook the Job completion events with other machinery, but since this part is confined to things I have actively done, I wouldn't want to speculate on the "best" way for that
this section is speculation, as I have not personally worked with this part
Kubernetes offers dynamic admission controllers which are intended to allow one to have very complicated rules about what workloads one allows in their cluster, but has the pleasing side-effect of being consulted before Pod creation (and I can only presume deletion) takes place. That enables you to run arbitrary code in response to those webhook events, and then just return "Allow" from the validating admission controller
