Kubernetes is an open-source container orchestration platform designed to automate the deployment, scheduling, scaling, networking and lifecycle management of containerised workloads. It was originally developed at Google and released as open source in 2014, with its design influenced by Google's earlier internal container-management systems. Kubernetes has since become a major platform for running distributed applications across clusters of compute nodes and is available through managed services as well as self-managed installations.
Its architecture centres on a control plane that maintains cluster state and worker nodes that execute workloads. Users describe desired resources through Kubernetes API objects, and controllers continuously attempt to make actual cluster state conform to that desired state. Kubernetes is therefore more than a container launcher: it provides abstractions for workload scheduling, service discovery, networking, configuration, secrets, storage and controlled application updates.
The Kubernetes architecture consists of several important components. The API server provides the principal interface through which clients and cluster components communicate. The cluster's persistent state is stored in etcd, a distributed key-value store. The scheduler selects suitable nodes for newly created workloads based on resource requirements, constraints, affinity rules and other scheduling information. Controllers observe cluster state and take actions to reconcile it with desired state.
Worker nodes run components responsible for managing workloads and networking, while a container runtime executes containers. The exact component architecture can vary across Kubernetes distributions and managed services, because cloud providers may operate portions of the control plane on behalf of customers. This separation allows users to declare resources through the Kubernetes API while platform components continuously perform the lower-level operations needed to maintain the requested state.
Kubernetes organises workloads through objects such as Pods, Deployments, StatefulSets, DaemonSets and Jobs. A Pod is the smallest deployable unit in Kubernetes and can contain one or more containers that share networking and certain storage resources. Deployments commonly manage stateless application replicas and support rolling updates, while StatefulSets provide mechanisms suited to workloads requiring stable identities and persistent storage relationships. DaemonSets ensure that a workload runs on selected nodes, making them useful for node-level agents.
Jobs and CronJobs support finite or scheduled workloads. These abstractions separate the description of an application workload from the individual machine on which it happens to execute. If a node fails, controllers can recreate eligible workloads elsewhere, subject to resource availability and scheduling constraints. This reconciliation model is fundamental to Kubernetes because operators generally specify desired workload characteristics rather than manually managing individual containers.
Kubernetes networking provides stable service discovery and communication between distributed workloads. Pods receive network identities, while Service objects provide stable endpoints through which other workloads can reach changing sets of Pods. Different networking implementations are supplied through the Kubernetes networking model and container network interfaces. Ingress and, in newer architectures, Gateway-related resources can expose HTTP and other application traffic to external clients through configured routing mechanisms.
NetworkPolicies can restrict traffic between selected workloads when the installed network implementation supports the required policy features. Kubernetes networking differs from ordinary host networking because workloads may move between nodes and their IP addresses can change. The platform therefore relies on abstractions that decouple application connectivity from the lifecycle of individual Pods. Understanding these abstractions is important when designing applications because service discovery, load balancing, DNS and network policy become distributed platform concerns rather than simple server configuration tasks.
Kubernetes manages configuration and sensitive values through objects such as ConfigMaps and Secrets, although the security properties of these mechanisms depend on cluster configuration and external integrations. Configuration should generally be separated from container images so that the same image can be deployed across environments with different settings. Secrets require stronger protection because they can contain credentials, tokens or keys, and appropriate encryption, access control and external secret-management integrations may be necessary.
Kubernetes uses Role-Based Access Control to determine what identities can perform against which API resources. Service accounts or workload identities allow applications to interact with APIs without relying on personal user credentials. Excessively broad permissions can create severe security consequences because Kubernetes control-plane access can indirectly provide control over workloads and infrastructure. Secure cluster design therefore requires careful management of API access, admission controls, network policies, image provenance and workload privileges.
Kubernetes supports scaling and resilience through several mechanisms. Deployments can maintain a specified number of replicas, while autoscaling mechanisms can adjust workload capacity according to configured signals. Node-level scaling can add or remove compute capacity when cluster resources become constrained, depending on the environment and infrastructure integration. Health probes allow Kubernetes to distinguish workloads that are functioning from those that are merely running.
Liveness probes can trigger container restarts when an application is considered unhealthy, while readiness probes control whether a workload should receive traffic. Poorly designed probes can cause instability, however, because an application can be restarted unnecessarily or removed from service during temporary conditions. Resource requests and limits also influence scheduling and resource isolation. Correct capacity configuration is therefore essential because Kubernetes can only make effective scheduling and scaling decisions from the resource and health information it receives.
Kubernetes is highly extensible. Custom Resource Definitions allow additional API object types to be introduced, while controllers and operators can implement domain-specific reconciliation logic. This enables Kubernetes to manage resources beyond basic container workloads, including databases, certificates, infrastructure integrations and application-specific services. The operator pattern packages operational knowledge into software that watches resources and performs actions to maintain desired state. Kubernetes also has a large ecosystem covering networking, storage, observability, security, deployment and policy.
This extensibility is powerful but contributes to complexity because a production cluster may contain many interacting controllers, admission mechanisms and custom resources. Kubernetes should therefore not be adopted merely because it is capable of solving a problem; its operational complexity, team expertise, workload requirements and managed-service alternatives should be considered when selecting an architecture.
Kubernetes provides portability, automated reconciliation, workload scheduling, scaling, service discovery, controlled deployments and a broad ecosystem, but it also introduces substantial operational complexity. Cluster upgrades, networking, storage, security, observability, resource management and application debugging can require specialised knowledge. Kubernetes is not itself a cloud provider and does not eliminate the need to manage underlying compute, storage and network resources unless a managed Kubernetes service handles those responsibilities. It also does not make containers secure automatically.
Kubernetes should be distinguished from Docker: Docker is primarily a container development and runtime ecosystem, whereas Kubernetes orchestrates workloads across clusters and can use container runtimes other than Docker. Kubernetes is also distinct from Terraform because Terraform commonly provisions infrastructure, while Kubernetes primarily manages workloads and resources within a cluster. Its importance comes from providing a general reconciliation-based platform for operating distributed containerised applications at scale.
