<blockquote>
<p>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?</p>
</blockquote>
<p>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:</p>
<h2>Helm</h2>
<p><em>This part I have done, extensively, and works as advertised</em></p>
<p>The way most people manage groups of related resources is via <a href="https://helm.sh" rel="nofollow noreferrer">helm</a>, which in your case would create the <code>Job</code> as well as the <code>Ingress</code> 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 <a href="https://helm.sh/docs/helm/helm_uninstall/" rel="nofollow noreferrer"><code>helm uninstall</code></a> which will delete the <code>Job</code> and its associated <code>Ingress</code>.</p>
<p>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 &quot;best&quot; way for that</p>
<h2>Admission Controller</h2>
<p><em>this section is speculation, as I have not personally worked with this part</em></p>
<p>Kubernetes offers <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/" rel="nofollow noreferrer">dynamic admission controllers</a> which are <em>intended</em> 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 &quot;Allow&quot; from the validating admission controller</p>

CC BY-SA 4.0
2021-06-19T03:53:50.593Z
2021-06-19T03:53:50.593Z
mdaniel
<p>(I have just stared learning kubernetes, so apologies if my question sounds silly)</p>
<p>In my cluster I am running some pods that execute some batch operations and expose a webUI to keep track of the overall progress.</p>
<p>To access the webUI I am currently using a port-forward, but I was wondering</p>
<p>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?</p>

<kubernetes>
Create and delete ingress for temporary containers
Vektor88
# Create and delete ingress for temporary containers

(Asked by: username_0 on 2021-06-17)

(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?

**Tags:** kubernetes


---

## 1 answers

### Answer by username_1 on 2021-06-19. Score: 1

> 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:

## Helm

*This part I have done, extensively, and works as advertised*

The way most people manage groups of related resources is via [helm](https://helm.sh), 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`](https://helm.sh/docs/helm/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

## Admission Controller

*this section is speculation, as I have not personally worked with this part*

Kubernetes offers [dynamic admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-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


---

