What Are Kubernetes Core Components and How Do They Work?

Kubernetes Core Components

Master node components:

kube-apiserver : the control‑plane entry point that exposes the REST API.

kube-scheduler : decides on which node a Pod should run.

kube-controller-manager : runs various controllers to keep the actual cluster state aligned with the desired state.

etcd : a distributed key‑value store that holds all cluster configuration data.

Node components:

kubelet : manages the lifecycle of Pods on the node.

kube-proxy : implements Service load‑balancing and network proxying.

Container runtime (e.g., Docker, containerd): runs container images.

Pod vs. Deployment

Pod : the smallest deployable unit, a group of containers with a short‑lived lifecycle that may be recreated at any time.

Deployment : manages replica sets of Pods, providing rolling updates, rollbacks and high‑availability guarantees.

Service Types

ClusterIP (default): internal access only, not exposed outside the cluster.

NodePort : exposes the Service on each node’s IP and a static port (useful for testing).

LoadBalancer : provisions an external load balancer from the cloud provider.

ExternalName : maps the Service to an external DNS name.

ConfigMap vs. Secret

ConfigMap : stores non‑sensitive configuration data in plain text (environment variables, config files, etc.).

Secret : stores sensitive data (passwords, tokens, certificates) in an encoded form.

StatefulSet vs. Deployment

StatefulSet : for stateful applications; Pods get stable network IDs and storage, and are created/terminated in order.

Deployment : for stateless workloads; Pods can be scaled arbitrarily without ordering constraints.

Ingress and Common Implementations

Ingress : defines HTTP/HTTPS routing rules from outside the cluster to Services.

Common controllers: NGINX Ingress Controller, Traefik, HAProxy.

Limiting Pod Resource Usage

Define

resources

with

requests

(minimum) and

limits

(maximum) for CPU, memory, etc., to prevent resource contention.

<code>yaml
resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"
</code>

Pod Affinity & Anti‑Affinity

Affinity is expressed via

nodeAffinity

and

podAffinity

/

podAntiAffinity

to influence where Pods are scheduled.

Health Checks

Liveness Probe : checks if a container is alive; failure triggers a restart.

Readiness Probe : checks if a container is ready to receive traffic; failure prevents routing.

Typical DaemonSet Use Cases

Log collection agents (e.g., Fluentd)

Node monitoring agents (e.g., Node Exporter)

Network plugins (e.g., CNI components)

Kubernetes Volume Types

emptyDir : temporary storage tied to the Pod’s lifecycle.

hostPath : mounts a directory from the node (potential security risk).

PersistentVolumeClaim (PVC) : binds to a PersistentVolume for durable storage.

ConfigMap & Secret : mounted as files or environment variables for configuration data.

Pod Eviction Reasons

Node resource pressure (CPU/memory).

Node maintenance (e.g.,

kubectl drain

).

QoS policy violations (exceeding memory limits).

Node becomes NotReady or crashes.

Node Isolation (Prevent Scheduling)

Use

kubectl cordon

to mark a node unschedulable, or apply

taint

with matching

toleration

on Pods.

<code>bash
kubectl taint nodes node01 key=value:NoSchedule
</code>

Scheduling Algorithm Factors

Node resource availability (CPU, memory).

Node and Pod affinity/anti‑affinity.

Taints and tolerations.

Custom scheduler extensions.

Sidecar Pattern Example

A sidecar is an auxiliary container that extends the main container’s functionality. Typical example: the Envoy proxy sidecar in an Istio service mesh.

Secret Security

Secrets are Base64‑encoded and stored in etcd.

Enable etcd encryption in production.

RBAC restricts access to Secrets.

External secret managers (e.g., Vault) provide stronger protection.

Kubernetes QoS Classes

Guaranteed : identical

requests

and

limits

.

Burstable :

requests

<

limits

.

BestEffort : no

requests

or

limits

defined.

Scaling (Autoscaling)

Pod‑level: Horizontal Pod Autoscaler (HPA) based on CPU, memory, or custom metrics.

