假设在Kubernetes节点上运行了一些来自部署/StatefulSet/DaemonSet等的豆荚。
然后我直接重新启动节点,然后启动docker,使用相同的参数启动kubelet。
那些吊舱会怎么样?
据我所知:
apiserver
^
|(sync)
V
kubelet
^
|(sync)
V
-------------
| CRI plugin |(like api)
| containerd |(like api-server)
| runc |(low-level binary which manages container)
| c' runtime |(container runtime where containers run)
-------------
当kubelet从kubelet server接收到PodSpec时,它像远程服务一样调用CRI,步骤如下:
因此,我猜测:当节点和码头重新启动时,步骤1和步骤2已经完成,容器处于“停止”状态;然后当kubelet重新启动时,它从kube server获取最新信息,发现容器没有处于“运行”状态,因此它调用CRI运行容器,然后一切都恢复正常。
请帮我确认一下。
提前谢谢~
发布于 2020-09-23 14:44:02
好问题。首先要做几件事;Pod不是固定在某个节点上的。这些节点大多被看作是Kubernetes可以用来运行其工作负载的“服务器场”。例如,您为Kubernetes提供了一组节点,还提供了一组例如Deployment
--这是应该在您的服务器上运行的应用程序的期望状态。Kubernetes负责调度这些Pods,并且当集群中的某些内容发生更改时,它也会继续运行。
独立的吊舱不是由任何东西管理的,所以如果一个Pod崩溃了,它就不会被恢复。您通常希望将您的无状态应用部署为Deployments
,然后启动ReplicaSets
来管理应用程序的一组Pods (例如4个Pods )实例。
您想要的状态;带有replicas: 4
的replicas: 4
保存在Kubernetes控制平面内的etcd数据库中。
然后,Deployment
和ReplicaSet
的一组控制器负责保持应用程序的4个副本。例如,如果一个节点变得不负责(或死亡),将在其他节点上创建新的吊舱,如果它们是由ReplicaSet
控制器管理的。
库贝利特接收调度到节点的PodSpecs,然后通过定期的健康检查保持这些豆荚的存活。
是否只有无状态荚(非本地数据)才能正常恢复?
吊舱应该被看作是重要的--例如,可以消失--但由管理它们的控制器恢复--除非部署为独立的Pod。所以不要在舱内存储本地数据。
还有一些StatefulSet
吊舱,它们是用于有状态工作负载的,但是分布式有状态工作负载(通常有3个)使用木筏复制数据。etcd数据库是使用Raft的分布式数据库的一个例子。
发布于 2020-09-23 14:52:10
当节点被重新启动,并在其上被调度(由Deployment
或ReplicaSet
管理)时,这些控制器将负责在另一个健康的节点上调度所需数量的副本。因此,如果在重新启动节点上运行了2个副本,则它们将终止并在其他节点上调度。
在重新启动节点之前,您应该使用kubectl cordon
对将节点标记为不可调度进行重新安排,并给kubernetes时间重新安排豆荚。
无状态荚将不会在任何其他节点上重新调度,它们将被终止。
https://stackoverflow.com/questions/64029871
复制相似问题