Skip to content
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

docs: add cluster warming information #541

Merged
merged 3 commits into from
Mar 14, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/root/configuration/cluster_manager/cluster_stats.rst
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,8 @@ statistics. Any ``:`` character in the stats name is replaced with ``_``.
cluster_added, Counter, Total clusters added (either via static config or CDS)
cluster_modified, Counter, Total clusters modified (via CDS)
cluster_removed, Counter, Total clusters removed (via CDS)
total_clusters, Gauge, Number of currently loaded clusters
active_clusters, Gauge, Number of currently active (warmed) clusters
warming_clusters, Gauge, Number of currently warming (not active) clusters

Every cluster has a statistics tree rooted at *cluster.<name>.* with the following statistics:

Expand Down
23 changes: 23 additions & 0 deletions docs/root/intro/arch_overview/cluster_manager.rst
Original file line number Diff line number Diff line change
Expand Up @@ -24,3 +24,26 @@ distribution.

* Cluster manager :ref:`configuration <config_cluster_manager>`.
* CDS :ref:`configuration <config_cluster_manager_cds>`.

Cluster warming
---------------

When clusters are initialized both at server boot as well as via CDS, they are "warmed." This means
that clusters do not become available until the following operations have taken place.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not immediately clear what availability implies.. Does cluster unavailability imply that:

  • routes that reference the cluster fail validate_clusters check, and
  • listeners that reference the cluster remain in the warming state?


* Initial service discovery load (e.g., DNS resolution, EDS update, etc.).
* Initial active :ref:`health check <arch_overview_health_checking>` pass if active health checking
is configured. Envoy will send a health check request to each discovered host to determine its
initial health status.

The previous items ensure that Envoy has an accurate view of a cluster before it begins using it
for traffic serving.

When discussing cluster warming, the cluster "becoming available" means:

* For newly added clusters, the cluster will not appear to exist to the rest of Envoy until it has
been warmed. I.e., HTTP routes that reference the cluster will result in either a 404 or 503
(depending on configuration).
* For updated clusters, the old cluster will continue to exist and serve traffic. When the new
cluster has been warmed, it will be atomically swapped with the old cluster such that no
traffic interruptions take place.