Deployment Strategies on Kubernetes By Etienne Tremel Software - - PowerPoint PPT Presentation

▶
deployment strategies on kubernetes
SMART_READER_LITE
LIVE PREVIEW

Deployment Strategies on Kubernetes By Etienne Tremel Software - - PowerPoint PPT Presentation

Mar 22, 2024 206 likes •824 views

Deployment Strategies on Kubernetes By Etienne Tremel Software engineer at Container Solutions @etiennetremel February 13th, 2017 Agenda Kubernetes in brief Look at 6 different strategies Recreate Ramped Blue/Green

slide-1
SLIDE 1

Deployment Strategies on Kubernetes

By Etienne Tremel Software engineer at Container Solutions @etiennetremel February 13th, 2017

slide-2
SLIDE 2

Agenda

  • Kubernetes in brief
  • Look at 6 different strategies
  • Recreate
  • Ramped
  • Blue/Green
  • Canary
  • A/B Testing
  • Shadow
  • Sum-up
  • Next

2

slide-3
SLIDE 3

Kubernetes in brief

Deployments, replica-sets, pods and services

3

slide-4
SLIDE 4

Kubernetes in brief

Advanced routing using Ingress

4

Ingress controllers:

  • Nginx
  • HA Proxy
  • Traefik
  • Istio
  • Linkerd
  • GKE
  • etc.
slide-5
SLIDE 5

Kubernetes in brief

Configuration

5

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers:

  • name: nginx

image: nginx:1.7.9 ports:

  • containerPort: 80

Deployment configuration:

kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: nginx ports:

  • protocol: TCP

port: 80 targetPort: 9376

Service configuration:

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: my-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules:

  • host: foo.bar.com

http: paths:

  • path: /foo

backend: serviceName: my-service servicePort: 80

  • path: /bar

backend: serviceName: my-other-service servicePort: 80

Ingress configuration:

Deployment ReplicaSet Pod

slide-6
SLIDE 6

Deployment strategies

6

  • Recreate native
  • Ramped native
  • Blue/Green extra step needed
  • Canary extra step needed
  • A/B Testing require additional component
  • Shadow require additional component

Get your hands on: https://github.com/ContainerSolutions/k8s-deployment-strategies

slide-7
SLIDE 7

7

Recreate

slide-8
SLIDE 8

Recreate

8

In this case [LB] is a Kubernetes Service

slide-9
SLIDE 9

Recreate

9

In this case [LB] is a Kubernetes Service

slide-10
SLIDE 10

Recreate

10

In this case [LB] is a Kubernetes Service

slide-11
SLIDE 11

Recreate

11

In this case [LB] is a Kubernetes Service

slide-12
SLIDE 12

Recreate

12

[...] kind: Deployment spec: replicas: 3 strategy: type: Recreate [...]

$ kubectl apply -f ./manifest.yaml

slide-13
SLIDE 13

Recreate

Pattern of the traffic during a release

13

Service unavailable

slide-14
SLIDE 14

Recreate

Pros:

  • easy to setup

Cons:

  • high impact on the user, expect downtime that depends on both shutdown and boot duration
  • f the application

14

slide-15
SLIDE 15

15

Ramped

aka incremental, rolling update

slide-16
SLIDE 16

Ramped - aka Incremental, Rolling

16

In this case [LB] is a Kubernetes Service

slide-17
SLIDE 17

Ramped - aka Incremental, Rolling

17

In this case [LB] is a Kubernetes Service

slide-18
SLIDE 18

Ramped - aka Incremental, Rolling

18

In this case [LB] is a Kubernetes Service

slide-19
SLIDE 19

Ramped - aka Incremental, Rolling

19

In this case [LB] is a Kubernetes Service

slide-20
SLIDE 20

Ramped - aka Incremental, Rolling

20

In this case [LB] is a Kubernetes Service

slide-21
SLIDE 21

Ramped - aka Incremental, Rolling

21

[...] kind: Deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 # how many pods we can add at a time maxUnavailable: 0 # maxUnavailable define how many pods can be # unavailable during the rolling update [...]

$ kubectl apply -f ./manifest.yaml

slide-22
SLIDE 22

Ramped - aka Incremental, Rolling

Pattern of the traffic during a release

22

slide-23
SLIDE 23

Ramped - aka Incremental, Rolling

Pros:

  • easy to use
  • version is slowly released across instances
  • convenient for stateful applications that can handle ongoing rebalancing of the data

Cons:

  • rollout/rollback can take time
  • no control over traffic

23

slide-24
SLIDE 24

24

Blue/Green

aka red/black

slide-25
SLIDE 25

Blue/Green - aka Red/Black

25

slide-26
SLIDE 26

Blue/Green - aka Red/Black

26

slide-27
SLIDE 27

Blue/Green - aka Red/Black

27

slide-28
SLIDE 28

Blue/Green - aka Red/Black

28

slide-29
SLIDE 29

Blue/Green - aka Red/Black

Single service deployment

29

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

$ kubectl apply -f ./manifest-v2.yaml $ kubectl patch service my-app -p \ '{"spec":{"selector":{"version":"v2.0.0"}}}' $ kubectl delete -f ./manifest-v1.yaml

slide-30
SLIDE 30

Blue/Green - aka Red/Black

To rollout multiple services at once, use Ingress

30

[...] kind: Ingress spec: rules:

  • host: login.domain.com

http: paths:

  • backend:

serviceName: login-v2 servicePort: 80

  • host: cart.domain.com

http: paths:

  • backend:

serviceName: cart-v2 servicePort: 80 [...] [...] kind: Service metadata: name: login-v2 spec: selector: app: login version: v2.0.0 [...] [...] kind: Service metadata: name: cart-v2 spec: selector: app: cart version: v2.0.0 [...]

