Fix serialization of EnforceNodeAllocatable

[ivan4th]

EnforceNodeAllocatable being nil and [] are treated in different
ways by kubelet. Namely, nil is replaced with []string{"pods"} by
the defaulting mechanism.

E.g. if you run kubelet in Docker-in-Docker environment
you may need to run it with the following options:
--cgroups-per-qos=false --enforce-node-allocatable=
(this corresponds to EnforceNodeAllocatable being empty array and not
null) If you then grab kubelet configuration via /configz and try to
reuse it for dynamic kubelet config, kubelet will think that
EnforceNodeAllocatable is null, failing to run in the
Docker-in-Docker environment.

Encountered this while updating Virtlet for Kubernetes 1.6
(the dev environment is based on kubeadm-dind-cluster)

[k8s-reviewable]

This change is 

[yujuhong]

Change looks fine to me, but adding @mtaufen since he's the authority of kubelet config.

[mtaufen]

/lgtm

This looks good to me for now. But keep in mind you really shouldn't be using the existing dynamic config implementation for anything other than testing (it's still alpha). It will also change significantly in 1.7: kubernetes/enhancements#281

Sorry for lateness on this review.

[ivan4th]

@mtaufen thanks for the comment. I've rebased the PR. We use dynamic kubelet config during the deployment of our CRI implementation (Virtlet), but it'll require some updates anyway to be compatible with forthcoming k8s 1.7, and as of now it looks like we'll be able to use the new dynamic kubelet config mechanism, too.

[ivan4th]

@k8s-bot kubemark e2e test this

[ivan4th]

@k8s-bot gce etcd3 e2e test this

[mtaufen]

/lgtm

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ivan4th, mtaufen

Needs approval from an approver in each of these OWNERS Files:

• pkg/apis/componentconfig/OWNERS [mtaufen]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[mtaufen]

@ivan4th The Kubelet's configuration API is still alpha-grade, and likely to undergo violent breaking changes. At present, there is no guarantee that any field you are dynamically updating will still be dynamic in any future version. For this reason, I caution against using dynamic config for anything other than tests (even there, please use it sparingly, as I'm the one who gets to update everyone else's code when the API changes).

[ivan4th]

@mtaufen thanks! Well, our idea is giving users a simple way to try out Virtlet. It's CRI implementation that itself runs as a DaemonSet and in case of "bootstrap" mode (not intended for production!) it uses dynamic kubelet config to set remoteRuntimeEndpoint and remoteImageEndpoint. This makes Virtlet installation a matter of kubectl create and doesn't tie it to particular systemd unit structure etc. Any chance these settings will be available in future? Not asking for any guarantees, of course.

[ivan4th]

(running CRI impl as a DaemonSet is possible thanks to the CRI proxy mechanism that makes it easy to have multiple runtimes on the node)

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 44606, 46038)