Skip to main content
Mapagam

Understanding Kubernetes Architecture

1. Understanding Control Plane Components

Component Description Key Responsibilities Notes
API Server (kube-apiserver) Exposes the Kubernetes API
  • Validates and configures API objects
  • Manages etcd interactions
 Frontend for the control plane; all communication goes through it
etcd Consistent and highly-available key-value store
  • Stores cluster state and configuration
 Essential for maintaining cluster consistency; must be backed up regularly
Scheduler (kube-scheduler) Assigns workloads to nodes
  • Chooses the best node for new pods based on resource needs
  • Considers constraints and policies
 Uses predicates and priorities to make scheduling decisions
Controller Manager (kube-controller-manager) Runs controller processes
  • Manages node and replication controllers
  • Ensures desired state matches actual state
 Runs various controllers like node controller, replication controller
Cloud Controller Manager (cloud-controller-manager) Runs cloud provider-specific controllers
  • Manages cloud resources (e.g., load balancers, routes)
  • Integrates with cloud provider APIs
 Available only when running on a supported cloud platform

Example: API Server Configuration

# Example kube-apiserver configuration
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.0.0.1
    - --allow-privileged=true
    - --authorization-mode=RBAC
    image: k8s.gcr.io/kube-apiserver:v1.29.0
    name: kube-apiserver

2. Understanding Node Components

Component Description Role Notes
kubelet Agent that ensures containers are running in pods Primary node agent Communicates with the control plane to manage pods and containers
kube-proxy Network proxy that maintains network rules on nodes Networking agent Enables service discovery and load balancing for pods
Container Runtime Software responsible for running containers (e.g., Docker, containerd) Container execution engine Must be installed and configured on all nodes

Example: kubelet configuration

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
port: 10250
readOnlyPort: 10255
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
Note: kubelet is responsible for communicating with the API server and ensuring that pods are running as expected.

3. Understanding Pods as Deployment Units

Property Description Example
metadata.name Name of the Pod my-pod
spec.containers List of containers in the Pod 
[
  {
    "name": "nginx",
    "image": "nginx:1.21"
  }
]
spec.restartPolicy Restart policy for the Pod Always

Example: Basic Pod Definition

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
Note: A Pod is the smallest deployable unit in Kubernetes and can contain one or more containers that share storage and network.

4. Understanding Services and Networking

Service Type Description Use Case External Access
ClusterIP Exposes the service on an internal IP within the cluster Internal communication between pods No
NodePort Exposes the service on a static port on each node's IP Testing or simple access from outside the cluster Yes, via node IP and port
LoadBalancer Exposes the service externally using a cloud provider's load balancer Production environments with external traffic Yes, via external IP
ExternalName Maps the service to an external DNS name Integrating with external services Yes, via DNS name

Example: Exposing a Service with NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080
  selector:
    app: my-app

Example: Creating a LoadBalancer Service

apiVersion: vv1
kind: Service
metadata:
  name: external-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: web
Note: NodePort services are accessible on <NodeIP>:<NodePort> and are useful for development or testing.
Warning: LoadBalancer services require a cloud provider or external load balancer to function properly.

Networking Concepts in Kubernetes

  • Pods are the smallest deployable units in Kubernetes.
  • Services provide stable network access to pods.
  • Ingress manages external access to services within the cluster.
  • Network Policies control pod-to-pod communication.

5. Understanding Workload Resources

Resource Type Description Use Case Key Properties
Deployment Manages replicated pods and provides declarative updates Running stateless applications with desired replicas replicas, selector, template
StatefulSet Manages pods with stable network identifiers and persistent storage Applications requiring stable identities and storage (e.g., databases) replicas, serviceName, volumeClaimTemplates
DaemonSet Ensures a pod runs on each node in the cluster System-level services like logging agents or monitoring agents template, updateStrategy
Job Runs a pod until completion, then terminates One-time tasks or batch jobs (e.g., data processing) completions, parallelism, template
CronJob Runs jobs based on a schedule Scheduled tasks like backups or log rotation schedule, jobTemplate, concurrencyPolicy

Example: Deployment Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Example: StatefulSet Configuration

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
Note: Workload resources abstract the complexity of managing pods directly, offering higher-level constructs for scaling, updating, and managing application lifecycles.

6. Understanding Storage Abstractions

Storage Type Description Use Case Notes
PersistentVolume (PV) Cluster-level storage abstraction managed by admins Shared storage across pods, long-term data persistence Static or dynamically provisioned; managed by Kubernetes
PersistentVolumeClaim (PVC) Request for storage by a pod or workload Dynamic allocation of PVs based on requirements Bound to a PV once resources are available
StorageClass Dynamic provisioning of PVs based on storage type Automatically create PVs when PVCs are created Uses provisioners like AWS EBS, GCP PD, or local storage
EmptyDir Temporary storage mounted to pod Short-lived data, cache, or scratch space Deleted when pod is removed; no persistence
HostPath Mounts a file or directory from the host node’s filesystem Testing, debugging, or accessing host-level files Not recommended for production due to portability issues
ConfigMap Key-value pairs for configuration data Passing config to pods without rebuilding images Can be mounted as volumes or injected into env vars
Secret Secure storage for sensitive data (e.g., passwords, tokens) Storing credentials or keys securely Base64 encoded; not encrypted at rest by default

