Kind pod not supported

[rchenzheng]

I have a pod created as follows which does not get restarted when the secret k8s-ext-secret changes.

---
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  annotations:
    secret.reloader.stakater.com/reload: "k8s-ext-secret"
spec:
  containers:
  - name: busybox
    image: busybox:glibc
    command:
      - sleep
      - "3600"
    env:
      - name: K8S_SECRET
        valueFrom:
          secretKeyRef:
            name: k8s-ext-secret
            key: kubernetes-secret

It'd be nice if reloader would also restart pods with the annotation

[tcolgate]

How would a pod be restarted? Updating the pod definition doesn't cause a restart. There's no mechanism to cause a pod to restart, only the decision to "restart" a container if it dies. There no mechanism (that I've seen), to kill a container. So you'd either need to support hitting a webhook on a container, or add a sidecar in the same process namespace that could kill/HUP it (or add support to kubelet). Pods that are standalone (not created by a replicaset/sts/job etc), are quite rare, and not of much practical use.

[andy-v-h]

How would a pod be restarted? Updating the pod definition doesn't cause a restart. There's no mechanism to cause a pod to restart, only the decision to "restart" a container if it dies. There no mechanism (that I've seen), to kill a container. So you'd either need to support hitting a webhook on a container, or add a sidecar in the same process namespace that could kill/HUP it (or add support to kubelet). Pods that are standalone (not created by a replicaset/sts/job etc), are quite rare, and not of much practical use.

This is a use case I'm hitting today while trying to work with an upstream helm chart. They don't (currently) support additional labels on the StatefulSet, only the pod. If Reloader would delete the pod, it would get recreated with the updated secret, so the mechanism does exist, it's somewhat clunky - i would agree with that sentiment.

[tcolgate]

That wouldn't work well in practice though. If you had a statefulset with more than one pod, you'd probably end up deleting ("restarting"), all the pod at once, which is almost never a good idea. In the case given, it'd be easier to fork/PR the helm chart.