For T341553, we can start up a MediaWiki pod managed as part of a Job (which runs to completion and then terminates) instead of a Deployment (which stays up and serves indefinitely).
At present, those pods never complete. A pod is only Complete when all its containers terminate, and MediaWiki pods have a number of containers in addition to the app: service mesh proxy, Prometheus exporter, mcrouter, etc. After the maintenance script completes, and the "main" app container terminates, those "sidecar" containers (and therefore the pod, and therefore the job) linger forever.
What we need is a way to express that only the app container should count, and the pod should be wrapped up even if sidecar containers are still running -- as long as they're the only containers still running. KEP 753 proposes to add that functionality, but as I write this, it just got approved for Beta targeting Kubernetes v1.29 (expected December 2023) so we can try it when we're upgraded to that point.
In the meantime, there's an open-source controller https://github.com/otherguy/k8s-controller-sidecars that does the same job: you give your pod a pod.kubernetes.io/sidecars annotation listing the sidecar containers, and this controller does the needful. (Long run, we might have an interesting time keeping that annotation up-to-date if new sidecars are added and removed, but we can think about that later.)
On a review (there's not that much code there) it looks like it does what it says on the tin, so we can give it a try in prod and see if it solves the job lifecycle problem. I'll template that annotation behind the same values flag that we're using to switch from Deployment to Job, so it won't have any effect on the normal MW deployment's lifecycle.