[1.14] Warn on missing TLS secret #9994
Closed
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.
Backport #9974
Description
Updates the condition of a VirtualService referencing a TLS secret that does not exist from an error state to a warning state. This is to allow for eventual consistency with VS creation and TLS secret creation.
Fill out any of the following sections that are relevant and remove the others
API changes
Code changes
Test changes
[Describe] Kube2e: gateway [Context] Validation configuration [When] allowWarnings=false [Context] secret validation
Docs changes
TODO
Context
Users ran into this eventual consistency issue when applying a cert-manager
Certificate
resource at the same time as aVirtualService
resource. Because theCertificate
does not synchronously create the TLS secret, theVirtualService
is rejected by validation.Testing steps
# if you don't have a cluster, create one kind create cluster
# curl to validate that we're getting traffic curl -k --connect-to vs-1:8443:127.0.0.1 https://vs-1:8443
# curl to show we are still receiving traffic curl -k --connect-to vs-1:8443:127.0.0.1 https://vs-1:8443
# restart gloo deployment to roll the pod k rollout restart deploy/gloo -n gloo-system k rollout status deploy/gloo -n gloo-system
# curl to show that we are NO LONGER receiving traffic, even on the good VS curl -k --connect-to vs-1:8443:127.0.0.1 https://vs-1:8443
# restart gloo deployment to roll the pod k rollout restart deploy/gloo -n gloo-system k rollout status deploy/gloo -n gloo-system
# curl to show that we are receiving traffic on the good VS, but not on the invalid VS curl -k --connect-to vs-1:8443:127.0.0.1 https://vs-1:8443 curl -k --connect-to vs-2:8443:127.0.0.1 https://vs-2:8443
# curl to show that we are receiving traffic on both, now valid VS curl -k --connect-to vs-1:8443:127.0.0.1 https://vs-1:8443 curl -k --connect-to vs-2:8443:127.0.0.1 https://vs-2:8443
Checklist: