Kubernetes

A DaemonSet keeps one pod on every node matching its scope. It has no replica count: a new node automatically gets a pod, a deleted node loses its pod. Use it for per-node agents such as log shippers, metrics collectors, CNI and CSI plugins.

A Deployment manages ReplicaSets; a ReplicaSet manages Pods. Changing the pod template creates a new ReplicaSet, which is scaled up while the old one is scaled down. Old ReplicaSets stay at zero replicas so you can roll back.

Use kubectl rollout status to watch, rollout pause/resume to hold it, rollout history to list revisions and rollout undo (optionally --to-revision) to go back. How far back you can go is bounded by revisionHistoryLimit, default 10.

Init containers run to completion one at a time, in list order, before any app container starts. A non-zero exit means the kubelet retries that init container, or fails the Pod if restartPolicy is Never. Later containers never start.

A Job runs Pods until a set number of them terminate successfully, then stops. A Deployment keeps a set of Pods running forever, restarting them whenever they exit. A Job's Pod template must use restartPolicy Never or OnFailure — Always is rejected.

Labels are short identifying key/value pairs that selectors match, so Services, Deployments and kubectl -l find objects by them. Annotations carry non-identifying data of any shape, capped at 256 KiB in total, that tools read by key but nothing can select on.

kubectl create only makes new objects and fails if the name exists. kubectl replace overwrites an existing object with the whole file. kubectl apply creates or updates by merging the file into the live object and leaves fields it never set alone.

Kubernetes labels are key/value pairs on an object's metadata. A label selector lists requirements, all of which must match: equality (=, !=) or set-based (in, notin, exists). Services, ReplicaSets and kubectl use selectors to find objects.

kubectl delete deployment removes the Deployment, then the garbage collector deletes its ReplicaSets and their Pods, which point at their owners through ownerReferences. With --cascade=orphan, those references are removed instead, and the ReplicaSets and Pods keep running.

Client-side kubectl apply runs a three-way merge. Fields in your file are set on the live object, fields in the last-applied record but gone from the file are deleted, and fields in neither are left alone.

Every pod gets its own IP. Any pod can reach any other pod's IP directly, on any node, with no NAT. Containers inside one pod share a single network namespace, so they talk over localhost and share one port space.

CoreDNS runs in the cluster and its Service address is written into every pod's /etc/resolv.conf. A Service resolves as <service>.<namespace>.svc.cluster.local to its ClusterIP. Inside the same namespace the bare name works; across namespaces use <service>.<namespace>.

An Ingress is just declarative configuration: hostname and path rules mapping to Services, plus TLS. Kubernetes ships no code that acts on it. An ingress controller must be installed; it watches Ingress objects and programs a real proxy or load balancer to match.

A ClusterIP is a virtual IP with no machine behind it. kube-proxy runs on every node and programs kernel rules that rewrite the destination of packets aimed at that IP to one of the Service's backing pod IPs (DNAT). A backend is chosen once per new connection; connection tracking rewrites the replies back.

A type=LoadBalancer Service only records a request. The cloud-controller-manager's service controller, or another load-balancer implementation such as MetalLB, must create the balancer and write its address into status. <pending> means nothing has done that yet.

Three ways: envFrom to import all keys as env vars, valueFrom.configMapKeyRef to map one key to one env var, or a volume where each key becomes a file. Env values freeze at container start; mounted files are refreshed while the Pod runs.

Use the downward API: in the Pod spec, set env[].valueFrom.fieldRef with fieldPath metadata.name, metadata.namespace, spec.nodeName or status.podIP. The kubelet fills the values in when it creates the container — no API credentials or network call needed.

Base64 is encoding, not encryption — anyone can decode it. A Secret's value is stored as-is in etcd, plaintext by default, and readable by anyone with API read access to it. Real protection comes from RBAC, encryption at rest, and limiting who and what can read it.

Files from a configMap volume are refreshed by the kubelet, typically within about a minute. Environment variables never update, and a volume mounted with subPath never updates. Even a refreshed file only helps if the application re-reads it.

A SecretStore or ClusterSecretStore defines provider access. An ExternalSecret names remote keys and a target Secret. The operator fetches the values, writes the Secret, and re-reads the provider every refreshInterval, which defaults to one hour.

ReadWriteOnce: mounted read-write by one node. ReadOnlyMany: mounted read-only by many nodes. ReadWriteMany: mounted read-write by many nodes. ReadWriteOncePod: exactly one pod cluster-wide. Except for ReadWriteOncePod, the scope is the node, not the pod.

CSI is a standard gRPC contract for storage drivers. A vendor ships the driver as ordinary pods in the cluster instead of code compiled into Kubernetes, so drivers install, upgrade and get fixed independently of the Kubernetes release.

