How to: Lab 12.5. Canary deployments
Canary deployment is an update strategy where updates are deployed to a subset of users/servers (canary application) for testing prior to full deployment. This is a scenario where Labels are required to distinguish deployments by release or configuration.
canary update strategy
![canary update strategy from https://life.wongnai.com/project-ceylon-iii-argorollouts-55ec70110f0a](https://user-images.githubusercontent.com/17856665/185770905-7c3901ec-f97a-4046-8411-7a722b0601a4.png)
1. Create a webserver application
   - three replicas
   - _Pod Template_ label `updateType=canary`
   - use image`nginx:1.19-alpine`
   - create an HTML document `index.html` with any content
   - mount the `index.html` file to the DocumentRoot as a _ConfigMap_ volume
2. Expose the Deployment on port 80 with Service name `canary-svc`
3. Verify created resources and test access with `curl`
4. Create a new application using [1] as base
   - one replica
   - _Pod Template_ label `updateType=canary`
   - use a newer version of the image `nginx:1.22-alpine`
   - create a new HTML document `index.html` with different content
   - mount the `index.html` file to the DocumentRoot as a _ConfigMap_ volume
5. Verify created resources and confirm the Service targets both webservers
6. Run multiple `curl` requests to the IP in [2] and confirm access to both webservers
7. Scale up the new webserver to three replicas and confirm all Pods running
8. Scale down the old webserver to zero and confirm no Pods running
9. Delete created resources

> Scaling down to zero instead of deleting provides an easy option to revert changes when there are issues
lab 12.5 solution
```sh