Kubernetes Architecture

A Kubernetes cluster consists of two types of resources: the Control Plane and Nodes.

1. Control Plane

The “brain” of the cluster. It makes global decisions (like scheduling) and detects/responds to cluster events.

• kube-apiserver: The front end for the Kubernetes control plane. It exposes the API.
• etcd: Consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.
• kube-scheduler: Watches for newly created Pods with no assigned node, and selects a node for them to run on.
• kube-controller-manager: Runs controller processes (like Node Controller, Job Controller).
• cloud-controller-manager: Links your cluster into your cloud provider’s API.

2. Nodes

The worker machines that run applications.

• kubelet: An agent that runs on each node in the cluster. It ensures that containers are running in a Pod.
• kube-proxy: A network proxy that runs on each node, maintaining network rules and performing connection forwarding.
• Container Runtime: The software responsible for running containers (e.g., Docker, containerd, CRI-O).

3. Objects

• Pod: The smallest deployable units of computing that you can create and manage in Kubernetes.
• Service: An abstract way to expose an application running on a set of Pods as a network service.
• Volume: A directory containing data, accessible to the containers in a Pod.
• Namespace: Virtual clusters backed by the same physical cluster.

Horizontal Pod Autoscaling (HPA)

The HPA automatically scales the number of Pods in a Deployment, ReplicaSet, or StatefulSet based on observed CPU utilization (or, with custom metrics support, on some other application-provided metrics).

1. How it Works

The HPA is implemented as a control loop. The Horizontal Pod Autoscaler controller periodically (default every 15s) queries the resource utilization against the metrics specified in each HPA definition.

• It fetches metrics from the Metrics Server (or a custom metrics API).
• It calculates the ratio between current utilization and desired utilization.
• It updates the replicas field of the target workload.

2. The Formula

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

3. Key Components

• Metrics Server: A cluster-wide aggregator of resource usage data.
• Cool-down / Delay: To prevent “flapping” (rapidly scaling up and down), HPA has built-in delays (e.g., stabilizationWindowSeconds).

4. Requirements

For HPA to work based on CPU/Memory, you must define requests for those resources in your Pod specification. If there are no requests, the HPA won’t know what “100% utilization” means and will fail to scale.

Configuration Management in Kubernetes

Kubernetes provides two primary objects for injecting configuration into containers at runtime, allowing you to keep your container images generic and environment-agnostic.

1. ConfigMaps

• Purpose: Storing non-sensitive configuration data (e.g., config files, environment variables, command-line arguments).
• Format: Key-value pairs.
• Usage: Can be mounted as files or injected as environment variables.

2. Secrets

• Purpose: Storing sensitive data (e.g., passwords, API keys, SSH keys, TLS certificates).
• Format: Key-value pairs, where values are Base64 encoded.
• Security: In a default cluster, Secrets are only obfuscated (Base64), not encrypted. For true security, they should be encrypted at rest (using a provider like AWS KMS or HashiCorp Vault).
• Usage: Similar to ConfigMaps, can be mounted as files or environment variables.

How to Inject Them

1. Environment Variables: Best for simple flags and settings.
2. Volumes (Files): Best for large configuration files. If the ConfigMap/Secret is updated, the files in the volume are eventually updated by the kubelet without a restart (if using the subPath feature, they are not updated).

Kubernetes Deployment Strategies

When you update a Deployment (e.g., change the image version), Kubernetes needs to replace the old Pods with new ones. It offers two primary strategies out of the box.

1. RollingUpdate (Default)

• Mechanism: Gradually replaces old Pods with new ones. It ensures that a certain number of Pods are always available to serve traffic.
• Key Parameters:
  • maxUnavailable: The maximum number of Pods that can be unavailable during the update.
  • maxSurge: The maximum number of Pods that can be created over the desired number of Pods.
• Pros: Zero downtime. If the new version fails its readiness probe, the rollout stops.
• Cons: For a period, two different versions of your app will be running simultaneously. Your database schema must support both versions.

2. Recreate

• Mechanism: Kills all existing Pods before creating new ones.
• Pros: Simple. Ensures that only one version of the application is running at any time. No risk of version mismatch during the update.
• Cons: Causes downtime between the time the old Pods are deleted and the new Pods become ready.

3. Advanced Strategies (via Ingress/Service Mesh)

• Blue/Green: Run both old (Blue) and new (Green) versions fully, then switch all traffic at once.
• Canary: Route a small percentage of traffic (e.g., 5%) to the new version to test it before rolling it out to everyone.

Kubernetes Ingress

An Ingress is an API object that manages external access to the services in a cluster, typically HTTP. It can provide load balancing, SSL termination, and name-based virtual hosting.

1. The Ingress Resource

The Ingress resource is a set of rules that allow inbound connections to reach the cluster services.

• Path-based routing: example.com/api goes to service A, example.com/shop goes to service B.
• Host-based routing: api.example.com goes to service A, shop.example.com goes to service B.

2. The Ingress Controller

The Ingress resource does nothing by itself. You must have an Ingress Controller running in the cluster to fulfill the Ingress.

• Common controllers include NGINX Ingress Controller, Traefik, HAProxy, and cloud-specific ones like AWS ALB Ingress Controller.
• It is usually a reverse proxy deployed as a Deployment or DaemonSet.

3. Why use Ingress over LoadBalancer Services?

While a LoadBalancer service creates a new cloud load balancer for every service (which is expensive and hard to manage), an Ingress allows you to use a single IP/Load Balancer to route traffic to dozens of internal services based on the URL path or hostname.

Kubernetes Health Probes

Probes allow Kubernetes to monitor the health of your applications and take automatic action when things go wrong.

1. Liveness Probe

• Goal: Is the container alive?
• Action: If it fails, the kubelet kills the container and restarts it (based on the restart policy).
• Use Case: Catching deadlocks where the app is running but can’t do anything.

2. Readiness Probe

• Goal: Is the container ready to serve traffic?
• Action: If it fails, the container’s IP is removed from all Services (endpoints). Traffic is stopped until it passes again.
• Use Case: During app startup (loading big files, connecting to DB) or when an app is temporarily overloaded.

3. Startup Probe

• Goal: Has the application started?
• Action: All other probes are disabled until the startup probe succeeds.
• Use Case: Legacy apps that take a long time to boot. It prevents the Liveness probe from killing the container before it finishes starting up.

Probe Mechanisms

• HTTP GET: Returns a 2xx or 3xx status code.
• TCP Socket: Can a TCP connection be established on a specific port?
• Exec: Run a command inside the container. Exit code 0 is success.
• gRPC: Uses the gRPC Health Checking Protocol.

Kubernetes RBAC

RBAC is the mechanism used to control who can do what within a Kubernetes cluster. It uses the rbac.authorization.k8s.io API group to drive authorization decisions.

1. The Four Core Objects

• Role: Defines a set of permissions within a specific Namespace. (e.g., “can read pods in ‘default’”).
• ClusterRole: Defines a set of permissions across the entire cluster or for non-namespaced resources (like Nodes).
• RoleBinding: Grants the permissions defined in a Role to a user or set of users within a specific Namespace.
• ClusterRoleBinding: Grants permissions defined in a ClusterRole to a user or set of users across the entire cluster.

2. Subjects

Subjects are the entities that are granted permissions:

• Users: Managed externally (e.g., via Google Accounts or certificates). Kubernetes does not have a “User” object.
• Groups: Sets of users.
• ServiceAccounts: Identities for processes running in Pods. This is how your code talks to the Kubernetes API.

3. Verbs and Resources

Permissions are defined as a combination of:

• Verbs: get, list, watch, create, update, patch, delete.
• Resources: pods, services, deployments, secrets, etc.

4. Best Practice: Least Privilege

Always start with no permissions and add only what is strictly necessary. Use Namespaced Roles instead of ClusterRoles whenever possible to limit the “blast radius” of a compromised identity.

Kubernetes Resource Management

Kubernetes allows you to specify how much CPU and Memory (RAM) each container needs. This is critical for the scheduler to decide which node to place a Pod on and for the node to manage its resources.

1. Requests

• Definition: The minimum amount of resources a container is guaranteed to have.
• Scheduling: The scheduler uses the sum of requests to ensure a node has enough capacity before placing a Pod there.
• Over-commitment: If a node is over-committed, containers are guaranteed their requested amount but may compete for any remaining “slack” capacity.

2. Limits

• Definition: The maximum amount of resources a container is allowed to consume.
• CPU Limits: If a container exceeds its CPU limit, it is throttled (slowed down). It is usually not killed.
• Memory Limits: If a container exceeds its memory limit, it is OOM Killed (Out of Memory) by the kernel.

