Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

The Evolution of Distributed Systems on Kubernetes

1.825 Aufrufe

Veröffentlicht am

Cloud native applications of the future will consist of hybrid workloads: stateful applications, batch jobs, stateless microservices, functions, (and maybe something else too) wrapped as Linux containers and deployed via Kubernetes on any cloud. Functions and the so-called serverless computing model is the latest evolution of what started as SOA years ago. But is it the last step of the application architecture evolution and is it here to stay? During this talk, we will take you on a journey exploring distributed application needs and how they evolved with Kubernetes, Istio, Knative, Dapr, and other projects. By the end of the session, you will know what is coming after microservices.

Veröffentlicht in: Software

The Evolution of Distributed Systems on Kubernetes

  1. 1. Bilgin Ibryam Product Manager @RedHat @bibryam The Evolution of Distributed Systems on Kubernetes 1
  2. 2. @bibryam Bilgin Ibryam 2 ● Product Manager at Red Hat ● Former Architect/Consultant ● Committer at Apache Camel ● Author of “Camel Design Patterns” and “Kubernetes Patterns” books ● Latest interest: cloud native data @bibryam
  3. 3. What comes after Microservices? 3
  4. 4. @bibryam Agenda 4 ● Distributed system needs ● Monolithic architectures ● Cloud-native technologies ■ Kubernetes, Istio, Knative, Dapr ● Future architecture trends
  5. 5. @bibryam 5 Modern distributed applications ● 100s of components and 1000s of instances ● Polyglot, independent, and automatable components ● Hybrid workloads on hybrid environments ● Open source, open standards, and interoperable ● Based on Kubernetes ecosystem
  6. 6. What are the needs of distributed applications? 6
  7. 7. @bibryam 7 Distributed application needs
  8. 8. @bibryam 8 Distributed application needs Lifecycle management ● Deployment/rollback ● Placement/scheduling ● Configuration management ● Resource/failure isolation ● Auto/manual scaling ● Hybrid workloads (stateless, stateful, serverless, etc)
  9. 9. @bibryam 9 Distributed application needs Advanced networking ● Service discovery and failover ● Dynamic traffic routing ● Retry, timeout, circuit breaking ● Security, rate limiting, encryption ● Observability and tracing
  10. 10. @bibryam 10 Distributed application needs Resource bindings ● Connectors for APIs ● Protocol conversion ● Message transformation ● Filtering, light message routing ● Point-to-point, pub/sub interactions
  11. 11. @bibryam 11 Distributed application needs Stateful abstractions ● Workflow management ● Temporal scheduling ● Distributed caching ● Idempotency ● Transactionality (SAGA) ● Application state
  12. 12. Monolithic architectures 12
  13. 13. @bibryam 13 Traditional middleware capabilities ● Stateful primitives ● Resource bindings ● Networking
  14. 14. @bibryam 14 Traditional middleware limitations ● Lifecycle management ○ Single, shared language runtime ○ Manual deployment/rollback ○ Manual placement ○ Manual scaling ○ No resource/failure isolation
  15. 15. Cloud-native architectures 15
  16. 16. @bibryam 16 Microservices and Kubernetes
  17. 17. @bibryam 17 Microservices and Kubernetes
  18. 18. @bibryam Health probes 18
  19. 19. @bibryam Managed start/stop 19
  20. 20. @bibryam Declarative deployment 20
  21. 21. @bibryam 21 Demands & placement Predictable resource demand Automated placement
  22. 22. @bibryam 22 Configuration management ● ConfigMaps used in Pods as: ○ environment variables ○ volumes ● Secrets: ○ Minimal Node spread ○ Only stored in memory in a tmpfs ○ Encrypted in the backend store (etcd) ○ Access can be restricted with RBAC
  23. 23. @bibryam 23 Foundational kubernetes capabilities More Kubernetes Patterns ● Foundational patterns ● Structural patterns ● Configuration patterns ● Behavioural patterns (For more Kubernetes Patterns, check out the link at the end of the slides)
  24. 24. @bibryam Batch/Periodic Job 24 Hybrid workloads Global SingletonStateful Service Stateless Service
  25. 25. @bibryam 25 Lifecycle capabilities ● Deployment/rollback ● Placement/scheduling ● Configuration management ● Resource/failure isolation ● Auto/manual scaling ● Hybrid workloads: stateless, stateful, batch jobs, serverless
  26. 26. How do we extend Kubernetes? 26
  27. 27. @bibryam 27 Out-of-process extension mechanism Deployment guarantees Lifecycle guarantees
  28. 28. @bibryam Sidecar 28
  29. 29. @bibryam Controller Pattern 29 Default schema ● ReplicaSet ● StatefulSet ● Job, CronJob Default controllers ● replicaset ● statefulset ● job, cronjob Managed resources state ● Pod ● PVC... Custom controller -> Custom behaviour
  30. 30. @bibryam Operator Pattern 30 kind: ConfigWatcher apiVersion: k8spatterns.io/v1 metadata: name: webapp-config-watcher spec: configMap: webapp-config podSelector: app: webapp Custom operator ● Go ● Helm ● Ansible ● Java ● Python Custom application ● AI/ML ● Big Data ● Storage ● Streaming ● Monitoring CustomResourceDefinition + Controller = Operator
  31. 31. Kubernetes based platforms 31
  32. 32. @bibryam 32 What is Service Mesh?
  33. 33. @bibryam 33 What is Service Mesh?
  34. 34. @bibryam 34 What is Service Mesh?
  35. 35. @bibryam 35 What is Service Mesh?
  36. 36. @bibryam 36 Networking capabilities API Gateway Service Mesh Abstract away details and decouple consumers from implementations ● Controls what’s allowed in/out ● Bridging security domains ● Request / response transformation ● Protocol, data format transformation ● API composition ● Rate limiting Enhances the reliability and the visibility of the networking interactions ● Telemetry, tracing collection ● Service discovery, load balancing ● TLS termination/origination ● Request routing, traffic splitting ● Traffic shadowing ● Rate limiting
  37. 37. @bibryam 37 What is Knative? Serving Common infrastructure for request-driven interactions that can "scale to zero". Eventing Common infrastructure for consuming and producing events declaratively. Kubernetes-based platform to deploy, and manage serverless workloads.
  38. 38. @bibryam 38 Knative Serving concepts ● Scale-to-zero & activation ● Rapid autoscaling ● Traffic splitting ● Callable by Knative eventing ● Simplified deployment model ○ Single Port ○ No PersistentVolumes ○ Single Container apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: lotto spec: replicas: 1 selector: matchLabels: app: lotto template: metadata: labels: app: lotto spec: containers: - image: cds19/lotto
  39. 39. @bibryam 39 Knative Eventing concepts ● Sources (Kafka, CronJob, Apache Camel 200+, etc) ● Broker implementations (In-memory, Kafka, etc) ● CloudEvents data format ● Trigger with filters ● Sequence: chaining multiple steps composed of containers
  40. 40. @bibryam 40 Lifecycle, networking, binding capabilities ● Knative Serving ○ Simplified deployment for stateless workloads ○ Traffic based autoscaling including Scale-to-Zero ○ Traffic splitting for custom rollout / rollback scenarios ● Knative Eventing ○ External triggers for feeding Knative Services ○ Based on CloudEvents ○ Backed by proven messaging systems ○ Declarative messaging infrastructure
  41. 41. @bibryam 41 What is Dapr? Sidecar architecture Developer first, standard APIs used from any programming language or framework. Building blocks Make it easy for developers to create microservice without being an expert in distributed systems. A portable runtime for building distributed applications.
  42. 42. @bibryam 42 Dapr building blocks Distributed Tracing See and measure the message calls across components and networked services Service Invocation Act as a reverse proxy with built-in service discovery, tracing and error handling Publish & Subscribe Secure, scalable messaging between services Resource Bindings Trigger code through events from input and output bindings to external resources. Actors Encapsulate code and data in reusable actor objects as a common microservices State Management Provides a key/value-based state API with pluggable state stores for persistence
  43. 43. @bibryam 43 Dapr architecture Source:https://github.com/dapr/docs
  44. 44. @bibryam 44 Dapr on Kubernetes Source:https://github.com/dapr/docs
  45. 45. @bibryam 45 Full circle ● Centralized control plane ● Centralized data plane ● Centralized control plane ● Decentralized, highly-scalable data plane Service discovery Dynamic routing Resiliency Observability Deployment Placement Config mgmt Scaling Bindings State abstraction Pub/Sub Observability Connectors Eventing Filtering Serverless
  46. 46. Future cloud native trends 46
  47. 47. @bibryam 47 Lifecycle trends Source:https://operatorhub.io
  48. 48. @bibryam ● Introduction of Service Mesh Interface specification ● Architecture consolidation of Istio with istiod ● More L7 protocols: MongoDB, DynamoDB, ZooKeeper, MySQL, Redis, Kafka(8188) ○ KIP-559 can enable bridging, validation, encryption, filtering, transformation ● HTTP Cache filter (eCache) ● HTTP tap filter (with matcher) ● WebAssembly (wasm) filters with dynamic loading (C++ -> Rust, Go, etc) 48 Networking trends
  49. 49. @bibryam 49 Binding trends Dev Environment Cloud kamel CLI Camel K Operator Custom Resource Running Pod Fast redeploy! Less than 1 second! - from: uri: "direct:route" steps: - split: tokenize: "," - to: "mock:split" Camel-K Operator: 1. Choose a runtime 2. Scaffold a project 3. Add boilerplate 4. Add dependencies 5. Create container image 6. Create Kubernetes resources for deployment Source:https://github.com/apache/camel-k Live updates!
  50. 50. @bibryam 50 State trends Source:https://github.com/cloudstateio/cloudstate
  51. 51. What does all this mean? 51
  52. 52. @bibryam 52 Multi-runtime microservices are here
  53. 53. @bibryam 53 Smart sidecars and dumb pipes
  54. 54. @bibryam 54 What comes after Microservices?
  55. 55. Thank You 55 @bibryam https://k8spatterns.io

×