-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update core components upgrade documentation #492
Update core components upgrade documentation #492
Conversation
* Cert-manager | ||
* Etcdadm CAPI provider | ||
* EKS Anywhere controllers and CRDs | ||
* Flux |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flux is an optional component, not a core component. Might want to mention that.
Also looks like in the other docs we are calling it the Gitops controller, not Flux specifically.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: g-gaston, taneyland The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
docs/content/en/docs/tasks/cluster/cluster-core-components-upgrade.md
Outdated
Show resolved
Hide resolved
eksctl anywhere upgrade cluster -f ./cluster.yaml | ||
``` | ||
In addition to upgrading other cluster attributes that you may have modified in your cluster specification, any core components with newer versions will also be upgraded. | ||
You can see which components were upgraded by running `kubectl get pods -A` and observing the updated `Age` for the upgraded components. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't a good way to determine what got upgraded. Assuming a user upgraded a cluster they may have also upgraded worker nodes which would require all pods to be scheduled to new nodes. Is there a way to diff the components or validate component versions by parsing the manifest?
/lgtm |
Issue #, if available:
Description of changes:
This PR adds a new section under the
Cluster management
section of our documentation to describe how to upgrade core components using the CLI.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.