The Travel Demo has been deployed in the previous step but without installing any Istio sidecar proxy.
In that case, the application won’t connect to the control plane and won’t take advantage of Istio’s features.
In Kiali, we will see the new namespaces in the overview page:
But we won’t see any traffic in the graph page for any of these new namespaces:
If we examine the Applications, Workloads or Services page, it will confirm that there are missing sidecars:
In this tutorial, we will add namespaces and workloads into the ServiceMesh individually step by step.
This will help you to understand how Istio sidecar proxies work and how applications can use Istio’s features.
We are going to start with the control workload deployed into the travel-control namespace:
Step 1Enable Auto Injection on the travel-control namespace
Step 2Enable Auto Injection for control workload
Understanding what happened:
Open Travel Demo to Outside Traffic
The control workload now has an Istio sidecar proxy injected but this application is not accessible from the outside.
In this step we are going to expose the control service using an Istio Ingress Gateway which will map a path to a route at the edge of the mesh.
Step 1Create a DNS entry for the control service associated with the External IP of the Istio Ingress
MinikubeKubernetes Service EXTERNAL-IP for “LoadBalancer” TYPE is provided in minikube plaform using the minikube tunnel tool.
For minikube we will check the External IP of the Ingress gateway:
$ kubectl get services/istio-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.101.6.144 10.101.6.144 15021:30757/TCP,80:32647/TCP,443:30900/TCP,31400:30427/TCP,15443:31072/TCP 19h
And we will add a simple entry to the
/etc/hosts of the tutorial machine with the desired DNS entry:
Then, from this machine, the url
control.travel-control.istio-cluster.org will resolve to the External IP of the Ingress Gateway of Istio.
OpenShiftOpenShift does not provide the Kubernetes Service EXTERNAL-IP for “LoadBalancer” TYPE. Instead, you can expose the istio-ingressgateway service.
For OpenShift we will expose the Ingress gateway as a service:
$ oc expose service istio-ingressgateway -n istio-system
$ oc get routes -n istio-system
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
istio-ingressgateway <YOUR_ROUTE_HOST> istio-ingressgateway http2 None
Then, from this machine, the host <YOUR_ROUTE_HOST> will resolve to the External IP of the Ingress Gateway of Istio. For OpenShift we will
not define a DNS entry, instead, where you see
control.travel-control.istio-cluster.org in the steps below, subsitute the value of <YOUR_ROUTE_HOST>.
Step 2Use the Request Routing Wizard on the control service to generate a traffic rule
Use “Add Route Rule” button to add a default rule where any request will be routed to the control workload.
Use the Advanced Options and add a gateway with host
control.travel-control.istio-cluster.org and create the Istio config.
Verify the Istio configuration generated.
Step 3Test the control service by pointing your browser to
Step 4Review travel-control namespace in Kiali
Understanding what happened:
- External traffic enters into the cluster through a Gateway
- Traffic is routed to the control service through a VirtualService
- Kiali Graph visualizes the traffic telemetry reported from the control sidecar proxy
- Only the travel-control namespace is part of the mesh