Core Objects Overview

Core objects are the fundamental building blocks of Kubernetes. They provide the essential functionality needed to run applications—containers (pods), networking (services), configuration (ConfigMaps, Secrets), organization (namespaces), infrastructure (nodes), and storage (PersistentVolumes). Understanding core objects is essential because they’re used in almost every Kubernetes deployment.

Think of core objects like the basic tools in a toolbox. You need a hammer (pods) to drive nails, a screwdriver (services) to connect things, a tape measure (ConfigMaps) to configure sizes, and so on. While you might use specialized tools (workload objects) for specific tasks, you always need the core tools.

Core Objects

Pods

Pods are the smallest deployable units in Kubernetes. They contain one or more containers that share storage and network.

Purpose:

Run containerized applications
Group tightly coupled containers
Provide atomic scheduling unit

Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80

Key Fields:

spec.containers - Container definitions
spec.volumes - Storage volumes
spec.nodeSelector - Node selection
status.phase - Current phase (Pending, Running, Succeeded, Failed)

Services

Services provide stable networking for pods. They abstract away pod IP addresses and provide load balancing.

Purpose:

Expose pods to network
Provide stable IP and DNS name
Load balance traffic across pods
Enable service discovery

Example:

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

Key Fields:

spec.selector - Selects pods by labels
spec.ports - Port mappings
spec.type - Service type (ClusterIP, NodePort, LoadBalancer)
status.loadBalancer - Load balancer status (for LoadBalancer type)

Service Types:

ClusterIP - Internal cluster IP (default)
NodePort - Expose on node ports
LoadBalancer - Cloud load balancer
ExternalName - External service alias

ConfigMaps

ConfigMaps store non-sensitive configuration data that can be consumed by pods.

Purpose:

Store configuration data
Separate configuration from container images
Update configuration without rebuilding images
Share configuration across pods

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgresql://db:5432"
  log_level: "info"
  config.yaml: |
    server:
      port: 8080
      host: 0.0.0.0

Usage in Pods:

spec:
  containers:
  - name: app
    envFrom:
    - configMapRef:
        name: app-config
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

Key Fields:

data - Key-value configuration data
binaryData - Binary configuration data

Secrets

Secrets store sensitive data like passwords, tokens, and keys.

Purpose:

Store sensitive information securely
Separate secrets from container images
Control access to sensitive data
Enable secret rotation

Example:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQ=

Usage in Pods:

spec:
  containers:
  - name: app
    envFrom:
    - secretRef:
        name: db-credentials
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: db-credentials

Key Fields:

data - Base64-encoded sensitive data
stringData - Plain text (automatically encoded)
type - Secret type (Opaque, kubernetes.io/tls, etc.)

Note: Secrets are not encrypted at rest by default. Enable encryption at rest for production.

Namespaces

Namespaces provide logical separation of resources within a cluster.

Purpose:

Organize resources
Isolate resources between teams/projects
Apply resource quotas
Control access with RBAC

Example:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: production

Default Namespaces:

default - Default namespace for resources
kube-system - Kubernetes system components
kube-public - Publicly readable resources
kube-node-lease - Node heartbeat information

Key Concepts:

Most resources are namespaced
Resource names must be unique within namespace
Same name can be used in different namespaces
Cluster-scoped resources (Nodes, PVs) are not namespaced

Nodes

Nodes represent worker machines in the cluster.

Purpose:

Represent cluster infrastructure
Report node capacity and status
Enable node selection and scheduling
Track node conditions and resources

Example:

# Nodes are typically created automatically
# You can label and annotate them:
kubectl label nodes node-1 disktype=ssd

Key Fields:

status.capacity - Node resource capacity
status.allocatable - Allocatable resources
status.conditions - Node health conditions
spec.taints - Node taints for scheduling

Node Conditions:

Ready - Node is healthy
MemoryPressure - Low memory
DiskPressure - Low disk space
PIDPressure - Too many processes

PersistentVolumes (PVs)

PersistentVolumes represent cluster-level storage that can be mounted into pods.

Purpose:

Provide persistent storage
Abstract storage implementation
Enable storage lifecycle management
Support different storage backends

Example:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-volume
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  hostPath:
    path: /data

Key Fields:

spec.capacity - Storage capacity
spec.accessModes - Access modes (RWO, ROX, RWX)
spec.persistentVolumeReclaimPolicy - What happens when released
spec.storageClassName - Storage class name

Access Modes:

ReadWriteOnce (RWO) - Single node read-write
ReadOnlyMany (ROX) - Multiple nodes read-only
ReadWriteMany (RWX) - Multiple nodes read-write

Reclaim Policies:

Retain - Manual cleanup
Recycle - Basic scrub (deprecated)
Delete - Delete storage

PersistentVolumeClaims (PVCs)

PersistentVolumeClaims request storage from PersistentVolumes.

Purpose:

Request storage for pods
Abstract storage details
Enable dynamic provisioning
Bind to available PersistentVolumes

Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast

Usage in Pods:

spec:
  containers:
  - name: app
    volumeMounts:
    - name: storage
      mountPath: /data
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: pvc-claim

Key Fields:

spec.accessModes - Required access modes
spec.resources.requests.storage - Storage size
spec.storageClassName - Storage class (for dynamic provisioning)

Object Relationships

graph TB Namespace --> Pod Namespace --> Service Namespace --> ConfigMap Namespace --> Secret Namespace --> PVC Pod --> ConfigMap Pod --> Secret Pod --> PVC Service --> Pod PVC --> PV Node --> Pod style Namespace fill:#e1f5ff style Pod fill:#fff4e1 style Service fill:#e8f5e9 style ConfigMap fill:#f3e5f5 style Secret fill:#f3e5f5 style PVC fill:#fff4e1 style PV fill:#fff4e1 style Node fill:#e1f5ff

Common Patterns

Pod with ConfigMap and Secret

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: my-app:1.0
    env:
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: database_host
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

Service Exposing Pods

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

Pod with Persistent Storage

apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
  - name: app
    image: my-app:1.0
    volumeMounts:
    - name: data
      mountPath: /var/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: my-pvc

Key Takeaways

Pods run containers and are the fundamental execution unit
Services provide stable networking and load balancing
ConfigMaps store non-sensitive configuration
Secrets store sensitive data (enable encryption at rest)
Namespaces organize and isolate resources
Nodes represent cluster infrastructure
PersistentVolumes provide cluster-level storage
PersistentVolumeClaims request storage for pods
Core objects work together to run applications

Core Objects Overview

Core Objects

Pods

Services

ConfigMaps

Secrets

Namespaces

Nodes

PersistentVolumes (PVs)

PersistentVolumeClaims (PVCs)

Object Relationships

Common Patterns

Pod with ConfigMap and Secret

Service Exposing Pods

Pod with Persistent Storage

Key Takeaways

See Also