DEV Community: Sreekanth Kuruba

Inside Kubernetes Service Networking: Follow a Packet from ClusterIP to Pod

Sreekanth Kuruba — Wed, 21 Oct 2026 07:31:53 +0000

You already know that a Kubernetes Service provides a stable IP address for accessing Pods.

But what happens inside the cluster when you run:

curl http://web-service

How does the request reach a backend Pod? Who redirects the packet? And what happens when that Pod is replaced?

Let's follow a packet from the Service's ClusterIP to a backend Pod and explore DNAT, connection tracking, and Linux networking rules.

1. Start with a Simple Service

Consider this Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Assume Kubernetes assigns the Service this ClusterIP:

10.96.100.10

The Service accepts traffic on port 80 and forwards it to eligible backend Pods on port 8080.

Suppose one backend Pod has this IP address:

10.244.2.8:8080

The client sends a request to 10.96.100.10:80. The networking datapath must direct that traffic to an appropriate backend.

2. What Happens Behind the Scenes?

Several components work together:

Service: Provides a stable virtual IP and port.
EndpointSlice: Tracks the backend endpoints associated with the Service.
EndpointSlice controller: Maintains EndpointSlices for selector-based Services.
kube-proxy: Watches Service and EndpointSlice changes and programs forwarding rules when kube-proxy is used.
Linux kernel: Processes packets using the configured networking rules.
CNI networking: Provides connectivity between Pods, including communication across nodes when necessary.

In a typical kube-proxy iptables setup, no dedicated userspace process listens on the ClusterIP. Instead, the Linux kernel applies networking rules to redirect traffic.

Other implementations, including eBPF-based datapaths, can handle Service forwarding differently.

3. Follow the Packet: From ClusterIP to Pod

Imagine the client Pod runs on Node A, while the backend Pod runs on Node B.

Client Pod — Node A
10.244.1.10:50000
        |
        | Destination: 10.96.100.10:80
        v
Service ClusterIP
10.96.100.10:80
        |
        | DNAT
        v
Backend Pod — Node B
10.244.2.8:8080
        |
        v
Application processes the request

Let's examine the packet's journey.

Step 1: The client sends a request

The client application opens a TCP connection to:

10.96.100.10:80

This is the Service address, not the backend Pod's IP address.

Step 2: Networking rules select a backend

In a typical kube-proxy iptables configuration, kube-proxy programs rules that direct Service traffic through chains associated with the Service and its endpoints.

A simplified representation is:

PREROUTING
    |
    v
KUBE-SERVICES
    |
    v
Service-specific chain
    |
    v
Endpoint-specific chain
    |
    v
DNAT to 10.244.2.8:8080

These chain names illustrate the general flow; actual rules and packet paths depend on the implementation and configuration.

The important distinction: kube-proxy programs and updates the rules, while the Linux kernel processes packets against them. kube-proxy does not need to inspect every packet in userspace.

Step 3: DNAT changes the destination

DNAT stands for Destination Network Address Translation.

Before translation:

Destination: 10.96.100.10:80

After translation:

Destination: 10.244.2.8:8080

The destination changes to the selected backend Pod's IP and target port.

The application still connects to the Service address. It does not need to discover or track individual backend Pod IPs.

Step 4: The packet reaches the backend Pod

Because the backend Pod is on Node B, the cluster's networking implementation must deliver the packet to that node.

Depending on the CNI and cluster configuration, this can involve ordinary routing, packet encapsulation, or other datapath mechanisms.

The backend Pod receives the request on port 8080, where its application is listening.

This is where Service forwarding and the underlying Pod network work together.

4. What Happens to the Response?

The backend application sends a response to the client.

In a typical connection-tracked NAT setup, Linux connection tracking records the connection's translation state. This allows the networking stack to apply the corresponding reverse translation to response packets.

From the client's perspective, the response belongs to the connection it opened to the Service address.

Source NAT (SNAT) may also be used on some traffic paths, depending on the networking configuration. It can change the source address seen by the backend, so whether the original client IP is preserved depends on the path and implementation.

5. What Happens When a Pod Is Replaced?

Suppose a backend Pod is deleted or becomes ineligible to receive traffic.

An EndpointSlice might initially contain:

10.244.2.8
10.244.2.9
10.244.3.5

After an endpoint change, the eligible set might become:

10.244.2.9
10.244.3.5
10.244.3.12

The replacement Pod has a different IP, but the client can continue using the same Service address:

10.96.100.10:80

In a kube-proxy-based cluster, kube-proxy observes the updated Service and EndpointSlice information and reconciles its forwarding rules. Other datapaths have their own mechanisms for updating endpoint selection.

There is an important limitation: new connections can use the updated set of eligible backends, but existing connections may fail if their selected backend disappears. A stable Service IP does not guarantee that every connection survives a Pod replacement.

6. Does Every Cluster Use iptables?

No. Kubernetes Service forwarding depends on the proxy implementation and cluster configuration.

Mode	How it handles Service traffic
iptables	Uses Linux netfilter rules for packet filtering and translation
nftables	Uses the newer Linux nftables framework for Service forwarding
IPVS	An older kube-proxy mode that is deprecated in Kubernetes 1.35
eBPF-based datapath	Can implement Service forwarding using eBPF, sometimes replacing kube-proxy

The nftables mode became stable in Kubernetes 1.33. It is the recommended kube-proxy replacement for Linux nodes where the kernel and networking components support it, but iptables remains the default for compatibility.

IPVS is deprecated in Kubernetes 1.35. The current roadmap expects it to be disabled by default in Kubernetes 1.40 and removed in 1.43; these are planned milestones, not completed removals.

Why does this matter? A troubleshooting command that works for an iptables-based cluster may not reveal the relevant rules in a cluster using nftables or an eBPF-based datapath.

7. Troubleshoot Service Traffic Step by Step

If a Service cannot reach its backend, investigate each layer instead of immediately blaming kube-proxy.

Step 1: Check the Service

kubectl get svc web-service
kubectl describe svc web-service

Verify the ClusterIP, Service port, target port, and selector.

Step 2: Check the Pods and labels

kubectl get pods -o wide --show-labels

Confirm that the backend Pods have the expected labels and are running.

Step 3: Check EndpointSlices

kubectl get endpointslices \
  -l kubernetes.io/service-name=web-service

If there are no eligible endpoints, investigate the Service selector, Pod labels, readiness, and endpoint conditions.

Step 4: Test the backend directly

From a location that can reach the Pod IP, try:

curl http://10.244.2.8:8080

Use an actual backend Pod IP and the port on which the application listens.

If this fails, investigate the application, Pod, listening port, and underlying network first.

Step 5: Test through the Service

curl http://10.96.100.10:80

If the direct Pod test succeeds but the Service test fails, investigate Service configuration and the active networking datapath.

Step 6: Inspect the networking rules

For a cluster using iptables:

sudo iptables-save -t nat

For a cluster using nftables:

sudo nft list ruleset

These commands may require node access and elevated privileges. Their output depends on the active implementation.

For deeper troubleshooting, tools such as tcpdump can help identify where packets stop. For example:

sudo tcpdump -ni any host 10.96.100.10

Packet captures may require access to the node, and traffic may not appear at every interface or in the same form after address translation. With eBPF-based networking, use the observability tools provided by that implementation.

8. Key Takeaways

A Kubernetes Service provides a stable destination while its backend endpoints can change.

In a typical kube-proxy iptables setup:

The client sends traffic to the ClusterIP.
Linux networking rules select a backend.
DNAT changes the destination to the Pod IP and target port.
The cluster network delivers the packet to the backend.
Connection tracking helps handle the response path.
Endpoint changes update the forwarding configuration for subsequent traffic.

Understanding this flow helps you troubleshoot networking layer by layer: Service configuration, EndpointSlices, packet translation, and Pod connectivity.

Instead of treating Kubernetes networking as a black box, you can follow the packet and investigate where the problem occurs.

Related reading: This article builds on my earlier guide, How Does Traffic Actually Reach Your Pods? Kubernetes Services & kube-proxy Explained, which covers Service types, selectors, EndpointSlices, and kube-proxy fundamentals.

Next in the series: Kubernetes Ingress Explained — How External HTTP Traffic Reaches Your Applications.

From Docker to Kubernetes: When Docker Stops Being Enough

Sreekanth Kuruba — Tue, 06 Oct 2026 03:15:33 +0000

You learned how to build an image.

You can start a container:

docker run myapp

You can inspect it, read its logs, attach volumes, configure networks, set resource limits, add health checks, and harden its security.

Then Docker Compose helps you run several services together.

So why does Kubernetes exist?

If Docker already does a good job of running containers, what problem is Kubernetes actually solving?

The answer becomes clearer when one container becomes hundreds.

1. Start With One Container

Imagine a simple web application.

User
 │
 ▼
Web Container
 │
 ▼
