Kubernetes Borg/Omega history topic 6: Watch. This is a deep topic. It's a follow-up to the controller topic. I realized that I forgot to link to the doc about Kubernetes controllers: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/controllers.md …
-
-
We built Kubernetes upon Etcd due to its similarities to Chubby and to the Omega store. When we exposed Etcd's watch (https://coreos.com/etcd/docs/latest/learning/api.html …) through the K8s API, we let more Etcd details bleed through than originally intended. We need to clean up some of those details soon
Show this thread -
The Kubernetes model is described here: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md#declarative-control …
Show this thread -
Some other systems use message buses for notifications. Why didn't we? Controllers need to start from the initial state, we also don't want them to fall behind or operate on state that's too stale, and they need to be able to handle "missed" events -- the level-based rationale
Show this thread -
We also wanted Kubernetes to run with a small number of dependencies, and with bounded compute and storage capacity: if we assumed a managed message bus that could store a week of events and an elastic compute platform to process them in parallel, the design would be different
Show this thread -
Watch works well for our typical scenario of mostly active entities with high rates of change per entity, and not a vast number of inactive entities (as opposed to, say, sales catalog entries), since it assumes access to all the relevant state. At some point, we'll need to shard
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.