Simplifying Microservices with Istio in Google Kubernetes Engine — Part II

What I write about Istio is a subset of the awesome documentation that is on the Istio site. Please read the official docs to understand more.

In Part I of this series, we saw how we could use Istio to simplify communication between our microservices.

In this part, we’ll see how services within the Istio Service Mesh communicate with external services over HTTPS

Figure 1: Logical view of the service communication model

In Figure 1 above, our PetService (that talks to the PetDetailsService and the PetMedicalHistoryService) will now also invoke an external service located at https://thedogapi.co.uk/ that returns dog image urls.

The external service communication from within the Istio Service Mesh is shown in Figure 2 below.

• As always, all communication between the services within the service mesh is through the proxies over HTTP
• To communicate with external services over HTTPS, the internal service will still send HTTP requests which are intercepted by the sidecar proxy that does TLS origination and communicates with the external service over an encrypted channel.

Figure 2: Istio Service Mesh representation of the communication with external services

Github repo

The petservice code to do this looks like:

Note: see how we invoke the https url for the DogAPI as http://api.thedogapi.co.uk:443/v2/dog.php

Let’s see what happens when we run the following command where 108.59.82.93 is the Ingress IP address.(see Part I)

curl http://108.59.82.93/pet/123

The response looks like:

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  },
  "dogAPIResponse": {
    "message": "request to https://api.thedogapi.co.uk/v2/dog.php failed, reason: read ECONNRESET",
    "type": "system",
    "errno": "ECONNRESET",
    "code": "ECONNRESET"
  }
}

You will notice in the above response that the dogAPIResponse (not the most original name) section has an error when our petservice tries to access the external service located at https://api.thedogapi.co.uk

This is because all the external traffic (egress) is blocked by default. The sidecar proxy explained in the previous article, allows communication only within the cluster.

Note: As I had mentioned in Part I, this restriction is quite helpful, when we want to govern the way our services talk to external services and prevent any unauthorized communication with outside systems.

Healthcare/Financial systems can especially leverage this feature to protect PHI/PII data from being shared inadvertently or even maliciously from internal services.

To enable egress traffic, you would need to create an egress rule as follows:

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
  name: dogapi-egress-rule
spec:
  destination:
    service: api.thedogapi.co.uk
  ports:
    - port: 443
      protocol: https
EOF

To check if this egress rule has been created, you can run the following command and you should see the egress rule dogapi-egress-rule has been created.

kubectl get egressrule
NAME                 AGE
dogapi-egress-rule   5m

Let’s try the above curl command again:

$ curl http://108.59.82.93/pet/123
{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  },
  "dogAPIResponse": {
    "count": 1,
    "api_version": "v2",
    "error": null,
    "data": [
      {
        "id": "rCaz-LNuzCC",
        "url": "https://i.thedogapi.co.uk/rCaz-LNuzCC.jpg",
        "time": "2017-08-30T21:43:03.0",
        "format": "jpg",
        "verified": "1",
        "checked": "1"
      }
    ],
    "response_code": 200
  }
}

And it works! You can see a sample url for a pet image returned in the DogAPI response.

Conclusion: We saw how we can enable communication from the service mesh to external services by creating explicit rules.

In subsequent articles, we will see how to do other important tasks such as traffic routing and ramping, using circuit breakers etc.

Resources:

1. Part I of this article series: https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-i-849555f922b8
2. The Istio home page https://istio.io/
3. DevOxx Istio presentation by Ray Tsang: https://www.youtube.com/watch?v=AGztKw580yQ&t=231s
4. Github link to this example: https://github.com/nmallya/istiodemo
5. All things Kubernetes: https://kubernetes.io/
6. The DogAPI page: https://thedogapi.co.uk/