Database

Running it is straightforward:

docker run myapp

Nothing complicated yet.

Now traffic increases.

You need several application instances.

Then the application itself grows:

Frontend
API
Database
Redis
Background workers
Monitoring
Logging components

Docker Compose can describe and run these services together:

docker compose up

For development and many single-host environments, that's extremely useful.

But then another requirement appears:

The application can no longer live on one machine.

2. When One Server Becomes Ten

Imagine you now have 100 containers that need to run across 10 machines.

Suddenly, docker run isn't the difficult part.

The difficult questions are:

Which machine should run each container?

What if that machine fails?

What if one container crashes?

What if traffic suddenly triples?

How do applications find containers that are constantly being replaced?

How do you update 50 instances without taking everything offline?

At this point, the problem has changed.

You're no longer dealing primarily with a container problem.

You're dealing with an orchestration problem.

3. This Is Where Kubernetes Enters

A useful simplified progression is:

This doesn't mean:

Docker = beginner

Kubernetes = advanced Docker

They're solving different layers of the problem.

Docker gives you tools to build and run containers.

Kubernetes gives you a system for coordinating containerized workloads across infrastructure.

And that changes the question you're asking.

4. Kubernetes Changes the Question

With Docker, you might say:

docker run myapp

You're directly telling the system what action to perform.

Kubernetes encourages a different model.

You describe the state you want.

For example:

I want three instances of this application running.

Conceptually:

replicas: 3

Kubernetes continually works to make reality match that desired state.

Desired State
     │
     ▼
3 replicas should exist
     │
     ▼
Kubernetes observes reality
     │
     ▼
Only 2 exist?
     │
     ▼
Create another

That idea — desired state and reconciliation — is one of the biggest mental shifts from manually operating containers.

You stop thinking only about:

"Start this container."

And start thinking:

"Keep my application in this state."

5. What Happens When Things Fail?

Suppose your application should have three instances:

App 1    App 2    App 3
  ✓        ✓        ✓

Then one fails:

App 1    App 2    App 3
  ✓        ✗        ✓

You don't want someone to discover the failure and manually create a replacement.

Kubernetes controllers continuously compare the current state with the desired state.

If three replicas should exist but only two remain, Kubernetes can work to restore the desired number.

Desired: 3
Actual: 2

     ↓

Create replacement

     ↓

Actual: 3

But containers aren't the only things that fail.

Machines fail too.

Imagine:

Node 1
 ├─ App
 └─ Worker

Node 2
 ├─ App
 └─ API

Node 3
 ├─ App
 └─ Worker

If Node 2 becomes unavailable, several workloads may disappear at once.

Now another question appears:

Where should the replacements run?

Kubernetes can schedule replacement workloads onto available nodes according to the workload configuration and cluster conditions.

Failure has moved from being something you manually react to into something the platform continuously observes and responds to.

That's a major reason orchestration exists.

6. From Containers to Scheduled Pods

Kubernetes doesn't normally manage an individual container as its smallest deployable unit.

It manages a Pod.

Conceptually:

Pod
 │
 ├── Application Container
 │
 └── Optional Supporting Container

A Pod can contain one or more tightly coupled containers that share certain resources such as networking.

Most commonly, you'll still encounter one main application container per Pod.

Containers haven't disappeared.

Kubernetes has added a management layer around them.

But now we have another problem.

Suppose the cluster contains several nodes with different available resources.

Where should a new Pod run?

Doing this manually for hundreds of workloads would quickly become difficult.

Kubernetes uses its scheduler to select an appropriate node based on factors such as:

Resource requirements
Scheduling constraints
Node conditions
Affinity rules
Taints and tolerations

The important change is this:

Placement becomes a cluster decision instead of a human manually choosing a server.

7. Scaling Creates Another Problem

Suppose three application instances normally handle your traffic.

Then traffic increases dramatically.

You need six.

Docker can certainly start more containers.

But in a larger environment, you also need a system that understands:

How many instances should exist
Where they should run
Whether enough resources are available
What should happen when instances fail

Kubernetes workloads can be scaled manually, and Kubernetes also supports automatic scaling based on configured metrics and policies.

But creating more instances introduces another problem.

How does anything reliably find them?

8. Replaceable Pods Need Stable Networking

Pods are designed to be replaceable.

Suppose an API Pod has this IP:

10.0.1.7

It disappears.

A replacement appears with a different IP:

10.0.3.12

If your frontend depends directly on the old address, it now points at something that no longer exists.

Kubernetes solves this problem with Services.

        Frontend
            │
            ▼
       API Service
            │
      ┌─────┼─────┐
      ▼     ▼     ▼
    Pod A Pod B Pod C

Pods can come and go.

The Service provides a stable way to reach the workload.

That reveals another important Kubernetes idea:

The individual instance is temporary. The application identity should remain stable.

9. Docker Concepts Don't Disappear

This is where learning Docker first starts paying off.

Many of the problems you've already encountered still exist in Kubernetes.

Docker concept	Kubernetes world
Container	Container inside a Pod
Image	Container image
Resource limits	Requests and limits
Health checks	Liveness, readiness, and startup probes
Networking	Pod and Service networking
Persistent data	Persistent Volumes / Claims
Environment/config	ConfigMaps and Secrets
Restart/recovery thinking	Controllers and reconciliation

Kubernetes doesn't make Docker knowledge useless.

It builds on many of the same container fundamentals while adding orchestration around them.

Take health checks as an example.

With Docker, we learned:

Running doesn't necessarily mean healthy.

Kubernetes makes the distinction even more useful.

Liveness Probe

Roughly asks:

Is this container functioning, or should Kubernetes restart it?

Readiness Probe

Asks:

Is this Pod currently ready to receive traffic?

Startup Probe

Helps protect slow-starting applications from liveness checks being applied too early.

An application can therefore be alive without being ready to serve users.

Alive ≠ Ready

The underlying problem hasn't disappeared.

The orchestration layer simply has more ways to respond to it.

10. Updating One Container Is Easy. Updating Fifty Isn't.

Replacing one Docker container is straightforward.

But imagine updating 50 application instances.

Stopping all of them at once could create downtime.

Instead, you'd prefer something like:

Old Old Old Old

      ↓

New Old Old Old

      ↓

New New Old Old

      ↓

New New New Old

      ↓

New New New New

Kubernetes Deployments support controlled rolling updates.

If something goes wrong, rollout history and rollback mechanisms can help return the workload to an earlier revision.

Again, Kubernetes isn't making the individual container smarter.

It's coordinating how a group of containerized instances changes over time.

That's the pattern throughout this article.

The container isn't necessarily the difficult part anymore.

Coordinating all the containers is.

11. Kubernetes Didn't Simply Replace Docker

This is one of the most common misconceptions.

You may have heard:

"Kubernetes stopped using Docker."

That can make it sound as though Docker images somehow stopped working with Kubernetes.

They didn't.

Kubernetes needs a container runtime to actually run containers.

Modern Kubernetes communicates with container runtimes through the Container Runtime Interface (CRI).

Common examples include:

containerd
CRI-O

Kubernetes removed its old Docker-specific integration layer, known as dockershim.

But that doesn't mean Docker-built container images became unusable.

The important takeaway is:

Docker images didn't stop working with Kubernetes. Kubernetes changed how it communicates with container runtimes.

A simplified model is:

Build Container Image
        │
        ▼
Store in Registry
        │
        ▼
Kubernetes
        │
        ▼
Container Runtime
        │
        ▼
Run Containers

So the choice isn't simply:

Docker OR Kubernetes.

Different tools are operating at different layers.

12. So When Does Docker Stop Being Enough?

Not every application needs Kubernetes.

That's important.

If you have:

A few containers
One server
Predictable traffic
Simple deployments
Limited scaling requirements

Docker or Docker Compose may be completely sufficient.

Adding Kubernetes could simply introduce complexity you don't need.

Kubernetes starts becoming more useful when the problems themselves change:

Many workloads
Multiple machines
Automated scheduling
Failure recovery
Service discovery
Horizontal scaling
Rolling deployments
High availability
Cluster-wide resource management

So perhaps the wrong question is:

"When should I graduate from Docker to Kubernetes?"

A better question is:

"Do I actually have an orchestration problem?"

If the answer is no, Kubernetes may be solving a problem you don't have.

The Journey From `docker run`

This series started with a deceptively simple command:

docker run

Then we went underneath it.

We explored:

Docker internals
Image builds
Networking
Storage
Container security
Docker Compose
Production reliability
Rootless Docker and advanced security

And something interesting happened.

The deeper we went, the less Docker looked like simply:

"A tool that runs containers."

We started seeing the Linux kernel.

Namespaces.

cgroups.

Filesystems.

Networks.

Security boundaries.

Resource management.

Application lifecycle.

Eventually, the question changed.

It was no longer:

How do I run this container?

It became:

