Skip to content
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

constant http request errors to external service domain even after modifying DNS record #36768

Closed
fatedier opened this issue Jan 10, 2022 · 7 comments
Labels
area/networking lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while

Comments

@fatedier
Copy link
Contributor

fatedier commented Jan 10, 2022

Bug Description

There are already K8s services with port 80 and protocol HTTP.

Start a new test service written in golang and it will keep sending HTTP requests to xxx.com resolved to an error IP with no response.

Test service always gets 503 connection failure error because of 10s of connection timeout. Then resolve xxx.com to correct IP, I expect the test service can get 200 responses but not. It can't recover anymore.

However, it can be recovered if xxx.com is changed to xxx.com:8080 since the go client will get network errors like connection reset by peer instead of HTTP 503 code response. It can reconnect to a new correct IP.

istioctl proxy-config listeners shows there are 80 listeners and not for 8080.

0.0.0.0        80    Trans: raw_buffer; App: HTTP                                                                    Route: 80
0.0.0.0        80    ALL                                                                                             PassthroughCluster

For my scenario, there are many services that constantly call external services on port 80 with different hosts. Assume that one external service is down and DNS record is resolved to another IP, internal services will always get 503 HTTP response and can't recover anymore until restart itself(client using keepalive HTTP transport won't disconnect and create a new connection).

Without istio, internal service can recover after the DNS record is resolved to correct IP.

Version

Istio
client version: 1.12.1
control plane version: 1.12.1
data plane version: 1.12.1 (3 proxies)

K8s version 1.16.15

Additional Information

No response

@howardjohn
Copy link
Member

Is your application re-resolving DNS? Or it holds open connection to envoy, getting all 503s, so never re-resolves?

@fatedier
Copy link
Contributor Author

Is your application re-resolving DNS? Or it holds open connection to envoy, getting all 503s, so never re-resolves?

It's a simple go HTTP client and will keep open connection to envoy because there are always HTTP requests on this connection getting 503s.

@howardjohn
Copy link
Member

I opened envoyproxy/envoy#19458, this cannot be done without Envoy changes. Or explicitly make a https://istio.io/docs/reference/config/networking/service-entry/ for each domain

@fatedier
Copy link
Contributor Author

Thanks for your quick response.

I have read about ServiceEntry, but we can't use it simply because it's difficult to list all domains used by all services in production environment.

Hope envoy changes can fix this issue.

@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Apr 11, 2022
@fatedier
Copy link
Contributor Author

Not stale

1 similar comment
@zirain
Copy link
Member

zirain commented Apr 18, 2022

Not stale

@zirain zirain removed the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Apr 18, 2022
@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Jul 17, 2022
@istio-policy-bot istio-policy-bot added the lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. label Aug 1, 2022
@ramaraochavali ramaraochavali removed the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Jan 25, 2023
@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Apr 26, 2023
@istio-policy-bot
Copy link

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2023-01-25. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while
Projects
None yet
Development

No branches or pull requests

5 participants