ConfigMaps 102: Using ConfigMaps in Dynamic Application Deployments
summary
Shows that embedding a tiny Kubernetes client (client-go) in an app lets the app read and compose ConfigMaps on demand, avoiding name/order/startup constraints and the ~1 minute pod sync latency. Demonstrates a Go loop that polls every 10s and writes keys to files, and a real Oshinko-based Spark cluster that changes worker count and logging level from stored ConfigMaps and works as expected. Notes the 1 MB ConfigMap limit and optional=true added in 1.6.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:17You're still here ...
- 0:44Overview
- 2:08What is a ConfigMap?
- 2:55How does it make my life better?
- 4:12How can I create one?
- 6:08How can my app consume one?
- 8:23There are some limitations
- 11:55An alternative method
- 12:10Dynamic Application Model
- 13:31Flexible Ordering
- 13:46Flexible Naming
- 14:08Update Handling
- 14:57Composability
- 16:41Too much?
- 17:37Limited Exposure
- 19:16Making the clientset outside a pod...
- 22:53radanalytics.io
- 23:33Containerized Spark App
- 23:51Make a cluster with oshinko
- 24:37How Oshinko uses ConfigMaps
- 30:58Takeaways and Info
related talks
20mMagic Dust in your apps? Configurable frontend...
30mWho Let the Pods Out? Extending Kubernetes with Custom Controllers and CRDs
33mLevel Up Your Developer Experience 🧭
27mManaging Developer Workflows with the Kubernetes API
26mThe Control Loop As An Application Development Framework
35mPlays Well with Others: Composability for Cloud Native Applications
35mDancing with Helm, Skaffold and Minikube!
28mOverview Of Challenges And Solutions For Orchestrating Applications To Multiple DC And Edge Clusters