Skip to content

Commit

Permalink
Add details about rolling restarts behaviors
Browse files Browse the repository at this point in the history
  • Loading branch information
jeanfabrice committed Dec 9, 2023
1 parent cf50a7b commit d26f3bb
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions docs/operating-eck/upgrading-eck.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,8 @@ Upgrading the operator results in a one-time update to existing managed resource

1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8

NOTE: Stepping over one of these versions, for example upgrading ECK from 2.6 to 2.9, still triggers a rolling restart.

If you have a very large Elasticsearch cluster or multiple Elastic Stack deployments, this rolling restart might be disruptive or inconvenient. To have more control over when the pods belonging to a particular deployment should be restarted, you can <<{p}-exclude-resource,add an annotation>> to the corresponding resources to temporarily exclude them from being managed by the operator. When the time is convenient, you can remove the annotation and let the rolling restart go through.

CAUTION: Once a resource is excluded from being managed by ECK, you will not be able to add/remove nodes, upgrade Stack version, or perform other <<{p}-orchestrating-elastic-stack-applications, orchestration tasks>> by updating the resource manifest. You must remember to remove the exclusion to ensure that your Elastic Stack deployment is continually monitored and managed by the operator.
Expand Down

0 comments on commit d26f3bb

Please sign in to comment.