Explore Our DevOps Hub

Introduction:

Welcome to the wonderful world of Kubernetes! If you’re curious about managing containerized applications effectively, understanding Kubernetes’ architecture is crucial. This blog post is your friendly guide to navigating the essential components and how they work together to orchestrate your applications seamlessly.

The Big Picture: Control Plane vs. Data Plane

Imagine Kubernetes as an orchestra:

• Control Plane: The conductor, leading the show. It comprises several components that make key decisions, manage the overall state, and issue instructions.
  • API Server: The central point of entry for commands and interactions.
  • etcd: The data store, keeping track of the desired and current state of the cluster.
  • Scheduler: Assigns containers to nodes based on resource availability and policies.
  • Controller Manager: Ensures the cluster state matches the desired state using various controllers (Deployment, ReplicaSet, Pod, etc.).
• Data Plane: The musicians, carrying out the conductor’s instructions. Nodes are the individual servers where containers run the applications.
  • Kubelet: Resides on each node, receiving instructions from the control plane and managing containers locally.
  • Container Runtime: (e.g., Docker, containerd) The engine that starts, stops, and manages individual containers.
  • Pods: Group one or more containers that share storage and network resources. They’re the atomic unit of deployment in Kubernetes.
• Below is the diagram which explain the architecture of k8s with diagram.

Beyond the Orchestra: Essential Concepts

Remember, the orchestra needs sheet music:

Pod:

• Smallest deployable unit, grouping one or more containers with shared resources.
• Isolated with own network namespace and security context.
• Resource limits: CPU, memory can be specified and enforced.
• Can have ephemeral or persistent storage.

Deployment:

• Manages desired state of pods, ensuring desired number of replicas are running.
• Scales replicas up or down easily.
• Performs rollouts with controlled updates and rollbacks.
• Self-heals by restarting containers or replacing pods during failures.

StatefulSet:

• Manages deployments of stateful applications with persistent storage and ordered scaling.
• Uses Persistent Volumes (PVs) or local storage provisioners.
• Maintains stable pod identities even after scaling or restarts.
• Updates pods one by one to preserve state.

DaemonSet:

• Runs a pod on each node in a cluster, suitable for background tasks or agents.
• Ensures a pod runs on every node.
• Self-heals by replacing failed pods on their assigned nodes.

ReplicaSet:

• Internal component used by Deployments and StatefulSets.
• Manages the scale of a deployment/statefulset, ensuring desired number of replicas.
• Creates and scales pods to match replica count.
• Self-heals by replacing failed pods.

ConfigMap:

• Stores non-sensitive configuration data in key-value pairs.
• Accessible to pods as environment variables.
• Decouples configuration from code, no image rebuilds needed.
• Shares configuration across pods for consistency.

Secret:

• Stores sensitive data like passwords, tokens, credentials.
• Accessible to pods via environment variables or files.
• Encapsulates secrets, preventing exposure in logs or code.
• Granular access control for specific pods or namespaces.

Namespace:

• Provides a virtual cluster within the physical cluster.
• Isolates resources and permissions for different teams or projects.
• Groups related resources logically.

Service:

• Exposes an application through a stable network identity (service name and port).
• Load balances traffic across healthy pods.
• Enables service discovery for pods.
• Ensures service remains accessible even with pod failures.

Ingress:

• Controls external traffic entering the cluster.
• Provides routing, TLS termination, and authentication.
• Routes traffic based on URL paths or hosts.
• Decrypts HTTPS traffic at the ingress.
• Integrates with authentication providers.

PersistentVolume (PV):

• Represents persistent storage that can be claimed by pods.
• Has reclaim policy defining lifecycle management when pods using it are deleted.
• Specifies access modes (ReadWriteOnce, ReadOnlyMany).

PersistentVolumeClaim (PVC):

• Requests storage from the cluster, referencing a specific PV or storage class.
• Specifies desired storage size and access modes.
• Associates with a specific PV through binding.

Node:

• A worker machine in the cluster where pods run.
• Runs a specific Kubernetes version.
• Has CPU, memory, storage resources available.
• Can have labels and annotations for scheduling.

ServiceAccount:

• Identity used by pods to access API server or other resources.

The Magic Behind the Orchestration:

• Desired State vs. Actual State: Controllers continuously compare the desired state (defined in Deployments) to the actual state (running pods). Any discrepancies trigger actions to achieve the desired state.
• Self-Healing: If a pod fails, Kubernetes automatically starts a new one to maintain the desired number of replicas.
• Scaling: Easily scale applications up or down by adjusting replica counts in Deployments.

Conclusion:

This is just a taste of Kubernetes’ architecture. By understanding these core building blocks, you’ll be well on your way to leveraging its power for robust and scalable containerized application management. As you delve deeper, explore advanced topics like networking, storage, and security to truly master the Kubernetes symphony!