Kubernetes networking and storage architecture answers two separate production questions: how traffic reaches a workload and what data survives when Pods are replaced.
For a small team, the cleanest design is to keep these layers explicit. Raff Technologies uses the same separation in its managed Kubernetes platform: worker nodes live on private networking, public traffic enters through a managed endpoint and Kubernetes traffic-routing resources, while stateful workloads use storage independently from an individual Pod's lifecycle.
The architecture can be summarized as:
Traffic path Client → Gateway / Ingress / LoadBalancer → Service → Pod State path Pod → PVC → PV → StorageClass / storage backend → backup / recovery
A Service gives changing Pods a stable network identity. Gateway API or Ingress controls external application traffic. NetworkPolicy restricts allowed Pod traffic when the cluster network implementation enforces it. PersistentVolumes and StorageClasses provide durable mounted storage, while backups solve a different problem: recovery after deletion, corruption, or larger failure.
This guide owns the architecture boundary between those systems. For implementation details, continue to the dedicated guides on Kubernetes Services, Ingress, and Load Balancers, Kubernetes DNS and Service Discovery Troubleshooting, Kubernetes Network Policies, and Kubernetes Persistent Storage.
Kubernetes networking has five distinct layers
Treating "Kubernetes networking" as one feature makes production troubleshooting harder. A more useful model separates five responsibilities.
| Layer | Primary responsibility | Typical Kubernetes/cloud object |
|---|---|---|
| Pod network | Pod-to-Pod reachability | CNI / cluster network |
| Service discovery | Stable identity for changing Pods | Service + EndpointSlice + DNS |
| External traffic entry | Bring traffic into Services | Gateway API, Ingress, Service type LoadBalancer |
| Workload segmentation | Restrict allowed traffic | NetworkPolicy |
| Infrastructure boundary | Keep nodes and adjacent cloud resources private | VPC, firewall |
The layers cooperate, but they are not substitutes for one another.
A private VPC does not automatically prevent every Pod from talking to every other Pod. A NetworkPolicy does not replace an infrastructure firewall. An Ingress does not replace Service discovery. A Service does not automatically make the application public.
The architecture becomes easier to review when every application dependency can be mapped to one of these layers.
Pod networking is the cluster reachability layer
Each Kubernetes Pod receives its own network identity inside the cluster. Containers in the same Pod share a network namespace and can communicate over localhost; communication between Pods is provided by the cluster network implementation.
A simplified internal path looks like this:
Pod A ↓ cluster network ↓ Pod B
The application should not depend on individual Pod IP addresses being permanent. Pods are replaceable. They can be recreated after a deployment, node failure, rescheduling event, or scaling action.
That is why production applications normally depend on Services, not on Pod addresses.
For teams operating several nodes, this distinction also separates the cloud network from the Kubernetes network. The VPC carries node and infrastructure connectivity; the Kubernetes network provides workload-level reachability on top of that infrastructure.
Services provide stable workload identity
A Kubernetes Service gives clients a stable way to reach a changing group of Pods.
Conceptually:
Client workload ↓ Service ↓ EndpointSlices ↙ ↘ Pod A Pod B
The Service remains stable while backend Pods can change.
Use a Service when:
- an API must be reachable by several other workloads;
- a deployment can have multiple replicas;
- Pods may be rescheduled between nodes;
- DNS-based discovery is preferable to hard-coded addresses.
A Service is therefore part of service discovery and traffic distribution, not persistent state.
For the detailed differences between ClusterIP, NodePort, LoadBalancer, and application-routing layers, use Kubernetes Services Explained: Ingress and Load Balancers.
Gateway API is the forward-looking application traffic model
For HTTP, HTTPS, gRPC, and other routed application traffic, Kubernetes now has two important API families: Ingress and Gateway API.
Ingress remains stable and widely deployed, but the Kubernetes project has frozen the Ingress API and recommends Gateway API for new functionality. Gateway API is the successor model and separates infrastructure ownership from application routing more explicitly.
A Gateway API path typically looks like:
Internet ↓ Gateway ↓ HTTPRoute / GRPCRoute ↓ Service ↓ Pods
The main architecture advantage is not simply that Gateway API is newer. It models different responsibilities more cleanly:
- infrastructure or platform teams can own GatewayClass and Gateway resources;
- application teams can own Routes;
- routes can express richer traffic behavior without provider-specific Ingress annotations.
Ingress is still valid for existing applications and environments where the chosen controller is built around it. There is no requirement to replace a working Ingress deployment immediately.
The important production rule is: do not expose every Service publicly just because Kubernetes makes exposure easy.
Most internal APIs, workers, databases, queues, and administrative components should remain private.
For the traffic-entry decision itself, use Kubernetes Load Balancer vs Ingress Controller.
NetworkPolicy is workload segmentation, not a cloud firewall
Kubernetes NetworkPolicy controls traffic to and from selected Pods at the network-policy layer.
It is useful for designs such as:
frontend ↓ allowed api ↓ allowed database frontend ─X→ database
A common baseline is to start from default-deny rules and then add explicit application paths.
But two constraints matter.
First, NetworkPolicy requires enforcement by the cluster network implementation. Creating a NetworkPolicy object does not help if the networking implementation does not enforce that API.
Second, NetworkPolicy is not a replacement for:
- VPC segmentation;
- host or edge firewall policy;
- application authentication;
- authorization;
- secrets management;
- TLS.
Use it as one control inside a layered security model.
The implementation details—including ingress, egress, namespace selectors, DNS allowances, and rollout safety—belong in Kubernetes Network Policies for Small Teams.
Private networking belongs below Kubernetes
The cloud network and the Kubernetes network should reinforce each other.
A production pattern can look like:
Internet ↓ Managed public endpoint ↓ private cloud network / VPC ├── worker node A ├── worker node B └── worker node C ↓ Kubernetes Services ↓ Pods
This structure keeps worker infrastructure private while still allowing deliberate public application entry.
It also provides a cleaner path to private adjacent services such as databases, VMs, storage systems, monitoring agents, or VPN-connected networks.
The design question is therefore not "VPC or Kubernetes networking?" The two operate at different layers.
Use the VPC to define the infrastructure trust boundary. Use Kubernetes networking resources to define workload reachability and application traffic paths inside that boundary.
Kubernetes storage begins with workload state classification
Before creating a PersistentVolumeClaim, classify the state the application actually owns.
| Data type | Typical home | Reason |
|---|---|---|
| Container image | Registry | Immutable deployment artifact |
| Application code | Container image/build artifact | Replaceable |
| Temporary cache | Ephemeral storage or cache service | Rebuildable |
| Database records | Managed DB or purpose-built database storage | Needs consistency and recovery controls |
| Shared uploads | Object storage in many architectures | Decouples files from Pod/node lifecycle |
| Durable filesystem data | PersistentVolume | Requires mounted filesystem semantics |
| Logs and metrics | Observability system | Should survive individual Pods |
| Backup archives | Separate recovery target | Must survive live-state failures |
A useful Kubernetes architecture often puts less state inside the cluster, not more.
Stateless application tiers backed by managed databases or object storage are usually easier to scale, replace, and recover. PersistentVolumes remain appropriate when software genuinely requires mounted durable filesystem state.
PVC, PV, and StorageClass solve different parts of persistence
Kubernetes persistence is usually represented through three layers:
Pod ↓ mounts PersistentVolumeClaim ↓ binds to PersistentVolume ↓ provisioned by StorageClass / CSI implementation
A PersistentVolumeClaim (PVC) expresses what storage a workload requests.
A PersistentVolume (PV) represents storage available to the cluster.
A StorageClass describes how storage is provisioned and can define provider-specific parameters, reclaim behavior, expansion support, and volume-binding behavior.
This separation is useful because a Pod can disappear while the storage resource remains available according to its lifecycle policy.
Two StorageClass decisions deserve explicit review in production:
- reclaim policy — whether storage is deleted or retained after the claim is released;
- volume binding mode — whether a volume is provisioned immediately or waits until the scheduler knows where the consuming Pod will run.
For topology-constrained storage, WaitForFirstConsumer can avoid provisioning a volume in a location that does not match the Pod's scheduling requirements.
For the storage-specific decision tree, continue to Kubernetes Persistent Storage: Volumes, Storage Classes, and Backups.
Persistence is not backup
A persistent volume answers:
Will the data remain when this Pod is replaced?
A backup answers:
Can we recover an earlier usable state after data loss, deletion, corruption, or a larger failure?
Those are different guarantees.
A PVC can remain healthy while the application has already:
- deleted the wrong records;
- overwritten customer files;
- propagated logical database corruption;
- encrypted data through compromised credentials;
- changed a schema incorrectly.
That is why production state needs a recovery design outside the basic PV lifecycle.
For each stateful workload, define:
- what data must survive ordinary Pod replacement;
- what failure modes require a backup;
- where backups live;
- what RPO and RTO matter;
- how restore is tested;
- who owns the recovery decision.
If the answer is only "the volume is persistent," the recovery design is incomplete.
Design traffic and state together, but keep their failure domains separate
Use one workload matrix during architecture review:
| Workload | Traffic path | State path | Recovery model |
|---|---|---|---|
| Public stateless API | Gateway/Ingress → Service → Pods | External DB/object storage | Redeploy app; restore data service separately |
| Private worker | Private dependencies only | Usually none | Recreate Pod |
| Stateful application | Service → Pods | PVC/PV | Volume + application-aware backup |
| Database in cluster | Strictly restricted Service | Purpose-built persistent storage | Database-consistent backup and restore |
| Shared file workload | App Service | PVC or object storage | Storage-specific restore strategy |
This makes four architecture planes visible:
- Reachability — which components can connect.
- Exposure — which paths are public.
- Persistence — which state survives workload replacement.
- Recovery — which earlier state can be restored.
A production review should be able to answer all four for every critical workload.
How this maps to Raff Kubernetes
Raff Managed Kubernetes keeps the same responsibility boundaries visible.
Current Raff Kubernetes provides:
- a $0 standard control plane;
- optional three-master HA for $30/month;
- private networking for cluster nodes;
- a managed public endpoint with DNS and TLS;
- node pools and autoscaling;
- built-in monitoring and pod logs;
- dedicated storage nodes from 10 GB to 1,000 GB at $0.08/GB-month;
- unmetered public bandwidth up to 3 Gbps with $0 public egress fees.
The important architecture distinction is that these capabilities still solve different layers.
Private networking protects the infrastructure boundary. Kubernetes Services and routing resources control workload traffic. Dedicated storage provides persistent capacity. Application backups and restore testing remain separate recovery responsibilities.
For managed-versus-self-managed ownership, use Managed vs Self-Managed Kubernetes. For live product scope and current pricing, use Raff Kubernetes.
Production review checklist
Before putting a workload into production, verify:
Networking
- Worker infrastructure is private unless a public node path is explicitly required.
- Public traffic has one deliberate entry architecture.
- Internal services are not exposed publicly without a requirement.
- Applications use Services rather than Pod IPs.
- DNS/service discovery behavior is understood.
- NetworkPolicy enforcement support is confirmed before relying on policy.
- Gateway API versus Ingress ownership is intentional.
Storage
- Every persistent workload has a named PVC/storage owner.
- StorageClass behavior is understood.
- Reclaim policy matches the deletion/recovery expectation.
- Topology and binding behavior match scheduling constraints.
- Stateful data is not placed on a PVC merely because it can be.
- Backup and restore are designed separately from persistence.
Recovery
- The team knows what survives Pod loss.
- The team knows what survives node loss.
- The team knows what survives logical data corruption.
- A restore path exists for business-critical state.
- Recovery is tested, not assumed.
Final architecture recommendation
Start from the workload rather than from Kubernetes primitives.
Keep infrastructure private by default. Give replaceable Pods stable identities through Services. Use Gateway API or an existing Ingress implementation only for traffic that must enter the cluster. Add NetworkPolicy when workload segmentation is required and the network implementation enforces it.
For state, prefer external managed data services or object storage when they better match the application's needs. Use PersistentVolumes when software requires durable mounted filesystem semantics, and treat backup and restore as a separate system.
That separation produces a Kubernetes platform that is easier to scale, secure, troubleshoot, and recover.
Continue with Kubernetes Services, Ingress, and Load Balancers for traffic primitives, Kubernetes Network Policies for workload isolation, and Kubernetes Persistent Storage for stateful workload design.