How do I reliably operate large numbers of containers across multiple machines?

That's where the container problem becomes an orchestration problem.

And that's where Kubernetes begins.

Docker is surprisingly easy to start with.

That's one of its greatest strengths.

But underneath that simple experience is a much deeper system.

You don't need to master every Docker internal before learning Kubernetes.

But understanding the foundation makes Kubernetes feel much less mysterious.

Because eventually you realize:

Kubernetes isn't where containers begin.

It's what becomes useful when operating containers becomes the bigger problem.

Question for You

When did Kubernetes start making sense to you — while learning Pods and Deployments, or only after understanding the problems orchestration is trying to solve?

Rootless Docker & Advanced Security: Which Root Are We Actually Talking About?

Sreekanth Kuruba — Thu, 24 Sep 2026 03:31:18 +0000

You run a container as root.

That sounds dangerous.

But here's a more interesting question:

Which root?

Root inside the container?

Root on the host?

Or the root user running the Docker daemon?

They aren't necessarily the same thing.

And understanding that difference changes how you think about Docker security.

We've already seen that containers rely on namespaces, capabilities, seccomp, and other Linux mechanisms for isolation.

Now let's go one level deeper.

What if Docker itself didn't need root privileges in the first place?

That's where Rootless Docker enters the picture.

1. Why Docker Has So Much Power

When you run:

docker run nginx

the Docker CLI isn't creating the container by itself.

A simplified flow looks like this:

User
 │
 ▼
Docker CLI
 │
 ▼
Docker Daemon
 │
 ▼
Container Runtime
 │
 ▼
Linux Kernel

In a traditional Docker installation, the Docker daemon normally runs with root privileges.

That's powerful because container management involves operations around:

Namespaces
cgroups
Networking
Filesystems
Processes

But that power creates an important security boundary.

If someone gains unrestricted control over a rootful Docker daemon, they may gain extremely powerful access to the host.

So Docker security isn't only about:

"Is my application running as root?"

You also need to ask:

"Who controls Docker itself?"

2. The Docker Socket Is a Security Boundary

You've probably seen:

/var/run/docker.sock

The Docker CLI commonly communicates with the Docker daemon through this Unix socket.

That makes access to the socket much more powerful than it might initially appear.

Someone with sufficient Docker access could potentially create highly privileged containers or expose sensitive host resources inside them.

That's why blindly doing this is dangerous:

-v /var/run/docker.sock:/var/run/docker.sock

It might look like you're simply giving a container access to Docker.

In reality, you're exposing a highly privileged control interface.

A useful mental model is:

Protect access to the Docker daemon like you protect administrative access to the host.

And this leads to the next question.

If the daemon itself is so powerful, does it always need to run as root?

3. Container Root ≠ Host Root

Before answering that, we need to clarify what root actually means.

Suppose a process inside a container reports:

uid=0(root)

It's root inside that environment.

But that doesn't necessarily mean it must have the same identity or privileges as UID 0 on the host.

Linux user namespaces can map identities inside one namespace to different identities outside it.

Conceptually:

Container                  Host

UID 0 (root)   ────────▶   UID 100000
UID 1          ────────▶   UID 100001
UID 2          ────────▶   UID 100002
...

Inside the namespace:

UID 0 = root

From the host's perspective, that identity can correspond to an unprivileged UID.

This creates an important distinction:

Root inside a user namespace doesn't necessarily mean root on the host.

That's one of the ideas Rootless Docker builds upon.

4. So What Is Rootless Docker?

Traditional Docker commonly looks like this:

Normal User
     │
     ▼
Docker CLI
     │
     ▼
Docker Daemon
   (root)
     │
     ▼
Containers
     │
     ▼
Linux Kernel

Rootless Docker changes the privilege model:

Normal User
     │
     ▼
Docker CLI
     │
     ▼
Docker Daemon
 (non-root)
     │
     ▼
User Namespace
     │
     ▼
Containers
     │
     ▼
Linux Kernel

The Docker daemon runs without host-root privileges, while user namespaces and other Linux mechanisms allow container operations to happen from an unprivileged user context.

A process may still appear as:

uid=0(root)

inside its user namespace.

But that identity can be mapped to an unprivileged identity on the host.

Why does that matter?

Because if something compromises the daemon or a container, the attack begins from a less privileged position.

That's the real value of Rootless Docker.

Rootless Docker doesn't make compromise impossible. It reduces what a compromise starts with.

5. Rootful vs Rootless: What Actually Changes?

Here's the simpler mental model:

Question	Rootful Docker	Rootless Docker
Docker daemon	Runs as root	Runs as a normal user
User namespaces	Not inherently required for the daemon's privilege model	Fundamental to the rootless model
Host privilege exposure	Higher	Reduced
Low-level host access	Easier	More restricted
Compatibility	Broad	Some limitations
Security posture	Requires careful privilege management	Reduces daemon privileges by design

Rootless doesn't eliminate Docker security concerns.

It changes the starting privilege level.

And that's important.

But there's another trap here.

It's tempting to think:

"Docker is rootless now. Problem solved."

Not quite.

6. Rootless Is Only One Security Layer

A container can still have more access than the application actually needs.

Rootless Docker answers one question:

How much host privilege does Docker itself start with?

It doesn't answer every other security question.

For example:

Which privileged operations can the application perform?
Can it gain additional privileges?
Can it modify its filesystem?
Which system calls can it make?
Which host resources can it access?

That's why container security works better as layers.

Each layer removes a different kind of unnecessary power.

Security isn't one wall.

It's a series of boundaries an attacker has to cross.

7. Reduce What the Container Can Do

Linux traditionally gives root enormous power.

Capabilities split many privileged operations into smaller units.

Docker already starts containers with a reduced set of Linux capabilities.

But for workloads that allow it, you can go further.

Start by dropping all capabilities:

docker run \
  --cap-drop=ALL \
  nginx

Then add back only what the workload genuinely requires.

For example:

docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  nginx

The principle is simple:

Start with less privilege. Add privilege only when the workload proves it needs it.

There's another question:

What if the process starts with limited privileges but later finds a way to gain more?

Docker provides another useful control:

--security-opt no-new-privileges=true

For example:

docker run \
  --security-opt no-new-privileges=true \
  nginx

This tells the kernel that processes in the container should not gain additional privileges through mechanisms such as setuid or setgid binaries.

So these controls answer two different questions:

Capabilities

What privileged operations can this process perform?

no-new-privileges

Can this process gain more privilege later?

That's a much stronger model than simply asking whether the process is called root.

8. Reduce What the Container Can Change

Now suppose an attacker compromises the application.

Even with reduced privileges, another question matters:

What can the process modify?

Many applications don't need to write to their entire container filesystem.

If yours doesn't, Docker can make the root filesystem read-only:

docker run --read-only nginx

That reduces the places where a compromised process can modify:

Application files
Binaries
Configuration
Other filesystem content

Some applications still need writable locations for temporary files or runtime data.

Those can be provided separately.

For example:

docker run \
  --read-only \
  --tmpfs /tmp \
  nginx

The security principle is straightforward:

If something doesn't need write access, don't give it write access.

9. Reduce What the Container Can Reach

Containers share the host's Linux kernel.

That makes the kernel interface another important boundary.

seccomp

Applications interact with the kernel using system calls.

Docker's default seccomp profile blocks many system calls that typical containers don't require.

For many workloads, keeping Docker's default profile is a sensible starting point.

More sensitive environments can use more restrictive workload-specific profiles.

The principle remains the same:

Allow what is required. Reduce everything else.

AppArmor and SELinux

Normal Unix permissions aren't the only way Linux can control access.

Mandatory Access Control systems such as:

AppArmor
SELinux

can enforce additional policies around what processes are allowed to access.

Think of ordinary permissions as asking:

"Does this user normally have permission?"

Mandatory Access Control adds another question:

"Even if normal permissions allow it, does security policy allow it?"

These controls don't replace Rootless Docker.

And Rootless Docker doesn't replace them.

They protect different boundaries.

10. Where Rootless Docker Doesn't Fit

At this point Rootless Docker might sound like something that should simply be enabled everywhere.

But security controls come with trade-offs.

Depending on the environment, Rootless Docker can have differences or limitations involving areas such as:

Networking
Privileged ports
cgroup behavior or configuration
Storage
Host integration
Certain low-level workloads

Some workloads genuinely require deeper host access that doesn't fit well with a rootless environment.

So the goal isn't:

"Rootless everywhere at any cost."

The better principle is:

"Use the least privilege that still allows the workload to function correctly."

Rootless Docker is especially worth evaluating where reducing daemon privilege is valuable and the workload doesn't require functionality incompatible with the rootless model.

11. Putting the Layers Together

Now the individual controls start making more sense.

Instead of simply:

docker run nginx

a more restricted workload might look conceptually like:

