Add a new version of reviews

Deploy the new version of the reviews microservice without the app=reviews label. Without that label, the new version will not be selected to provide the reviews service. As such, it will not be called by the production code. Run the following command to deploy the reviews microservice version 2, while replacing the label app=reviews by app=reviews_test:
Access your application to ensure the deployed microservice did not disrupt it.
Test the new version of your microservice from inside the cluster using the testing container you deployed earlier. Note that your new version accesses the production pods of the ratings microservice during the test. Also note that you have to use the pod IP to access your new version of the microservice, because it is not selected for the service.
1. Get the IP of the pod:
```
$ REVIEWS_V2_POD_IP=$(kubectl get pod -l app=reviews_test,version=v2 -o jsonpath='{.items[0].status.podIP}')
$ echo $REVIEWS_V2_POD_IP
```
2. Send a request to the pod and see that it returns the correct result:
```
$ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl -sS "$REVIEWS_V2_POD_IP:9080/reviews/7"
```
3. Perform primitive load testing by sending a request 10 times in a row:
The previous steps ensure that your new version of reviews will work and you can deploy it. You will deploy a single replica of the service into production so the real production traffic will start to arrive to your new service version. With the current setting, 75% of the traffic will arrive to the old version (three pods of the old version) and 25% will arrive to the new version (a single pod).

To deploy reviews v2, redeploy the new version with the app=reviews label, so it will become addressable by the reviews service.
```
$ kubectl label pods -l version=v2 app=reviews --overwrite
```
Bookinfo Web Application with black stars as ratings
If you encounter any problems with the new version in a real-world scenario, you could quickly undeploy the new version, so only the old version will be used:
```
$ kubectl delete deployment reviews-v2
$ kubectl delete pod -l app=reviews,version=v2
pod "reviews-v2-79c8c8c7c5-4p4mn" deleted
```
Allow time for the configuration change to propagate through the system. Then, access your application’s webpage several times and see that now black stars do not appear.

To restore the new version:

Access your application’s webpage several times and see that now the black stars are present approximately 25% of the time.
Next, increase the replicas of your new version. You can do it gradually, carefully checking that the number of errors does not increase:
```
$ kubectl scale deployment reviews-v2 --replicas=3
deployment.apps/reviews-v2 scaled
```
Now, access your application’s webpage several times and see that the black stars appear approximately half the time.
```
$ kubectl delete deployment reviews-v1
deployment.apps "reviews-v1" deleted
```
Accessing the web page of the application will return reviews with black stars only.

In the previous steps, you performed the update of . First, you deployed the new version without sending it simulated production traffic. You tested it in the production environment using test traffic. You checked that the new version provides correct results. You released the new version, gradually increasing the production traffic to it. Finally, you decommissioned the old version.

From here, you can improve your deployment strategy using the following example tasks. First, test the new version end-to-end in production. This requires the ability to drive traffic to your new version using request parameters, for example using the user name stored in a cookie. In addition, perform shadowing of the production traffic to your new version and check if your new version provides incorrect results or produces errors. Finally, gain more detailed control of the rollout. As an example, you can deploy at 1%, then increase by 1% an hour as long as there does not appear to be degradation in the service. Istio enhances the value of Kubernetes by helping you perform these tasks in a straightforward way. For more detailed information and best practices about deployment, see Deployment models.

From here, you have two choices:

Use a service mesh. In a service mesh, you put all the reporting, routing, policies, security logic in sidecar proxies, injected transparently into your application pods. The business logic remains in the code of the application, no changes are required to the application code.

See to learn how Istio can per can perform the tasks mentioned here and more. In the next modules, you explore various Istio features.

You are ready to enable Istio on productpage.