anchor.diff:  +
   Now all pods are serving `v2` version of the Deployment.
   
  -=== Ingress Controller
  -
  -Achieving right percentage of traffic using Deployment and Service requires spinning-up as many pods as necessary. For example, if the version `v1` has 4 replicas of a pod. Then, in order to direct 5% traffic to the version `v2`, 1 pod replica of `v2` version would require 16 more replicas of `v1` version. This is not an optimal usage of resource. Weighted traffic switching with Kubernetes Ingress can be used to solve this problem.
  +==== Delete Canary Deployment
  +
  +Run this command to delete all resource created above:
  +
  +    $ kubectl delete svc/app-service deployment/app-v1 deployment/app-v2
  +
  +=== Ingress Controller (Not Yet Implemented)
  +
  +Achieving the right percentage of traffic using Deployments and Services requires spinning-up as many pods as necessary. For example, if the version `v1` has 4 replicas of a pod. Then, in order to direct 5% traffic to the version `v2`, 1 pod replica of `v2` version would require 16 more replicas of `v1` version. This is not an optimal usage of resource. Weighted traffic switching with Kubernetes Ingress can be used to solve this problem.
   
   https://github.com/zalando-incubator/kube-ingress-aws-controller[Kubernetes Ingress Controller for AWS], by Zalando, is an ingress controller for Kubernetes.
   
  
positive.code: 
  Let's verify.
  
  ==== Create canary
  
  . Deploy `v1` version of Deployment:
  
  
negative.code: +
  Note that we are explicitly specifying the label `name=app` in the query to only pick the pods that are specified in the service definition at `templates/app-service.yaml`. There are two pods from `v1` version and 2 pods from `v2` version. Accessing this service will have 50% response from `v1` version and the other 50% from `v2` version.
  
  ==== Scale Canary Deployment
  
  The number of pods to be included from `v1` version and `v2` version can now be indepently scaled using the two Deployments.
  
  