Rather than downloading the hash every time, we can record the hashes
for our well-known assets and bake them into the kOps binary. If the
hash is not baked in, we will continue to fall-back to downloading it,
this is important for new k8s versions, or where the user specifies a
version of one of our well-known assets (such as containerd).
We generate a kube-scheduler configuration file in the kops CLI, and
nodeup will use it if provided (instead of generating one).
We put the configuration file into the fileAssets.
Users can provide a kube-scheduler configuration in additional
objects, and this will be used as the base configuration (we add the
kubeconfig path).
Issue #13352
Co-authored-by: Ciprian Hacman <ciprian@hakman.dev>
We will be managing cluster addons using CRDs, and so we want to be
able to apply arbitrary objects as part of cluster bringup.
Start by allowing (behind a feature-flag) for arbitrary objects to be
specified.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
kube-apiserver doesn't expose the healthcheck via a dedicated
endpoint, instead relying on anonyomous-access being enabled. That
has previously forced us to enable the unauthenticated endpoint on
127.0.0.1:8080.
Instead we now run a small sidecar container, which
proxies /healthz and /readyz requests (only) adding appropriate
authentication using a client certificate.
This will also enable better load balancer checks in future, as these
have previously been hampered by the custom CA certificate.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
In our kube-dns manifest for 1.6 we often had an empty section,
normalization converted this to `{}` which causes `kubectl apply` to
fail.
We can simply skip empty objects when outputing.
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.
The k8s.gcr.io prefix is an alias, but for CI builds we run from a
docker load, and we only double-tag from 1.10 onwards. For versions
prior to 1.10, remap k8s.gcr.io to the old name. This also means that
we won't start using the aliased names on existing clusters, which could
otherwise be surprising to users.