-
Notifications
You must be signed in to change notification settings - Fork 5.5k
sds: keep warming when dynamic inserted cluster can't be extracted secret entity #13894
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
Changes from 45 commits
b882bde
7e9332d
8e99e81
478f578
b4af995
8cda02f
5841c9e
99276bc
6e95a07
3c600ec
fa718a9
cb5a373
456b5b9
b77dae0
c24b729
476d706
96a71c4
3a2cfea
34ea49c
b2b99be
5bbae5f
1e4f950
31354e4
39606e6
0ad2773
186c305
5f83864
1cdfbe6
0e237a1
2a46a40
231bfff
3c6902f
d05a1a3
a4fcf00
1575c36
a18c4a6
9fb4528
fb056ad
31bfe83
6ff7ae2
d1cf6a2
37a272f
c83b7c8
85639eb
edead46
150a789
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -431,6 +431,19 @@ void ClusterManagerImpl::onClusterInit(Cluster& cluster) { | |
| // We have a situation that clusters will be immediately active, such as static and primary | ||
| // cluster. So we must have this prevention logic here. | ||
| if (cluster_data != warming_clusters_.end()) { | ||
| if (Runtime::runtimeFeatureEnabled( | ||
| "envoy.reloadable_features.cluster_keep_warming_no_secret_entity") && | ||
| !cluster.info()->transportSocketMatcher().factoriesReady()) { | ||
| // If `envoy.reloadable_features.cluster_keep_warming_no_secret_entity` is enabled, | ||
| // when a cluster depends on a SDS secret but the secret entity is not ready, instead of | ||
| // marking it active immediately, keep it warming until the next CDS update. This let | ||
| // keep Envoy not advertise itself in ready state so it won't get traffic in deployments | ||
|
Shikugawa marked this conversation as resolved.
Outdated
|
||
| // with readiness probes that checks the state. | ||
| // TODO(lizan): #13777/#13952 In long term we want to fix this behavior with init manager | ||
| // to keep clusters in warming state until Envoy get SDS response. | ||
| ENVOY_LOG(warn, "Failed to activate {} due to no secret entity", cluster.info()->name()); | ||
| return; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still don't understand how this blocks initialization. Unless I am missing something, the ClusterManagerInitHelper will still complete initialization with this early return. This will cause workers to start, etc., leading to 503s. If this is not the case can you update the comments? This will block warming -> active in a subsequent CDS update, which is marginally better, but I don't think it fixes the problem of server init?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add the additional comment from the offline:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right. That's what I thought. |
||
| } | ||
| clusterWarmingToActive(cluster.info()->name()); | ||
| updateClusterCounts(); | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.