Show topologySpreadConstraints in Describe command

[ardaguclu]

What type of PR is this?

/kind feature
/kind bug

What this PR does / why we need it:

Currently describe command does not show topologySpreadConstraints
field(although get command returns). This PR adds support for showing topologySpreadConstraints in
describe command.For simplicity, if this field is not set, it will not show
(unlike to other core fields whose are shown as <none> even if they are null).

For kubectl describe pod/testpod, result will be like;

Topology Spread Constraints:  topology.kubernetes.io/zone1:ScheduleAnyway when max skew 3 is exceeded
                              topology.kubernetes.io/zone2:DoNotSchedule when max skew 1 is exceeded for selector foo=bar

For kubectl describe deployment/testdeployment, result will be like;

Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:                      nginx:1.14.2
    Port:                       80/TCP
    Host Port:                  0/TCP
    Environment:                <none>
    Mounts:                     <none>
  Volumes:                      <none>
  Topology Spread Constraints:  topology.kubernetes.io/zone1:ScheduleAnyway when max skew 3 is exceeded
                                topology.kubernetes.io/zone2:DoNotSchedule when max skew 1 is exceeded for selector foo=bar

Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?

topologySpreadConstraints will be shown in describe command for pods, deployments, daemonsets, etc.

[k8s-ci-robot]

Please note that we're already in Test Freeze for the release-1.24 branch. This means every merged PR has to be cherry-picked into the release branch to be part of the upcoming v1.24.0 release.

[ardaguclu]

/cc @soltysh @brianpursley

[brianpursley]

Strange we don't show all the information for a pod template. I wonder what the criteria is for deciding what should be shown for a pod template. For example, we don't show tolerations.

I think it is fine to add this here. I wonder if we should (as a separate PR) add the other spec fields, where they make sense.

[ardaguclu]

I think it is fine to add this here. I wonder if we should (as a separate PR) add the other spec fields, where they make sense.

I have the same question in my mind. As far as I understand, since describe is nicer way to showing resources, there is no promise that describe shows everything get shows.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ardaguclu, brianpursley

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/kubectl/OWNERS [brianpursley]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[brianpursley]

/triage accepted
/priority important-soon
/lgtm