You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Overview of the Issue
So a couple of problem with ServiceRouter CRDs in consul-k8s, I will try to summarize them all in this ticket because they are somewhat related and probably fixed with the same effort on your side.
When specifying routes[].destination.requestTimeout, if I specify it as 180s, consul-k8s will actually make that 3m0s so when we are using tools like ArgoCD to make sure manifests are not changes, that causes diff between the manifest we submitted as 180s and what is persistent in the CRD: 3m0s. That is kind of easy to work around by changing our manifests to use 180s but this leads to number 2)
It seems like we always have to specify idleTimeout: 0s because if we do not specify it, the CRD defaults to it anyway and also causes diffs in ArgoCD. Again, we have to work around it by asking engineers to add that value even though it does not make sense for their destination logic.
Which leads us to the main problem which is the fact that when we are running in WAN federation, there is only ever one admin partition and that is called "default". consul-k8s has a problem where it defaults the partition to empty value but Consul sever 1.5.x sets it as the value default so your configEntry.MatchesConsul(entry) check fails even though nothing is different between Consul and Kubernetes.
If we just decide to set partition: default in our CRDs without any of the above patches, we get this error:
error when replacing "/dev/shm/2022498401": admission webhook "mutate-servicerouter.consul.hashicorp.com" denied the request: servicerouter.consul.hashicorp.com "feature-flags-http-with-migrations" is invalid: spec.routes[0].destination.partition: Invalid value: "default": Consul Enterprise partitions must be enabled to set destination.partition
So, we cannot use admin partitions because we use -WAN federation but Consul is setting the partition to default but consul-k8s does not think partitions are enabled, so it is kind of a vicious cycle.
Community Note
Overview of the Issue
So a couple of problem with ServiceRouter CRDs in consul-k8s, I will try to summarize them all in this ticket because they are somewhat related and probably fixed with the same effort on your side.
routes[].destination.requestTimeout
, if I specify it as180s
, consul-k8s will actually make that3m0s
so when we are using tools like ArgoCD to make sure manifests are not changes, that causes diff between the manifest we submitted as180s
and what is persistent in the CRD:3m0s
. That is kind of easy to work around by changing our manifests to use180s
but this leads to number 2)idleTimeout: 0s
because if we do not specify it, the CRD defaults to it anyway and also causes diffs in ArgoCD. Again, we have to work around it by asking engineers to add that value even though it does not make sense for their destination logic.Which leads us to the main problem which is the fact that when we are running in WAN federation, there is only ever one admin partition and that is called "default". consul-k8s has a problem where it defaults the partition to empty value but Consul sever 1.5.x sets it as the value
default
so yourconfigEntry.MatchesConsul(entry)
check fails even though nothing is different between Consul and Kubernetes.Running a
diff
instead ofcmp
shows the problem:Reproduction Steps
Expected behavior
Expected was to not have an infinity sync loop in the consul-connect-injector pods.
Environment details
consul-k8s version 1.2.3
Additional Context
This is the diff that I was able to at least stop it from syncing all the time:
The text was updated successfully, but these errors were encountered: