Wait for the Envoy proxy Deployment in the Gateway WAF tutorial - #2936
Merged
ctauchen merged 1 commit intoAug 21, 2026
Merged
Conversation
The tutorial sent its first request right after waiting on the Gateway's Accepted condition. Accepted only means the Gateway passed validation, so the request can land before Envoy is serving and fail with a connection error. Measured on a 3.24 cluster: Accepted goes True about 2 seconds after the Gateway is applied, while the first successful request needs about 21 seconds. Waiting on the Envoy proxy Deployment's Available condition returns at 20.2 seconds, one second before traffic starts flowing.
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves the Calico Enterprise Gateway WAF tutorial reliability by adding an explicit readiness gate for the Envoy proxy Deployment, reducing the chance that the first request test fails due to the proxy not being fully started yet.
Changes:
- Add a
kubectl wait --for=condition=Availablestep that waits for the Envoy proxy Deployment created for the Gateway. - Apply the same change to both the
next(unversioned) andversion-3.24-1tutorial copies.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| calico-enterprise/threat/gateway-waf/tutorial.mdx | Adds a wait step for the Envoy proxy Deployment to be Available before sending test traffic. |
| calico-enterprise_versioned_docs/version-3.24-1/threat/gateway-waf/tutorial.mdx | Mirrors the same Deployment readiness wait step for the 3.24-1 versioned docs. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+117
to
+118
| At this point `Accepted` only means Gateway passed validation. Let's now wait for the Envoy proxy | ||
| Deployment that Ingress Gateway creates: |
Comment on lines
+117
to
+118
| At this point `Accepted` only means Gateway passed validation. Let's now wait for the Envoy proxy | ||
| Deployment that Ingress Gateway creates: |
Collaborator
|
LGTM, pending clean build. Are you ready to merge? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Product Version(s):
Calico Enterprise 3.24 (both
nextandversion-3.24-1; the two files were byte-identical, so the change is the same in each)Issue:
None. Found while running the tutorial end to end on a fresh 3.24 cluster.
Link to docs preview:
To be added once the Netlify deploy preview builds. The page is
calico-enterprise/threat/gateway-waf/tutorial.SME review:
DOCS review:
Additional information:
Step 2 of the tutorial waits on the Gateway's
Acceptedcondition, then step 3 immediately sends a request through the gateway.Acceptedonly means the Gateway passed validation. Envoy Gateway still has to create the Envoy proxy Deployment, and Envoy still has to finish starting, so that first request can fail with a connection error.I hit this following the tutorial verbatim on a fresh cluster. The first request failed at 39 seconds of gateway pod age and returned 200 on a retry once Envoy had settled.
Timings I measured, with the Gateway applied at a known time and an in-cluster poller requesting the gateway service every 2 seconds:
Accepted=Truelisteners[0]Programmed=TrueProgrammedFalse (AddressNotAssigned)with no load balancer providerAvailable=TrueSo both Gateway conditions fire about 19 seconds too early to be useful as a readiness gate, and the Deployment's
Availablecondition lands one second before traffic starts flowing.The added command waits on the Deployment rather than the pod on purpose.
kubectl waitresolves a label selector once and then watches only the objects it matched at that moment. A pod wait can latch onto a pod that is shutting down from an earlier attempt and then time out while the new pod is already serving. I reproduced that: a pod wait timed out after its full 180 seconds while the gateway was returning 200.There is no race in the added command. Envoy Gateway creates the Deployment within 1 second of the Gateway apply, so the selector always matches something.
Tested on Calico Enterprise
v3.24.0-3.0-calient-0.dev-1305-g13d6dbddb5fd, operatorv1.45.0-0.dev-13-g5615c1ab5e8e, kubectlv1.35.2, on a GCP kubeadm cluster with no load balancer provider.scripts/vale-lint.sh --no-exit --minAlertLevel=warningreports 0 errors, 0 warnings and 0 suggestions on both files.Merge checklist: