This lets us use labels (or annotations), meaning we can experiment
with different clouds without changing the API.
We also add initial (experimental/undocumented) support for exposing a "Metal" provider.
Previously it worked on ClusterSpec, but that means we can't read the
labels or annotations. We want to use those labels/annotations to
experiment with new cloud providers (e.g. bare metal) before adding
this to the API.
Introduce generics so we also get type-safety.
Generate and upload keys.json + discovery.json to public store
Don't enable anonymous auth on publicjwks
Remove tests that won't work using FS VFS anymore
When the PublicJWKS feature-flag is set, we expose the apiserver JWKS
document publicly (including enabling anonymous access). This is a
stepping stone to a more hardened configuration where we copy the JWKS
document to S3/GCS/etc.
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>
Previously when setting the external cloud controller manager
configuration the core components `kubelet`, `apiserver` and
`kubecontroller-manager` were configured to use the external cloud
controller manager. Without setting the feature flag
EnableExternalCloudController this lead to a cluster in which the
masters had the cloud controller taint
`node.cloudprovider.kubernetes.io/uninitialized` which prevents
essential pods, like dns-controller to not be scheduled and leaves a
cluster where worker nodes can't connect to the api server because they
cannot resolve its hostname.
Image names from 1.16 on include an architecture suffix,
e.g. "-amd64"; the generic alias continues to work when pulling, but
when loading from a tarball (i.e. running in CI) we must use the
per-architecture name.