docker run \
  --read-only \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt no-new-privileges=true \
  --memory=512m \
  --cpus=1.0 \
  nginx

Not every application will work with exactly this configuration.

And that's actually the important part.

Hardening forces you to ask:

What does this application actually need?

Instead of:

"What can I give it so it definitely works?"

Those are very different security mindsets.

A practical review might ask:

Can the application run as a non-root user?
Can Docker itself run rootless?
Which capabilities does the workload actually require?
Can no-new-privileges be enabled?
Can the root filesystem be read-only?
Is seccomp protection active?
Is AppArmor or SELinux available?
Is Docker socket access tightly controlled?
Are resource limits configured?
Is --privileged being avoided unless there is a specific requirement?

The goal isn't to enable every option blindly.

It's to understand why each privilege exists.

Final Thought

Docker security becomes easier to understand when you stop thinking of root as one universal identity.

There is:

The user running Docker
The Docker daemon
The process inside the container
The user namespace
The host kernel

Those identities and privilege boundaries interact.

That's why:

Root inside a container doesn't automatically mean root on the host.

And it's why Rootless Docker matters.

But Rootless Docker is only one part of the larger idea.

Capabilities reduce what a process can do.

no-new-privileges limits privilege escalation.

Read-only filesystems reduce what can be changed.

seccomp reduces unnecessary kernel access.

AppArmor and SELinux add additional policy boundaries.

User namespaces change what identities mean outside the container.

The strongest container isn't necessarily the one with the most security features enabled.

It's the one that has only the privileges it actually needs.

Question for You

If your application works perfectly with fewer privileges, what reason is there to give it more?

Have you tried Rootless Docker in a development or production environment?

Docker in Production: What Changes When Containers Meet Reality?

Sreekanth Kuruba — Wed, 26 Aug 2026 12:25:33 +0000

post 8:

You run a container.

It starts successfully.

The application works.

So… is it production-ready?

Not necessarily.

The real test of a production container isn't what happens when everything works.

It's what happens when something goes wrong.

What happens when the application consumes all available memory?

What happens when the process crashes?

What happens when the application is running, but isn't actually healthy?

Where do the logs go?

How do you know something is wrong before users tell you?

And when the container fails, how do you find the actual cause?

Running Docker in production isn't just about starting containers.

It's about making them reliable, observable, manageable, and recoverable.

1. Production Starts With Boundaries

A container that works perfectly on a developer's laptop can behave very differently under production load.

Development often prioritizes:

Speed
Convenience
Easy debugging
Frequent changes

Production prioritizes:

Reliability
Predictability
Security
Observability
Recovery

One of the first production questions is:

What happens if this container consumes more resources than expected?

That's where resource limits come in.

2. Resource Limits – Don't Let One Container Consume Everything

Without appropriate resource limits, a container can consume more host resources than intended.

For example:

docker run \
  --memory=512m \
  --cpus=1.0 \
  nginx

This limits the container to:

512 MB memory
1 CPU

Why does this matter?

Imagine one application suddenly starts consuming several gigabytes of memory.

Without appropriate limits, it could affect other workloads running on the same host.

Resource limits create boundaries between workloads.

But remember:

A resource limit doesn't fix a memory leak.

It only limits how much damage that container can cause to the host.

So now we have another question:

What if the container is running, but the application inside it is broken?

3. Health Checks – Running Doesn't Mean Healthy

One of the most important production concepts is the difference between:

Container is running

and

Application is healthy.

A container can be running while the application inside is:

Hung
Unable to connect to a database
Returning errors
Failing internal checks

Docker supports health checks.

For example:

HEALTHCHECK --interval=30s --timeout=5s \
  CMD curl -f http://localhost:8080/health || exit 1

Now Docker can track the application's health status.

The important idea is:

Process alive ≠ application healthy

A health check only reports the container's health status. Docker does not automatically restart a container simply because it becomes unhealthy.

An orchestrator or external health-monitoring tool is needed to take further action.

Health vs. Recovery

Situation	What happens
Process exits	A restart policy can restart the container
Health check becomes `unhealthy`	Docker reports the status; it doesn't automatically restart the container
Container repeatedly crashes	A restart policy may keep retrying
Application is unhealthy but still running	Monitoring or orchestration is needed to take further action

So what happens when the application actually crashes and exits?

That's where restart policies come in.

4. Restart Policies – What Happens After a Crash?

Applications crash.

Processes exit unexpectedly.

Production systems need a recovery strategy.

Docker provides restart policies such as:

docker run --restart=unless-stopped nginx

Common policies include:

no
on-failure
always
unless-stopped

For example:

--restart=on-failure

tells Docker to restart the container when it exits with a failure.

Notice the distinction:

Health check → reports health

Restart policy → reacts to container exits

A restart policy doesn't automatically fix an application that is alive but unhealthy.

And if an application crashes repeatedly, restarting it doesn't solve the underlying problem.

It simply keeps trying to recover.

Recovery and diagnosis are two different problems.

Which leads to another question:

When something fails, where is the evidence?

5. Logging – Keep the Evidence

When something fails in production, logs are often your first source of evidence.

Docker captures container output from:

stdout
stderr

You can inspect it with:

docker logs <container>

Follow logs in real time:

docker logs -f <container>

And limit the output:

docker logs --tail 100 <container>

But don't treat docker logs as your complete production logging strategy.

Docker's default json-file logging driver can grow over time and consume host disk space if log rotation isn't configured.

Production environments should consider log rotation using options such as:

max-size
max-file

For high-volume applications, a non-blocking logging mode can also help prevent logging from affecting application performance.

Larger environments may also send logs to a centralized logging system for:

Log retention
Search and filtering
Centralized access
Alerting

Logs are your first witness. Treat them like evidence, not decoration.

They tell you what happened. But what if you want to know what is happening right now?

6. Monitoring – Know Before Users Tell You

Logs tell you what happened.

Metrics help you understand what is happening.

At minimum, monitor things such as:

CPU usage
Memory usage
Network activity
Container restarts
Disk usage
Application response time
Error rates

Docker provides a simple starting point:

docker stats

This gives you a live view of container resource consumption.

But production monitoring usually goes further.

You want to know:

Is the application healthy before customers start reporting that it is broken?

That's where metrics, dashboards, and alerts become important.

But even with monitoring, failures will happen.

The next skill is knowing how to investigate them.

7. Troubleshooting – Don't Just Restart Everything

When a container isn't working, don't randomly restart everything.

Use a systematic approach.

Step 1: Check the container status

docker ps -a

Look for:

Exited containers
Restarting containers
Unexpectedly stopped services

Step 2: Check the logs

docker logs <container>

Look for:

Application errors
Configuration problems
Connection failures
Permission issues

Step 3: Inspect the container

docker inspect <container>

Check:

Environment variables
Mounts
Networks
Restart policies
Health status

Step 4: Check resource usage

docker stats

Look for:

High CPU
High memory
Unusual resource consumption

Step 5: Check networking

If the application cannot reach another service, verify:

Network configuration
Service/container name
Ports
DNS resolution
Connectivity between containers

Step 6: Check the image

Sometimes the problem isn't the container.

It's the image.

Check:

Image version
Recent changes
Application dependencies
Base image updates

The goal is to move from:

“The container isn't working.”

to:

“This specific component is failing for this specific reason.”

8. Image Versions – Know What You're Running

Consider:

FROM nginx:latest

It looks convenient.

But latest can change over time.

The same Dockerfile may produce different results later because the underlying image changed.

Using a known version gives you more predictable deployments:

FROM nginx:1.29

Production environments can go even further by using carefully controlled image versions or immutable image references.

The principle is simple:

Know exactly what you're deploying.

9. Smaller Images – Reduce What You Ship

Production images should contain only what the application needs.

Smaller images can provide:

Faster image pulls
Faster deployments
Smaller attack surface
Less unnecessary software

Multi-stage builds can help.

For example:

FROM node:22 AS build

WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

The build environment doesn't need to be included in the final runtime image.

This separates:

Build environment

from

Runtime environment

10. Make Containers Replaceable

Here's another important production mindset:

Containers should be replaceable, not precious.

Don't rely on manually changing files inside a running container as a permanent fix.

For example:

docker exec -it <container> bash

can be useful for troubleshooting.

But manually editing application files inside the container creates a change that disappears when the container is replaced.

Instead:

Change the configuration or code
Build a new image
Test it
Deploy the new version
Replace the old container

This makes deployments predictable and repeatable.

And this raises another important question:

What happens to data when the container disappears?

11. Separate Application Lifecycle From Data Lifecycle

Containers are usually treated as disposable.

Application data may not be.

For example:

Database data
Uploaded files
Application-generated persistent data

That's where Docker volumes or external storage come in.

The container can be replaced while the data remains.

This separation is important:

Application lifecycle ≠ Data lifecycle

The application can change.

The container can disappear.

