A map of the interconnected ideas surrounding the core k8s concept

This map explores the implications, assumptions, and dependencies that make the Kubernetes Object Model work.

---

The Core Concept: The Declarative Control Loop

At the center is the idea that Kubernetes is not an orchestration system that executes a list of commands (Imperative). Instead, it is a system of independent, composable control processes that continuously drive the Current State toward a provided Desired State.

1. The "Record of Intent" (API & Etcd)

The system implicitly assumes that the "Desired State" must be persisted and versioned before any action is taken.

• The Object as a Contract: A Kubernetes object (defined in YAML) is a "record of intent." Once created, the system treats it as a contract it must fulfill.
• Asynchronous Communication: The user does not talk to the Kubelet or the Controller. The user talks to the API Server, which writes to etcd. The actual work happens asynchronously when controllers "watch" these changes.
• Implication: This requires Eventual Consistency. You cannot assume that because the API server said "201 Created," the resource is actually running. You must check the .status field, which controllers update to reflect reality.

2. Challenges: The Imperative Mindset (Operations)

This model fundamentally challenges how traditional sysadmins operate.

• "Fire and Forget" vs. "Observe and Correct": In traditional ops, you run a script to start a service. If the script finishes, you are done. In Kubernetes, the work is never "done." The controller runs a non-terminating loop (like a thermostat).
• Implication: Operations shift from action-based (e.g., restart service) to state-based (e.g., "delete the pod so the ReplicaSet creates a fresh one").
• Conflict Resolution: This challenges how we handle configuration. If you edit a live object manually (Imperative), and a YAML file is reapplied later (Declarative), conflicts occur. Kubernetes solves this via Server-Side Apply and Field Management, tracking who "owns" which field in the configuration.

3. Depends On: The "Disposable" Assumption (Ephemerality)

The Declarative model relies heavily on the assumption that individual components are unreliable and disposable.

• Cattle, not Pets: Pods are ephemeral. They are not "rescheduled" when they die; they are replaced by new Pods with different UIDs.
• Dependency on Abstraction: Because Pods die and change IPs, the system depends on higher-level abstractions to maintain stability.
  • Service Discovery: We need Services (stable IPs) because Pod IPs churn.
  • Storage Decoupling: We need PersistentVolumeClaims (PVCs) because the Pod's filesystem dies with the Pod.

4. Implications: The "Flat Network" Requirement

For the control loop to work universally (scheduling any Pod on any Node), the system implicitly assumes a specific networking model.

• Assumption: Every Pod must be able to reach every other Pod without NAT (Network Address Translation). This creates a "flat" network where the Pod IP is the same from inside the Pod and outside the Pod.
• Dependency: This forces the requirement for CNI Plugins (Calico, Flannel, Cilium) to wire up this network across different nodes. If the network isn't flat, the abstraction leaks, and the "Desired State" cannot be achieved.

5. Extensibility: "Teaching" the Control Loop (CRDs & Operators)

The system implies that the control loop logic shouldn't be hardcoded only for built-in resources (like Pods).

• CRD (Custom Resource Definition): This allows you to define a new "Desired State" schema (e.g., kind: Database).
• Operator Pattern: This is simply writing your own Controller. It watches your CRD and executes the "Make it so" logic.
• Implication: This turns Kubernetes from a "Container Orchestrator" into a generic "API-driven Infrastructure Framework." You can use the same logic to manage AWS buckets or physical switches, provided you write a controller that talks to them.

Summary Map

Concept Area	Interconnected Idea	How it relates to the Core
Persistence	etcd	The "Brain" that stores the Desired State. The system stops without it.
Execution	Controllers	The "Hands" that enforce the state. They read the API and touch the world.
Networking	CNI / Flat Network	The "Circulatory System." A hard dependency for Pods to communicate regardless of location.
Storage	CSI / PVCs	Decouples data from the ephemeral compute (Pod) lifecycle.
Operations	YAML / Apply	The language used to describe the Desired State.
Extension	CRDs / Operators	Allows users to add new concepts to the Declarative Model.