所以，假设我有一个DeploymentConfig正在运行的，因为ReplicationController它最终正在运行一个 pod。如果我不止一次DeploymentConfig更新.ReplicationControllersReplicationController
现在，如果我有Deploymentconfig详细信息，我该如何确定ReplicationController实际上是哪个在管理 pod？我知道的一种方法是获取并将deploymentconfig.status.latestVersion其与. 但这是人们做事的方式吗？openshift.io/deployment-config.latest-versionReplicationController
使用标签查询复制控制器对象。部署、rc 和 pods 包含匹配的标签
如果您更新部署，则会创建一个新的复制控制器并触发滚动更新。发布旧的 rc 对象被删除。
继续 P Ekambaram 的回答。
只要您不使用其他应用程序来维护此处提到的 pod 自定义。有可能所有的复制控制器实际上都维护了一个部署。
根据 kubernetes文档：
将 ReplicationControllers 与服务一起使用
多个 ReplicationController 可以位于单个服务后面，例如，一些流量流向旧版本，一些流向新版本。
ReplicationController 永远不会自行终止，但预计它不会像服务一样长寿。服务可能由多个 ReplicationController 控制的 pod 组成，并且预计在服务的生命周期内可能会创建和销毁许多 ReplicationController（例如，对运行服务的 pod 执行更新）。 服务本身和它们的客户端都应该忽略维护服务 pod 的 ReplicationController。
希望能帮助到你。