The data should survive when it needs to.

12. Security Still Matters

Production reliability doesn't replace security.

The security principles from the previous article still apply:

Don't run applications as root when unnecessary
Avoid --privileged
Use appropriate capabilities
Keep images updated
Use seccomp and other security controls
Scan images
Limit container resources

A production container isn't secure simply because it is running.

Reliability, security, and observability have to work together.

13. A Practical Production Checklist

Before running a container in production, ask:

[ ] Is the image version controlled?
[ ] Is the container running as a non-root user where possible?
[ ] Are CPU and memory limits defined?
[ ] Is a health check configured?
[ ] Is an appropriate restart policy configured?
[ ] Is log rotation configured?
[ ] Are important metrics being monitored?
[ ] Are alerts configured for critical failures?
[ ] Is persistent data stored outside the container filesystem?
[ ] Can the container be safely replaced?
[ ] Is the image regularly updated and scanned?
[ ] Is there a documented troubleshooting process?

You don't need every advanced platform feature on day one.

But you should know what happens when something goes wrong.

Summary

Running Docker in production isn't simply:

docker run

It's about designing for what happens after the container starts.

You need to think about:

Resources → How much can the container consume?
Health → Is the application actually working?
Recovery → What happens when it crashes?
Logs → Where is the evidence?
Monitoring → How do we know something is wrong?
Troubleshooting → How do we find the cause?
Images → Do we know exactly what we're deploying?
Data → What survives when the container disappears?
Security → What privileges does the workload actually need?

A container that runs successfully is only the beginning.

Production readiness starts when you ask what happens when things go wrong.

Question for You

What's the first thing you check when a Docker container fails in production — logs, resources, health status, or something else?

Next Topic

Rootless Docker & Advanced Security: Running Containers With Fewer Privileges

Think `docker compose up` just starts containers? There’s more happening behind the scenes. And one common assumption about `depends_on` can cause real problems. I break down what Compose actually does—and what it doesn’t.

Sreekanth Kuruba — Tue, 18 Aug 2026 08:10:23 +0000

Sreekanth Kuruba

Aug 18

Docker Compose Isn't What I Thought It Was

#docker #devops #containerization #cloudnative

3 min read

Docker Compose Isn't What I Thought It Was

Sreekanth Kuruba — Tue, 18 Aug 2026 03:21:36 +0000

post 7:

A practical guide to understanding Docker Compose—what it is, how it works, and the misconceptions that catch most beginners.

You've mastered single containers.

Now it's time to build a real application.

A frontend.
A backend.
A database.
A Redis cache.

Suddenly you're juggling multiple docker run commands.

Ports.
Networks.
Volumes.
Environment variables.

Chaos.

Then someone says:

"Just use Docker Compose."

It works beautifully.

But here's the twist most people never realize…

Why Docker Compose Exists

Imagine starting an application like this:

Frontend
Backend
PostgreSQL
Redis

Running each container manually quickly becomes repetitive and error-prone.

Docker Compose lets you describe your entire application in a single YAML file and start everything with one command.

Instead of remembering dozens of commands, you define your infrastructure once.

What Docker Compose Actually Is

Docker Compose is not a container orchestrator.

Docker Compose is a tool that reads your Compose YAML file and uses the Docker Engine to create and manage the resources defined in it.”

Modern Docker uses Compose V2, which runs as:

docker compose

instead of the older:

docker-compose

Compose runs only when you execute a command.

It creates the required Docker resources, starts the containers, and then exits.

This makes it ideal for development, testing, and single-host deployments, but it doesn't provide orchestration features like automatic scheduling, self-healing, or multi-node management.

A Simple docker-compose.yml

services:
  web:
    build: .
    ports:
      - "8080:80"
    environment:
      - DB_HOST=db
    depends_on:
      - db

  db:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:alpine

volumes:
  postgres_data:

YAML Quick Reference

Key	Purpose
services	Defines containers (web, db, redis)
build	Builds an image from a Dockerfile
image	Uses an existing image from a registry
ports	Maps host ports to container ports
environment	Sets environment variables
depends_on	Controls startup order
volumes	Stores persistent data

What Happens When You Run docker compose up?

docker-compose.yml
        ↓
Compose reads the YAML
        ↓
Creates networks
        ↓
Creates volumes
        ↓
Builds images (if needed)
        ↓
Starts containers
        ↓
Application is running

One command replaces many manual docker run commands.

Modern Compose Features

1. Profiles

Profiles let you enable optional services only when needed.

For example, if your Compose file has a service assigned to the cache profile:

redis:
  image: redis:alpine
  profiles:
    - cache

You can start it with:

docker compose --profile cache up

Useful for:

Development-only services
Optional tools
Testing environments

2. Watch (Compose V2)

develop:
  watch:
    - action: sync
      path: ./src
      target: /app/src

Run:

docker compose watch

Compose automatically syncs file changes without rebuilding the container.

(Available in recent Docker Compose V2 releases.)

The Biggest Gotcha

Many beginners believe this:

depends_on:
  - db

means

"The database is ready."

It doesn't.

It only means

"The database container has started."

The application inside may still be initializing.

A better approach is to combine startup ordering with health checks or design your application to retry connections until dependencies are available.

Common Expectations vs Reality

Expectation	Reality
Compose is a production orchestrator	It's primarily a development and single-host deployment tool
`depends_on` waits for the application	It only waits for the container to start
Automatic scaling	Manual
Self-healing	Not provided
Multi-node orchestration	Not supported
Hot reload	Supported with `docker compose watch` (Compose V2)

Simple Mental Model

Think of Docker Compose as a project manager.

Instead of starting every container one by one, Compose reads a blueprint and launches everything in the correct configuration.

It doesn't replace Docker.

It simply coordinates Docker for you.

Summary

In this guide you learned:

Why Docker Compose exists
What Compose actually is
Compose V2 vs the old Compose V1
Understanding services, build, image, ports, environment, depends_on, profiles, networks, and volumes
What happens during docker compose up
Modern features like Profiles and Watch
Common misconceptions about Compose

Why This Matters

Docker Compose is one of the most valuable tools for local development.

It lets developers spin up complete applications with a single command, making multi-container development simple and repeatable.

As applications grow across multiple servers and require features like automatic scaling, self-healing, and high availability, orchestration platforms such as Kubernetes become the next step.

Question for You

What's the biggest misconception you had about Docker Compose?

Or what's one feature you wish you had discovered sooner?

Docker Security Internals: How Safe Are Your Containers Really?

Sreekanth Kuruba — Tue, 11 Aug 2026 07:27:40 +0000

post 6:

You run containers every day.

But have you ever asked yourself this uncomfortable question:

If one container gets compromised… can it break out and take down the entire host?

Most people assume containers are “secure by default.”

They’re not.

They’re isolated by default — and isolation is not the same as security.

This post explains how Docker security actually works under the hood, what the real risks are, and how to harden your containers properly.

1. The Foundation: Linux Kernel Features

Docker doesn’t invent its own security model.

It relies heavily on existing Linux kernel features:

Namespaces → Isolation of processes, network, filesystem, and more
cgroups → Resource limits for CPU, memory, and I/O
Capabilities → Fine-grained control over root privileges
seccomp → Filtering of potentially dangerous system calls
AppArmor / SELinux → Mandatory Access Control

Understanding these layers is the key to understanding container security.

2. Namespaces – Isolation, Not Security

Namespaces give each container its own private view of the system.

For example:

PID namespace → Container processes are isolated from host processes
Network namespace → Container gets its own network stack
Mount namespace → Container gets its own filesystem view
User namespace → Container users can be mapped to unprivileged users on the host

This isolation is powerful — but it isn't perfect.

All containers still share the same Linux kernel.

That means a serious kernel vulnerability could potentially affect the host and other containers.

Namespaces provide isolation, not complete security.

3. cgroups – Preventing Resource Exhaustion

Namespaces control what a container can see.

cgroups control how much of the host's resources it can consume.

Without resource limits, a single container could potentially:

Consume excessive CPU
Exhaust available memory
Generate excessive disk I/O

For example:

docker run --memory=512m --cpus=1.0 nginx

Here:

--memory=512m limits memory usage
--cpus=1.0 limits CPU usage

This helps prevent one container from consuming an unreasonable amount of the host's resources.

4. The Root Problem – Still Real

By default, many containers run as root (UID 0) inside the container.

However, Docker starts containers with a reduced set of Linux capabilities, limiting what that root process can do.

This significantly reduces the attack surface.

But container root is still something to take seriously.

If an application is compromised and has excessive privileges, combined with a kernel or runtime vulnerability, an attacker could potentially attempt a container escape.

A good practice is to run applications as a non-root user whenever possible.

For example, in a Dockerfile:

FROM nginx:alpine

USER 1000

Also avoid using:

--privileged

unless there is a specific, well-understood requirement.

