Build Reliable Storage for Amazon EKS with Simplyblock

Amazon EKS gives you the flexibility of Kubernetes without the overhead of managing control planes yourself. But when it comes to persistent storage, things get tricky fast — especially if you’re dealing with zone-dependent volumes, bottlenecks on EBS, or challenges scaling storage alongside compute.

That’s where simplyblock comes in. It gives your EKS workloads fast, scalable, and zone-independent block storage using NVMe-over-TCP. You get full control over performance, volume allocation, and scaling — without relying on EBS limitations or overprovisioning.

Why EKS and Simplyblock Fit Together

EKS provides the orchestration, but storage often bottlenecks stateful apps. EBS volumes can’t easily move across zones, and scaling them without downtime is painful.

With simplyblock, volumes are not tied to a zone. You can attach and resize them on demand, replicate across zones for high availability, and keep latency low thanks to NVMe-over-TCP. This flexibility makes it especially effective in environments running software-defined storage, where resilience and elasticity are critical.

🚀 Set Up Reliable Storage for Your Amazon EKS Cluster
Run stateful workloads with fast, zone-aware volumes that scale as you grow.
👉 See how simplyblock supports Amazon EKS

Step 1: Install Simplyblock in Your EKS Cluster

Start with a running Amazon EKS cluster backed by Nitro-based EC2 instances (m5, r5, or c5). These support NVMe devices, which simplyblock uses to build storage pools. Deploy the simplyblock DaemonSet and CSI driver in your cluster. Setup details are available in the installation docs. Once complete, simplyblock volumes can be managed through both sbctl and Kubernetes PVCs.

Step 2: Create and Attach a Volume

Let’s say you want to run PostgreSQL on EKS with a 200 GB persistent volume.

First, create a pool and volume:

sbctl pool create eks-pool /dev/nvme0n1

sbctl volume add eks-db-volume 200G eks-pool

Connect the volume:

sbctl volume connect eks-db-volume

mkfs.ext4 /dev/nvme0n1

This creates a formatted block device ready for Kubernetes. More advanced usage options can be found in the usage guide. This example also works well for workloads that need fast provisioning, such as database branching.

Step 3: Expose It to Kubernetes

Define a StorageClass for simplyblock:

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: simplyblock-fast

provisioner: csi.simplyblock.io

Create a PersistentVolumeClaim:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: postgres-pvc

spec:

  accessModes:

    – ReadWriteOnce

  storageClassName: simplyblock-fast

  resources:

    requests:

      storage: 200Gi

Now deploy a pod that mounts it:

apiVersion: v1

kind: Pod

metadata:

  name: postgres

spec:

  containers:

  – name: postgres

    image: postgres:14

    volumeMounts:

    – mountPath: /var/lib/postgresql/data

      name: db-storage

  volumes:

  – name: db-storage

    persistentVolumeClaim:

      claimName: postgres-pvc

Your PostgreSQL pod now runs on a simplyblock-backed volume. For stateful workloads, this approach ensures consistent storage availability, which is especially useful in fast backup and disaster recovery setups.

Step 4: Troubleshooting Setup Issues

If the pod doesn’t see the volume:

• Confirm with lsblk on the node that the device is attached.
• Check CSI logs:
  
  kubectl logs -n kube-system -l app=csi-simplyblock
• Ensure port 4420 is open for NVMe-over-TCP.
  

If you’re using raw EBS NVMe devices, AWS documents how they behave on Nitro instances in the NVMe EBS guide.

Step 5: Ongoing Operations and Scaling

As workloads grow, volumes can be resized without downtime. For example:

sbctl volume resize eks-db-volume 400G

resize2fs /dev/nvme0n1

This expands the volume and filesystem live, with no disruption to the pod. For lifecycle tasks like rebalancing pools or monitoring usage, see the operation and management docs. This aligns closely with software-defined storage principles, where automation and flexibility reduce operational overhead.

Step 6: Performance and Best Practices

To get the best performance when running stateful workloads on Amazon EKS with simplyblock, it’s important to optimize both your instance selection and configuration. Choose EC2 instances that provide high disk bandwidth to avoid I/O bottlenecks. 

For workloads with heavy sequential writes, such as databases or analytics pipelines, tuning block sizes can significantly improve efficiency. In environments with many concurrent applications, distributing data across multiple volumes ensures balanced performance and scalability.

Monitoring system health is also essential — you can track metrics with sbctl stats and adjust parameters as needed. A full list of available configuration options can be found in the reference section.

Keeping Storage in Sync with EKS Growth

As your EKS clusters scale, simplyblock makes sure storage scales with them. Volumes can grow, failover across zones, and rebalance on demand. By combining Kubernetes-native PVCs with simplyblock’s flexible backend, you get the resilience EKS workloads need without being tied to EBS limitations.

This also means teams spend less time reconfiguring storage manually and more time focusing on applications. With built-in flexibility and zone independence, simplyblock keeps your EKS environments ready for both rapid growth and long-term stability. For teams building managed platforms, this is especially valuable in databases-as-a-service models where resilience and cost-efficiency are critical.

Questions and Answers