Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
The Elements of Kubernetes
Aaron Schlesinger
Microsoft Azure Containers
Lead, SIG-Service-Catalog
★ Kubernetes is growing fast
★ Usage, development, projects
★ We’re in the wild west
Why we’re here
Building an app for Kubernetes
Dev/Test Containerize CI/CD
Staging Pre-prod Prod
ResilienceMonitoring Tracing Logging Observability
Lots to figure out
No one size fits all
We need a “north star” for people
building cloud-native apps
★ Help app operators/developers decide what to do
★ Stand up to rapid technology changes
★ Guide SIGs
Best practices, not rules
North Star
What we have now
★ Opinions
★ Evidence
★ Fragmentation
I’ve seen the good & the bad
I’m here to propose ideas
Observability is golden
★ Kubernetes schedules containers
★ Kubernetes observes containers
★ You observe containers
Observability is golden
★ Resource limits
★ Readiness & liveness checks
★ HPA
Kubernetes observing your app
You observing your app
Adopt a rich ecosystem of cloud native tools:
★ Logging
★ Service mesh
★ Tracing
When all else fails, crash
Crash-only software
★ You’ll have bugs, network outages, disk issues, etc...
★ Kubernetes is your retry loop
What that might look like
★ Your app connects to a DB on startup
★ App fails to connect, crashes
★ Tracing sees the conn. failure
★ Kubernetes restarts it
★ Monitoring, log aggregation pick up the restart
★ Alerting notifies if too many restarts
★ ...
Unordered is better than
ordered
★ Kubernetes & your app are distributed systems
★ Ordering is very hard in distributed systems
★ Try not to rely on ordering
Unordered is better than ordered
Use Kubernetes primitives.
★ Sidecar for locks, leader election
★ Resource versions in Kubernetes resources
★ Init containers (can be messy)
But sometimes you need it
Loose coupling is better than
tight coupling
Loose coupling is better than tight
★ Kubernetes is always watching
★ Your app should tolerate dynamism
What that might look like
★ Pod => Pod messaging via Services
★ Crash if you can’t connect (crash-only)
★ Look for Kube resources via labels, not names
… But tight coupling isn’t
always wrong
★ Pods have >1 containers on purpose
★ Run tightly coupled containers in a pod
Tight coupling isn’t always wrong
★ Envoy
★ Fluentd logging driver
★ Metrics
What that might look like
Record your configuration
Record your configuration
★ Kubernetes APIs are declarative
★ Keep the latest working configuration in your repository
★ Let Kubernetes reconcile
What might that look like
Ask for the least
Ask for the least
If you’re:
★ Configuring RBAC permissions
★ Configuring containers in a pod
★ Asking for CPU shares or memory
★ Asking for disk space with a PersistentVolumeClaim
Ask for the fewest possible of them. Leave more for Kubernetes
What that might look like
★ Read-only permissions for your monitoring system
★ One CPU share for each web frontend
★ Minimal disk for your log aggregator
★ Tiny memory for your local proxy
Build on the shoulders of
giants
Build on the shoulders of giants
★ Kubernetes provides a big API
○ … to abstract functionality that’s hard to get right
★ Maybe the community doesn’t do what you need
○ … but try to find the next best thing and build atop
What that might look like
Helm for managing your app lifecycle
★ Or the Helm API (which is gRPC)
Traefik for Ingress
★ Or Traefik => service mesh => your app
Fluentd for Logging
★ Or app => local translator => fluentd
Parting thoughts: where
should we go from here?
Who should define our guidelines?
★ I’ve started the conversation here
★ We all have a wealth of experience
★ We need to share it
The elements of kubernetes
We need your thoughts
https://github.com/arschles/kube-best-practices
Thank you
aaron.schlesinger@microsoft.com
@arschles
github.com/arschles
Community Extras
Pay it forward
Pay it forward
★ If you “build on the shoulders of giants,” open source it
★ You’ll be moving cloud native forward
★ We’ll progress as community & concept because of your work
Disagree constructively
★ Cloud native is young
★ If you disagree with a choice, others do too
★ Make your voice heard, and offer solutions
Disagree constructively

More Related Content

