<p>In Kubernetes I have a Deployment that uses a secret and injects them as environment variables:</p>

<pre><code>apiVersion: apps/v1
kind: Deployment
...
envFrom:
  - secretRef:
    name: api-env
</code></pre>

<p>I need to update some of the environment variables, so I deleted the secret <code>api-env</code> and created it again with the updated values.</p>

<p>How do I trigger the deployment to update itself with the new env secrets without any downtime?</p>

Justin
<p>I see a few alternatives, in order of viability:</p>

<ol>
<li>For k8s' versions >v1.15: <code>kubectl rollout restart deployment $deploymentname</code>: this will
restart pods incrementally without causing downtime. </li>
<li><p>For older versions: Updating the deployment template will trigger a rollout. From <a href="https://github.com/kubernetes/kubernetes/issues/13488#issuecomment-356892053" rel="noreferrer">this issue</a>: <code>kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'</code></p></li>
<li><p>Mount secrets on volumes instead of as environment variables, as <a href="http://kubernetes.io/docs/user-guide/secrets/#using-secrets-as-files-from-a-pod" rel="noreferrer">Mounted Secrets are
updated automatically</a></p></li>
<li><a href="https://github.com/kubernetes/kubernetes/issues/22368" rel="noreferrer">One approach</a> is to consider the Secret/Configmap as immutable and when creating a new one changing the deployment to point to it.</li>
<li>Program your application to watch for changes in the <a href="https://docs.openshift.com/container-platform/3.9/rest_api/api/v1.Secret.html#Get-api-v1-watch-namespaces-namespace-secrets-name" rel="noreferrer">Secrets API</a>.</li>
</ol>
