Add status column for kubectl get replicationcontroller/service

[gouyang]

kubectl get replicaController/service does not tell whether the replicaController is in health state or service is running, how about add a status column to indicate that?

[bgrant0607]

Adding this to Deployment - #20009

[bgrant0607]

Would like to add this to ReplicaSet and ReplicationController, also. Probably ReadyReplicas, which we could also add to Deployment.

[janetkuo]

@foxish let's start with adding running / ready replicas (pods) to kubectl get replicationcontroller and feel free to ask me questions

[foxish]

@janetkuo Based on our offline discussion, adding a new field to api/types.go:ReplicationControllerStatus is not preferable at the moment. So, we choose to make multiple GET calls to fetch the status of the pods. It seems difficult to see which would be the appropriate place to make those calls back to the pods.

[0xmichalis]

@janetkuo Based on our offline discussion, adding a new field to api/types.go:ReplicationControllerStatus is not preferable at the moment. So, we choose to make multiple GET calls to fetch the status of the pods. It seems difficult to see which would be the appropriate place to make those calls back to the pods.

Can you elaborate on why? We are already doing this for Deployments and 1) I have stumbled across many cases where people want to know the available replicas of their controllers individually and 2) doing this at the replica set status and then using that at the deployment level seems more correct and would offload complexity from the deployment controller. That's why I have opened #28381

[smarterclayton]

So I think that a serious problem with the cluster today is when pods can't be created for the following reasons:

1. Quota
2. Policy decisions (pod security policy)
3. Placement constraints
4. Any other logic that can block progress

I think 1-3 are enough to justify some small amount of status to be rolled up - it would massively improve the user experience of naive clients (kubectl describe rc foo) and web clients. It would remove a whole class of questions on stack overflow (why do I not have X things). It will become increasingly difficult over time because we will add more things to that list.

I think this may also be covered in another issue, so I don't want to hijack, but I do think from a usability issue controllers are responsible for summarizing the total state of the decisions they make, not just through events. It can definitely be tricky to keep that status up to date in a performant matter, but i think it's critical.

[bgrant0607]

@Kargakis @smarterclayton I clarified with @janetkuo. Her comment was directed at @foxish rather than a general statement.

We should add an aggregate status field (probably multiple of them). I commented on #29481 as well.

As for identifying reasons such as quota, etc., that's #21912.

[smarterclayton]

Thanks, sorry for the confusion.