I have an Openshift 4.6 platform running an applicative pod.
We use postman to send request to the pod.
The applicative pod return a 200 http response code, but get a 502 in postman.
So there is a interim component inside OpenShift/K8s that should transform the 200 into a 502.
Is there a way to debug/trace more information in Egress ?
Thanks
Nicolas
The HTTP 502 error is likely returned by the OpenShift Router that is forwarding your request to your application.
In practice this often means that the OpenShift Router (HAProxy) is sending the request to your application and it does not receive any or an unexpected answer from your application.
So I would recommend that you check your applications logs if there is any error in your application and if your application returns a valid HTTP answer. You can test this by using curl localhost:<port> from your application Pods to see if there is a response being returned.
Related
Problem statement:
My goal is to have istio with external authorization service (ideally HTTP, if not possible than GRPC would do as well). There is a requirement to be able to control what exact status code will be returned to client on authorization service. The latter requirement is the most problematic part.
My research
I have read istio documentation on external authorizer
I have made a prototype with HTTP Auth service, but whatever non 200 status
code I return from Auth Service the client always receives 403
Forbidden
In mesh config specification I see the only possibility to set statusOnError but it will be used only in case auth service is unreachable and it can not be dynamically changed.
Also in envoy documentation for GRPC service I see possibility to set custom status
HTTP attributes for a denied response.
{
"status": "{...}",
"headers": [],
"body": "..."
}
Questions:
Is having custom status possible only with GRPC auth service?
Is istio using envoy API-V3 or API-V2?
Any suggestion how to cook istio with external authorizer and custin status codes?
I made the GRPC Auth service prototype and found the answer. It is counter-intuitive but GRPC external auth service is really more flexible than HTTP one. And it really allows to set arbitrary status code
i have a microservices architecture deployed. I have several worker, and ambassador as a gateway. My problem is i got error log http 5xx, but i don't know what is the payload of the request. So i can't reproduce the error.
Is there any way to dump payload at ambassador/envoy when there is 5xx request?
I am creating istio service mesh and then trying to call an external service from istio pod.
I followed steps in link
https://istio.io/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/
till
2 Verify that your ServiceEntry was applied correctly by sending a request to http://edition.cnn.com/politics.
but in place of "edition.cnn.com", used my service.
When I try to do curl inside my pod, I am getting the below error.
[2020-02-02T10:02:52.465Z] "GET / HTTP/1.1" 503 UF,URX "-" "-" 0 91 150 - "-" "curl/7.58.0" "fafa8680-bdf1-468a-b50f-1a4430707ceb" "service.abc.com" "173.25.13.66:80" outbound|80||service.abc.com - 173.25.13.66:80 10.44.0.6:47544 - default
I can ping to service.abc.com, but how do I debug this error, and how to get more logs for analysis? As it did not mention to create steps for mtls and destination rules in above link, I did not create them.
Note: I am not facing any issue with edition.cnn.com, but getting issues when using my service which is external to mesh and is running in another server within my company network.
service.abc.com service supports only http or only https or both http and https? Is it configured to redirect http to https ? if you hit an endpoint with http and if its neither listening on port 80 nor redirecting http to https you are expected to get 503.
If you follow all the steps till 5 in the doc and assuming that service.abc.com is a https service it should work as expected because at step 5 even if you are sending a http request istio egress gateway is going to convert it to https(TLS origination) before it sends out the request to service.abc.com.
Busy building an API, and some parts of our API heavily depend on a third party.
When we are unable to connect to the 3rd party, or the connection fails, I simply returned an error 500. However, I was wondering if it wouldn't make more sense to return a 502 Bad Gateway or a 504 Gateway Timeout?
However, my interpretation is that it could only be relevant for proxies, and not for API's?
In that case I would suggest to use 503 Service Unavailable and use the Retry-After Header to specify the time the client should wait before retrying.
When it's a matter of RESTful APIs I always check this super complete guide, which contains all the answers for all the all the questions you will ever imagine.
Service Unavailable - service is (temporarily) not available (e.g. if a required component or downstream service is not available) — client retry may be sensible. If possible, the service should indicate how long the client should wait by setting the Retry-After header.
I am trying to create a service that has 2 dependencies. One of the dependencies is internally managed while the 2nd requires an external http outbound call to a third party API. The sequence requires the updating the resource and then executing the http outbound call.
So my question is, on the event of a failure on the 2nd step, what is the correct http status code to return?
Should the response be 424 or 500 with a message body explaining the encountered error?
424: Method Failure - Indicates the method was not executed on a particular resource within its scope because some part of the method's execution failed causing the entire method to be aborted.
500: Internal Server Error.
The failure you're asking about is one that has occurred within the internals of the service itself, so a 5xx status code range is the correct choice. 503 Service Unavailable looks perfect for the situation you've described.
5xx codes are for telling the client that even though the request was fine, the server has had some kind of problem fulfilling the request. On the other hand, 4xx codes are used to tell the client it has done something wrong (and that the server is just fine, thanks). Sections 10.4 and 10.5 of the HTTP 1.1 spec explain the different purposes of 4xx and 5xx codes.
Status code 424 is defined in the WebDAV standard and is for a case where the client needs to change what it is doing - the server isn't experiencing any problem here.
As second operation is an external service call, you should choose 502 or 504 according to the situations.
Quoted from: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3
10.5.3 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
10.5.5 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to
return 400 or 500 when DNS lookups time out.
503 Service Unavailable is appropriate if the issue is one that the server expects to be alleviated (such as if it gets a 503 from the upstream server, for instance). 502 Bad Gateway should be used for unknown errors from an upstream server, where you don't know how to respond.