The --privileged option grants a container significantly more access to the host and disables or weakens several isolation protections.

5. seccomp – Blocking Dangerous System Calls

seccomp (Secure Computing Mode) is another important Docker security layer.

Applications interact with the Linux kernel through system calls.

A compromised application could potentially try to use unusual or dangerous system calls to interact with the kernel.

Docker provides a default seccomp profile that blocks many system calls that containers typically don't need.

You can also apply a custom, stricter profile:

docker run \
  --security-opt seccomp=/path/to/custom-profile.json \
  nginx

This can further reduce the container's attack surface.

The key idea is simple:

If an application doesn't need a system call, don't give it access to that system call.

6. Rootless Docker – Reducing Host-Level Risk

Traditional Docker deployments commonly use a Docker daemon that requires root privileges.

This creates an important security consideration because access to the Docker daemon can provide powerful control over containers and, depending on configuration, the host.

Rootless Docker allows the Docker daemon and containers to operate without requiring root privileges.

Container root can be mapped to an unprivileged user on the host.

This reduces the potential impact of certain container or daemon compromises.

Rootless Docker is particularly useful in environments where reducing host-level privileges is important, although it can have some feature and compatibility limitations.

7. Practical Docker Hardening Checklist

Here are some practical steps you can apply:

Run containers as a non-root user whenever possible
Use official and regularly updated base images
Enable Rootless Docker when it fits your environment
Use --read-only for the container filesystem when the application allows it
Set resource limits such as --memory and --cpus
Keep Docker's default seccomp profile unless you have a reason to change it
Use AppArmor or SELinux where appropriate
Scan images regularly with tools such as Trivy or Docker Scout
Avoid --privileged unless there is a specific requirement
Keep Docker Engine and container images updated

Security is not achieved by using just one of these controls.

It comes from multiple layers working together.

Summary

Docker security is not magic.

It is a combination of multiple Linux and Docker security mechanisms:

Namespaces → Process and resource isolation
cgroups → Resource control
Capabilities → Privilege reduction
seccomp → System call filtering
AppArmor / SELinux → Mandatory Access Control
Rootless Docker → Reduced host-level privileges

Default Docker settings provide a useful level of isolation, but production environments often require deliberate security hardening.

The important thing to remember is:

Containers are isolated, but isolation alone does not make them secure.

Understanding what happens underneath Docker helps you move from:

“It works.”

“It works — and it’s properly secured.”

Next Topic

Docker Compose Internals – How It Orchestrates Multi-Container Applications

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

Sreekanth Kuruba — Tue, 04 Aug 2026 06:18:32 +0000

Most Linux problems aren't actually difficult.

They're difficult because they're often debugged in the wrong order.

Many beginners immediately:

Restart services randomly
Run commands without a plan
Change configurations before understanding the problem
Guess instead of observing

Experienced engineers do something different.

They follow a structured troubleshooting process.

This article isn't about learning new Linux commands.

It's about knowing when and why to use the commands you've already learned throughout this Linux Beginner Series.

Think of it as putting everything together into one practical troubleshooting workflow that's used in real Linux and DevOps environments.

Quick Troubleshooting Workflow

Observe
   ↓
Check System Health
   ↓
Identify Problem Type
   ↓
Read Logs
   ↓
Verify Service
   ↓
Check Network
   ↓
Check Disk
   ↓
Recent Changes
   ↓
Find the Root Cause
   ↓
Apply the Fix

Keep this workflow in mind as you read through the guide.

Step 0: Observe Before You Change Anything

Before running a single command, pause for a moment.

Ask yourself:

What exactly is broken?
When did the issue start?
Is everyone affected or only some users?
Is the problem constant or intermittent?
What changed recently?

Many troubleshooting sessions become longer because people try to fix the problem before they understand it.

Good troubleshooting begins with observation, not commands.

Step 1: Check Overall System Health

Your first goal is to understand the overall health of the system—not to fix anything yet.

Useful commands:

uptime
free -h
top

Look for:

High load average
High CPU usage
Low available memory
Signs that the server is under heavy load

At this stage, you're only gathering evidence.

A quick system health check often tells you where to investigate next.

Step 2: Identify the Type of Problem

Before diving deeper, classify the issue.

Problem Type	Common Symptoms	First Commands to Check
CPU	Slow system, high CPU usage	`top`, `htop`
Memory	Applications crashing, OOM kills	`free -h`
Disk	"No space left on device"	`df -h`, `du -sh`
Network	Connection failures	`ping`, `curl`, `ip a`
Service	Service unavailable	`systemctl status`
Application	Errors or exceptions	Application logs

Classification narrows your investigation instead of jumping between unrelated commands.

A well-classified problem is already half solved.

Step 3: Read the Logs

Logs are usually the most reliable source of information during troubleshooting.

System logs:

journalctl -xe

Specific service:

journalctl -u nginx

Traditional log files:

tail -f /var/log/nginx/error.log

Search for errors:

grep -i error /var/log/syslog

For large log files, use less to navigate comfortably instead of opening the entire file at once.

💡 Tip: Replace nginx with the service you're troubleshooting, such as sshd, docker, or apache2.

Logs often tell you what failed.

Your job is to discover why it failed.

Step 4: Verify the Service

Never assume a service is healthy just because the application isn't responding.

Check the service status:

systemctl status nginx

Verify the running process:

ps aux | grep nginx

A service can be running while still failing to serve requests correctly.

For example:

The process may be running.
The application may have failed during startup.
The service may be unable to connect to its database.
Configuration errors may prevent it from serving requests.

Always verify the service before moving on to other areas.

Step 5: Check the Network

If the service looks healthy, verify connectivity.

Useful commands:

ping <host>
curl -I http://localhost:8080
ip a
ss -tuln

These commands help answer questions like:

Can the server reach other systems?
Is the application listening on the expected port?
Is the network interface configured correctly?

Many "application issues" are actually network or DNS problems.

Step 6: Check Disk Space and Inodes

Disk-related problems are among the most common causes of Linux issues.

Check disk usage:

df -h

Check inode usage:

df -i

Find large directories:

