我想知道在这种情况下会发生什么,或者是否有可能:Kubernetes群集-如果部署的容器重新启动策略为:始终但在POD级别上,您指定的restartPolicy为:不使用Kubernetes会怎么做?
wqnecbli1#
正如@Turing85所评论的,在正常的用例中,部署和它的Pod不能有不同的restartPolicy,因为部署创建了Pod。(例如,kubectl edit pod <pod-name>),您将得到一个错误,因为此属性在创建后无法更改。但是,我们可以欺骗一个部署,或者更具体地说,欺骗底层的副本集接受一个手动创建的Pod。Kubernetes中的副本集通过使用标签知道哪些Pod是它们的。如果检查属于您的部署的副本集,您将看到一个标签选择器,它向您显示了ReplicaSet需要显示哪些标签才能将Pod部分视为ReplicaSet。因此,如果要手动创建稍后由ReplicaSet管理的Pod,请首先创建具有所需restartPolicy的Pod。此Pod启动并准备就绪后,删除ReplicaSet的现有Pod,并更新Pod的标签以包含正确的标签。现在ReplicaSet中有一个具有不同restartPolicy的Pod。这真的很麻烦,实际上取决于删除和更新标签的时间,因为一旦您删除ReplicaSet中的一个Pod,它就会尝试创建一个新的Pod。本质上,您必须比ReplicaSet创建新Pod更快地更改标签。
restartPolicy
kubectl edit pod <pod-name>
1条答案
按热度按时间wqnecbli1#
正如@Turing85所评论的,在正常的用例中,部署和它的Pod不能有不同的
restartPolicy
,因为部署创建了Pod。(例如,kubectl edit pod <pod-name>
),您将得到一个错误,因为此属性在创建后无法更改。但是,我们可以欺骗一个部署,或者更具体地说,欺骗底层的副本集接受一个手动创建的Pod。Kubernetes中的副本集通过使用标签知道哪些Pod是它们的。如果检查属于您的部署的副本集,您将看到一个标签选择器,它向您显示了ReplicaSet需要显示哪些标签才能将Pod部分视为ReplicaSet。因此,如果要手动创建稍后由ReplicaSet管理的Pod,请首先创建具有所需
restartPolicy
的Pod。此Pod启动并准备就绪后,删除ReplicaSet的现有Pod,并更新Pod的标签以包含正确的标签。现在ReplicaSet中有一个具有不同restartPolicy
的Pod。这真的很麻烦,实际上取决于删除和更新标签的时间,因为一旦您删除ReplicaSet中的一个Pod,它就会尝试创建一个新的Pod。本质上,您必须比ReplicaSet创建新Pod更快地更改标签。