Jonathan Gold from Container Solutions gave a workshop on advanced deployment strategies with Kubernetes and Istio at the spring 2019 Kubernetes and Cloud Native meetup in Ottawa.

1. training@container-solutions.com
www.container-solutions.com
Deployment Strategies
29.05.2019

2. Today’s Mission
1. Intro
2. Kubernetes Refresher
3. Built-in Deployment Strategies
4. Istio Intro
5. Canary Deployment
6. A/B Testing

3. Who's Who
Who are we? Who am I?

4. Container Solutions
We are a Cloud Native consultancy based in Amsterdam, Berlin, London,
Montreal, and Warsaw.
Kubernetes Certified Service Provider (KCSP), Kubernetes Training
Partner (KTP) and experts in Cloud Native strategy and technology.
https://container-solutions.com/
We are hiring!

5. Who am I?
Jonathan Gold

6. Deploying a new version of an application can have unintended and
unforeseen consequences, so it is important to strategize accordingly.
There are trade-offs for each strategy, so in addition to learning how to use
each one, we’ll also discuss why you might choose one over the others.
Here are the strategies we’ll cover:
● Recreate
● RollingUpdate
● Blue/Green
● Canary with Istio
● A/B Testing with Istio
Introduction

7. Kubernetes Refresher

8. Deployment
● Encapsulates ReplicaSet
● Controlled change from current
state to desired state
● Can rollback to a previous state
If an update goes awry

9. ReplicaSet
● Ensures a specified number of
pod replicas are running at any
given time
● Automatically created in
Deployment (usually)

10. Service
● Stable endpoint for ephemeral
back ends.
● Forward traffic to pod or a group
of pods that work together
● Grouped by a Label Selector
● 4 different types (ClusterIP,
NodePort, LoadBalancer,
ExternalName)

11. Ingress
● Route traffic via a service to a set
of pods
● Rules that allow inbound
connections to reach Kubernetes
services
● Multiple implementations (nginx,
istio, Traefik, HAProxy, Gloo, etc)

12. ● Each application has specific needs for availability during
deployments
● Each deployment strategy has its advantages and disadvantages, it is
necessary to choose the right strategy.
Deployment Strategies

13. Recreate

14. How does it work?
All running instances are terminated and then new instances with the
new version are created.
1. Version 1 services traffic
2. Delete version 1
3. Deploy version 2
4. Wait until all replicas are ready

16. Configuration
● Version A is terminated then
version B is rolled out [...]
kind: Deployment
spec:
replicas: 3
strategy:
type: Recreate
[...]

17. Pros
● Easy to set up
Cons
● High impact on the user
● Downtime depends on both shutdown and boot duration of the
application
Recreate

18. RollingUpdate

19. How does it work?
● New ReplicaSet is created with the new version of the application
● Number of old replicas decreased
● New replicas increased

21. Configuration
[...]
kind: Deployment
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
[...]
● Version B is slowly rolled out and
replacing
version A
● When .spec.strategy.type ==
RollingUpdate, maxUnavailable
and maxSurge fields can be
specified to control the rolling
update process

22. Pros
● Easy to use
● Version is slowly released across instances
● Convenient for new versions that are backward compatible or
support API versioning.
Cons
● Rollout/Rollback can take time
● No control over traffic
RollingUpdate

23. Blue/Green

24. How does it work?
● The “green” version of the application is deployed alongside the
“blue” version.
● The old version is considered “blue” and the new version is
considered “green”
● After testing that the new version meets the requirements, we
update the Kubernetes Service object that plays the role of load
balancer to send traffic to the new version by replacing the version
label in the selector field.

26. [...]
kind: Service
spec:
selector:
app: my-app
version: v1.0.0
[...]
Configuration
● Here we match both the app and
the version
● When switching traffic, update
the label “version” with the
appropriate value, ie: v2.0.0

27. Configuration
$ kubectl apply -f version2.yaml
$ kubectl patch service my-app -p
'{"spec":{"selector":{"version":"v2.0.0"}}}'
$ kubectl delete -f version1.yaml
● Version B is released alongside
version A
● The traffic is switched to version
B

28. Blue/Green
Pros
● Instant Rollout/Rollback
● Dirty way to fix application dependency hell
Cons
● Expensive as it requires double the resources
● Proper test of the entire platform should be done before releasing to
production

29. Canary

30. container-solutions.com @moretea_nl
Canary deployments in 1918

31. How does it work?
● Consists of routing a subset of users to a new functionality. It allows
to reduce risk by pushing changes to a small group of users
● If no error is detected, then scale up to the number of replicas of the
new version and delete the old deployment
● In Kubernetes, a Canary deployment can be done using two
Deployments with common pod labels. One replica of the new
version is released alongside the old version. Not very scalable, the
reason for using service mesh.

33. K8s mechanisms are not enough

35. Pros
● Version released for a subset of users
● Convenient for error rate and performance monitoring
fast rollback
Cons
● Sticky sessions might be required
● Precise traffic requires additional CNI like Istio or Linkerd
Canary

36. Hands-on
Canary Deployment

37. Bonus Tasks/Questions
● Increase the traffic to trigger the pod autoscaler (then watch it scale
back down as you adjust the distribution).
● Adjust the horizontal pod autoscaler to raise the target CPU
percentage.
● How would you integrate Canary deployments into a CI setup?

38. A/B Testing

39. How does it work?
● A/B testing is about testing a hypothesis. It is usually a technique for
making business decisions based on statistics
● At first, the new version is deployed alongside the old one. Traffic is
distributed amongst versions based on some parameters to target a
given pool of users (cookie, user agent, location, weight etc.)
● Then, the two versions are compared to determine which one
perform better

41. Pros
● ?
Cons
● ?
A/B Testing

42. Pros
● Several versions run in parallel
● Full control over the traffic distribution
● Useful for business purposes, e.g. to test conversion rates
Cons
● It requires an intelligent LoadBalancer such as Istio, Linkerd, etc.
● Hard to troubleshoot errors for a given session, distributed tracing
becomes mandatory
A/B Testing

43. Hands-on
A/B Testing

44. Bonus Tasks/Questions
● Add a new route for a different browser (e.g. Safari)
● What happens if you don’t use a browser? (e.g. curl)
○ Create a default route.
● What other elements would you use to trigger an A/B split?

45. Recap
What have we learned?

46. Best practices:

47. Questions?