Question

发生了什么：

使用命令“ kubectl replace -f [yaml文件]”时，旧的ReplicaSet和旧的Pod仍可与新的ReplicaSet和新的Pod一起使用。

您期望发生的事情：

旧的ReplicaSet应该缩小为0，旧的Pod将被删除。

如何再现（尽可能最小且精确）：

两个yaml文件之间的差异。新的yaml文件具有：

在spec.template.metadata.labels中添加component: propel-sx

在spec.template.spec.affinity中添加亲和力部分

affinity:
podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: component
          operator: In
          values:
          - propel-sx
      topologyKey: kubernetes.io/hostname
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: workLoad
          operator: In
          values:
          - ExtraHigh
      topologyKey: kubernetes.io/hostname

我们需要了解的其他信息吗？：

我发现一个奇怪的事情，旧的ReplicaSet将丢失字段“ ownerReferences”。我认为该字段将用于连接旧的ReplicaSet和新的ReplicaSet。按比例缩小旧的窗格，按比例放大新的窗格。但是我不知道为什么“ ownerReferences”字段丢失了。

环境： -Kubernetes版本（使用kubectl version）：

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:21:50Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

OS（例如来自/ etc / os-release）： CentOS Linux 7（核心）
内核（例如uname -a）：

Linux shc-sma-cd75.hpeswlab.net 3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Answer 1

请注意，kubectl replace会破坏该对象并在其位置创建一个新对象。这可能会导致副本集（属于“部署”对象的“子代”）遗留下来，并且不再假定它们完全属于任何部署。从理论上讲，可以通过显式指定一个标签选择器来缓解这种情况，该标签选择器供Deployment用来查找属于自己的Pod（请参见此处的example），但是最好改用kubectl apply，这样您的部署是更新的，而不是删除并重新制作的（这将保留由k8s自动设置的标签选择器，如果您未设置的话）。

我假设您希望部署具有默认的“滚动升级”行为：他们会创建一个新的副本集并在耗尽旧副本集（滚动升级）之前启动它。如果不是：要更改此设置，请添加

strategy:
    type: Recreate

部署规范中的

。这将使旧的副本集在新的副本集启动之前就耗尽。

使用命令'kubectl replace -f [yaml file]'时，旧的ReplicaSet和旧的Pod仍与新的ReplicaSet和新的Pod一起使用。

1 个答案: