1、Node状态变为NotReady
2、Pod 5分钟之内状态无变化
3、5分钟之后的状态变化:
Daemonset Pod: 状态变为Nodelost
Deployment、Statefulset和Static Pod的状态:先变为NodeLost,然后马上变为Unknown。
4、Deployment的pod会recreate,Static Pod和Statefulset的Pod会一直处于Unknown状态。
但Deployment如果是node selector停掉kubelet的node,则recreate的pod会一直处于Pending的状态。
1、Node状态变为Ready。
2、Daemonset的pod不会recreate,旧pod状态直接变为Running。
3、Deployment的则是将kubelet进程停止的pod删除
旧Pod状态在集群中有变化,但Pod状态在变化时发现集群中Deployment的Pod实例数已经够了,所以对旧Pod做了删除处理
4、Statefulset的Pod会重新recreate。
5、Staic Pod没有重启,直接被删除
我们在node controller中发现,除了daemonset pods外,都会调用delete pod api删除pod。
但并不是调用了delete pod api就会从apiserver/etcd中删除pod object,仅仅是设置pod 的deletionTimestamp,标记该pod要被删除。真正删除Pod的行为是kubelet,kubelet grace terminate该pod后去真正删除pod object。这个时候statefulset controller 发现某个replica缺失就会去recreate这个pod。
但此时由于kubelet挂了,无法与master通信,导致Pod Object一直无法从etcd中删除。如果能成功删除Pod Object,就可以在其他Node重建Pod。
另外,要注意,statefulset只会针对isFailed Pod,(但现在Pods是Unkown状态)才会去delete Pod。
// delete and recreate failed pods
if isFailed(replicas[I]) {
ssc.recorder.Eventf(set, v1.EventTypeWarning, "RecreatingFailedPod",
"StatefulSetPlus %s/%s is recreating failed Pod %s",
set.Namespace,
set.Name,
replicas[I].Name)
if err := ssc.podControl.DeleteStatefulPlusPod(set, replicas[I]); err != nil {
return &status, err
}
if getPodRevision(replicas[I]) == currentRevision.Name {
status.CurrentReplicas—
}
if getPodRevision(replicas[I]) == updateRevision.Name {
status.UpdatedReplicas—
}
status.Replicas—
replicas[I] = newVersionedStatefulSetPlusPod(
currentSet,
updateSet,
currentRevision.Name,
updateRevision.Name,
i)
}
所以针对node异常的情况,有状态应用(Non-Quorum)的保障,应该补充以下行为:
监测node的网络、kubelet进程、操作系统等是否异常,区别对待。
比如,如果是网络异常,Pod无法正常提供服务,那么需要:
kubectl delete pod -f —grace-period=0进行强制从etcd中删除该pod。
强制删除后,statefulset controller就会自动触发在其他Node上recreate pod。