Intermediate–Advanced 15 terms

Kubernetes Operations

Core Kubernetes resources and operational concepts: pods, deployments, services, ingress, autoscaling, and probes.

  • pod /pɒd/

    Smallest deployable unit in Kubernetes; one or more containers sharing the same network namespace and storage volumes.

    "Each pod gets its own IP address — the sidecar container in the pod can reach the main app container on localhost."
  • deployment /dɪˈplɔɪmənt/

    Workload resource that manages a set of identical replica pods; handles rolling updates and rollbacks declaratively.

    "We updated the image tag in the Deployment manifest and kubectl apply'd it — Kubernetes rolled out the new version one pod at a time with no downtime."
  • service /ˈsɜːvɪs/

    Stable network endpoint that load-balances traffic across pods matching a label selector; provides a fixed DNS name regardless of pod IP changes.

    "The Service named api-svc always routes to healthy backend pods — even as pods are replaced during a rolling update, the DNS name stays constant."
  • ingress /ˈɪŋɡres/

    Kubernetes resource that routes external HTTP/S traffic to services based on hostname and path rules; requires an Ingress controller such as nginx or Traefik.

    "We added an Ingress rule to route /api/* to the backend service and /* to the frontend service, both under the same domain."
  • namespace /ˈneɪmspeɪs/

    Virtual cluster within a Kubernetes cluster for isolating resources between teams or environments; RBAC and resource quotas can be scoped per namespace.

    "We deploy staging and production in separate namespaces on the same cluster, with resource quotas preventing either from starving the other."
  • ConfigMap /ˈkɒnfɪɡmæp/

    API object that stores non-sensitive configuration data as key-value pairs; mounted into pods as environment variables or files.

    "The app reads its database URL from a ConfigMap volume mount — changing the config no longer requires rebuilding the Docker image."
  • Secret /ˈsiːkrɪt/

    API object that stores sensitive data such as passwords and tokens; base64-encoded by default and can be encrypted at rest with KMS.

    "The database password is stored in a Kubernetes Secret and injected as an environment variable — it never appears in the container image or ConfigMap."
  • PersistentVolumeClaim /pəˈsɪstənt ˈvɒljuːm kleɪm/

    A request for storage by a pod; abstracts the underlying storage implementation (EBS, NFS, local disk) from the application.

    "The database pod uses a PersistentVolumeClaim so data survives pod restarts and rescheduling to a different node."
  • StatefulSet /ˈsteɪtfʊl set/

    Workload resource for stateful applications; provides stable network identity, ordered pod management, and persistent storage per pod.

    "We deploy Kafka with a StatefulSet so each broker gets a stable hostname like kafka-0, kafka-1 and retains its own PersistentVolumeClaim."
  • DaemonSet /ˈdeɪmən set/

    Ensures exactly one copy of a pod runs on every node (or a subset); used for log collectors, monitoring agents, and network plugins.

    "The log-shipping DaemonSet ensures Fluent Bit runs on every node and ships container logs to our centralized logging platform."
  • HPA /eɪtʃ piː eɪ/

    Horizontal Pod Autoscaler; automatically scales the number of pod replicas based on CPU utilisation, memory, or custom metrics.

    "The HPA scaled the API deployment from 3 to 12 replicas during the Black Friday traffic spike, then scaled back down overnight."
  • resource request /rɪˈzɔːs rɪˈkwest/

    Minimum CPU and memory guaranteed to a container by the scheduler; used to decide which node a pod is placed on.

    "Setting a CPU request of 250m ensures our pod is only scheduled on nodes with at least that capacity available."
  • resource limit /rɪˈzɔːs ˈlɪmɪt/

    Maximum CPU and memory a container is allowed to use; a container exceeding its memory limit is OOMKilled by the kernel.

    "We set a memory limit of 512Mi — when a memory leak caused the app to exceed it, Kubernetes restarted the container automatically."
  • liveness probe /ˈlaɪvnɪs prəʊb/

    Periodic check that restarts a container if it fails; indicates whether the application is alive and not deadlocked.

    "The liveness probe hits /healthz every 10 seconds — when the app deadlocked and stopped responding, Kubernetes restarted the container within 30 seconds."
  • readiness probe /ˈredɪnɪs prəʊb/

    Periodic check that removes a pod from the Service's endpoint list if it fails; indicates whether the app is ready to accept traffic.

    "The readiness probe prevents traffic from reaching a pod during startup warming — the pod only joins the load balancer pool once the probe passes."

Ready to practice?

Test your knowledge of these terms in the interactive exercise.

Start exercise →