fix: Update shoot management guide due to new cert-based kubeconfigs #267
Conversation
|
I am marking this as a draft since the kubeconfig CA rotation screenshots and prose still need to be finalized. Currently, I cannot access https://admin-dev.cleura.cloud (getting an "Internal server error" message). As soon as I can take my screenshots, I am amending and lifting the "draft" status. |
colder-is-better
force-pushed
the
kubeconfig-mgm-up
branch
3 times, most recently
from
3e43b44 to
61de9b1
Compare
colder-is-better
force-pushed
the
kubeconfig-mgm-up
branch
2 times, most recently
from
56d664e to
18c32c6
Compare
| - cluster: | ||
| certificate-authority-data: DATA+OMITTED | ||
| server: https://api.ghar.p268.staging-k8s.{{gui_domain}} | ||
| name: garden-p268--ghar-external | ||
| - cluster: | ||
| certificate-authority-data: DATA+OMITTED | ||
| server: https://api.ghar.p268.internal.staging-k8s.{{gui_domain}} | ||
| name: garden-p268--ghar-internal |
There was a problem hiding this comment.
I believe we want to use the k8s, not staging-k8s subdomain here.
And also we should explain what the difference between the "internal" and "external" cluster is.
There was a problem hiding this comment.
When I run kubectl config view against the dev-cloud shoot cluster, I get the staging-k8s subdomain. Are you suggesting I should manually change this into k8s?
Also, although I only have a suspicion about what those internal and external clusters refer to, when I run kubectl config view against the non dev-cloud shoot cluster, I don't see internal nor external.
In not so many words, I need more context and/or pointers before providing more details about those internal and external clusters.
There was a problem hiding this comment.
Okay, in that case let's merge this PR last, i.e. leave it open until we can verify the behavior of the production environment.
There was a problem hiding this comment.
After the upgrade has landed in production, no matter if we have a Kubernetes 1.26 or Kubernetes 1.27 shoot, issuing kubectl config view gives us something like the following:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://api.gharnew.p43597.k8s.cleura.cloud
name: garden-p43597--gharnew-external
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://api.gharnew.p43597.internal.k8s.cleura.cloud
name: garden-p43597--gharnew-internal
contexts:
- context:
cluster: garden-p43597--gharnew-external
user: garden-p43597--gharnew-external
name: garden-p43597--gharnew-external
- context:
cluster: garden-p43597--gharnew-internal
user: garden-p43597--gharnew-external
name: garden-p43597--gharnew-internal
current-context: garden-p43597--gharnew-external
kind: Config
preferences: {}
users:
- name: garden-p43597--gharnew-external
user:
client-certificate-data: DATA+OMITTED
client-key-data: DATA+OMITTED
Note that I did not replace actual data with DATA+OMITTED. That is in the actual output, along with the internal and external literals.
There was a problem hiding this comment.
In that case, please update the PR accordingly.
colder-is-better
force-pushed
the
kubeconfig-mgm-up
branch
4 times, most recently
from
3cbf63e to
e5827bd
Compare
After introducing Kubernetes 1.27, shoot clusters with Kubernetes 1.26 and beyond will use certificate-based kubeconfig files. We explain the difference between "old" static kubeconfigs and new certificate-based ones, and we show how to issue and use them regardless of the Kubernetes version our shoot cluster uses. Then, we explain how to rotate static or certificate-based kubeconfigs.
colder-is-better
force-pushed
the
kubeconfig-mgm-up
branch
from
e5827bd to
5288883
Compare
After introducing Kubernetes 1.27, shoot clusters with Kubernetes 1.26 and beyond will use certificate-based kubeconfig files. We explain the difference between "old" static kubeconfigs and new certificate-based ones, and we show how to issue and use them regardless of the Kubernetes version our shoot cluster uses. Then, we explain how to rotate static or certificate-based kubeconfigs.