Node‑level: Cluster Autoscaler adds or removes nodes when resources are insufficient.

PodDisruptionBudget

Defines the minimum number of Pods that must remain available during voluntary disruptions, ensuring high availability during upgrades or maintenance.

kube-proxy Modes

userspace (deprecated): low performance, high overhead.

iptables : moderate performance, widely used.

ipvs (recommended): high performance with advanced load‑balancing.

ResourceQuota

Limits the total amount of resources (CPU, memory, number of Pods, etc.) that can be requested within a namespace, ensuring fair sharing among tenants.

Admission Controllers

Validate or mutate API requests before they are persisted. Common controllers include NamespaceLifecycle, LimitRanger, ResourceQuota, PodSecurityPolicy (deprecated), ValidatingAdmissionWebhook, and MutatingAdmissionWebhook.

Vertical Pod Autoscaler (VPA)

Analyzes historical resource usage of Pods and adjusts their

requests

(CPU/memory) on the next restart to better fit actual needs.

Diagnosing Pods That Won’t Start

Inspect events:

kubectl describe pod <pod-name>

Check container logs:

kubectl logs <pod-name> -c <container-name>

Examine node resources:

kubectl top nodes

Verify node status:

kubectl get nodes

NetworkPolicy for Pod Communication Control

Uses label selectors and Ingress/Egress rules (often with Calico) to allow or deny traffic between Pods.

<code>yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
</code>

Viewing Cluster Resource Usage

Run

kubectl top nodes

for node metrics and

kubectl top pods

for Pod metrics (requires Metrics Server).

PVC vs. PV Relationship

PersistentVolume (PV) : provisioned storage resource provided by the administrator.

PersistentVolumeClaim (PVC) : a user’s request for storage that binds to a suitable PV.

imagePullPolicy Options

Always : always pull the image (default for

latest

tag).

IfNotPresent : pull only if the image is not already present locally.

Never : never pull; the image must exist on the node.

Why Define Readiness and Liveness Probes in Production

Readiness : prevents traffic from being sent to Pods that are not ready.

Liveness : automatically restarts unhealthy Pods, improving reliability.

Pod Restart Policies

Always (default): restart on any container exit.

OnFailure : restart only on non‑zero exit codes.

Never : never restart, regardless of exit status.

Probe Types

Exec : runs a command inside the container.

HTTPGet : performs an HTTP request.

TCPSocket : attempts a TCP connection.

PersistentVolume Lifecycle

Provisioning : static (admin creates PV) or dynamic (PVC triggers creation via StorageClass).

Binding : PVC is bound to a suitable PV, entering the Bound state.

Using : Pods mount the PVC to consume the storage.

Releasing : after PVC deletion, PV becomes Released and awaits admin action.

Reclaiming : policy determines final handling –

Retain

(manual cleanup),

Delete

(automatic deletion), or deprecated

Recycle

.

ResourceQuota vs. LimitRange

ResourceQuota caps the total resources a namespace can request, while LimitRange sets minimum and maximum resource values for individual Pods/containers.

RBAC Authorization

Roles define permissions on resources; RoleBindings assign those permissions to users or ServiceAccounts. ClusterRoles and ClusterRoleBindings apply cluster‑wide.

Ingress Controller Routing & Traffic Management

An Ingress Controller watches Ingress resources and routes external HTTP(S) traffic to Services based on host and path rules. Popular controllers include NGINX, Traefik, HAProxy, and Envoy.

Service Mesh vs. Ingress

Ingress provides entry‑point routing for external traffic only. A Service Mesh extends traffic management to internal service‑to‑service communication, offering load balancing, retries, circuit breaking, observability, and security.

Container Probes Overview

Liveness : determines if a container is alive; failure triggers a restart.

Readiness : indicates if a container is ready to serve traffic; unready Pods are omitted from service endpoints.

Startup : used for slow‑starting containers to delay other probes until the startup probe succeeds.