Search
15 results for “containers”
Search results
Docker Fundamentals
How images, containers, volumes, and networks fit together in Docker's runtime model, and the shift from installing software to running images.
Kubernetes Fundamentals
Learn Kubernetes through Pods, Deployments, Services, probes, resources, rollouts, and an official-docs-based troubleshooting workflow.
What is the difference between a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.
Why does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
Why is publishing a port with `-p 8080:80` different from the container just "having" port 80?
A container's ports exist only on its own private network namespace by default; nothing on the host or outside can reach them until Docker explicitly forwards a host port to it. `-p 8080:80` tells Docker's network layer to forward the host's port 8080 to port 80 inside the container's namespace, host port first, container port second. Leaving a port `EXPOSE`d in a Dockerfile only records metadata/documentation, it has no effect on connectivity at all: another container on the same Docker network can already reach any port the first container is listening on, EXPOSE or not. Publishing to the host is the one thing that always requires an explicit `-p`.
What is the difference between a Pod, a Deployment, and a Service?
A Pod is the smallest deployable unit, one or more containers that share network and storage, scheduled together onto a node. Pods are ephemeral and disposable; Kubernetes recreates them freely and their IPs change every time. A Deployment manages a set of identical Pods (a ReplicaSet under the hood), handling rolling updates, rollbacks, and keeping the desired replica count running even as individual Pods die. A Service gives that changing set of Pods a stable network identity, a fixed virtual IP and DNS name, so other things in the cluster don't need to track individual Pod IPs, which change constantly.
What does the Kubernetes control loop actually do?
Every Kubernetes controller (Deployment, ReplicaSet, etc.) runs a reconciliation loop: it continuously compares the desired state (what you declared in a manifest, stored in etcd) against the observed actual state of the cluster, and takes action to close any gap. If you declared 3 replicas and only 2 Pods are running, the ReplicaSet controller creates one more. This is the same declarative, converge-toward-desired-state model as Terraform, but running continuously and automatically rather than on-demand.
Why can't you rely on a Pod's IP address for service discovery?
Pods are ephemeral by design, Kubernetes kills and recreates them constantly (failed health checks, node drains, rolling deployments, autoscaling), and every new Pod gets a brand-new IP address. Hardcoding or caching a Pod IP breaks the moment that Pod is replaced. A Service solves this by providing a stable virtual IP and DNS name that always routes to whichever Pods currently match its label selector, regardless of how many times the underlying Pods have been replaced.
What is the difference between readiness, liveness, and startup probes?
Readiness decides whether a Pod should receive Service traffic; a failed readiness probe removes the Pod from eligible backends without restarting it. Liveness decides whether a stuck container should be restarted. A startup probe protects slow-starting containers by delaying readiness and liveness checks until startup succeeds. Reusing one strict check for all three can create restart loops or route traffic too early.
How would you troubleshoot a Service that exists but returns no response?
Work from the application outward: confirm the selected Pods are Ready and serving on the expected container port, compare the Service selector with Pod labels, inspect EndpointSlices to verify Kubernetes discovered backends, confirm port and targetPort, then test Service DNS and IP from inside the cluster. An empty EndpointSlice usually points to a selector/readiness mismatch; healthy endpoints with failed DNS or routing move the investigation to cluster networking.
Why Every Container in Your Rolling Deploy Takes an Extra 10 Seconds to Stop
Why npm as PID 1 can prevent Node.js from receiving SIGTERM, trigger Docker's ten-second timeout, and end container shutdown with SIGKILL.
Kubernetes OOMKilled Troubleshooting Guide
A practical Kubernetes OOMKilled troubleshooting guide using kubectl describe, previous logs, events, metrics, requests, limits, QoS, and node memory pressure.
What is the difference between the Baseline and Restricted Pod Security Standards levels, and why are they cumulative?
Baseline blocks the most well-known container privilege-escalation paths, privileged containers, host namespaces, hostPath volumes, dangerous Linux capabilities, while still allowing a fairly permissive pod spec otherwise. Restricted inherits every Baseline rule and adds real hardening on top: it requires running as non-root, forbids privilege escalation outright, requires a restricted seccomp profile, and requires dropping all Linux capabilities except NET_BIND_SERVICE. A read-only root filesystem is not part of either standard, it's a separate hardening measure some organizations layer on as their own policy, on top of, not as part of, Restricted. They're cumulative by design, Restricted is Baseline plus more, so a workload that passes Restricted automatically satisfies Baseline too, and a cluster can apply different levels per namespace based on how much a given workload can be trusted.
Why would an organization use multiple AWS accounts instead of one account holding all resources?
Separate accounts per environment (production, staging, development) or per team give a hard isolation boundary that a single account with tags or naming conventions cannot: a mistake or compromised credential in a development account cannot reach production resources at all, rather than merely being restricted by IAM policy within the same account. It also gives cleaner cost attribution (billing rolls up per account), independent service quotas, and a natural blast-radius limit for security incidents. AWS Organizations, and patterns built on top of it like a landing zone, exist specifically to make many accounts manageable, centralized billing, centralized logging, and org-wide SCPs, without losing that isolation.
Microsoft Entra Conditional Access: MFA and Location Controls
How Conditional Access Evaluates Sign‑Ins Behind the Scenes