<p>I'v got microservices deployed on GKE, with Helm v3; all apps/helms stood nicely for months, but yesterday for some reason pods were re-created</p>
<pre class="lang-sh prettyprint-override"><code>kubectl get pods -l app=myapp  

NAME                     READY   STATUS    RESTARTS   AGE
myapp-75cb966746-grjkj   1/1     Running   1          14h
myapp-75cb966746-gz7g7   1/1     Running   0          14h
myapp-75cb966746-nmzzx   1/1     Running   1          14h
</code></pre>
<p>the <code>helm3 history myapp</code> shows it was updated 2days ago (40+hrs), not yesterday (so I exclude possibility someone simply run <code>helm3 upgrade ..</code>; (seems like someone ran a command <code>kubectl rollout restart deployment/myapp</code>), any thoughts how can I check why the pods were restarted?  I'm not sure how to verify it; PS: the logs from <code>kubectl logs deployment/myapp</code> go back only to 3 hours ago</p>
<hr />
<p>just for reference, I'm not asking for this command <code>kubectl logs -p myapp-75cb966746-grjkj</code>, with that there is no problem, I want to know what happened to the 3 pods that were there 14 hrs ago, and were simply deleted/replaced - and how to check that.</p>
<hr />
<p>also no events on the cluster</p>
<pre class="lang-sh prettyprint-override"><code>MacBook-Pro% kubectl get events
No resources found in myns namespace.
</code></pre>
<hr />
<p>as for describing the deployment all there is, is that first the deployment was created few months ago</p>
<pre class="lang-sh prettyprint-override"><code>CreationTimestamp:      Thu, 22 Oct 2020 09:19:39 +0200
</code></pre>
<p>and that last update was &gt;40hrs ago</p>
<pre class="lang-sh prettyprint-override"><code>lastUpdate: 2021-04-07 07:10:09.715630534 +0200 CEST m=+1.867748121
</code></pre>
<p>here is full describe if someone wants</p>
<pre class="lang-sh prettyprint-override"><code>MacBook-Pro% kubectl describe deployment myapp
Name:                   myapp
Namespace:              myns
CreationTimestamp:      Thu, 22 Oct 2020 09:19:39 +0200
Labels:                 app=myapp
Annotations:            deployment.kubernetes.io/revision: 42
                        lastUpdate: 2021-04-07 07:10:09.715630534 +0200 CEST m=+1.867748121
                        meta.helm.sh/release-name: myapp
                        meta.helm.sh/release-namespace: myns
Selector:               app=myapp,env=myns
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        5
RollingUpdateStrategy:  25% max unavailable, 1 max surge
Pod Template:
  Labels:       app=myapp
  Annotations:  kubectl.kubernetes.io/restartedAt: 2020-10-23T11:21:11+02:00
  Containers:
   myapp:
    Image:      xxx
    Port:       8080/TCP
    Host Port:  0/TCP
    Limits:
      cpu:     1
      memory:  1G
    Requests:
      cpu:      1
      memory:   1G
    Liveness:   http-get http://:myappport/status delay=45s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:myappport/status delay=45s timeout=5s period=10s #success=1 #failure=3
    Environment Variables from:
      myapp-myns  Secret  Optional: false
    Environment:
      myenv: myval
    Mounts:
      /some/path from myvol (ro)
  Volumes:
   myvol:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      myvol
    Optional:  false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  &lt;none&gt;
NewReplicaSet:   myapp-75cb966746 (3/3 replicas created)
Events:          &lt;none&gt;
</code></pre>

potatopotato
<p>First thing first, I would check nodes on which the Pods were running.</p>
<ul>
<li>If a Pod is restarted (which means that the <strong>RESTART COUNT</strong> is incremented) it usually means that the Pod had an error and that error caused the Pod to crash.</li>
<li>In your case tho, the Pod were completely recreated, this means (like you said) that someone could have use a rollout restart, or the deployment was scaled down and then up (both manual operations).</li>
</ul>
<p>The most common case for Pods to be created automatically, is that the node / nodes where the Pods were being executed had a problem. If a node becomes <strong>NotReady</strong>, even for a small amount of time, Kubernetes Scheduler will try to schedule new Pods on other nodes in order to match the desired state (number of replicas and so on)</p>
<p>Old Pods on a <strong>NotReady</strong> node will go into <strong>Terminating</strong> state and will be forced to terminate as soon as the <strong>NotReady</strong> node will become <strong>Ready</strong> again (if they are still up and running)</p>
<p>This is described in details in the documentation ( <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime</a> )</p>
<blockquote>
<p>If a Node dies, the Pods scheduled to that node are scheduled for deletion after a timeout period. Pods do not, by themselves, self-heal. If a Pod is scheduled to a node that then fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances.</p>
</blockquote>
