fix(dockerfile): use deterministic version for kubectl

[ethanfrogers]

reading from stable.txt causes builds to be non-deterministic which could lead to problems in the future. we should be explicit about the version of kubectl that we ship. v1.16.0 was the latest version as of this PR.

[ezimanyi]

I wonder if we might want to actually stay one release behind the latest, given that kubectl officially supports versions of Kubernetes +/- 1 version from its version.

So if we ship kubectl 1.16 we technically are only supporting Kubernetes 1.15 and 1.16 (though in principle probably further back). Shipping 1.15 would give us support for Kubernetes 1.14-1.16. Given that 1.16 is still really new and not likely to be used in production, I even wonder if we should ship kubectl 1.14 to officially support 1.13-1.15 and then have things outside that range be probably supported.

[ethanfrogers]

So, I went with 1.16.0 because that's what got shipped with the 1.16 and 1.15 releases yesterday (10/1/2019). I'm hesitant to go backwards after that, honestly.

How do you feel about shipping multiple versions of kubectl? Kubernetes accounts allow you to specify a path to a specific kubectl executable. We could package multiple, default a specific one, but tell users where other exists on the filesystem if they need to override it.

[ezimanyi]

Given that all the calls to kubectl are orchestrated by clouddriver it seems like it would be complicated for users to try to override it. (I guess you could point the symlink to a different one---but if we're going to make people ssh to their docker containers and modify symlinks, I'm not sure that making them directly download what they want is any worse.)

It's true that we probably don't want to go backwards, but maybe going forward we can think more about the policy, and pin kubectl to 1.16 until whatever policy we decide tells us to bump it.

[ethanfrogers]

The ManagedAccount class exposes kubectlExecutable so it should be as simple as saying "kubectl executables are located here". It should be as simple as adding a property to the accounts they need to override.

[ethanfrogers]

@spinnakerbot cherry-pick 1.16

[ethanfrogers]

@spinnakerbot cherry-pick 1.15

[spinnakerbot]

Cherry pick successful: #4065

[spinnakerbot]

Cherry pick successful: #4066

[ezimanyi]

Oh, nice, didn't realize you could configure kubectlExecutable; that might be a good solution then. (I guess it still does have the downside of bringing along multiple kubectl versions in the container even for people who don't need them, though maybe that's minor.)