An SRE explains Kubernetes workload types during an onboarding session: "A Pod is the atomic unit — one or more containers sharing network and storage. You rarely create Pods directly. Deployments manage stateless apps — they ensure N replicas are running and handle rolling updates. StatefulSets are for stateful apps: databases, Kafka. They give stable network identities and ordered deployment. DaemonSets run exactly one Pod per node — good for log collectors and monitoring agents. Jobs run to completion once; CronJobs run on a schedule." When would you use a StatefulSet instead of a Deployment?
Deployment: stateless apps. Pods are interchangeable — any pod can serve any request. Rolling updates replace pods in batches. Pods can be rescheduled to different nodes without concern. StatefulSet: stateful apps. Guarantees: stable, unique network identity (pod-0, pod-1, pod-2 — names are deterministic), stable persistent storage (each pod gets its own PVC), ordered deployment (pod-0 must be Running before pod-1 starts), ordered termination (pod-N-1 terminates before pod-N). Use cases: PostgreSQL, MySQL, MongoDB, Kafka, ZooKeeper, Cassandra, Elasticsearch. Headless Service: StatefulSets typically use a headless Service (ClusterIP: None) to allow DNS resolution of individual pod names (pod-0.service.namespace.svc.cluster.local). Kubernetes resource vocabulary: Pod: smallest deployable unit. Contains 1+ containers sharing localhost network. ReplicaSet: ensures N replicas run. Managed by Deployment. namespace: virtual cluster within a cluster. Isolates resources. node: physical/VM worker machine. cluster: set of nodes + control plane. control plane: kube-apiserver, etcd, kube-scheduler, kube-controller-manager. In conversation: 'If your developers ask for Kafka on Kubernetes, reach for a StatefulSet — or better, the Strimzi Operator, which manages the StatefulSet complexity for you.'
2 / 5
A platform engineer explains Kubernetes networking to a backend developer: "Services give stable endpoints to a set of pods. ClusterIP is the default — internal cluster access only. NodePort exposes the service on a port on every node's IP — useful for development but not production. LoadBalancer provisions an external load balancer — good for prod but expensive at scale. Ingress is the better option at scale: one load balancer for many services, with HTTP routing rules. The Ingress controller (like nginx-ingress or Traefik) watches for Ingress resources and configures itself." What is the difference between a Kubernetes Service and an Ingress?
Service: provides a stable IP address and DNS name for a set of pods (selected by label selectors). Service types: ClusterIP: internal cluster IP only. Default. NodePort: exposes on each node's IP at a static port (30000-32767). Reachable from outside but clunky for production. LoadBalancer: provisions cloud load balancer (ELB, GCE LB). One LB per Service — expensive at scale. ExternalName: maps service to an external DNS name. Ingress: L7 HTTP routing resource. Rules: route traffic by hostname (api.example.com) or path (/api, /web) to different Services. Ingress controller: a pod running in the cluster that watches Ingress objects and configures itself (nginx, Traefik, HAProxy, AWS ALB controller). One external LB routes to many Services → cost-efficient. TLS termination: Ingress handles SSL certificates (cert-manager for Let's Encrypt automation). kubectl commands: kubectl get pods -n namespace — list pods in a namespace. kubectl describe pod NAME — events, resource usage, conditions. kubectl logs pod NAME -c container — container logs. kubectl exec -it pod NAME -- bash — interactive shell. kubectl port-forward pod NAME 8080:8080 — local access to pod port. In conversation: 'We consolidated 30 LoadBalancer Services into one Ingress controller. Monthly cloud bill for LBs dropped by $2K.'
3 / 5
An engineer explains RBAC to a developer who just got a 403 on kubectl: "RBAC — Role-Based Access Control — controls who can do what in the cluster. A Role defines permissions within a namespace; a ClusterRole applies cluster-wide. A RoleBinding grants a Role to a user, group, or ServiceAccount within a namespace. A ServiceAccount is the identity pods use to authenticate to the Kubernetes API. Your deployment's pod is using the default ServiceAccount, which has no permissions. You need to create a ServiceAccount with a Role and RoleBinding." What is a ServiceAccount in Kubernetes and why is it important for security?
ServiceAccount: a namespaced Kubernetes resource representing the identity of a pod. Every pod runs with a ServiceAccount (default is 'default' with minimal permissions). Token is mounted as a file in the pod: /var/run/secrets/kubernetes.io/serviceaccount/token. Used to authenticate API calls from pods (e.g., an app that reads ConfigMaps, a controller that creates Deployments). Security best practice: create a dedicated ServiceAccount per workload; bind only the Roles it needs (least privilege). RBAC vocabulary: Role: namespaced; defines verbs (get, list, watch, create, update, patch, delete) on resources (pods, configmaps, secrets). ClusterRole: cluster-scoped; also used for non-namespaced resources (nodes, PVs). RoleBinding: grants a Role to a subject (user, group, ServiceAccount) within a namespace. ClusterRoleBinding: cluster-wide binding. Subject: user, group, or ServiceAccount being granted a role. Principle of least privilege: grant only the permissions needed. Secret vocabulary: Secret: base64-encoded sensitive data (not encrypted by default — enable encryption at rest). Types: Opaque, kubernetes.io/tls, kubernetes.io/dockerconfigjson. ConfigMap: non-sensitive configuration as key-value pairs or files. In conversation: 'The first cluster security audit identified 50 services running as default ServiceAccount with overbroad permissions. We spent a sprint creating dedicated ServiceAccounts and were shocked how many apps were reading secrets they had no business touching.'
4 / 5
A DevOps lead explains Helm at a platform team meeting: "Helm is Kubernetes' package manager. A chart is a collection of templated Kubernetes manifests. You configure a chart with a values.yaml file — overriding defaults without modifying the templates. Installing a chart creates a release — a named, versioned instance in your cluster. Helm upgrades can be rolled back. The chart repository (like Artifact Hub) is where you find community charts for Nginx, PostgreSQL, Prometheus, etc. We use Helm for third-party software; for our own apps we use Kustomize." What is a Helm chart and what problem does it solve compared to raw Kubernetes manifests?
Helm chart structure: Chart.yaml (metadata: name, version, description), templates/ (Kubernetes YAML with Go templating: {{ .Values.replicaCount }}), values.yaml (default configuration), charts/ (sub-chart dependencies). What it solves: raw manifests are static YAML. For 10 environments (dev/staging/prod-eu/prod-us...) you'd maintain 10 copies. Helm templates parameterise the differences; each environment provides its own values.yaml override. Helm workflow: helm repo add: add a chart repository. helm search repo: find charts. helm install release-name chart-name -f custom-values.yaml: install chart as a named release. helm upgrade release-name chart-name -f new-values.yaml: update. helm rollback release-name 1: roll back to revision 1. helm uninstall release-name: delete all chart resources. helm list: list releases. Helm vs. Kustomize: Helm: templating + packaging + release management. Better for distributing software to others (third-party charts). Kustomize: overlays on top of base YAML. No templates — just patches. Built into kubectl. Better for maintaining your own application across environments. In conversation: 'We use Helm for everything external — Prometheus, Kafka, cert-manager — and Kustomize for our own services. The separation keeps chart updates clean.'
5 / 5
An SRE explains Kubernetes resource management to a developer whose pod keeps being killed: "Your pod is getting OOMKilled — Out of Memory Killed. The kubelet kills pods that exceed their memory limit. You need to set resource requests and limits correctly. Requests are what Kubernetes uses for scheduling — the node must have at least this much available. Limits are the hard cap — exceed them and the pod is throttled (CPU) or killed (memory). The common mistake: setting limits much higher than requests. This works until the node is overcommitted, then everyone gets throttled." What is the difference between resource requests and limits in Kubernetes?
Resource requests: what the pod is guaranteed. The scheduler only places a pod on a node that has enough remaining capacity. Used for bin-packing (fitting many pods onto nodes). If requests = limits, the pod has Guaranteed QoS (Quality of Service). Resource limits: the maximum the pod can use. CPU limit exceeded → pod is throttled (CPU capped; doesn't die). Memory limit exceeded → OOMKilled (container killed; pod may restart). QoS classes: Guaranteed: requests == limits for all containers. Highest priority; last to be evicted. Burstable: at least one container has requests < limits. Evicted when node is under pressure. BestEffort: no requests or limits. Evicted first. Kubernetes vocabulary: OOMKilled: Out Of Memory Killed — memory limit exceeded. CrashLoopBackOff: pod repeatedly crashes and Kubernetes backs off restarts exponentially. Pending: pod can't be scheduled — insufficient resources, PVC not bound, node affinity mismatch. ImagePullBackOff: container image can't be pulled — wrong image name, registry credentials missing. Eviction: kubelet removes a pod to reclaim resources on an overloaded node. LimitRange: namespace-level defaults and maximums for requests/limits. ResourceQuota: limits total resource usage for a namespace. In conversation: 'Golden rule: set requests to what you actually need at steady state, and limits 2-3x higher to handle spikes. Monitor actual usage with Prometheus metrics and adjust quarterly.'