Use kube-scheduler image instead of hyperkube

[cofyc]

What problem does this PR solve?

Use scheduler image instead of hyperkube which is unnecessary and very large.

# docker images | grep v1.12.2
gcr.io/google-containers/hyperkube                               v1.12.2                      3e4497624dd0        7 months ago        635MB
gcr.io/google_containers/kube-scheduler                          v1.12.2                      d6d57c76136c        7 months ago        58.3MB

Does this PR introduce a user-facing change?:

Scheduler image is updated to use "k8s.gcr.io/kube-scheduler" which is much smaller than "gcr.io/google-containers/hyperkube". You must pre-pull the new scheduler image into your airgap environment before upgrading.

[cofyc]

/run-e2e-tests

[tennix]

I remember that the registry has changed to k8s.gcr.io.

[cofyc]

Updated to use k8s.gcr.io.

[cofyc]

/run-e2e-tests

[weekface]

LGTM

[aylei]

LGTM

[cofyc]

/run-e2e-tests

[weekface]

/run-e2e-tests

[cofyc]

/run-e2e-tests

[tennix]

@cofyc This actually has user-facing change, when upgrading, a new image needs to be pulled. This has an impact if user's deployment is in airgap environment.

[gregwebs]

Suggested change

	kubeSchedulerImageName: k8s.gcr.io/kube-scheduler
	# This image is much smaller then gcr.io/google-containers/hyperkube
	kubeSchedulerImageName: k8s.gcr.io/kube-scheduler

[gregwebs]

@tennix I think it is reasonable to expect users to inspect all the changes to the values file on upgrade if we haven't re-structured them.

In an airgap environment wouldn't you pull the image and push it with a new tag to your own repository anyways?

[tennix]

@gregwebs The user-facing change is for our release note. In an airgap environment, users may think only newer tidb-operator image is required when upgrading tidb-operator. So I think we should have a release note for this change.

[cofyc]

I'm going to add a release note for airgap users.

[cofyc]

Release note has been updated. PTAL.

[tennix]

LGTM

[cofyc]

/run-e2e-tests