Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Avoiding the Heat Death of Kubernetes and the C...

Avoiding the Heat Death of Kubernetes and the CNCF Landscape

Presented at KubeCon EU 2024 in Paris as a poster session: https://www.cncf.io/blog/2024/02/22/announcing-new-poster-pavilion-sessions-at-kubecon-cloudnativecon-europe/
Sched link: https://sched.co/1YhDq
Co-presenter Madhav Jivrajani (https://twitter.com/MadhavJivrajani)

Abstract:
The concept of entropy is a measure of disorderliness or chaos. The second law of Thermodynamics states that the Universe evolves spontaneously towards more chaotic states, eventually to “the Heat Death”. Kubernetes started off as a container orchestrator for stateless web apps. But now, what once was an orderly list of use-cases, has become a turbulent sea of possibility and complexity. This is also the case for the CNCF Landscape as a whole. With novel use cases in e.g. AI, cloud native will also need to evolve, increasing entropy. However, as we navigate these possibilities with Kubernetes at the base, it is critical that we talk about some of the philosophies and early decisions of the project, as well as how they have fared with an evolving industry. In doing so, we understand what we can rely on it for and what we can’t. Continuing from Tim Hockin’s keynote, join us as we talk about the physics of cloud native and how our community can deal with unseen use cases and scale.

Lucas Käldström

March 20, 2024
Tweet

More Decks by Lucas Käldström

Other Decks in Technology

Transcript

  1. Entropy, Life and Information In Physics, entropy is a measure

    of disorderliness or “chaos” in a system, or it is a measure of how many states a given system can be in, with more states corresponding to a higher entropy. The First Law of Complexodynamics (Aaronson, 2011) Kolmogorov complexity (1963): The length of the smallest program to output a string. Thus high entropy can have low complexity. Information value of a message is thus linked to its entropy and complexity. 4. Ensure the symbols are correctly recognized (know what API struct to decode into) 5. Interpret the message with the right meaning (=semantics). (Shannon, 1948 + Burgess, 2013) *All information transmission in the end happens through physical particles one way or the other, so there is always room for error and distortion. **Kubernetes was not necessarily designed with Promise Theory in mind. We don’t know if Promise Theory had influence on the Kubernetes design. The Promise of Kubernetes Promise Theory: Based around the idea that actors (humans, controllers, etc.) of a system announce what they can promise to do (define an interface), in a “bottoms up” way, compared to military-style “top-down obligations” (that might be ambiguous). Promises, modelling real-world interactions, might succeed, or not, which forces the system designer to plan for failure, compared to it being an afterthought. You can look at a system’s promises at various scales/levels of detail, where at a larger scale low-level promises “cancel out”. How does Kubernetes relate to Promise Theory?** Kubernetes is a set of controllers promising to fulfill user desired state, communicating through a consistent declarative view of the infrastructure state, defined through APIs with strong semantics. Controllers either promise an outcome to a user or another controller and make use of promises given to them to fulfill actions. Implementation complexity is encapsulated into these controllers, to yield users a lower-entropic / higher-level state-driven interface that can be inspected (unlike Turing machines). The API machinery of Kubernetes designed to transmit intent as reliably as possible, through JSON with explicit type metadata and strong & uniform API semantics. Internal vs external: Consider how controller-to-controller promises in Kubernetes kind of “cancel out” for the end user, they do not need to know how a Deployment implements workload orchestration, only the API surface. Caveat: Hyrum’s law says that all observable behavior is depended upon. CNCF Ecosystem and Entropy Similar to the origin of life, is there a region of time in the growth of the CNCF ecosystem that is favourable to innovation, adaptation and adoption? Kubernetes as a “Platform for Platforms”: It is meant to be built on top of, beyond containers, for controlling arbitrary infrastructure in an uniform way. Kubernetes provides a declarative, extensible, yet uniform API server for storing both (users’) desired and (observed) actual state of the infrastructure. Dunbar (1992) showed that humans have limited capacity for social relationships: this includes technology tools as well. One cannot “know” more than a certain number of tools and patterns. (Just try reading a sentence with 5 clauses). This limits feasible growth opportunities of the CNCF ecosystem, especially if projects do not find ways to “cancel out” complexity through joint promises and interoperability. Can we achieve that? Call To Action: As we grow further, we need to focus on better standards and semantics in the ecosystem to be able to innovate and keep users’ “complexity budget” (Hockin) in check. Avoiding the Heat Death of Kubernetes and the CNCF Landscape Lucas Käldström and Madhav Jivrajani As entropy increases, the ability of a system to do productive work, its free energy goes down. Second Law of Thermodynamics: Entropy can only spontaneously stay constant or increase. Often more entropy => more “complexity”, but a uniform heat death is not really “complex”. Schrödinger explored entropy and meaning of life in 1944, suggesting the existence of highly-ordered human beings is paid for by inevitable human-created chaos. How can two actors communicate? 1. Agree on a set of symbols (=API) to use for information representation. 2. Encode and decode the message accurately (e.g. JSON/protobuf). 3. Ensure any distortion*, noise or errors in the message are corrected, or detected, Project Comparison Dimensions: Can we find common “dimensions” and “promises” of projects for easier comparison and evaluation? This could help users and be part of graduation level evaluation.
  2. Entropy, Life and Information References: Blundell, S. J., and Blundell,

    K. M. (2009). Concepts in Thermal Physics, 2nd edn, Oxford https://doi.org/10.1093/acprof:oso/9780199562091.001.0001 Schrödinger, E. (1992). What is life? : the physical aspect of the living cell ; with mind and matter ; & autobiographical sketches. Cambridge University Press. https://archive.org/details/whatislifeothers00schr/ Aaronson, S. (2011). The First Law of Complexodynamics https://scottaaronson.blog/?p=762 Kolmogorov, A. N. (1963). On Tables of Random Numbers. Sankhyā: The Indian Journal of Statistics, http://www.jstor.org/stable/25049284 Shannon C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal 379. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x The Promise of Kubernetes References: Burgess, M. (2013) In Search of Certainty. Createspace Independent Pub http://markburgess.org/certainty.html Käldström, L. (2021) Encoding human-like operational knowledge using declarative Kubernetes operator patterns. BSc thesis, Aalto University. https://github.com/luxas/research The Kubernetes Authors (2014->). API Conventions. https://github.com/kubernetes/community/blob/master /contributors/devel/sig-architecture/api-conventions.md Wright, H. (2020?) Hyrum’s Law. https://www.hyrumslaw.com/ CNCF Ecosystem and Entropy References: Beda, J. (2018) Kubernetes is a Platform Platform. DevOpsDays Seattle. https://youtu.be/QEu6dpQnJ7A Dunbar, R. I. M. (1992). Neocortex size as a constraint on group size in primates. Journal of Human Evolution. 22 (6): 469–493. https://doi.org/10.1016%2F0047-2484%2892%2990081-J Hockin, T. (2023). Keynote: A Vision for Vision - Kubernetes in Its Second Decade. KubeCon + CloudNativeCon Chicago. https://youtu.be/WqeShpaztZY Avoiding the Heat Death of Kubernetes and the CNCF Landscape Lucas Käldström and Madhav Jivrajani