du -sh /* 2>/dev/null | sort -hr

A full disk—or exhausted inodes—can prevent applications from:

Writing log files
Creating temporary files
Saving uploaded data
Starting correctly

Even if CPU and memory look healthy, disk issues can bring an application down.

Step 7: Look for Recent Changes

Many production issues are caused by something that recently changed.

Review recent logs:

journalctl --since "1 hour ago"

Check recent logins:

last -10

Ask yourself:

Was there a recent deployment?
Was a configuration changed?
Was a package updated?
Did anyone restart the service?

If you need to locate a configuration file, use tools like find or whereis.

Before making major configuration changes, consider creating a backup with tar so you can easily restore the original if needed.

Looking for recent changes often shortens the investigation dramatically.

Step 8: Find the Root Cause, Not Just the Symptom

Finding an error doesn't always mean you've found the real problem.

For example:

A web application crashes.

The logs show write failures.

You check the disk.

The disk is full.

The application wasn't the real problem.

The full disk was.

Always ask yourself:

"Is this the root cause, or just another symptom?"

This habit separates troubleshooting from guessing.

A Simple Troubleshooting Workflow

Whenever something breaks, follow the same sequence:

Observe the problem
        ↓
Check system health
        ↓
Identify the problem type
        ↓
Read the logs
        ↓
Verify the service
        ↓
Check the network
        ↓
Check disk space
        ↓
Look for recent changes
        ↓
Find the root cause
        ↓
Apply the fix

Following the same workflow every time reduces guesswork and speeds up troubleshooting.

A Real-World Example

Imagine a user reports:

"The website is down."

Instead of restarting Nginx immediately:

Check whether the service is running.
Read the service logs.
Notice repeated "No space left on device" errors.
Run:

df -h

Discover the disk is full.
Free up disk space.
Restart the service if necessary.

The restart wasn't the solution. Finding the root cause was.

Common Beginner Mistakes

Avoid these habits:

Restarting services without checking logs
Ignoring CPU, memory, or disk usage
Running random commands without a plan
Assuming the first error is the real cause
Skipping recent changes

Good troubleshooting isn't about memorizing commands.

It's about following a consistent process.

Final Thoughts

Linux troubleshooting isn't about knowing hundreds of commands.

It's about asking the right questions in the right order.

Commands help you collect evidence.

A structured process helps you solve the problem.

The faster you narrow down the problem, the faster you'll reach the root cause.

That's the mindset experienced engineers develop over time.

Start with a simple process.

Practice it consistently.

You'll spend less time guessing and more time solving problems.

Congratulations!

If you've followed this Linux Beginner Series from the beginning, you've built a solid foundation in:

Linux basics
Filesystem structure
Users & Permissions
Processes
Disk usage
Networking
Logs
Package management
Finding files & text
Viewing files efficiently
File compression
Troubleshooting workflow

That's no longer just a collection of Linux commands.

It's a practical foundation for understanding how Linux systems work and how to troubleshoot them with confidence.

Remember:

Good engineers don't memorize every command.

They know how to investigate problems, gather evidence, and find the root cause.

The best way to improve at troubleshooting is simple:

Break things in a safe environment.
Fix them.
Learn from them.

That's where real learning happens.

Thank you for following this Linux Beginner Series!

Your Turn

What's one Linux troubleshooting lesson you learned the hard way?

Share your experience in the comments—your story might help another beginner avoid the same mistake.

Happy learning!

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Sreekanth Kuruba — Thu, 30 Jul 2026 06:44:14 +0000

Working with files in Linux isn't just about creating and editing them.

Sometimes you need to:

Archive multiple files into one
Compress files to save disk space
Share files with others
Create backups

Linux provides several tools for this, each with a different purpose.

Let's simplify them.

What is File Compression?

File compression reduces the size of a file.

Benefits:

Saves disk space
Faster file transfers
Easier backups
Reduces bandwidth usage

Example:

A 100 MB log file might become a much smaller compressed file, depending on its contents.

Archive vs Compression

Many beginners think they're the same.

They are not.

Archive

Combines multiple files into a single file.

Example:

photos/
docs/
notes.txt

↓

backup.tar

Compression

Reduces the size of a file.

Example:

backup.tar

↓

backup.tar.gz

👉 tar archives files. gzip compresses them.

1. Create an Archive with tar

tar -cvf backup.tar Documents/    #Create an archive
tar -tvf backup.tar               #View archive contents
tar -xvf backup.tar               #Extract an archive

Options:

c → Create
v → Verbose (show progress)
f → File name
x → Extract

Best for:

Backups
Bundling multiple files
Moving folders

2. Compress with gzip

Compress a file:

gzip file.txt          # Creates file.txt.gz
# Result
file.txt.gz
gunzip file.txt.gz     # decompress
gzip -k file.txt       # Keep original file

Best for:

Log files
Large text files
Saving disk space

3. Archive and Compress Together

Most common command:

# Create compressed archive
tar -czvf backup.tar.gz Documents/
# Extract
tar -xzvf backup.tar.gz

Options:

z → Use gzip compression

👉 This is one of the most common backup commands in Linux.

4. Working with ZIP Files

# Create ZIP
zip -r project.zip project/
# Extract
unzip project.zip
# List contents
unzip -l project.zip

Best for:

Sharing files with Windows users
Cross-platform compatibility

5. Compare the Tools

Tool	Purpose	Best For
`tar`	Archive files	Backups
`gzip`	Compress files	Saving space
`tar + gzip`	Archive and compress	Linux backups
`zip`	Archive and compress	Sharing files across operating systems

Real-World Example

You need to back up a website before making changes.

# Create backup
tar -czvf website-backup.tar.gz /var/www/html
# Restore later if needed
tar -xzvf website-backup.tar.gz

This is a common practice before upgrades, migrations, or configuration changes.

Common Beginner Mistakes

Thinking tar compresses files by itself
Forgetting -z when creating .tar.gz archives
Compressing files that are already compressed (like .jpg or .mp4)
Extracting archives into the wrong directory
Deleting backups before verifying they can be restored

Simple Mental Model

Think of it like packing for a trip:

tar → Put all your clothes into one suitcase.
gzip → Compress the suitcase to make it smaller.
tar.gz → Pack everything into one suitcase and compress it.
zip → A suitcase that's easy to share with almost any operating system.

Summary

In this guide you learned:

What file compression is
Archive vs. compression
Creating archives with tar
Compressing files with gzip
Creating .tar.gz archives
Working with ZIP files
Common beginner mistakes

Why This Matters

File compression is used every day by:

Linux administrators
DevOps engineers
Cloud engineers
Developers

Whether you're creating backups, transferring files, or saving disk space, understanding these tools is an essential Linux skill.

Congratulations!
You’ve now covered the essential Linux fundamentals.

In the next and final post, we’ll combine everything from this series into a practical troubleshooting workflow you can use to diagnose Linux issues with confidence.

Next Post

Linux Troubleshooting Flow for Beginners

Question for You

Which compression format do you use most often: .tar.gz or .zip? And in what situation?

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Sreekanth Kuruba — Tue, 21 Jul 2026 06:38:18 +0000

Introduction

Finding a file is only half the job.

The next step is reading it.

Whether it's a configuration file, a log, or a text document, Linux provides several commands to view files efficiently.

Each command has a different purpose.

Knowing which one to use can save time and make troubleshooting much easier.

Let's simplify them.

Why Not Just Use cat for Everything?

Many beginners learn:

cat filename

Then use it for every file.

It works...

Until the file has 50,000 lines.

Linux provides better tools depending on what you're trying to do.

1. View the Entire File with cat

The cat command displays the complete contents of a file.

Example:

cat config.txt
cat file1.txt file2.txt     # Combine files
cat > notes.txt             # Create new file

Best for:

Small files
Quick checks
Combining files

2. Read Large Files with less

Large files are difficult to read with cat.

Use:

less /var/log/syslog
less /etc/nginx/nginx.conf

Useful shortcuts:

Space → Next page
b → Previous page
/text → Search
q → Quit

Best for:

Configuration files
Large logs
Documentation

3. View the Beginning with head

Sometimes you only need the first few lines.

head file.txt
head -20 file.txt          # First 20 lines

Useful for:

Checking file headers
Previewing files

4. View the End with tail

Need the latest log entries?

tail file.txt
tail -20 file.txt          # Last 20 lines

Perfect for log files.
Checking recent changes.

5. Monitor Files Live with tail -f

One of the most-used Linux troubleshooting commands.

tail -f /var/log/nginx/error.log
tail -f app.log

As new lines are written, they appear instantly.

Stop with:

Ctrl + C

Useful for:

Monitoring logs
Watching application output
Debugging services

6. Count with wc

Want to know how big a file is?

wc file.txt
wc -l file.txt             # Count only lines
wc -w file.txt             # Count words
wc -m file.txt             # Count characters

Useful for:

Scripts
Reports
Log analysis

Real-World Example

An application isn't starting.

First, check the configuration file:

# First, check the configuration file:
less /etc/nginx/nginx.conf

# Monitor the error log:
tail -f /var/log/nginx/error.log

# Need to know how many errors occurred?
grep -i error app.log | wc -l

This is a common workflow when troubleshooting Linux systems.

Common Beginner Mistakes

Using cat for huge files
Forgetting less supports searching
Not using tail -f for live logs
Thinking head and tail only work with 10 lines

Simple Mental Model

Think of these commands like reading a book.

Command	Think of it as...
`cat`	Read the whole book
`less`	Read page by page
`head`	Read the first page
`tail`	Read the last page
`tail -f`	Watch new pages being written
`wc`	Count pages, words, or characters

Summary

In this guide you learned:

cat → View complete files
less → Read large files
head → View the beginning
tail → View the end
tail -f → Monitor files live
wc → Count lines, words, and characters

Why This Matters

Configuration files and logs are everywhere in Linux.

Knowing how to read them efficiently is an essential skill for developers, system administrators, and DevOps engineers.

The right command can save time and make troubleshooting much easier.

Next Post

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Question for You

Which command do you use the most when reading files in Linux?

cat
less
tail
Or something else?

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Sreekanth Kuruba — Tue, 14 Jul 2026 03:03:02 +0000

One of the most common questions Linux beginners ask is:

“Where is this file?”
“How do I find a specific error in logs?”
“Where is this command installed?”

Linux has powerful tools to answer these questions quickly.

In this guide, you’ll learn the most useful search commands.

Finding Files vs Searching Text

These are two different tasks:

Finding files = Locating a file or directory on the system → find
Searching text = Looking for words inside files → grep

1. Find Files with `find`

# Find a specific file
find /home -name "nginx.conf"

# Search entire system (ignore permission errors)
find / -name "*.log" 2>/dev/null

# Find only directories
find . -type d

# Find only files
find . -type f

# Find files larger than 100MB
find / -type f -size +100M 2>/dev/null

Useful for:

Finding configuration files
Locating log files
Finding large files
Searching project directories

Best Tip: Always try to narrow the search path instead of searching from / whenever possible.

2. Search Text Inside Files with `grep`

# Search for a word
grep error app.log

# Case insensitive search
grep -i error app.log

# Search recursively in directory
grep -r "database" /etc/

# Show line numbers
grep -n "listen" nginx.conf

# Count matches
grep -c "failed" auth.log

Useful for:

Searching logs
Finding configuration values
Looking for error messages
Debugging applications

3. Find Executable Location with `which`

which python3
which docker
which nginx

Shows the full path of the command that will be executed.

Useful for:

Finding executable locations
Checking which version of a command Linux will run
Verifying software installation

4. Find Program Files with `whereis`

whereis nginx
whereis python3

It can show:

Binary location
Source files (if available)
Manual pages

Useful when you want to know where a program and its documentation are stored.

Bonus: Fast File Search with `locate`

locate nginx.conf

Much faster than find because it uses a database.

If it doesn't return recent files, Update database:

sudo updatedb

Note: locate may not be installed by default on every Linux distribution.

Real-World Troubleshooting Example

Nginx is not starting.

# Find config file
find /etc -name nginx.conf 2>/dev/null

# Search for errors in logs
grep -i error /var/log/nginx/error.log

# Check executable
which nginx

# See all related files
whereis nginx

This is a common workflow during Linux troubleshooting.

Common Beginner Mistakes

Using find / instead of a specific directory
Forgetting 2>/dev/null when searching the whole system
Confusing find with grep
Not knowing the difference between which and whereis
Forgetting that locate may require an updated database

Simple Mental Model

Command	Use For
`find`	Locate files and directories
`grep`	Search text inside files
`which`	Find executable path
`whereis`	Find program + docs
`locate`	Fast filename search

Summary

In this guide you learned:

How to find files with find
How to search text with grep
How to locate commands with which and whereis
How to perform fast filename searches with locate

Next Post:

Viewing Files in Linux (cat, less, head, tail & wc)

Question for You

Which command do you use most while troubleshooting — find, grep, or something else?

Linux Package Management Explained Simply (apt, dnf, yum & rpm)

Sreekanth Kuruba — Tue, 07 Jul 2026 03:13:00 +0000

Quick Note

In my previous article, I mentioned that Linux Troubleshooting Flow for Beginners would be the final post in this series.

While preparing it, I realized there were a few practical Linux skills every beginner should learn first. These topics will make the troubleshooting guide much easier to understand and follow.

Before we wrap up the series, we'll cover:

Package Management
Finding Files & Text
Viewing Files Efficiently
File Compression

Then we'll bring everything together in the final Linux Troubleshooting Flow for Beginners.

Introduction

Installing software on Linux is very different from Windows.

On Windows, you usually download an .exe installer.

On Linux, software is typically installed and managed using package managers.

This is one of the most practical skills every Linux beginner should learn early.

What is a Package?

A package is a ready-to-install bundle that contains:

The main program
Required libraries
Configuration files
Documentation

Examples: nginx, git, docker, curl, vim

Think of a package as a ready-to-install software box.

What is a Package Manager?

A package manager is a tool that installs, updates, removes, and manages software packages.
Instead of downloading software manually, you simply run a command.

Example:

sudo apt install git

The package manager automatically:

Downloads packages from trusted repositories
Install required dependencies automatically
Upgrade installed software
Removes them cleanly

Instead of manual downloading, you just run one command.

Why Use a Package Manager?

Without package managers, you would have to:

Search for software manually
Download files from websites
Install dependencies yourself
Update each application separately

Package managers automate all of this.

What is a Repository?

Package managers download software from repositories.

A repository is a trusted online collection of software packages maintained by your Linux distribution.

Instead of downloading software from random websites, Linux installs it securely from these repositories.

Common Package Managers

Distribution	Package Manager	Low-level Tool
Ubuntu / Debian	`apt`	`dpkg`
Fedora / RHEL / Rocky	`dnf`	`rpm`
Older RHEL / CentOS	`yum`	`rpm`

Most Ubuntu users will use apt, while Fedora and modern RHEL-based systems use dnf.

Most Useful Commands

1. Update Package List

Before installing software, update the package list.

sudo apt update          # Ubuntu/Debian
sudo dnf check-update    # Fedora/RHEL

Note: apt update does not upgrade installed packages.

2. Upgrade Installed Packages

sudo apt upgrade   #Ubuntu/Debian
sudo dnf upgrade   #Fedora/RHEL

Installs the latest available versions of your installed packages.

3. Install a Package

sudo apt install nginx   #Ubuntu/Debian
sudo dnf install nginx   #Fedora/RHEL

Example packages:

sudo apt install git
sudo apt install curl
sudo apt install vim

4. Remove a Package

sudo apt remove nginx    #Ubuntu/Debian
# Remove package and configuration files
sudo apt purge nginx     
sudo dnf remove nginx    #Fedora/RHEL

5. Search for Packages

apt search docker    #Ubuntu/Debian
dnf search docker    #Fedora/RHEL

Useful when you're unsure of the exact package name.

6. View Package Information

apt show nginx    #Ubuntu/Debian
dnf info nginx    #Fedora/RHEL

Shows details such as:

Version
Description
Dependencies
Package size

7. List Installed Packages

apt list --installed   #Ubuntu/Debian
dnf list installed     #Fedora/RHEL

Useful for verifying whether software is already installed.

Low-Level Tool: rpm

The rpm command works directly with RPM package files.

rpm -q nginx          # Check if installed
rpm -qi nginx         # Detailed info

Usually you don't need to use rpm directly. On RPM-based systems, dnf handles package installation and dependencies for you.

Common Beginner Mistakes

Running apt upgrade without apt update first
Confusing apt update with apt upgrade
Installing software from random websites instead of official repositories
Forgetting to use sudo
Removing important system packages

Simple Mental Model

Think of a package manager like an App Store for Linux:

Package = App
Repository = App Store
Package Manager = Installer + Updater

Summary

In this guide you learned:

What packages and package managers are
Basic package management commands using apt and dnf
Basic package management commands
Common mistakes to avoid

Why This Matters

Package management is a daily task for:

Linux administrators
DevOps engineers
Cloud engineers
Developers

If you know how to manage packages, setting up and maintaining Linux systems becomes much easier.

Next Post:

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

DEV Community: Sreekanth Kuruba

Inside Kubernetes Service Networking: Follow a Packet from ClusterIP to Pod

1. Start with a Simple Service

2. What Happens Behind the Scenes?

3. Follow the Packet: From ClusterIP to Pod

Step 1: The client sends a request

Step 2: Networking rules select a backend

Step 3: DNAT changes the destination

Step 4: The packet reaches the backend Pod

4. What Happens to the Response?

5. What Happens When a Pod Is Replaced?

6. Does Every Cluster Use iptables?

7. Troubleshoot Service Traffic Step by Step

Step 1: Check the Service

Step 2: Check the Pods and labels

Step 3: Check EndpointSlices

Step 4: Test the backend directly

Step 5: Test through the Service

Step 6: Inspect the networking rules

8. Key Takeaways

From Docker to Kubernetes: When Docker Stops Being Enough

1. Start With One Container

2. When One Server Becomes Ten

3. This Is Where Kubernetes Enters

4. Kubernetes Changes the Question

5. What Happens When Things Fail?

6. From Containers to Scheduled Pods

7. Scaling Creates Another Problem

8. Replaceable Pods Need Stable Networking

9. Docker Concepts Don't Disappear

Liveness Probe

Readiness Probe

Startup Probe

10. Updating One Container Is Easy. Updating Fifty Isn't.

11. Kubernetes Didn't Simply Replace Docker

12. So When Does Docker Stop Being Enough?

The Journey From docker run

Question for You

Rootless Docker & Advanced Security: Which Root Are We Actually Talking About?

1. Why Docker Has So Much Power

2. The Docker Socket Is a Security Boundary

3. Container Root ≠ Host Root

4. So What Is Rootless Docker?

5. Rootful vs Rootless: What Actually Changes?

6. Rootless Is Only One Security Layer

7. Reduce What the Container Can Do

8. Reduce What the Container Can Change

9. Reduce What the Container Can Reach

seccomp

AppArmor and SELinux

10. Where Rootless Docker Doesn't Fit

11. Putting the Layers Together

Final Thought

Question for You

Docker in Production: What Changes When Containers Meet Reality?

Health vs. Recovery

Step 1: Check the container status

Step 2: Check the logs

Step 3: Inspect the container

Step 4: Check resource usage

Step 5: Check networking

Step 6: Check the image

Think `docker compose up` just starts containers? There’s more happening behind the scenes. And one common assumption about `depends_on` can cause real problems. I break down what Compose actually does—and what it doesn’t.

Docker Compose Isn't What I Thought It Was

Docker Compose Isn't What I Thought It Was

Docker Security Internals: How Safe Are Your Containers Really?

1. The Foundation: Linux Kernel Features

2. Namespaces – Isolation, Not Security

3. cgroups – Preventing Resource Exhaustion

4. The Root Problem – Still Real

5. seccomp – Blocking Dangerous System Calls

6. Rootless Docker – Reducing Host-Level Risk

7. Practical Docker Hardening Checklist

Summary

Next Topic

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Finding Files vs Searching Text

The Journey From `docker run`

1. Find Files with `find`

2. Search Text Inside Files with `grep`

3. Find Executable Location with `which`

4. Find Program Files with `whereis`

Bonus: Fast File Search with `locate`