“The Elements of Style” is one of the most important and foundational guidelines on how to write well. It has effectively summarized, in a list of seminal guidelines, how to harness the power of the English language to write high quality prose of almost any kind.
In computing, we have similar guides for various technologies. Python offers “The Zen Of Python”, Ruby has “The Rails Doctrine”, and so on...
One of the powers these documents wield is that they help serve as a “north star” that guides an entire community toward the same goals.
I believe we need a similar guide for Kubernetes. It would describe how app developers and operators should think about and use the features in Kubernetes to build and deploy reliable, stable apps. Armed with such a guide, we could all hope to better understand the “essence” of Kubernetes in pursuit of building better cloud native apps.
We don’t have anything like this today, but many in the Kubernetes community have strong, detailed opinions for what should go in this guide. Much of it is tribal knowledge or scattered in blog posts.
In this talk, I’ll try to bring many of these opinions together and lay out an “Elements of Kubernetes” guide for app developers and operators alike. I’ll do so by relating each “element” to stories and details I’ve seen in the community that reveal what makes a good Kubernetes and cloud native app.
This talk was given at KubeCon / CloudNativeCon 2017 on December 7th, 2017 in Austin, TX
1 of 44
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
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
★ ...
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
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
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
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
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