Kubernetes & Cloud Native Architecture - Operations & Deployment

A Pod is the smallest deployable unit in Kubernetes, representing a single instance of a running process in your cluster. It encapsulates one or more containers (e.g., Docker containers), storage resources, a unique network IP, and options that govern how the containers should run.

A ConfigMap is an API object used to store non-sensitive configuration data in key-value pairs. It allows you to decouple configuration artifacts from image content to keep containerized applications portable. ConfigMaps can be consumed by Pods as environment variables, command-line arguments, or as files in a volume.

A Pod progresses through several phases:
1. Pending: The Pod has been accepted by the Kubernetes system, but one or more of the container images has not been created or configured.
2. Running: The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
3. Succeeded: All containers in the Pod have terminated successfully, and will not restart.
4. Failed: All containers in the Pod have terminated, and at least one container has terminated in failure (e.g., non-zero exit status), and will not restart.
5. Unknown: For some reason, the state of the Pod could not be obtained.

A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. Its primary role is to maintain the desired state of a set of Pods, automatically creating or deleting Pods as needed to match the configured replica count.

A Deployment provides declarative updates for Pods and ReplicaSets. It manages the creation, update, and deletion of ReplicaSets to achieve the desired state of your application. Deployments handle rolling updates, rollbacks, and scaling by orchestrating changes to ReplicaSets without direct user interaction with the ReplicaSet objects.

A Deployment is used for stateless applications, where Pods are interchangeable and have no unique identity or persistent state. A StatefulSet, on the other hand, is designed for stateful applications that require stable, unique network identifiers, stable persistent storage, and ordered, graceful deployment and scaling. Each Pod in a StatefulSet has a sticky identity and predictable naming.

You would choose a StatefulSet for applications that require:

Common use cases include databases (e.g., MySQL, PostgreSQL), message queues (e.g., Kafka), and other distributed systems that rely on stable identities and persistent data.

A Service is an abstract way to expose an application running on a set of Pods as a network service. It's needed because Pods are ephemeral and can be created or destroyed, changing their IP addresses. A Service provides a stable IP address and DNS name, acting as a load balancer to distribute traffic to the healthy Pods that match its selector, ensuring continuous access to your application.