Transitioning Your Service Mesh From IBM Cloud Kubernetes Service Ingress to Istio Ingress
10 min read
Migrating a service mesh from Kubernetes Ingress resources to Istio’s ingress gateway
Through a tremendous collaborative effort between IBM, Google, Lyft, Red Hat, and other members of the open source community, Istio is officially ready for production. Istio adds additional layers of service mesh management on top of those available in Kubernetes and allows developers to connect, secure, and manage microservices. You can learn more about the basics of Istio by reading our post, “What is Istio?”
This tutorial will provide steps for migrating a service mesh from Kubernetes Ingress resources to Istio’s ingress gateway in an IBM Cloud Kubernetes Service environment.
Install Kubernetes CLI
Download and install the IBM Cloud Kubernetes Service CLI
Verify your container-service plugin is version 0.1.558 or later
Created a standard cluster using either the UI or CLI
Configure kubectl to manage your cluster
Install Helm CLI
Download the latest version of Istio
1. Using IBM Kubernetes Service ALB and Kubernetes Ingress resources to access a service
IBM Cloud Kubernetes Service exposes applications deployed within your cluster using Kubernetes Ingress resources. The application load balancer (ALB) accepts incoming traffic and forwards the requests to the corresponding service. Your cluster ALB is assigned a URL to expose the deployed services using the name format <cluster_name>.<region>.containers.appdomain.cloud. Retrieve your cluster’s ingress subdomain and configure this value as an environment variable for the steps that follow:
For this tutorial, we will use a simple HTTP request and response service called httpbin. Begin by deploying a copy of this service to your space in IBM Cloud Kubernetes Service:
Next, apply a Kubernetes Ingress resource to access the httpbin service and expose the /headers API:
The serviceName and servicePort match those specified in the Kubernetes service definition in samples/httpbin/httpbin.yaml. Verify that the httpbin service is now accessible using curl:
2. Chain ALB to Istio ingress gateway
The latest install steps and installation methods for Istio can be found here. This blog will follow the steps for Helm.
2.1 Install Istio using Helm
First, configure Tiller in your cluster:
Next, install Istio’s crds to your cluster:
Then, install the Istio control plane:
Verify Istio is up and running:
Note: If the cluster was created with limited resources, some pods may get stuck in PENDING state, in which case specify the demo profile values file during the install command:
2.2 Inject the httpbin service with Istio
With this configured, your Kubernetes services will automatically get deployed with Istio’s sidecar proxy. Since the httpbin service is already deployed, deleting the httpbin pod will cause it to get redeployed with the sidecar in place:
The httpbin service now has two containers in the pod: httpbin app and istio-proxy sidecar. Verify the new httpbin pod is running and curl the httpbin service again.
Observe the additional headers returned in the response this time around. The Envoy proxy running in the Istio sidecar captures all traffic to the httpbin service, applies any traffic management policies, and then routes the request to the httpbin service.
Note: If Istio was deployed with –set mtls.enabled=true, the curl command above will fail since the Kubernetes Ingress resource does not have mTLS configured between the ALB and httpbin service. This option will be addressed in a follow-up blog.
2.3 Convert the Kubernetes Ingress resource to Istio Gateway and VirtualService rules
The ALB relies on Kubernetes Ingress resources to control how traffic is routed to services deployed in your cluster. In Istio, ingress traffic is configured via Gateways and VirtualServices. Gateways and VirtualServices provide a super set of the functionality provided by the Kubernetes Ingress resource in a more flexible format. In the same way that the routing behavior of the ALB is configured by Kubernetes Ingress resources, Istio uses Gateways and VirtualServices to configure Istio’s ingress gateway. Traffic from outside the Istio service mesh is routed by the ingress gateway:
To make the transition easier for users who may already have Kubernetes Ingress resources defined for their services, Istio provides a converter tool as part of istioctl for migrating Ingress resource definitions to corresponding VirtualServices:
The VirtualService tells Istio which service to route to based on the request host and request path and since “istio-system/istio-autogenerated-k8s-ingress” is specified under gateways, the routing information will only be used with a corresponding Gateway rule named istio-autogenerated-k8s-ingress in the istio-systemnamespace. The Gateway is required to open a port on the Istio ingress gateway for incoming requests but this has already been created during the install process with the
--set global.k8sIngress.enabled=true flag.
Finally, the original Kubernetes Ingress resource needs to be deleted and recreated so that it points to the Istio ingress gateway rather than the httpbin service directly:
Perform the curl command once more to verify that traffic is now routed from the ALB to the Istio ingress gateway and finally the httpbin service.
3. Create a host name to access the Istio ingress gateway directly
IBM Cloud Kubernetes Service allows users to configure a host name which will resolve directly to a Kubernetes network load balancer (NLB) IP. The steps below will enable the Istio ingress gateway to accept web traffic directly instead of first going through the ALB.
3.1 Create a host name for your cluster
First retrieve the NLB IP for the Istio ingress gateway:
Then, create the host name for your cluster:
This will create a host name using the following format:
3.2 Update Istio with the new host name
Replace the original INGRESS_HOST defined in Section 1 with the host name created above.
Modify the VirtualService rule with the updated INGRESS_HOST value
Now, you can curl the Istio ingress gateway directly using the NLB host name provided for your cluster:
With these instructions, existing services can be migrated from the default IBM Cloud Kubernetes Service ALB to using the Istio ingress gateway. After migration is complete, you can begin exploring the additional ingress configuration options for your service mesh available with Istio Gateways and VirtualServices.
What is Istio? (video): https://www.youtube.com/watch?v=1iyFq2VaL5Y&t=1s
Learn more about what you can do with IKS NLB’s: https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer#loadbalancer_hostname_dns
Configure Mutual TLS between the ALB and Istio: Coming Soon