I missed these in the previous PR. This removes the direct dependency on v1 entirely.
The kubernetes 1.19 upgrade will remove the indirect reference on v1.
When using a "mixed instance policy"[1] instance group spot and onDemand nodes are part of the same
ASG. The ASG handles the percentage of spot vs onDemand instances. There are no annotations, EC2 tags or labels to identify which
instances are onDemand vs spot. There is a field called `InstanceLifecycle` accessible through `EC2.DescribeInstances`.
The field `InstanceLifecycle` is available only in `spot` and
`scheduled` AWS EC2 instance types.
This PR introduces a new label to be attached on AWS EC2 spot nodes.
The label is:
```
node-role.kubernetes.io/spot-worker: "true"
```
or
```
node-role.kubernetes.io/scheduled-worker: "true"
```
[^1]: https://github.com/kubernetes/kops/blob/master/docs/instance_groups.md#mixedinstancepolicy-aws-only
The client-go signature for most methods adds a context.Context
object, and also makes Options mandatory. Feed through a
context.Context through many of our methods (but use context.TODO to
stop it getting totally out of hand!)
Currently the images have a timestamp of epoch 0:
```
$ docker inspect kope/kops-controller:1.18.0-alpha.2 -f '{{ .Created }}'
1970-01-01T00:00:00Z
```
The `container_image` bazel rule [0] mentions that `creation_time` has a default value of 0 unless `stamp = True`, so this should be enabled on all container_image rules that are pushed to a docker registry.
[0] https://github.com/bazelbuild/rules_docker#container_image-1
Writing to a hostPath from a non-root container requires file
ownership changes, which is difficult to roll out today. See
discussion in #8454
We were primarily using the logfile for e2e diagnostics, so we're
going to look into collecting the information via other means instead.
We also haven't yet shipped this logfile in a released version (though
we have shipped it in beta releases)
We then `docker load` it when using a KOPS_BASE_URL.
This should simplify the development process (particularly once we
also do this for dns-controller; at that point we won't need a
registry at all).
This should also fix the problems in CI, where the kops-controller
image isn't available. We've been getting away with testing with the
previous version for dns-controller, which changes pretty slowly. But
that's not a good idea for kops-controller, which is likely to be more
critical and evolve more rapidly.