K8s
How it works
A Kubernetes cluster consists of a control plane and worker nodes. A user submits a declarative description of the desired state (e.g. a Deployment manifest specifying a replica count) to the API server. The API server persists this state in the distributed key-value store etcd. The scheduler assigns pods to nodes based on resources and constraints, and the controller manager runs control loops that compare the actual state with the desired state and take corrective action. On each node, the kubelet agent starts and supervises containers through a (CRI-compliant) container runtime, while kube-proxy maintains network rules and load-balances traffic to Services.
Problem solved
Manually deploying and operating many containers across a fleet of servers is error-prone and scales poorly. Kubernetes solves scheduling containers onto available nodes, automatically restarting and replacing failures, scaling in response to load, and managing configuration declaratively and consistently across distributed and multi-cloud environments.
Components
The cluster's central entry point, exposing the Kubernetes REST API. It validates and processes requests and is the only component that talks directly to etcd.
A distributed, consistent key-value store that holds the entire cluster state and configuration; it is the source of truth for the desired state.
Assigns newly created pods to nodes based on available resources, affinity constraints, tolerations, and other rules.
Runs control loops (controllers) that observe cluster state and reconcile the actual state toward the desired state, e.g. maintaining a target replica count.
An agent that runs on each node; it accepts pod specifications from the API server and ensures the described containers are running and healthy.
Maintains network rules on nodes, enabling network communication to pods and load-balancing of traffic to Services.
The software responsible for running containers (e.g. containerd, CRI-O), communicating with the kubelet through the CRI interface.
The smallest deployable unit in Kubernetes: one or more containers that share networking and storage and are scheduled and run together.
An object that declaratively manages a set of pod replicas, handling rolling updates and rollbacks.
A stable network abstraction (fixed address and DNS name) that provides access and load-balancing to a dynamically changing set of pods.
Implementation
Pods without defined requests/limits can be poorly scheduled and cause node resource exhaustion and evictions.
etcd holds the entire cluster state; lack of backups or overload leads to data loss or control-plane instability.
Overly broad RBAC roles, privileged containers, and absent NetworkPolicies increase the cluster's attack surface.
Evolution
On 6 June 2014 Google announces Kubernetes, a project rooted in experience with the internal Borg system.
The paper "Large-scale cluster management at Google with Borg" (EuroSys 2015) documents the system that inspired Kubernetes.
On 21 July 2015 Kubernetes 1.0 is released; the project becomes the seed technology of the newly formed Cloud Native Computing Foundation (CNCF).
Hyperparameters (configurable axes)
The desired number of identical pod instances maintained by a Deployment/ReplicaSet.
Declared CPU/memory requests and upper limits for containers, affecting scheduling and node stability.
Rules for automatically changing the replica count based on metrics (e.g. CPU usage or custom metrics).
How new versions are rolled out (e.g. RollingUpdate vs Recreate) and the maxSurge/maxUnavailable parameters.
Execution paradigm
Kubernetes is not a neural-network architecture; the execution-paradigm fields describe its control model (state-reactive control loops), not an ML compute flow.
The scheduler routes pods to specific nodes, and controllers (reconciliation loops) conditionally take corrective action depending on the gap between desired and actual state.
Hardware requirements
Kubernetes orchestrates containers independently of the compute layer; it runs on CPUs and exposes accelerators (GPU/TPU) to nodes via device plugins.