42 posts tagged with "Containers"

Kubernetes networking makes no sense until you understand these Linux primitives. Every pod-to-pod connection, every service load balancer, and every network policy maps directly to Linux networking concepts that have existed for decades. Master these fundamentals and container networking becomes transparent.

docker stats shows you what is happening right now. It does not show you what happened at 3 AM when response times spiked. It does not alert you when a container's memory is trending toward its limit. It does not graph CPU usage over the past week to help you right-size your resource limits. For real monitoring, you need metrics collection, storage, visualization, and alerting. The standard stack for Docker is cAdvisor + Prometheus + Grafana, and you can have it running in under fifteen minutes.

Bridge networks work on a single host. Your containers can talk to each other when they are on the same machine. But when you have three application servers across three hosts, a bridge network does nothing for you. Overlay networks solve this — they create a virtual network that spans multiple Docker hosts, letting containers communicate as if they were on the same LAN, regardless of which physical machine they are running on.

You have a CI pipeline that builds your container image and runs tests. The last step runs kubectl apply -f manifests/ against the production cluster. It works, until someone SSH-es into the server and runs kubectl edit deployment to "hotfix" something. Now your Git repository says one thing and the cluster says another. Nobody knows what is actually running in production. This is the exact problem GitOps solves.

You run docker stop myapp and wait. After 10 seconds, Docker force-kills the container. Your application never received the shutdown signal, never flushed its write buffers, never closed database connections. Running docker top on a long-running container reveals dozens of zombie processes consuming PIDs. Both problems share the same root cause: your application is running as PID 1 in the container, and it was never designed for that responsibility.

Docker isn't magic — here's how to build a container with just Linux commands. Containers are nothing more than regular Linux processes with three layers of isolation: namespaces (what a process can see), cgroups (what a process can use), and a changed root filesystem (where a process lives). Once you understand these primitives, Kubernetes networking, Docker storage drivers, and container security all start making sense.