search

openanalytics / shinyproxy

ShinyProxy - Open Source Enterprise Deployment for Shiny and data science apps
https://www.shinyproxy.io
Apache License 2.0
514 stars 152 forks source link

orphan pods #484

Open fcomte opened 5 months ago

fcomte commented 5 months ago

Hello,

I notice that some user pod can become orphan.

onyxia@rstudio-479106-0:~/work/pocapp-helm-chart$ helm uninstall portail-shiny 
release "portail-shiny" uninstalled
onyxia@rstudio-479106-0:~/work/pocapp-helm-chart$ kubectl get pods
NAME                                          READY   STATUS    RESTARTS   AGE
rstudio-479106-0                              1/1     Running   0          3d
sp-pod-31203b5c-a93b-4791-9219-e5ba80e65a8a   1/1     Running   0          13m
sp-pod-8139198a-c4c3-4b32-87bd-3b4da69c472a   1/1     Running   0          3d
sp-pod-8d67aa39-35af-40c5-a7da-c5f9fd0fbbbb   1/1     Running   0          8d
sp-pod-c36df99b-6c95-4fd2-91e9-892524daf6c3   1/1     Running   0          3d1h
sp-pod-e3efc308-2e13-48a3-be3e-fdcc0a2d1453   1/1     Running   0          41s
sp-pod-f353365e-36cb-4e86-a10c-1008cd6e4510   1/1     Running   0          7d1h

I wonder why shiny proxy does not use the medatada ownerReference for each sp-pod in kubernetes. It would say to kubernetes that those pods must be garbage collected when the shinyproxy pod is deleted.

RespiceFinem commented 3 months ago

I'm running into this same problem locally and in production; when shinyproxy pulls a new image, the shiny apps that were managed by the old instance are orphaned, and have to be manually stopped and deleted.

It's cerntainly possible that I'm missing some configuration, but shouldn't these containers be reacting to the missing parent?

LEDfan commented 3 months ago

Hi, if you are using Kubernetes and you want smooth updates of the ShinyProxy config, we advice to use the shinyproxy operator: https://github.com/openanalytics/shinyproxy-operator . This fully manages updating the configuration, by starting new instances and stopping old instances, without breaking existing apps or connections.

Since the operator needs full control over the pods, we currently don't add the ownerReference. We could change this in the future (but make sure k8s doesn't remove the pods), but it might cause weird behavior with pods created in different namespaces.