$ kubectl apply -f ./manifest-v2.yaml $ kubectl apply -f ./ingress.yaml $ kubectl delete -f ./manifest-v1.yaml

slide-31
SLIDE 31

Blue/Green - aka Red/Black

Pattern of the traffic during a release

31

slide-32
SLIDE 32

Blue/Green - aka Red/Black

Pros:

  • instant rollout/rollback
  • good fit for front-end that load versioned assets from the same server
  • 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

32

slide-33
SLIDE 33

33

Canary

slide-34
SLIDE 34

Canary

34

slide-35
SLIDE 35

Canary

35

slide-36
SLIDE 36

Canary

36

slide-37
SLIDE 37

Canary

37

slide-38
SLIDE 38

Canary

38

[...] kind: Deployment metadata: name: my-app-v1 spec: replicas: 9 template: labels: app: my-app version: v1.0.0 [...] [...] kind: Service metadata: name: my-app spec: selector: app: my-app [...] [...] kind: Deployment metadata: name: my-app-v2 spec: replicas: 1 template: labels: app: my-app version: v2.0.0 [...]

$ kubectl apply -f ./manifest-v2.yaml $ kubectl scale deploy/my-app-v2 --replicas=10 $ kubectl delete -f ./manifest-v1.yaml

slide-39
SLIDE 39

Canary

Example of shifting traffic based on weight (percentage) using Istio

39

[...] kind: RouteRule metadata: name: my-app spec: destination: name: my-app route:

  • labels:

version: v1.0.0 weight: 90 # 90% traffic

  • labels:

version: v2.0.0 weight: 10 # 10% traffic [...]

$ kubectl apply -f ./manifest-v2.yaml $ kubectl apply -f ./routerule.yaml

slide-40
SLIDE 40

Canary

Pattern of the traffic during a release

40

slide-41
SLIDE 41

Canary

Pros:

  • version released for a subset of users
  • convenient for error rate and performance monitoring
  • fast rollback

Cons:

  • slow rollout
  • sticky sessions might be required
  • precise traffic shifting would require additional tool like Istio or Linkerd

41

slide-42
SLIDE 42

42

A/B Testing

slide-43
SLIDE 43

A/B Testing

43

slide-44
SLIDE 44

A/B Testing

44

slide-45
SLIDE 45

A/B Testing

45

slide-46
SLIDE 46

A/B Testing

46

Possible conditions:

  • Geolocalisation
  • Language
  • Cookie
  • User Agent (device, OS, etc.)
  • Custom Header
  • Query parameters
slide-47
SLIDE 47

A/B Testing

Example of shifting traffic based on request Headers using Istio

47

[...] kind: RouteRule metadata: name: my-app-v1 spec: destination: name: my-app route:

  • labels:

version: v1.0.0 match: request: headers: x-api-version: exact: "v1.0.0" [...] [...] kind: RouteRule metadata: name: my-app-v2 spec: destination: name: my-app route:

  • labels:

version: v2.0.0 match: request: headers: x-api-version: exact: "v2.0.0" [...]

$ kubectl apply -f ./manifest-v2.yaml $ kubectl apply -f ./routerule.yaml

slide-48
SLIDE 48

A/B Testing

Pattern of the traffic during a release

48

slide-49
SLIDE 49

A/B Testing

Pros:

  • several versions run in parallel
  • full control over the traffic distribution
  • great tool that can be used for business purpose to improve conversion

Cons:

  • requires intelligent load balancer (Istio, Linkerd, etc.)
  • hard to troubleshoot errors for a given session, distributed tracing becomes mandatory

49

slide-50
SLIDE 50

50

Shadow

aka Mirrored, Dark

slide-51
SLIDE 51

Shadow - aka Mirrored, Dark

51

slide-52
SLIDE 52

Shadow - aka Mirrored, Dark

52

slide-53
SLIDE 53

Shadow - aka Mirrored, Dark

53

slide-54
SLIDE 54

Shadow - aka Mirrored, Dark

54

slide-55
SLIDE 55

Shadow - aka Mirrored, Dark

Example of mirroring traffic using Istio

55

[...] kind: RouteRule spec: destination: name: my-app route:

  • labels:

version: v1.0.0 weight: 100

  • labels:

version: v2.0.0 weight: 0 mirror: name: my-app-v2 labels: version: v2.0.0 [...]

$ kubectl apply -f ./manifest-v2.yaml $ kubectl apply -f ./routerule.yaml

slide-56
SLIDE 56

Shadow - aka Mirrored, Dark

Pattern of the traffic during a release

56

slide-57
SLIDE 57

Shadow - aka Mirrored, Dark

Pros:

  • performance testing of the application with production traffic
  • no impact on the user
  • no rollout until the stability and performance of the application meet the requirements

Cons:

  • complex to setup
  • expensive as it requires double the resources
  • not a true user test and can be misleading
  • requires mocking/stubbing service for certain cases

57

slide-58
SLIDE 58

Sum-up

  • recreate if downtime is not a problem
  • recreate and ramped doesn’t require any extra step (kubectl apply is enough)
  • ramped and blue/green deployment are usually a good fit and easy to use
  • blue/green is a good fit for front-end that load versioned assets from the same server
  • blue/green and shadow can be expensive
  • canary and a/b testing should be used if little confidence on the quality of the release
  • canary, a/b testing and shadow might require additional cluster component

58

slide-59
SLIDE 59

Sum-up

59

slide-60
SLIDE 60

Next

Hands on Kubernetes deployment strategies: https://github.com/ContainerSolutions/k8s-deployment-strategies Blog post about strategies: https://container-solutions.com/kubernetes-deployment-strategies https://thenewstack.io/deployment-strategies

60

slide-61
SLIDE 61

Thank You

61