Example: Using PersistentVolume and PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Example: Using StorageClass for Dynamic Provisioning

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi
Note: StorageClass allows for dynamic provisioning of volumes using external storage providers like AWS EBS, GCP PD, or Azure Disk.

7. Understanding Configuration Resources

Note: Configuration resources in Kubernetes are used to manage application settings and external dependencies without baking them into container images.
Resource Type Description Use Case Example
ConfigMap Stores non-confidential configuration data in key-value pairs Application configuration, environment variables 
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.url: "jdbc:postgresql://db:5432/myapp"
  log.level: "INFO"
Secret Stores sensitive data like passwords, tokens, or keys in base64-encoded format Secure credentials, TLS certificates 
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=
PersistentVolume (PV) Represents a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using StorageClasses Shared storage for stateful applications 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  nfs:
    server: nfs-server.default.svc.cluster.local
    path: "/data"
PersistentVolumeClaim (PVC) Represents a request for storage by a user Requesting storage for pods 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-db
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Example: Using ConfigMap in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: app-container
    image: myapp:latest
    envFrom:
      - configMapRef:
          name: app-config

Example: Using Secret in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: secure-container
    image: myapp:latest
    envFrom:
      - secretRef:
          name: db-secret

Key Concepts

  • ConfigMaps store non-sensitive configuration data and can be mounted as volumes or injected as environment variables.
  • Secrets are used for sensitive data and are base64-encoded when stored.
  • PersistentVolumes provide a way to define storage that is independent of the lifecycle of pods.
  • PersistentVolumeClaims allow pods to request storage resources from the cluster.

8. Understanding Namespaces and Multi-Tenancy

Feature Description Use Case
Namespace A namespace is a virtual cluster within a Kubernetes cluster, isolating resources. Multi-tenancy, team isolation, environment separation (dev/staging/prod).
Default Namespaces Each cluster has default namespaces: default, kube-system, kube-public. System resources, public access, and default resource placement.
Resource Quotas Limit resource consumption (CPU, memory) per namespace. Prevent one tenant from consuming all cluster resources.
Limit Ranges Enforce resource limits per container or pod in a namespace. Ensure consistent resource allocation across teams.

Example: Creating a Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: production

Example: Deploying to a Namespace

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
Note: Namespaces are not a security boundary. They provide logical separation but do not isolate pods or services from each other.

Key Benefits of Namespaces

  • Isolation: Teams or environments can work independently.
  • Resource Control: Resource quotas and limit ranges prevent overconsumption.
  • Scalability: Easier to manage large clusters with many teams.

Namespaces vs. Clusters

  • Namespace: Logical partition within a cluster.
  • Cluster: A full Kubernetes installation with its own control plane and nodes.

9. Understanding API Resources and Extensions

Resource Type Description Examples Notes
Pod Basic unit of deployment in Kubernetes 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.21
 Represents one or more containers running on a node
Service Abstracts network access to pods 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
 Provides stable network endpoint for pods
Deployment Manages stateless applications 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
 Handles rolling updates and rollbacks
Ingress Manages external access to services 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80
 Enables HTTP/HTTPS routing to services
ConfigMap Stores configuration data 
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.json: |
    {
      "port": "8080"
    }
 Allows decoupling of configuration from image
Secret Stores sensitive information 
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=
 Stores sensitive data like passwords or tokens

Example: Creating a Custom Resource Definition (CRD)

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              cronSpec:
                type: string
                pattern: "^(\*|[0-9])"
              replicas:
                type: integer
                minimum: 1
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
Note: CRDs allow extending Kubernetes API with custom resources.

API Resource Categories

  • Core Resources: Basic building blocks like Pod, Service, Deployment
  • Extended Resources: Additional functionality like Ingress, ConfigMap, Secret
  • Custom Resources: User-defined resources via CRDs

10. Understanding Cluster Add-Ons

Add-On Description Functionality Status
DNS CoreDNS Service discovery within the cluster NEW
Dashboard Kubernetes Dashboard Web UI for managing cluster resources DEPRECATED
Ingress Controller NGINX Ingress Controller Exposes HTTP/HTTPS routes from outside the cluster NEW
Metrics Server Metrics Server Collects and exposes cluster metrics NEW
CNI Plugins Calico, Flannel, Weave Container Network Interface for pod networking NEW

Example: Deploying CoreDNS Add-On

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: kube-dns
  template:
    metadata:
      labels:
        k8s-app: kube-dns
    spec:
      containers:
      - name: coredns
        image: k8s.gcr.io/coredns/coredns:v1.9.3
        ports:
        - containerPort: 53
          name: dns
          protocol: UDP
Note: Add-ons are typically deployed in the kube-system namespace.

Add-Ons Overview

  • CoreDNS provides DNS resolution for services.
  • Ingress Controllers manage external access to cluster services.
  • Metrics Server collects resource usage data for autoscaling.

Was this article helpful?

Related Cheat Sheets