The Kubernetes Effect
10 likes6,117 views
The document discusses Kubernetes and cloud native application design. It begins by defining cloud native as structuring teams and technology around automation and microservices packaged as containers orchestrated by platforms like Kubernetes. It then covers common Kubernetes resources like pods, services, deployments and Kubernetes design patterns like sidecars, init containers and immutable configuration. The document advocates principles for container-based applications including single concern, self-containment and image immutability. It also recommends techniques like using volumes for persistent data and logging to standard output/error.
![[WSO2Con USA 2018] Deploying Applications in K8S and Docker](https://cdn.slidesharecdn.com/ss_thumbnails/deployingapplicationsink8sanddocker-wso2conusa2018-180723073457-thumbnail.jpg?width=560&fit=bounds)
![[Lakmal] Automate Microservice to API](https://cdn.slidesharecdn.com/ss_thumbnails/lakmalautomatemicroservicetoapi-210512215049-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to The Kubernetes Effect (20)
Ad
More from Bilgin Ibryam (7)
Ad
Recently uploaded (19)
The Kubernetes Effect
- 1. The Kubernetes Effect by @bibryam
- 2. Who am I? ➢ Bilgin Ibryam ➢ @bibryam ➢ http://ofbizian.com/ ➢ http://github.com/bibryam/ ➢ Integration Architect at Red Hat ➢ Committer for Camel, OFBiz, Isis at ASF ➢ Author of Camel Design Patterns, Kubernetes Patterns ➢ Interested in Integration, Cloud Native, Blockchain
- 3. Agenda
- 4. Cloud native... A common defnition: Cloud Native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity. @jbeda A typical application: Applications adopting the principles of microservices packaged as containers orchestrated by platforms running on top of cloud infrastructure.
- 5. A Kubernetes based microservice
- 6. Local vs distributed primitives
- 7. Distributed abstractions and primitives ● Application packaging (Container) ● Deployment unit (Pod) ● Auto scaling (HPA) ● Atomic work unit (Job) ● Recurring execution (CronJob) ● Service discovery (Service) ● Load balancing (Service) ● Application placement (Scheduler) ● Lifecycle management (Deployment) ● Health checks (liveness/readiness) ● Lifecycle hooks (PostStart/PreStop) ● Artifact grouping (Label) ● Custom Resource Defnition (CRD)
- 8. Software design principles ● KISS - Keep it simple, stupid ● DRY - Don't repeat yourself ● YAGNI - You aren't gonna need it ● SoC - Separation of concerns ● SOLID Principles by Robert C. Martin: • Single responsibility • Open/Closed • Liskov substitution • Interface segregation • Dependency inversion Principles represent abstract guidelines or believes that help create systems with higher-quality attributes.
- 9. The twelve-factor app i.e. the Heroku way 1. One codebase tracked in revision control, many deploys 2. Explicitly declare and isolate dependencies 3. Store confg in the environment 4. Treat backing services as attached resources 5. Strictly separate build and run stages 6. Execute the app as one or more stateless processes 7. Export services via port binding 8. Scale out via the process model 9. Maximize robustness with fast startup and graceful shutdown 10.Keep development, staging, and production as similar as possible 11. Treat logs as event streams 12.Run admin/management tasks as one-off processes
- 10. Principles of container-based application design ● Build time: ● Single Concern Principle (SCP) ● Self-Containment Principle (S-CP) ● Image Immutability Principle (IIP) ● Runtime: ● High Observability Principle (HOP) ● Lifecycle Conformance Principle (LCP) ● Process Disposability Principle (PDP) ● Runtime Confnement Principle (RCP) https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
- 11. Single concern principle Design patterns: • Sidecar • Ambassador • Adapter • Init-container • Defer-container
- 13. Image immutability principle Also known as: • Dev/Prod parity • Snowflakes vs Phoenix • Impedance mismatch
- 14. High observability principle Healthcheck implementations: • Spring Boot Actuator • Dropwizard Metrics • WildFly Swarm Monitor • MicroProfle Healthchecks • Apache Camel • And many others!
- 15. Lifecycle conformance principle ● Graceful shutdown: ● SIGTERM ● SIGKILL ● Lifecycle hooks: ● PreStop ● PostStart
- 16. Process disposability principle Also known as: ● Cattle rather than pets ● Don’t rely on a particular instance. ● Be aware of shots at your cattle. ● Be robust against sudden death. ● Stateless or with replicated state ● Idempotent startup ● Graceful shutdown
- 17. Runtime confnement principle Implications: ● Pod scheduling ● Pod auto scaling ● Pod eviction ● Pod QoS classes: ● Best Effort ● Burstable ● Guaranteed ● Capacity management
- 18. Agenda
- 19. Software design patterns Object-oriented patterns Container orchestration patterns A reusable solution to a reoccurring problem within a given context.
- 21. Sidecar pattern ● Use cases ● Monitoring, health checks, watchdog ● Logging ● Confguration ● Networking ● Offload proxy
- 23. Specialized Sidecars Ambassador Pattern Proxy Pattern ● Use cases ● Reverse proxy to a heterogeneous system ● Log normalizer ● Metrics exporter ● Use cases ● Out-of-process proxy ● Resiliency ● Monitoring ● Security
- 24. Init-container pattern ● Use cases ● Wait for external dependency ● Confguration ● Initialization
- 26. More Kubernetes Patterns Confguration Patterns ● EnvVar Confguration ● Confguration Resource ● Confguration Template ● Immutable Confguration Advanced Patterns ● Stateful Service ● Custom Resource Descriptors ● Custom Controller ● Build Container
- 27. Immutable confguration pattern ● Use cases ● Immutable confguration data ● Large confguration fles
- 28. Confguration template pattern ● Use cases ● Complex templating logic
- 29. Custom controller/Operator patterns Application Controller ● Prometheus operator ● Zookeeper operator ● Infnspan operator ● Strimzi - Kafka operator Extension controllers ● Expose controller (fabric8) ● Confgmap controller (fabric8) ● Linux Update Operator
- 30. Techniques and practices • Aim for small images - this reduces container size, improves build, and deployment time. • Support arbitrary user IDs - avoid using the sudo command or requiring a specifc user ID. • Mark important ports - declare ports using the EXPOSE command. • Use volumes for persistent data - the data that needs to be preserved after a container is destroyed. • Set image metadata - Image metadata in the form of tags, labels, and annotations. • Synchronize host and image - attributes such as time and machine ID. • Log to STDOUT and STDERR - to ensure container logs are picked up and aggregated properly.
- 31. Agenda
- 32. Kubernetes resources ● The Kubernetes Effect (blog post) https://www.infoq.com/articles/kubernetes-effect ● Principles of container-based application design (white paper) https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper ● Design patterns for container-based distributed systems (white paper) https://www.usenix.org/system/fles/conference/hotcloud16/hotcloud16_burns.pdf ● Designing Distributed Systems (free ebook) https://azure.microsoft.com/en-us/resources/designing-distributed-systems ● Kubernetes Patterns (ebook) https://leanpub.com/k8spatterns ● Kubernetes in Action (ebook) https://www.manning.com/books/kubernetes-in-action
- 33. Q & A