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
Hi Kong Community,
I'm encountering an issue with Kong 3.7's upstream hash configuration. I'm hoping someone can help me understand why all requests are being routed to the first target when the Hash on header header is missing.
Environment:
Kong Version: 3.7
Upstream Configuration:
{
"hash_fallback": "none",
"name": "admin-scm_Upstream_testaws",
"hash_on_header": "pp-depot-hashid",
"hash_on_query_arg": null,
"id": "1633806f-163a-46dd-ad34-0611cdd1a0ee",
"hash_on_uri_capture": null,
"hash_on_cookie": null,
"hash_on_cookie_path": "/",
"hash_fallback_query_arg": null,
"hash_fallback_uri_capture": null,
"host_header": null,
"client_certificate": null,
"use_srv_name": false,
"tags": ["k8s-1739002503300704098"],
"algorithm": "consistent-hashing",
"slots": 10000,
"hash_on": "header",
"hash_fallback_header": "pp-userid",
"created_at": 1589536188,
"updated_at": 1739002503
}
I have three targets configured for this upstream.
When the pp-depot-hashid header is missing, all requests are being routed to the first target.
This behavior does not occur in Kong 1.5.1, where requests are distributed among all targets when pp-depot-hashid is missing.
Expected Behavior:
When pp-depot-hashid is missing, requests should be distributed among all targets using the default load balancing strategy (e.g., round-robin).
Actual Behavior:
All requests are routed to the first target when pp-depot-hashid is missing.
Steps to Reproduce:
Configure an upstream with hash_on_header: pp-depot-hashid and hash_fallback: none.
Add three targets to the upstream.
Send requests without the pp-depot-hashid header.
Observe that all requests are routed to the first target.
Questions:
Is this a known issue in Kong 3.7?
Are there any configuration changes or workarounds to ensure requests are distributed among all targets when pp-depot-hashid is missing?
Why does this behavior differ from Kong 1.5.1?
Thank you in advance for any insights or assistance!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi Kong Community,
I'm encountering an issue with Kong 3.7's upstream hash configuration. I'm hoping someone can help me understand why all requests are being routed to the first target when the Hash on header header is missing.
Environment:
Kong Version: 3.7
Upstream Configuration:
{
"hash_fallback": "none",
"name": "admin-scm_Upstream_testaws",
"hash_on_header": "pp-depot-hashid",
"hash_on_query_arg": null,
"id": "1633806f-163a-46dd-ad34-0611cdd1a0ee",
"hash_on_uri_capture": null,
"hash_on_cookie": null,
"hash_on_cookie_path": "/",
"hash_fallback_query_arg": null,
"hash_fallback_uri_capture": null,
"host_header": null,
"client_certificate": null,
"use_srv_name": false,
"tags": ["k8s-1739002503300704098"],
"algorithm": "consistent-hashing",
"slots": 10000,
"hash_on": "header",
"hash_fallback_header": "pp-userid",
"created_at": 1589536188,
"updated_at": 1739002503
}
I have three targets configured for this upstream.
When the pp-depot-hashid header is missing, all requests are being routed to the first target.
This behavior does not occur in Kong 1.5.1, where requests are distributed among all targets when pp-depot-hashid is missing.
Expected Behavior:
When pp-depot-hashid is missing, requests should be distributed among all targets using the default load balancing strategy (e.g., round-robin).
Actual Behavior:
All requests are routed to the first target when pp-depot-hashid is missing.
Steps to Reproduce:
Configure an upstream with hash_on_header: pp-depot-hashid and hash_fallback: none.
Add three targets to the upstream.
Send requests without the pp-depot-hashid header.
Observe that all requests are routed to the first target.
Questions:
Is this a known issue in Kong 3.7?
Are there any configuration changes or workarounds to ensure requests are distributed among all targets when pp-depot-hashid is missing?
Why does this behavior differ from Kong 1.5.1?
Thank you in advance for any insights or assistance!
Beta Was this translation helpful? Give feedback.
All reactions