Kubernetes is built around a set of core concepts that define the architecture and components of the platform. In this article, we will provide an overview of these core concepts, which are essential for understanding how Kubernetes works and how to build and deploy applications on the platform.

Nodes

Nodes are the physical or virtual machines that make up a Kubernetes cluster. Each node runs a container runtime (such as Docker) and the necessary Kubernetes components to manage and communicate with the cluster. Nodes can be organized into groups, called worker nodes and control plane nodes.

Worker nodes are responsible for running the containerized applications (workloads), while control plane nodes host the critical components that manage the overall state of the cluster, such as the API server, etcd, and the controller manager.

Pods

Pods are the smallest and simplest unit in the Kubernetes object model. A pod represents a single instance of a running process and can contain one or more containers. Containers within a pod share the same network namespace, which means they can communicate with each other using localhost and share the same volume mounts.

Pods are ephemeral by nature; they can be created, destroyed, or rescheduled based on the needs of the cluster. If a node fails, the pods running on that node are terminated, and new pods are created on available nodes.

Services

Services are Kubernetes objects that provide a stable network endpoint for pods. They act as an abstraction layer for load balancing and service discovery, ensuring that traffic is routed to the appropriate pods as they are created, destroyed, or rescheduled. Services can be exposed within the cluster, externally, or both, depending on the desired configuration.

Deployments

Deployments are high-level abstractions that allow you to declaratively manage the desired state of your application. They manage the creation, scaling, and rolling updates of pods, ensuring that the desired number of replicas is maintained and that updates are performed without downtime. Deployments use ReplicaSets under the hood to manage the desired number of pod replicas.

ConfigMaps

ConfigMaps are Kubernetes objects used to store non-sensitive configuration data in key-value pairs. They can be used to decouple configuration data from container images, making it easier to manage and update application configurations without rebuilding the images. ConfigMaps can be consumed by pods as environment variables, command-line arguments, or files in a volume.

Secrets

Secrets are similar to ConfigMaps, but they are designed to store sensitive data, such as passwords, API keys, and tokens. The data stored in secrets is base64 encoded and can be consumed by pods in the same ways as ConfigMaps. Kubernetes ensures that secret data is stored securely and only accessible by authorized users and services.

Ingress

Ingress is an API object that manages external access to the services in a cluster, typically via HTTP or HTTPS. It provides a set of rules for routing external traffic to the appropriate services, based on factors such as hostnames or paths. Ingress resources require an Ingress controller, such as NGINX or Traefik, to implement the rules and manage the traffic.

StatefulSets

StatefulSets are a higher-level abstraction for managing stateful applications, such as databases or message queues, in a Kubernetes cluster. They ensure that pods are created with unique, persistent identities (e.g., web-0, web-1) and that their storage volumes are also unique and persistent. This allows stateful applications to maintain their data across pod rescheduling and updates.

DaemonSets

DaemonSets are used to deploy and manage one instance of a pod on every node in the cluster.