Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-19T03:53:50.593Z
Answers: 2021-06-19T03:53:50.593Z
Answers: mdaniel
Body: <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>
  
Tags: <kubernetes>
Title: Create and delete ingress for temporary containers
UserDisplayName: Vektor88
ThreadText: # 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
  
  
  ---
  
  