Top Kubernetes Objects with examples

Kubernetes objects represent the desired state and configuration of your workloads and resources in a cluster. Here are the top objects, common uses, brief examples, comparisons, and frequently asked questions for each, to help you prepare for principle engineer interview rounds.

1. Pod

Description: A Pod is the smallest deployable unit in Kubernetes, typically running one or more containers as a tightly coupled group.

Common Uses:

• Running single-container or closely related multi-container applications.

• Foundation for higher-level controllers (e.g., Deployments, StatefulSets).

Example YAML:

apiVersion: v1
kind: Pod
metadata:
  name: simple-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest

Comparison:

• Pod vs. Deployment: Pods are ephemeral; once lost, they aren't recreated unless managed by a controller like a Deployment

• Pod vs. Container: A Pod can have one or more containers, whereas a container is just an application package

Top FAQ:

• Q: How are Pods recreated if a node fails?

  • A: Pods aren't recreated automatically; controllers like Deployments handle this.

• Q: Can a Pod run across multiple nodes?

  • A: No, all containers in a Pod run on the same node

2. Deployment

Description: Manages stateless application Pods, handles scaling, self-healing, and rolling updates

Common Uses:

• Running and updating web servers, APIs, and stateless apps.

• Enabling zero-downtime deployments via rolling updates.

Example YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.16

Comparison:

	Deployment	StatefulSet
Use Case	Stateless apps	Stateful apps (databases)
Replicas	Interchangeable (no identity)	Each has unique identity
Pod Names	Random	Stable, ordinal

Top FAQ:

• Q: What's the main benefit of Deployments over Pods?

  • A: Deployments provide self-healing, scaling, and declarative updates.

• Q: How to rollback a Deployment?

  • A: Use kubectl rollout undo deployment/<name> to revert to the previous version.

3. Service

Description: Exposes running Pods as a stable network endpoint and handles load balancing

Common Uses:

• Internal/external app discovery.

• Load balancing across replicated Pods.

Example YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Comparison:

	ClusterIP	NodePort	LoadBalancer
Scope	Internal only	Exposes on node	External IP
Usage	App-to-app	Dev/test access	Cloud/Public apps

Top FAQ:

• Q: How does a Service maintain connectivity if Pods restart?

  • A: The Service routes traffic to replacement Pods matching its selector automatically.

• Q: Can I expose a Service outside the cluster?

  • A: Yes, use NodePort or LoadBalancer types.

4. ConfigMap & Secret

Description: Provide configuration and sensitive data (like passwords) to your workloads

Common Uses:

• Injecting environment variables, configuration files, or credentials into Pods.

Example YAML (ConfigMap):

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  app.properties: |
    KEY=value

Comparison:

	ConfigMap	Secret
Data type	Plain config	Sensitive data
Encoding	Base64 not required	Must use Base64

Top FAQ:

• Q: How do you mount a Secret in a Pod?

  • A: Reference it directly in the spec under envFrom or as a mounted volume.

5. StatefulSet

Description: Manages stateful applications, provides stable network identities and persistent storage for each Pod.

Common Uses:

• Databases, distributed systems needing stable disk or identity.

Example YAML:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:5.6

Comparison:

• StatefulSet vs. Deployment: StatefulSets maintain unique, stable identities for each Pod; Deployments do not

Top FAQ:

• Q: When to choose StatefulSet over Deployment?

  • A: For workloads needing stable storage or identity, like databases.

6. DaemonSet

Description: Ensures a specific Pod runs on every (or selected) node, typically for cluster-wide services (monitoring, logging agents).

Example YAML:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      containers:
      - name: exporter
        image: prom/node-exporter

Comparison:

• DaemonSet vs. Deployment: DaemonSet schedules Pods on all nodes; Deployment schedules on any available node

Top FAQ:

• Q: Can a DaemonSet Pod be evicted from a node?

  • A: Yes, but the DaemonSet will reschedule it as needed.

7. Ingress

Description: Manages external HTTP/S access to services in a cluster, typically via path or host-based routing.

Common Uses:

• Providing a single entry point for web apps.

• SSL termination, routing policies.

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.domain.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: my-service
            port:
              number: 80

Comparison:

• Ingress vs. Service: Ingress offers L7 (HTTP/S) routing, much more flexible than Service load balancing1.

Top FAQ:

• Q: Do I need an Ingress Controller to use Ingress objects?

  • A: Yes, Kubernetes Ingress needs a controller for enforcement.

8. Job & CronJob

Description:

• Job: Runs tasks to completion (e.g., batch data processing).

• CronJob: Runs Jobs on a scheduled/recurring basis.

Example YAML (CronJob):

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from Kubernetes!
          restartPolicy: OnFailure

Comparison:

	Job	CronJob
Runs	Once, till completion	At intervals
Purpose	Ad-hoc batch tasks	Scheduled tasks

Top FAQ:

• Q: Can a Job be restarted if it fails?

  • A: Yes, depending on its restartPolicy and backoff settings.

Summary Table: Top Kubernetes Objects

Object	Main Use	Example App	Special Feature
Pod	Single/multi-container workload	Single Nginx instance	Smallest deployable unit
Deployment	Stateless apps, rollout/rollback	Scalable web server	Manages ReplicaSets, updates
StatefulSet	Stateful apps needing identity/storage	MySQL, Kafka	Stable identity/persistent storage
DaemonSet	Cluster-wide services on all/some nodes	node-exporter, log shipper	Runs one Pod per node
Service	Load balancing, service discovery	Exposing web apps	Stable, virtual IP
Ingress	External HTTP/S routing	Central web entry point	Path, host, TLS routing
Job	Batch, one-off tasks	Data transformation	Runs to completion
CronJob	Scheduled repetitive tasks	Daily backup job	Time-based, recurring jobs
ConfigMap	Configuration injection	App config files	Injects data as ENV/volumes
Secret	Securely store credentials	API keys, passwords	Base64, access controls

Further FAQs (General)

• Q: How are Kubernetes objects managed?

  • A: Via the Kubernetes API, often using kubectl or declarative YAML files. The system ensures the actual state matches your desired state

• Q: What happens if you manually delete a Pod managed by a Deployment?

  • A: The Deployment automatically recreates the missing Pod.

• Q: How do you secure sensitive app data in Kubernetes?

  • A: Store in a Secret, and mount or inject it into your Pods.

• Q: What is the difference between an object and a resource?

  • A: An object is an instance of a resource type; resources define kinds (like Pod, Service)