5th chunk of `content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md`
3a9a9d432dfca11f71f41177ed8159cc5c4ba1d59636abdf00000001000008a2
Notice that this time we use the istioctl kube-inject command to modify bookinfo-v1.yaml before creating the deployments. It injects the Envoy sidecar into the Kubernetes pods as documented [here](https://istio.io/docs/reference/commands/istioctl.html#istioctl-kube-inject). Consequently, all of the microservices are packaged with an Envoy sidecar that manages incoming and outgoing traffic for the service.
In the Istio service mesh we will not want to access the application **productpage** directly, as we did in plain Kubernetes. Instead, we want an Envoy sidecar in the request path so that we can use Istio’s management features (version routing, circuit breakers, policies, etc.) to control external calls to **productpage** , just like we can for internal requests. Istio’s Ingress controller is used for this purpose.
To use the Istio Ingress controller, we need to create a Kubernetes [Ingress resource](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo-ingress.yaml) for the app, annotated with kubernetes.io/ingress.class: "istio", like this:
```
cat \<\<EOF ``` kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: bookinfo
annotations:
kubernetes.io/ingress.class: "istio"
spec:
rules:
- http:
paths:
- path: /productpage
backend:
serviceName: productpage
servicePort: 9080
- path: /login
backend:
serviceName: productpage
servicePort: 9080
- path: /logout
backend:
serviceName: productpage
servicePort: 9080
EOF
```
The resulting deployment with Istio and v1 version of the bookinfo app looks like this:

This time we will access the app using the NodePort address of the Istio Ingress controller:
```
export BOOKINFO\_URL=$(kubectl get po -l istio=ingress -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc istio-ingress -o jsonpath={.spec.ports[0].nodePort})