[GPII-3868]: Bump kubectl version to 1.15.0

[natarajaya]

New kubectl that is capable of doing rolling restarts.

Consumed by gpii-ops/gpii-infra#435.

[mrtyler]

LGTM

Please propose to upstream as well.

[amatas]

LGTM

[stepanstipl]

This is out of supported version skew - https://kubernetes.io/docs/setup/release/version-skew-policy/#kubectl.

kubectl is supported within one minor version (older or newer) of kube-apiserver.

Example:

kube-apiserver is at 1.13
kubectl is supported at 1.14, 1.13, and 1.12

We use Kubernetes 1.12 at the moment, supported kubectl versions therefore are 1.11, 1.12, 1.13. I have seen various issues causing kubectl to fail when using versions outside of supported range due to a difference in resource schema definitions and would strongly advise against this.

[natarajaya]

We use Kubernetes 1.12 at the moment, supported kubectl versions therefore are 1.11, 1.12, 1.13. I have seen various issues causing kubectl to fail when using versions outside of supported range due to a difference in resource schema definitions and would strongly advise against this.

@stepanstipl This is a good point. However, I tested it during our normal dev workflow and have not noticed any issues.

The only reason for this PR – need for rolling restarts during SA credentials rotation, and it turns out that it is not as simple as it sounds, and support for kubectl rollout restart been only recently added to 1.15 (took 3 years for K8s community). So if you have a better idea – I am open to suggestions.

Also, we can keep 1.12 as default kubectl, but add kubectl1.15 to use only for rolling restarts.

[stepanstipl]

The only reason for this PR – need for rolling restarts during SA credentials rotation, and it turns out that it is not as simple as it sounds, and support for kubectl rollout restart been only recently added to 1.15 (took 3 years for K8s community). So if you have a better idea – I am open to suggestions.

I don't think it's worth upgrading to unsupported version combination for this, there are other ways to solve this problem. From the top of my head - for example, updating some property of the deployment, like a label or annotation of the pod spec, will cause new ReplicaSet to be created with new pods and therefore effectively restart all the pods (which is what the kubectl rollout restart effectively does btw., it adds kubectl.kubernetes.io/restartedAt annotation to the deployment)

[stepanstipl]

@natarajaya can we close this PR as we abandoned the approach that would require this?