The elements of kubernetes

  • 1. The Elements of Kubernetes Aaron Schlesinger Microsoft Azure Containers Lead, SIG-Service-Catalog
  • 2. ★ Kubernetes is growing fast ★ Usage, development, projects ★ We’re in the wild west Why we’re here
  • 3. Building an app for Kubernetes Dev/Test Containerize CI/CD Staging Pre-prod Prod ResilienceMonitoring Tracing Logging Observability
  • 4. Lots to figure out No one size fits all
  • 5. We need a “north star” for people building cloud-native apps
  • 6. ★ Help app operators/developers decide what to do ★ Stand up to rapid technology changes ★ Guide SIGs Best practices, not rules North Star
  • 7. What we have now ★ Opinions ★ Evidence ★ Fragmentation
  • 8. I’ve seen the good & the bad
  • 9. I’m here to propose ideas
  • 11. ★ Kubernetes schedules containers ★ Kubernetes observes containers ★ You observe containers Observability is golden
  • 12. ★ Resource limits ★ Readiness & liveness checks ★ HPA Kubernetes observing your app
  • 13. You observing your app Adopt a rich ecosystem of cloud native tools: ★ Logging ★ Service mesh ★ Tracing
  • 14. When all else fails, crash
  • 15. Crash-only software ★ You’ll have bugs, network outages, disk issues, etc... ★ Kubernetes is your retry loop
  • 16. What that might look like ★ Your app connects to a DB on startup ★ App fails to connect, crashes ★ Tracing sees the conn. failure ★ Kubernetes restarts it ★ Monitoring, log aggregation pick up the restart ★ Alerting notifies if too many restarts ★ ...
  • 17. Unordered is better than ordered
  • 18. ★ Kubernetes & your app are distributed systems ★ Ordering is very hard in distributed systems ★ Try not to rely on ordering Unordered is better than ordered
  • 19. Use Kubernetes primitives. ★ Sidecar for locks, leader election ★ Resource versions in Kubernetes resources ★ Init containers (can be messy) But sometimes you need it
  • 20. Loose coupling is better than tight coupling
  • 21. Loose coupling is better than tight ★ Kubernetes is always watching ★ Your app should tolerate dynamism
  • 22. What that might look like ★ Pod => Pod messaging via Services ★ Crash if you can’t connect (crash-only) ★ Look for Kube resources via labels, not names
  • 23. … But tight coupling isn’t always wrong
  • 24. ★ Pods have >1 containers on purpose ★ Run tightly coupled containers in a pod Tight coupling isn’t always wrong
  • 25. ★ Envoy ★ Fluentd logging driver ★ Metrics What that might look like
  • 27. Record your configuration ★ Kubernetes APIs are declarative ★ Keep the latest working configuration in your repository ★ Let Kubernetes reconcile
  • 28. What might that look like
  • 29. Ask for the least
  • 30. Ask for the least If you’re: ★ Configuring RBAC permissions ★ Configuring containers in a pod ★ Asking for CPU shares or memory ★ Asking for disk space with a PersistentVolumeClaim Ask for the fewest possible of them. Leave more for Kubernetes
  • 31. What that might look like ★ Read-only permissions for your monitoring system ★ One CPU share for each web frontend ★ Minimal disk for your log aggregator ★ Tiny memory for your local proxy
  • 32. Build on the shoulders of giants
  • 33. Build on the shoulders of giants ★ Kubernetes provides a big API ○ … to abstract functionality that’s hard to get right ★ Maybe the community doesn’t do what you need ○ … but try to find the next best thing and build atop
  • 34. What that might look like Helm for managing your app lifecycle ★ Or the Helm API (which is gRPC) Traefik for Ingress ★ Or Traefik => service mesh => your app Fluentd for Logging ★ Or app => local translator => fluentd
  • 35. Parting thoughts: where should we go from here?
  • 36. Who should define our guidelines? ★ I’ve started the conversation here ★ We all have a wealth of experience ★ We need to share it
  • 38. We need your thoughts https://github.com/arschles/kube-best-practices
  • 42. Pay it forward ★ If you “build on the shoulders of giants,” open source it ★ You’ll be moving cloud native forward ★ We’ll progress as community & concept because of your work
  • 44. ★ Cloud native is young ★ If you disagree with a choice, others do too ★ Make your voice heard, and offer solutions Disagree constructively