volumeClaimTemplates makes the StatefulSet controller create one PersistentVolumeClaim per replica, named <template>-<statefulset>-<ordinal>. A Deployment's pod spec references one existing PVC, so every replica shares the same volume.

A StorageClass is a named storage tier: a provisioner plus its parameters. When a PersistentVolumeClaim names that class, the provisioner creates real storage and a matching PersistentVolume, which is bound to the claim. No admin pre-creates the volume.

An emptyDir is created when the Pod is placed on a node and deleted with the Pod, so it survives container restarts but not rescheduling. A PersistentVolumeClaim points at storage whose lifetime is independent of the Pod, so data survives deletion and rescheduling.

Both steer a Pod onto nodes carrying particular labels. nodeSelector is exact key=value matching and every entry must match. Node affinity adds an expression language (In, NotIn, Exists, Gt, Lt), OR-ed alternatives, and a soft preferred form the scheduler may ignore.

A pod requests a GPU as an extended resource, such as nvidia.com/gpu: 1, in its container limits. Extended resources are whole units the scheduler counts, not shares. So Kubernetes rejects fractions, requires the request to equal the limit, and never overcommits them.

It watches a metric (usually CPU) for a Deployment or StatefulSet and rewrites that workload's replica count, clamped between minReplicas and maxReplicas, to keep the metric near a target. Needs metrics-server plus resource requests on the pods. It adds and removes pods only — it never resizes a pod and never adds nodes.

KEDA is a Kubernetes operator that scales workloads on external event signals such as Kafka lag, queue depth or a Prometheus query. A ScaledObject names the target workload, its replica bounds and its triggers. KEDA turns that into an HPA it owns.

Spot nodes suit replicated, stateless or checkpointing work that can lose a node at short notice. Label the pool by capacity type and taint it, so only pods that tolerate the taint and select the label land there.

controller-runtime supplies a manager that runs shared caches, clients, work queues, leader election and metrics; Kubebuilder scaffolds the API types, markers and Makefile. You write Reconcile: fetch the object named by req, converge actual state to spec, then update status.

A CustomResourceDefinition registers a new resource type with the Kubernetes API server. You immediately get REST endpoints for it, storage in etcd, kubectl support, watches, RBAC and labels — but nothing acts on the objects until you run a controller for them.

An Operator is a custom Kubernetes resource type plus a controller running in the cluster. Users declare the desired database in a custom object; the controller continuously drives the real system to match that spec, automating install, backup, upgrade and failover.

The API server authenticates and authorizes, then runs mutating admission (webhooks may patch the object), then schema validation, then validating admission (accept or reject only), then writes to etcd. Mutation runs first so validators judge the final stored object.

The schema validates types, required fields and constraints at admission, applies declared defaults, and prunes — silently strips — any field it does not describe. To keep arbitrary content, mark that subtree with x-kubernetes-preserve-unknown-fields: true.

The LimitRanger admission plugin in kube-apiserver copies defaultRequest and default into any container missing a request or limit at Pod creation, then rejects Pods outside min and max. Running Pods are never changed.

A Kubernetes namespace scopes object names and most workload objects: Pods, Services, Secrets, ConfigMaps, PVCs. Nodes, PersistentVolumes, StorageClasses, ClusterRoles, CRDs and Namespaces themselves are cluster-scoped. Run kubectl api-resources --namespaced=false to list them.

A ResourceQuota is a namespaced object whose spec.hard caps the namespace's total CPU and memory requests and limits, storage requests and object counts. The API server rejects any create that would push usage past a cap.

Read the namespace's status.conditions. They usually point to objects held by finalizers whose controller is gone, or to an unavailable aggregated API that makes discovery fail. Restore that controller or API, or remove the stale finalizer or APIService.

Soft multi-tenancy gives each trusted team a namespace fenced by RBAC, quota and network policy. Hard multi-tenancy assumes hostile tenants and separates clusters or nodes, because namespaces still share the kernel, nodes, control plane and cluster-scoped objects.

metrics-server scrapes current CPU and memory usage from every kubelet, keeps only the latest points in memory, and serves them as the metrics.k8s.io API. It is not a monitoring system: no history, no custom metrics, no alerting.

kube-apiserver is the cluster's front door: a REST API that authenticates, authorises, validates and persists every object, and streams changes to watchers. Routing all writes through it gives one place for auth, validation, admission and audit.

kube-scheduler watches for Pods with an empty spec.nodeName, picks a suitable node, and writes that choice back to the API server (a binding). It does not start the container — the kubelet on the chosen node does that.

etcd is the cluster's only persistent database: a distributed, strongly consistent key-value store holding every API object (Pods, Deployments, Services, ConfigMaps, Secrets, RBAC, node state). Only kube-apiserver connects to it; everything else reads and writes through the API server.

