我已经在GKE上部署了微服务，使用Helm v3；所有的应用程序/头盔都运行了好几个月，但昨天由于某种原因，pod被重新创建了
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
helm3 history myapp显示它是在2天前(40多小时(更新的，而不是昨天(所以我排除了有人只是运行helm3 upgrade ..的可能性；(似乎有人运行了命令kubectl rollout restart deployment/myapp(，有什么想法吗？我该如何检查pod为什么重新启动？我不知道如何验证它；PS：来自kubectl logs deployment/myapp的日志只能追溯到3小时前的
仅供参考，我不是要求这个命令kubectl logs -p myapp-75cb966746-grjkj，没有问题，我想知道14小时前在那里的3个吊舱发生了什么，只是被删除/替换了-以及如何检查。
集群上也没有事件
MacBook-Pro% kubectl get events
No resources found in myns namespace.
关于描述部署，只有几个月前创建了第一个部署
CreationTimestamp: Thu, 22 Oct 2020 09:19:39 +0200
并且上次更新是>40小时前
lastUpdate: 2021-04-07 07:10:09.715630534 +0200 CEST m=+1.867748121
如果有人想要，这里有完整的描述
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: <none>
NewReplicaSet: myapp-75cb966746 (3/3 replicas created)
Events: <none>
首先，我要检查Pods运行的节点。
- 如果Pod重新启动(这意味着RESTART COUNT增加(，通常意味着Pod出现错误，该错误导致Pod崩溃
- 在你的案例中，Pod被完全重新创建，这意味着(就像你所说的(有人可能需要重新启动，或者部署被缩小然后扩大(都是手动操作(
自动创建Pod最常见的情况是执行Pod的节点出现问题。如果一个节点变得NotReady，即使在很短的时间内，Kubernetes Scheduler也会尝试在其他节点上调度新的Pod，以匹配所需的状态(副本数量等(
NotReady节点上的旧Pod将进入Terminating状态，并且一旦NotReadyeady(如果它们仍在运行(，就会被迫终止
文档(https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-寿命(
如果一个节点死亡，则计划在超时后删除该节点的Pod。播客本身并不能自我治愈。如果一个Pod被调度到一个节点，然后该节点发生故障，则该Pod被删除；同样，由于缺乏资源或节点维护，Pod将无法在驱逐中幸存下来。Kubernetes使用了一个更高级的抽象，称为控制器，用于处理管理相对一次性的Pod实例的工作。
我建议您运行kubectl describe deployment <deployment-name>和kubectl describe pod <pod-name>。
此外，kubectl get events将显示集群级别的事件，并可能帮助您了解发生了什么。
您可以使用
kubectl describe pod your_pod_name
其中，在Containers.your_container_name.lastState中，您可以获得最后一个pod被终止的时间和原因(例如，由于错误或由于OOMKilled(
文件参考：
kubectl explain pod.status.containerStatuses.lastState
KIND: Pod
VERSION: v1
RESOURCE: lastState <Object>
DESCRIPTION:
Details about the container's last termination condition.
ContainerState holds a possible state of container. Only one of its members
may be specified. If none of them is specified, the default one is
ContainerStateWaiting.
FIELDS:
running <Object>
Details about a running container
terminated <Object>
Details about a terminated container
waiting <Object>
Details about a waiting container
我的一个容器上的示例，由于应用程序中的错误而终止：
Containers:
my_container:
Last State: Terminated
Reason: Error
Exit Code: 137
Started: Tue, 06 Apr 2021 16:28:57 +0300
Finished: Tue, 06 Apr 2021 16:32:07 +0300
要获取容器(重新启动的容器(的先前日志，您可以在pod上使用--previous密钥，如下所示：
kubectl logs your_pod_name --previous