I am trying to implement the retry feature in VirtualService for egress traffic external to the mesh. This does not seem to work. Should we always configure egress gateway for retry to work?
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin-external
spec:
hosts:
- httpbin.org
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: tls
protocol: TLS
resolution: DNS
location: MESH_EXTERNAL
exportTo:
- "."
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: external-httpbin
spec:
hosts:
- httpbin.org
http:
- timeout: 3s
route:
- destination:
host: httpbin.org
weight: 100
retries:
attempts: 5
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream,retriable-4xx,5xx
virtual service you had shared doesn't have egress gateway linked to it.
gateways:
istio-egressgateway
Related
I tried with this Gateway, and VirtualService, didn't work.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: stomp
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: stomp
protocol: TCP
hosts:
- rmq-stomp.mycompany.com
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: rmq-stomp
spec:
hosts:
- rmq-stomp.mycompany.com
gateways:
- stomp
http:
- match:
- uri:
prefix: /
route:
- destination:
port:
number: 61613
host: rabbitmq.default.svc.cluster.local
There's no problem with the service, because when I tried to connect from other pod, it's connected.
Use tcp.match, not http.match. Here is the example I have found in istio gateway docs and in istio virtualservice dosc
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-mongo
namespace: bookinfo-namespace
spec:
hosts:
- mongosvr.prod.svc.cluster.local # name of internal Mongo service
gateways:
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same namespace as virtual service.
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.prod.svc.cluster.local
port:
number: 5555
So your would look sth like:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: rmq-stomp
spec:
hosts:
- rmq-stomp.mycompany.com
gateways:
- stomp
tcp:
- match:
- port: 80
route:
- destination:
host: rabbitmq.default.svc.cluster.local
port:
number: 61613
Here is a similar question answered: how-to-configure-istios-virtualservice-for-a-service-which-exposes-multiple-por
I’m working on setting up an Egress Gateway. I have a simple one that handles traffic for one host configured based on the Istio docs, so that part is fine. But when I look at how to handle multiple hosts, I find this verbiage:
To direct multiple hosts through an egress gateway, you can include a
list of hosts, or use * to match all, in the Gateway. The subset
field in the DestinationRule should be reused for the additional
hosts.
On this Istio docs page.
Unfortunately I have no idea what the second part of that actually means: "The subset field in the DestinationRule should be reused for the additional hosts." To be honest, I don't entirely understand how DR's work with EgressGateway's in general. I'm more used to a DR that specifies a set of pods as it's target in the "subset" field. So I don't quite get how the DR connections a specific host to the Gateway. I tried the following, but this doesn't work:
egress-gateway.yml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
namespace: env-specific-egress-experiments
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- news.ycombinator.com
- www.slashdot.org
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: env-specific-egressgateway-dr
namespace: env-specific-egress-experiments
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: hn
- name: slashdot
service-entries.yml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: news-ycombinator-com
namespace: env-specific-egress-experiments
spec:
hosts:
- news.ycombinator.com
ports:
- number: 80
name: http-port-hn
protocol: HTTP
- number: 443
name: https-port-hn
protocol: HTTPS
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: www-slashdot-org
namespace: env-specific-egress-experiments
spec:
hosts:
- www.slashdot.org
ports:
- number: 80
name: http-port-slashdot
protocol: HTTP
- number: 443
name: https-port-slashdot
protocol: HTTPS
resolution: DNS
virtual-service.yml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: external-service-vs-hn
namespace: env-specific-egress-experiments
spec:
hosts:
- news.ycombinator.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
- port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: hn
port:
number: 80
rewrite:
authority: news.ycombinator.com
- match:
- gateways:
- istio-egressgateway
port: 80
route:
- destination:
host: news.ycombinator.com
port:
number: 80
weight: 100
rewrite:
authority: news.ycombinator.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: external-service-vs-slash
namespace: env-specific-egress-experiments
spec:
hosts:
- www.slashdot.org
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
- port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: slashdot
port:
number: 80
rewrite:
authority: www.slashdot.org
- match:
- gateways:
- istio-egressgateway
port: 80
route:
- destination:
host: www.slashdot.org
port:
number: 80
weight: 100
rewrite:
authority: www.slashdot.org
If I try to curl one of the hosts with this configuration, I get
/ # curl http://news.ycombinator.com
/ # curl -SsL -D - http://news.ycombinator.com
HTTP/1.1 503 Service Unavailable
date: Tue, 23 Feb 2021 19:27:49 GMT
server: envoy
x-envoy-upstream-service-time: 45
content-length: 0
Also, just as an FYI, a few additional points:
This is just a simulation of part of what I'm trying to accomplish. Obviously I don't really care about connecting to HN or /. Those are just stand-ins for external sites in general
Long-term, the goal is to put an abstract name in front of a external service that can vary in terms of the actual host, based on the deployment. Eg, if I deploy qa-deployment.yml, then "mongodatabase" actually points to mongo.qa.mycompany.com, and if I deploy int-deployment.yml, "mongodatabase" points to mongo.int.mycompany.com, and so on. I think I can accomplish this part with an ExternalName service, and/or a ClusterIP that "floats" and doesn't point to any pods, but is just there for DNS resolution so the VirtualService can trigger.
Ultimately I want all outgoing traffic to go through an EgressGateway. But there will be multiple "things" that need to go through it, hence the particular point I'm stuck on now, which is getting the EgressGateway to work with multiple hosts.
Istio allows you to route a http request in a VirtualService to an external host provided a ServiceEntry exists. For example:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin-ext
spec:
hosts:
- httpbin.org
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- httpbin.domain.co
gateways:
- public-gateway.istio-system.svc.cluster.local
- mesh
http:
- match:
- gateways:
- public-gateway.istio-system.svc.cluster.local
port: 443
host: httpbin.domain.co
route:
- destination:
host: httpbin.org
port:
number: 80
However this only allows for a HTTP endpoint - how do I configure the external endpoint to be TLS/HTTPS?
This took me hours to work out - so worth sharing I feel.
In order to terminate this service as a TLS, a Destination Rule is required. My final config:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin-ext
spec:
hosts:
- httpbin.org
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS
location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- httpbin.domain.co
gateways:
- public-gateway.istio-system.svc.cluster.local
- mesh
http:
- match:
- gateways:
- public-gateway.istio-system.svc.cluster.local
port: 443
host: httpbin.domain.co
- gateways:
- public-gateway.istio-system.svc.cluster.local
port: 80
host: httpbin.domain.co
route:
- destination:
host: httpbin.org
port:
number: 443
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: httpbin-org
spec:
host: httpbin.org
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE
It there a way to use some kind of dynamic port mapping in the following scenario
(Istio > Kubernetes service):
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-virtualservice
spec:
hosts:
# my-service.default.svc.cluster.local ?
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /somepath/
route:
- destination:
host: my-service
And when using Istio, the end user do not need to know the port, and therefore is possible to create and use a dynamic free port?
Defining a service:
# K8s - Service
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- name: my-port
port: #*** Dynamic port? ***#
targetPort: 80
I am currently trying to configure Control Egress Traffic to be able to access external services in https specifically with hashicorp Vault which runs on port 8200.
Below I attach the detail of my virtual service and service entry
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: vault-se
spec:
hosts:
- vault.x.com
ports:
- number: 8200
name: https
protocol: HTTPS
resolution: DNS
location: MESH_EXTERNAL
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: vault-vs
spec:
hosts:
- vault.x.com
tls:
- match:
- port: 8200
sni_hosts:
- vault.x.com
route:
- destination:
host: vault.x.com
port:
number: 8200
weight: 100
Any idea where my fault is?