时间戳

首页 > 解决方案 > kubernetes部署突然pod重启，原因？

kubernetes - kubernetes部署突然pod重启，原因？

问题描述

我已经使用 Helm v3 在 GKE 上部署了微服务；所有应用程序/头盔都很好地放置了几个月，但昨天由于某种原因重新创建了 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 myapp2 天前（40 小时以上）更新的，而不是昨天更新的（所以我排除了有人简单地运行的可能性helm3 upgrade ..；（好像有人运行了一个命令kubectl rollout restart deployment/myapp），有什么想法可以检查为什么重新启动 pod？我不确定如何验证它; PS：日志kubectl logs deployment/myapp只能追溯到3小时前

仅供参考，我不是要求这个命令kubectl logs -p myapp-75cb966746-grjkj，没有问题，我想知道 14 小时前存在的 3 个 pod 发生了什么，并且被简单地删除/替换 - 以及如何检查。

集群上也没有事件

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>

标签： kuberneteslogginggoogle-cloud-platformgoogle-kubernetes-engine

解决方案

首先，我会检查运行 Pod 的节点。

  • 如果 Pod 重新启动（这意味着RESTART COUNT增加），通常意味着 Pod 出现错误并且该错误导致 Pod 崩溃。
  • 在您的情况下，Pod 已完全重新创建，这意味着（就像您说的那样）有人可能已经使用了推出重启，或者部署被缩小然后放大（都是手动操作）。

自动创建 Pod 的最常见情况是，执行 Pod 的节点/节点有问题。如果一个节点变为NotReady，即使是很短的时间，Kubernetes 调度器也会尝试在其他节点上调度新的 Pod 以匹配所需的状态（副本数量等）

NotReady节点上的旧Pod将进入Terminating状态，并在NotReady节点再次变为Ready时强制终止（如果它们仍在运行）

这在文档中有详细描述（https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime）

如果一个 Node 死亡，调度到该节点的 Pod 会在超时后被调度删除。Pod 本身不会自我修复。如果一个 Pod 被调度到一个失败的节点上，那么这个 Pod 就会被删除；同样，由于缺乏资源或节点维护，Pod 将无法生存。Kubernetes 使用更高级别的抽象，称为控制器，它处理管理相对一次性的 Pod 实例的工作。

推荐阅读