3. Quality of Service (QoS) Classes

Kubernetes assigns a QoS class to Pods based on their requests and limits:

• Guaranteed: Requests and Limits are equal for all containers in the Pod. (Most stable).
• Burstable: At least one container has a request, but they are not equal to limits.
• BestEffort: No requests or limits are specified. (First to be killed when the node is under pressure).

Kubernetes Scheduling Controls

By default, the Kubernetes scheduler tries to balance Pods across nodes. However, you often need to override this behavior for performance, security, or infrastructure reasons.

1. Taints and Tolerations

• Taints: Applied to Nodes. They allow a node to “repel” a set of pods. A taint has a key, value, and effect (e.g., NoSchedule).
• Tolerations: Applied to Pods. They allow (but do not require) the pod to schedule onto nodes with matching taints.
• Use Case: Dedicating nodes to a specific team or specialized hardware (like GPUs).

2. Node Affinity

• Definition: Applied to Pods. It is a set of rules used by the scheduler to determine where a pod can be placed, based on labels on the node.
• Types:
  • requiredDuringSchedulingIgnoredDuringExecution: Hard requirement (must match).
  • preferredDuringSchedulingIgnoredDuringExecution: Soft requirement (try to match).
• Use Case: Ensuring a Pod runs on a node with an SSD or in a specific Availability Zone.

3. Pod Affinity and Anti-Affinity

• Affinity: Keep related Pods together on the same node (e.g., an app and its cache) to reduce latency.
• Anti-Affinity: Keep Pods apart (e.g., don’t put two replicas of the same DB on the same node) to ensure high availability.

Summary Comparison

Feature	Applied To	Goal
Taints	Nodes	Keep Pods away.
Tolerations	Pods	Allow Pods to stay on tainted nodes.
Node Affinity	Pods	Pull Pods toward specific nodes.
Pod Anti-Affinity	Pods	Keep Pods away from other Pods.

Kubernetes Storage

Kubernetes uses a set of abstractions to manage persistent storage, allowing developers to request storage without knowing the details of the underlying infrastructure (e.g., AWS EBS, GCP PD, or local disks).

1. PersistentVolume (PV)

• Definition: A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a StorageClass.
• Scope: It is a cluster-level resource (like a Node) and is not tied to a specific namespace.
• Lifecycle: It has a lifecycle independent of any individual Pod that uses it.

2. PersistentVolumeClaim (PVC)

• Definition: A request for storage by a user.
• Scope: It is a namespace-level resource.
• Function: Just as a Pod consumes Node resources (CPU/Memory), a PVC consumes PV resources (Size/Access Modes).
• Binding: Kubernetes looks for a PV that matches the PVC’s requirements and “binds” them together.

3. StorageClass

• Definition: A way for administrators to describe the “classes” of storage they offer (e.g., “fast-ssd”, “slow-hdd”).
• Dynamic Provisioning: Allows PVs to be created on-demand when a PVC is created, rather than having an admin manually create PVs in advance.

4. Access Modes

• ReadWriteOnce (RWO): Mounted as read-write by a single node.
• ReadOnlyMany (ROX): Mounted as read-only by many nodes.
• ReadWriteMany (RWX): Mounted as read-write by many nodes (requires network storage like NFS).

Kubernetes Workload Types

Kubernetes provides several built-in workload resources to manage Pods. Each is designed for a specific type of application behavior.

1. Deployment (The Most Common)

Used for stateless applications (like web servers).

• Manages a set of identical Pods (ReplicaSet).
• Supports declarative updates (rolling updates) and rollbacks.
• Pods are interchangeable and have random names (e.g., web-789abc-xyz).

2. StatefulSet

Used for stateful applications (like databases or distributed systems).

• Provides a stable, unique network identifier (e.g., db-0, db-1).
• Provides stable, persistent storage linked to each specific Pod.
• Maintains a strict ordering for deployment, scaling, and termination.

3. DaemonSet

Ensures that all (or some) Nodes run a copy of a Pod.

• Useful for infrastructure-related tasks like log collection (Fluentd), node monitoring (Prometheus Node Exporter), or storage drivers.
• Automatically adds Pods to new nodes and removes them from deleted nodes.

4. Job & CronJob

• Job: Creates one or more Pods and ensures that a specified number of them successfully terminate. Useful for one-off tasks like database migrations.
• CronJob: Runs Jobs on a time-based schedule (like a Linux crontab).