/kind bug
/sig cli

What happened:
When I do a kubectl get -o yaml --export po/podName-v1-2722560640

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/created-by: |
      {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"podName-v1-2722560640","uid":"3e72e70e-8f20-11e7-a635-0cc47ad9df50","apiVersion":"extensions","resourceVersion":"73892987"}}
  creationTimestamp: null
  generateName: podName-v1-2722560640-
  labels:
    app: podName-v1
    pod-template-hash: "2722560640"
  ownerReferences:
  - apiVersion: extensions/v1beta1
    controller: true
    kind: ReplicaSet
    name: podName-v1-2722560640
    uid: 3e72e70e-8f20-11e7-a635-0cc47ad9df50
  selfLink: /api/v1/namespaces/default/pods/podName-v1-2722560640-crn8r

So from the metadata the namespace field got stripped but in the selfLink it is still there. Whereas with other resources such as deployments, RS or RCs it would have resulted in: /api/v1/namespaces//pods/podName-v1-2722560640-crn8r

What you expected to happen:
Consistent behaviour in the stripping of the namespaces across all resources instead of being stripped for most and not for pods (maybe some others too?)

How to reproduce it (as minimally and precisely as possible):
Try to kubectl get --o=yaml --export on a deployment and on a pod and see the difference.

Anything else we need to know?:
Seems to be affecting all versions of Kubectl right now. I've tried from 1.5.6 all the way up to 1.9.

Environment:

• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.3", GitCommit:"029c3a408176b55c30846f0faedf56aae5992e9b", GitTreeState:"clean", BuildDate:"2017-02-15T06:40:50Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.6", GitCommit:"114f8911f9597be669a747ab72787e0bd74c9359", GitTreeState:"clean", BuildDate:"2017-03-28T13:36:31Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Affects the newest 1.9 kubectl too

• Cloud provider or hardware configuration:
  Bare metal, 3 masters 7 workers

• OS (e.g. from /etc/os-release):
  Slackware 9.1.0

• Kernel (e.g. uname -a):
  Linux 4.4.29 Unit test coverage in Kubelet is lousy. (~30%) #1 SMP Mon Oct 31 14:44:45 CDT 2016 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux

• Install tools:
  Manual installation through Kubelet

• Others:
  N/A