1

So, lets say I have a DeploymentConfig running and because of that a ReplicationController which is eventually running a pod. If I updated the DeploymentConfig, more than once (let's assume), more ReplicationControllers would be created, and pods would be run by the one of the ReplicationController.

Now if I have Deploymentconfig details how do I figure out which ReplicationController is actually managing the pods? One way I know is getting the deploymentconfig.status.latestVersion and match that with the value of the annotation openshift.io/deployment-config.latest-version of ReplicationController. But is this the way people do it?

viveksinghggits
  • 661
  • 14
  • 35

2 Answers2

0

Query the replication controller object using label. Deployment, rc and pods contain matching label

If you update the deployment then a new replication controller get created and rolling update is triggered. post that old rc object get deleted.

P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
0

To continue from P Ekambaram's answer.

As long as You are not using another application to maintain pod customization like mentioned here. There is a chance that all of the replication controllers actually maintained a deployment.

According to kubernetes documentation:

Using ReplicationControllers with Services

Multiple ReplicationControllers can sit behind a single service, so that, for example, some traffic goes to the old version, and some goes to the new version.

A ReplicationController will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple ReplicationControllers, and it is expected that many ReplicationControllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the ReplicationControllers that maintain the pods of the services.

Hope it helps.

Piotr Malec
  • 3,429
  • 11
  • 16