Advanced Docker and Kubernetes Interview Questions

A container is a process, isolated with Linux namespaces (PIDs, network, mounts and more), limited with cgroups (CPU and memory), and given a file system by a union file system. There is no separate kernel.

Docker's default storage driver. It stacks image layers as read-only directories, and adds a writable layer on top. Changing a file copies it up to the writable layer first, which is called copy-on-write.

Docker's daemon uses containerd to manage the container lifecycle and images, and containerd uses runc to create containers according to the OCI standard. Kubernetes talks to containerd directly.

The process with PID 1 gets signals such as SIGTERM, and must reap zombie child processes. Many apps do neither well. Use the exec form, handle signals, or add --init.

Parallel builds, better caching, build secrets, SSH forwarding, multi-platform builds through buildx, and remote cache export.

A container with access to /var/run/docker.sock can start privileged containers and mount the host's file system, which amounts to root on the host.

Use a minimal, pinned, scanned image. Run as non-root, with a read-only root file system, --cap-drop=ALL, no-new-privileges, resource and PID limits, and no --privileged. Keep secrets out of the image.

Running the Docker daemon and containers as a normal user, using user namespaces, so that a container escape does not give root on the host.

Pin base images by digest, use lock files, avoid fetching floating versions during the build, and build in CI.

A pod is the smallest unit in Kubernetes. It holds one or more containers that share a network address and can share volumes. Sidecars, such as log shippers, run in the same pod.

A Deployment runs interchangeable pods, for stateless apps. A StatefulSet gives pods stable names and their own storage, for databases. A DaemonSet runs one pod on each node, for agents such as log collectors.

The Deployment creates a new ReplicaSet, and scales it up while scaling the old one down, within maxSurge and maxUnavailable. New pods get traffic once they pass readiness checks. kubectl rollout undo goes back.

A failing readiness probe removes a pod from Service traffic. A failing liveness probe restarts the container. Startup probes protect slow-starting apps.

ClusterIP is internal only. NodePort opens a port on each node. LoadBalancer creates a cloud load balancer. Ingress is an HTTP router by host and path, and needs an ingress controller.

Requests are what the scheduler reserves, and limits are the maximum. Exceeding a memory limit kills the container, and exceeding a CPU limit throttles it.

By default, they are only base64-encoded in the API. You should enable encryption at rest, restrict access with RBAC, and consider External Secrets or a vault.

It picks a node for each new pod, based on requests, node resources, affinity rules, taints and tolerations.

Use kubectl logs --previous and kubectl describe pod to read the events. Common causes are a bad config, a missing secret, a failing liveness probe, or an out-of-memory kill.

No node fits it. Usually it needs more CPU or memory than is free, a volume cannot be bound, or taints and affinity rules block it. kubectl describe pod shows the reason.

Through its label selector. Kubernetes keeps EndpointSlices listing the ready pods, and kube-proxy routes traffic to them. DNS maps the Service's name to its stable address.