Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Advanced Deployment Strategies with Kubernetes and Istio


Published on

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.

Published in: Technology
  • Be the first to comment

Advanced Deployment Strategies with Kubernetes and Istio

  1. 1. Deployment Strategies 29.05.2019
  2. 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. 3. Who's Who Who are we? Who am I?
  4. 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. We are hiring!
  5. 5. Who am I? Jonathan Gold
  6. 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. 7. Kubernetes Refresher
  8. 8. Deployment ● Encapsulates ReplicaSet ● Controlled change from current state to desired state ● Can rollback to a previous state If an update goes awry
  9. 9. ReplicaSet ● Ensures a specified number of pod replicas are running at any given time ● Automatically created in Deployment (usually)
  10. 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. 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. 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. 13. Recreate
  14. 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
  15. 15. Configuration ● Version A is terminated then version B is rolled out [...] kind: Deployment spec: replicas: 3 strategy: type: Recreate [...]
  16. 16. Pros ● Easy to set up Cons ● High impact on the user ● Downtime depends on both shutdown and boot duration of the application Recreate
  17. 17. RollingUpdate
  18. 18. How does it work? ● New ReplicaSet is created with the new version of the application ● Number of old replicas decreased ● New replicas increased
  19. 19. 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
  20. 20. 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
  21. 21. Blue/Green
  22. 22. 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.
  23. 23. [...] 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
  24. 24. 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
  25. 25. 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
  26. 26. Canary
  27. 27. @moretea_nl Canary deployments in 1918
  28. 28. 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.
  29. 29. K8s mechanisms are not enough
  30. 30. 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
  31. 31. Hands-on Canary Deployment
  32. 32. 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?
  33. 33. A/B Testing
  34. 34. 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
  35. 35. Pros ● ? Cons ● ? A/B Testing
  36. 36. 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
  37. 37. Hands-on A/B Testing
  38. 38. 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?
  39. 39. Recap What have we learned?
  40. 40. Best practices:
  41. 41. Questions?