Running Pods keep running: the kubelet keeps their containers alive and kube-proxy's installed Service rules keep routing. Anything that needs a write or fresh state stops working: scheduling, scaling, rollouts, rescheduling off failed nodes and kubectl.

The API server terminates TLS, then runs three gates in order: authentication (who are you — cert, service-account token, or OIDC token), authorization (may this identity do this verb on this resource — usually RBAC), and admission (mutating plugins/webhooks may edit the object, then validating ones may reject it). Only then is the object schema-validated and written to etcd.

runAsUser sets the numeric UID the container process runs as. runAsNonRoot: true makes the kubelet refuse to start the container if it would run as UID 0. Root inside the container is real root on the host kernel, so any container escape starts privileged.

A rule says which API groups, which resource types, and which verbs are allowed. Read-only pods is apiGroups: [""] (core group), resources: ["pods"], verbs: ["get","list","watch"]. A Role holds the rules; a RoleBinding attaches it to a user, group or ServiceAccount. RBAC is purely additive — there is no deny.

Base64 is an encoding, not encryption: anyone decodes it in one command, no key needed. By default a Secret sits unencrypted in etcd and is readable by anyone whose RBAC allows reading Secrets. Real protection is least-privilege RBAC, encryption at rest, and keeping plaintext manifests out of git.

It presents a ServiceAccount: a namespaced identity named by spec.serviceAccountName. The kubelet projects a signed JWT for it into the container at /var/run/secrets/kubernetes.io/serviceaccount/token. Leaving everything on default means all workloads share one identity, so any permission granted to it is granted to all of them and nothing is attributable.

Running pods keep running and existing Service traffic keeps flowing, because kubelets and kube-proxy work from state they already have. Anything that needs the API server stops: scheduling, rescheduling, scaling, rollouts, endpoint updates and CronJob runs.

Use kubectl exec -it POD -c CONTAINER -- sh. It starts an extra process inside an already-running container, streamed through the API server and the kubelet. The binary must exist in the image and the container must be running.

imagePullPolicy tells the kubelet when to check the registry: Always on every start, IfNotPresent only when the image is not cached, Never not at all. Unset, it defaults to Always for :latest or images with no tag and no digest, otherwise IfNotPresent.

kubectl logs POD -c CONTAINER shows the current instance; --previous shows the last terminated one. Add -f to follow, --since and --tail to bound output. Nothing appears if the app logs to a file instead of stdout/stderr, the pod never started, or the logs rotated.

No. Kubernetes keeps container logs only as files on the pod's node, tied to that pod; once the pod is deleted the kubelet removes its containers and log directory, and the replacement pod starts with empty logs.

The provider runs the control plane: kube-apiserver, etcd, the scheduler and controller managers, including their hosts, patching and availability. You still own worker nodes, workloads, RBAC, add-ons, network choices and deciding when to upgrade.

Cordon marks a node unschedulable so no new pods land there. Drain cordons it and then evicts its pods so their controllers recreate them elsewhere. Uncordon makes the node schedulable again without moving any pods back.

An etcd snapshot restores Kubernetes API objects (Deployments, Secrets, RBAC, PVC and PV objects, custom resources) but none of the bytes stored on persistent volumes. Volume data needs CSI snapshots or Velero; Git re-creates only what was committed.

The bootstrap token is a short-lived shared secret: the node checks a token-signed cluster-info and the API server accepts the new kubelet. The CA cert hash pins the cluster CA public key, so a leaked token cannot impersonate the cluster.

A Kubernetes cluster is one failure and control domain, so teams run many clusters to limit blast radius, place workloads in specific regions, draw compliance boundaries and give tenants isolation that namespaces cannot provide.

The app must read configuration from environment variables or mounted files, log to stdout and stderr, expose a readiness signal that reflects real ability to serve, shut down cleanly on SIGTERM, and size itself from its container limits.

A golden-path template is a platform-maintained, pre-approved way to deploy a service: developers fill in a few values and the template produces the Deployment, Service, probes and resources, so every team gets safe defaults without writing raw Kubernetes manifests.

A StatefulSet gives each PostgreSQL pod a stable name, its own volume and ordered rollout. It knows nothing about which pod is primary, replication, failover, backups or safe upgrades, so all of that is still yours.

Pods are disposable and restart anywhere with a new IP and an empty filesystem, so local disk, fixed IPs, in-memory sessions, host cron and log files break. They move to object storage or a PVC, a Service name, a shared session store, a CronJob and stdout.

Decide by ownership and risk, not by preference. In-cluster operators suit teams that can run databases, need portability or have no managed option. Otherwise a managed service is usually cheaper overall. Say no when nobody can own recovery.