Added instructions to update kubeconfig after manual certs renewal or cluster upgrade #7890
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Hi @saiteja313. Thanks for your PR. I'm waiting for a aws member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
eks-distro-bot
added
the
size/M
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7890 +/- ##
==========================================
+ Coverage 73.43% 73.46% +0.03%
==========================================
Files 576 577 +1
Lines 35667 35744 +77
==========================================
+ Hits 26191 26261 +70
- Misses 7823 7826 +3
- Partials 1653 1657 +4 ☔ View full report in Codecov by Sentry. |
|
|
||
| #### Update kubeconfig on Admin machine | ||
|
|
||
| Post completion of manual certificate rotation or if your Cluster was created more than a year ago, your kubeconfig file on Admin machine will have outdated certificates and would result in following error, |
There was a problem hiding this comment.
| Post completion of manual certificate rotation or if your Cluster was created more than a year ago, your kubeconfig file on Admin machine will have outdated certificates and would result in following error, | |
| Your local kubeconfig used to interact with the cluster contains a certificate that expires after 1 year. When you rotate cluster certificates a new kubeconfig with a new certificate is created as a Secret in the cluster. If you do not retrieve the new kubeconfig and your local kubeconfig certificate expires you will receive the following error: |
| @@ -168,3 +168,74 @@ ${IMAGE_ID} tmp-cert-renew \ | |||
| 5. Repeat the above steps for all control plane nodes. | |||
|
|
|||
| You can similarly use the above steps to rotate a single certificate instead of all certificates. | |||
|
|
|||
| #### Update kubeconfig on Admin machine | |||
There was a problem hiding this comment.
| #### Update kubeconfig on Admin machine | |
| #### Update your kubeconfig |
Admin machines are ephemeral. Suggesting they need to update the admin machine is a little misleading as it may no longer exist.
| This error typically occurs when the cluster certificates have been renewed or extended during the upgrade process. To resolve this issue, you need to update your local kubeconfig file with the new cluster credentials. | ||
| ``` | ||
|
|
||
| Follow below steps to update kubeconfig on Admin machine. |
There was a problem hiding this comment.
| Follow below steps to update kubeconfig on Admin machine. | |
| You can extract your new kubeconfig using the following steps. |
|
|
||
| Follow below steps to update kubeconfig on Admin machine. | ||
|
|
||
| 1. SSH to one of the Control Plane nodes and run the following command to validate connection with API Server, export kubeconfig from `${CLUSTER_NAME}-kubeconfig` secret object (`eksa-system` namespace) using kubectl and copy kubeconfig file to `/tmp` directory. |
There was a problem hiding this comment.
This step is only necessary if the local kubeconfig has already expired. If not, they should be able to retrieve the secret with the existing cert data.
Can we move the step to retrieve the admin.conf to a separate subheading "What do I do if my local kubeconfig has expired?"
| kubectl get nodes -o wide | ||
| kubectl get secrets -A |
There was a problem hiding this comment.
These steps aren't necessary so I think we can eliminate them.
| kubectl get nodes -o wide | ||
| kubectl get secrets -A |
| # open a root shell | ||
| sudo sheltie | ||
|
|
||
| export CLUSTER_NAME="<YOUR_CLUSTER_NAME_HERE>" |
|
|
||
| kubectl get secret ${CLUSTER_NAME}-kubeconfig -n eksa-system -o yaml > new-admin.kubeconfig | ||
|
|
||
| cat new-admin.kubeconfig | base64 -d > /tmp/new-admin-decoded.kubeconfig |
There was a problem hiding this comment.
You shouldn't need to decode the admin.conf. Decoding is only needed for the secret we extract from the cluster.
| # OR SFTP | ||
|
|
||
| sftp -i <keypair>@${CONTROLPLANE_IP}:/tmp/new-admin-decoded.kubeconfig . |
There was a problem hiding this comment.
Why would scp not work? I think we can include a single approach (scp) and let the user decide how they want to do it (I can think of several other approaches and we don't want to enumerate them).
| {{< /tabpane >}} | ||
|
|
||
|
|
||
| 2. **SSH to Admin Machine**, download the kubeconfig file from ControlPlane to your Admin machine and access Kubernetes Cluster |
There was a problem hiding this comment.
| 2. **SSH to Admin Machine**, download the kubeconfig file from ControlPlane to your Admin machine and access Kubernetes Cluster | |
| 2. From your admin machine, download the kubeconfig file from the ControlPlane node and use it to access your Kubernetes Cluster. |
Issue #, if available:
Description of changes:
Testing (if applicable):
Documentation added/planned (if applicable): This pull request is documentation update
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.