This repo demonstrates an approach to accessing external services from inside a service mesh, and applying some of the traffic management approaches to those services to apps running inside the mesh.
The external services are assumed to be available over HTTPS, proxied by an Istio egress gateway
which makes those services available inside the mesh over HTTP, although traffic inside the mesh
would be secured according to the TLS configuration of the mesh. This allows an Istio VirtualService
to manage the traffic to the external services from the point of view of the mesh workloads, enabling
traffic shifting (not currently working), fault injection, timeouts and retries, and so on.
Included are two apps that can be deployed to Cloud Foundry, where we assume access to those apps is
secured with TLS. The Kubernetes manifests that define the workloads that connect to these Cloud Foundry
services refer to those apps as hello-istio-v1.apps.coachella.cf-app.com and hello-istio-v2.apps.coachella.cf-app.com;
substitute the actual names for these apps in the Kubernetes manifest.
For details of deploying these Cloud Foundry apps, see the README for the Cloud Foundry apps.
To demonstrate connecting to external services and managing traffic, I've included several Kubernetes manifests for three main groupings of resources:
- A proxy, that accepts incoming web requests and returns the result of calling one of the external services
- A caller, that makes regular requests to the proxy
- A set of Istio configuration for re-exposing the external services inside the mesh and applying traffic management patterns
For details of deploying these Kubernetes resources, see the README for the Kubernetes manifests.
This demo relies on Istio being installed in a Kubernetes cluster. It's been tested with Istio 1.12.1 and Kubernetes 1.22.3.
For this demo, Istio must have the egress gateway enabled, as it is when installed using the demo profile.
Istio may be installed with external service passthrough disabled by default (set meshConfig.outboundTrafficPolicy.mode
to REGISTRY_ONLY). This will allow us to validate that our explicit configuration is allowing access
to the external services, rather than access to those services being available by default.
This demo has relied heavily on Istio documentation, in particular:
These together describe the patterns implemented here, which is:
- Allow access to the external services via a
ServiceEntry, and define it inside the mesh on port 80 - Create an egress
Gatewayto route access to the service from inside the mesh - Use a
DestinationRuleto set up TLS origination for the external service - Define a
VirtualServiceto direct traffic from the sidecars to the egress gateway and from the egress gateway to the external service
This allows an application inside the mesh to reference an external service by an arbitrary name, and have its requests to that service traverse the mesh via the Envoy sidecars and be subject to any traffic management or other rules that may be configured.
The result is a traffic flow that looks like this:
traffic --> envoy --> service-that-calls-externally --> app-that-calls-externally --> envoy --> istio-egressgateway --> external service
This demo currently doesn't implement traffic shifting correctly! The following steps describe what to expect when traffic shifting has been implemented.
To check that this demo is working as intended, tail the logs of the traffic pod(s) (kubectl logs deploy/traffic -f).
With the traffic shifting that is set up by default with these Kubernetes resources, the output should
come from a combination of the v1 and v2 services running on Cloud Foundry, with a few occurrences of
HTTP 418 failures (these show up as "fault filter abort"):
2022-02-04T10:34:33+00:00 Hello K8s, from CF v1 service!
2022-02-04T10:34:34+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:35+00:00 Hello K8s, from CF v1 service!
2022-02-04T10:34:36+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:37+00:00 fault filter abort
2022-02-04T10:34:38+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:39+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:40+00:00 Hello K8s, from CF v1 service!
2022-02-04T10:34:41+00:00 Hello K8s, from CF v1 service!
2022-02-04T10:34:42+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:43+00:00 Hello K8s, from CF v2 service!
2022-02-04T10:34:44+00:00 fault filter abort
2022-02-04T10:34:45+00:00 Hello K8s, from CF v1 service!