CloudStorage

Unlocking efficiency with Amazon S3 Batch Operations

Suppose you’re a librarian, but instead of books, you’ve got millions, maybe billions, of files stored in the cloud. That’s what it’s like for many folks using Amazon S3 (Simple Storage Service). It’s a fantastic place to keep your digital stuff, but managing those files, especially in bulk, can be a real headache. It’s like trying to reshelve a whole library by hand, one book at a time. Tedious, right? That’s where S3 Batch Operations steps in, like a team of super-efficient robot librarians.

What is Amazon S3 Batch Operations?

Think of S3 Batch Operations as a powerful command center tool that lets you tell S3, “Hey, I need you to do something to a whole bunch of files, not just one.” You create what’s called a “job.” In this job, you specify:

The Inventory: A list of all the objects you want to work on. You can use an S3 inventory report or even a simple CSV.
The Operation: What you want to do with those objects: copy them, tag them, restore them from the archive, process them using lambda functions, and modify their lifecycle retention policies.

Then, you just let it run. S3 Batch Operations takes care of the rest, processing your files automatically.

Key features of Amazon S3 Batch Operations

This isn’t just about doing things in bulk. It’s about doing them smartly. Here’s what makes S3 Batch Operations stand out:

Copying Objects: Need to duplicate objects across buckets or regions? Maybe for backup or to move data closer to your users? Batch Operations handles it. You can specify the destination, storage class, and other settings.
Setting Tags: Tags are like labels on your files. They help you organize, search, and manage your data. Batch Operations lets you add, modify, or delete tags on millions of objects at once. Imagine tagging all your customer invoices with a specific project ID, in one go.
Restoring Objects from Glacier: Glacier is like the deep archive of S3, cheap but slow. Batch Operations can initiate the restoration of objects from Glacier in bulk.
Invoking Lambda Functions: This is where it gets really interesting. You can trigger Lambda functions for each object. Imagine automatically resizing images, converting file formats, or extracting metadata. The possibilities are endless! For example, you can invoke a Lambda function with Batch Operations to analyze web server logs, extract relevant information, and load it into a data warehouse for further analysis.
Applying Retention Policies: Need to comply with regulations that require you to keep data for a certain period, or automatically delete it after a while? Batch Operations can apply or modify retention policies on large datasets.

Some use cases

Let’s get practical. Here are some scenarios where S3 Batch Operations becomes a lifesaver:

Metadata Updates: Suppose you need to change the tags on millions of objects to reflect a new categorization scheme or comply with updated policies. For example, renaming a tag that was used with the category “Client X” to be replaced with a tag with the category “Company Y”. Batch Operations makes this a breeze.
Data Migration: Want to move old files to a cheaper storage class like Glacier to save costs? Batch Operations can automate this, and you can selectively restore files as needed.
Large-Scale Data Processing: Need to run analytics, transform data, or enrich your datasets? Batch Operations, combined with Lambda, lets you do this on a massive scale, automatically.
Disaster Recovery Replication: Set up automatic object replication to another region as part of your disaster recovery strategy.
Compliance and Audits: Easily apply or modify retention policies to comply with regulations like GDPR or HIPAA. No more manual work or worrying about missing something.
Implementing Data Lakes or Data Warehouses: In this use case, Batch Operations is used for data transformation (ETL) tasks and for ingesting and transforming large amounts of unstructured data into a structured format within the data lake. For example, converting JSON files without a standard format to a structured format, such as Parquet.

Benefits of using S3 Batch Operations

Why bother with all this? Because it makes your life easier and your operations more efficient. Let’s break it down:

Automatic Retries: If an operation fails for some reason, S3 Batch Operations will automatically retry it. No need to babysit the process.
Detailed Progress Reports: You get detailed reports on the status of your job. You can see which operations succeeded, which failed, and why.
Operation Status Tracking: You can monitor the progress of your job in real time.
Automatic Scaling: It doesn’t matter if you’re processing a thousand objects or a billion. S3 Batch Operations scales automatically to handle the load.
Time and Resource Savings: Automate tasks that would otherwise take days or weeks to do manually.
Error Reduction: Minimize the risk of human error in managing your data.
Enhanced Operational Efficiency: Optimize your use of AWS resources.
Improved Data Governance: Make it easier to apply policies and comply with regulations.

In a few words

Amazon S3 Batch Operations isn’t just another feature; it’s a game-changer for anyone dealing with large amounts of data in S3. It’s like having a superpower that lets you manage your data with efficiency and precision.

S3 Access Points explained

Don’t you feel like your data in the cloud is a bit too… exposed? Like you’ve got a treasure chest full of valuable information (your S3 bucket), but it’s just sitting there, practically begging for unwanted attention? You wouldn’t leave your valuables out in the open in the real world, would you? Well, the same logic applies to your data in the cloud.

This is where AWS S3 Access Points come in. They act like bouncers for your data, ensuring only the right people get in. And for those of you with data scattered across the globe, we’ve got something even fancier: Multi-Region Access Points (MRAPs). They’re like the global positioning system for your data, ensuring fast access no matter where you are.

So buckle up, and let’s explore the fascinating world of S3 Access Points and MRAPs. Let’s try to make it fun.

The problem is that your S3 Bucket is wide open (By Default)

Think of an S3 bucket as a giant storage locker in the cloud. When you first create one, it’s like leaving the locker door wide open. Anyone who knows the lockers there can just waltz in and take a peek, or worse, start messing with your stuff.

This might be fine if you’re just storing cat memes, but what if you have sensitive customer data, financial records, or top-secret project files? You need a way to control who gets in and what they can do.

The solution is the Access Points, your data’s bouncers

Imagine Access Points as the bouncers standing guard at the entrance of your storage locker. They check IDs, make sure everyone’s on the guest list, and only let in the people you’ve authorized.

In more technical terms, an Access Point is a unique hostname that you create to enforce distinct permissions and network controls for any request made through it. You can configure each Access Point with its own IAM policy, tailored to specific use cases.

Why you need Access Points. It’s all about control

Here’s the deal:

Granular Access Control: You can create different Access Points for different applications or teams, each with its own set of permissions. Maybe your marketing team only needs read access to product images, while your developers need full read and write access to application logs. Access Points make this a breeze.
Simplified Policy Management: Instead of one giant, complicated bucket policy, you can have smaller, more manageable policies for each Access Point. It’s like having a separate rule book for each group that needs access.
Enhanced Security: By restricting access through specific Access Points, you reduce the risk of accidental data exposure or unauthorized modification. It’s like having multiple layers of security for your precious data.
Compliance Made Easier: Many industries have strict regulations about data access and security (think GDPR, HIPAA). Access Points help you meet these requirements by providing a clear and auditable way to control who can access what.

Let’s get practical with an Access Point policy example

Okay, let’s see how this works in practice. Here’s an example of an Access Point policy that only allows access to a bucket named “pending-documentation” and only permits read and write actions (no deleting!):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/Alice"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:us-west-2:123456789012:accesspoint/my-access-point/object/pending-documentation/*"
    }
  ]
}

Explanation:

Version: Specifies the policy language version.
Statement: An array of permission statements.
Effect: “Allow” means this statement grants permission.
Principal: This specifies who is granted access. In this case, it’s the IAM user “Alice” (you’d replace this with the actual ARN of your user or role).
Action: The S3 actions allowed. Here, it’s s3:GetObject (read) and s3:PutObject (write).
Resource: This is the crucial part. It specifies the resource the policy applies to. Here, it’s the “pending-documentation” bucket accessed through the “my-access-point” Access Point. The /* at the end means all objects within that bucket path.

Delegating access control to the Access Point (Bucket Policy)

You also need to configure your S3 bucket policy to delegate access control to the Access Point. Here’s an example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:DataAccessPointArn": "arn:aws:s3:us-west-2:123456789012:accesspoint/my-access-point"
        }
      }
    }
  ]
}

This policy allows any principal (“AWS”: “*”) to perform any S3 action (“s3:*”), but only if the request goes through the specified Access Point ARN.

Taking it global, Multi-Region Access Points (MRAPs)

Now, let’s say your data is spread across multiple AWS regions. Maybe you have users all over the world, and you want them to have fast access to your data, no matter where they are. This is where Multi-Region Access Points (MRAPs) come to the rescue!

Think of an MRAP as a smart global router for your data. It’s a single endpoint that automatically routes requests to the closest copy of your data in one of your S3 buckets across multiple regions.

Why Use MRAPs? Think speed and resilience

Reduced Latency: MRAPs ensure that users are always accessing the data from the nearest region, minimizing latency and improving application performance. It is like having a fast-food in each country, so clients can have their orders faster.
High Availability: If one region becomes unavailable, MRAPs automatically route traffic to another region, ensuring your application stays up and running. It’s like having a backup generator for your data.
Simplified Management: Instead of managing multiple endpoints for different regions, you have one MRAP to rule them all.

MRAPs vs. Regular Access Points, what’s the difference?

While both are about controlling access, MRAPs take it to the next level:

Scope: Regular Access Points are regional; MRAPs are multi-regional.
Focus: Regular Access Points primarily focus on security and access control; MRAPs add performance and availability to the mix.
Complexity: MRAPs are a bit more complex to set up because you’re dealing with multiple regions.

When to unleash the power of Access Points and MRAPs

Data Lakes: Use Access Points to create secure “zones” within your data lake, granting different teams access to only the data they need.
Content Delivery: MRAPs can accelerate content delivery to users around the world by serving data from the nearest region.
Hybrid Cloud: Access Points can help integrate your on-premises applications with your S3 data in a secure and controlled manner.
Compliance: Meeting regulations like GDPR or HIPAA becomes easier with the fine-grained access control provided by Access Points.
Global Applications: If you have a globally distributed application, MRAPs are essential for delivering a seamless user experience.

Lock down your data and speed up access

AWS S3 Access Points and Multi-Region Access Points are powerful tools for managing access to your data in the cloud. They provide the security, control, and performance that modern applications demand.

How to mount AWS EFS on EKS for scalable storage solutions

Suppose you need multiple applications to share files seamlessly, without worrying about running out of storage space or struggling with complex configurations. That’s where AWS Elastic File System (EFS) comes in. EFS is a fully managed, scalable file system that multiple AWS services or containers can access. In this guide, we’ll take a simple yet comprehensive journey through the process of mounting AWS EFS to an Amazon Elastic Kubernetes Service (EKS) cluster. I’ll make sure to keep it straightforward, so you can follow along regardless of your Kubernetes experience.

Why use EFS with EKS?

Before we go into the details, let’s consider why using EFS in a Kubernetes environment is beneficial. Imagine you have multiple applications (pods) that all need to access the same data—like a shared directory of documents. Instead of replicating data for each application, EFS provides a centralized storage solution that can be accessed by all pods, regardless of which node they’re running on.

Here’s what makes EFS a great choice for EKS:

Shared Storage: Multiple pods across different nodes can access the same files at the same time, making it perfect for workloads that require shared access.
Scalability: EFS automatically scales up or down as your data needs change, so you never have to worry about manually managing storage limits.
Durability and Availability: AWS ensures that your data is highly durable and accessible across multiple Availability Zones (AZs), which means your applications stay resilient even if there are hardware failures.

Typical use cases for using EFS with EKS include machine learning workloads, content management systems, or shared file storage for collaborative environments like JupyterHub.

Prerequisites

Before we start, make sure you have the following:

EKS Cluster: You need a running EKS cluster, and kubectl should be configured to access it.
EFS File System: An existing EFS file system in the same AWS region as your EKS cluster.
IAM Roles: Correct IAM roles and policies for your EKS nodes to interact with EFS.
Amazon EFS CSI Driver: This driver must be installed in your EKS cluster.

How to mount AWS EFS on EKS

Let’s take it step by step, so by the end, you’ll have a working setup where your Kubernetes pods can use EFS for shared, scalable storage.

Create an EFS file system

To begin, navigate to the EFS Management Console:

Create a New File System: Select the appropriate VPC and subnets—they should be in the same region as your EKS cluster.
File System ID: Note the File System ID; you’ll use it later.
Networking: Ensure that your security group allows inbound traffic from the EKS worker nodes. Think of this as permitting EKS to access your storage safely.

Set up IAM role for the EFS CSI driver

The Amazon EFS CSI driver manages the integration between EFS and Kubernetes. For this driver to work, you need to create an IAM role. It’s a bit like giving the CSI driver its set of keys to interact with EFS securely.

To create the role:

Log in to the AWS Management Console and navigate to IAM.
Create a new role and set up a custom trust policy:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Principal": {
               "Federated": "arn:aws:iam::<account-id>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/<oidc-provider-id>"
           },
           "Action": "sts:AssumeRoleWithWebIdentity",
           "Condition": {
               "StringLike": {
                   "oidc.eks.<region>.amazonaws.com/id/<oidc-provider-id>:sub": "system:serviceaccount:kube-system:efs-csi-*"
               }
           }
       }
   ]
}

Make sure to attach the AmazonEFSCSIDriverPolicy to this role. This step ensures that the CSI driver has the necessary permissions to manage EFS volumes.

Install the Amazon EFS CSI driver

You can install the EFS CSI driver using either the EKS Add-ons feature or via Helm charts. I recommend the EKS Add-on method because it’s easier to manage and stays updated automatically.

Attach the IAM role you created to the EFS CSI add-on in your cluster.

(Optional) Create an EFS access point

Access points provide a way to manage and segregate access within an EFS file system. It’s like having different doors to different parts of the same warehouse, each with its key and permissions.

Go to the EFS Console and select your file system.
Create a new Access Point and note its ID for use in upcoming steps.

Configure an IAM Policy for worker nodes

To make sure your EKS worker nodes can access EFS, attach an IAM policy to their role. Here’s an example policy:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Action": [
               "elasticfilesystem:DescribeAccessPoints",
               "elasticfilesystem:DescribeFileSystems",
               "elasticfilesystem:ClientMount",
               "elasticfilesystem:ClientWrite"
           ],
           "Resource": "*"
       }
   ]
}

This ensures your nodes can create and interact with the necessary resources.

Create a storage class for EFS

Next, create a Kubernetes StorageClass to provision Persistent Volumes (PVs) dynamically. Here’s an example YAML file:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  fileSystemId: <file-system-id>
  directoryPerms: "700"
  basePath: "/dynamic_provisioning"
  ensureUniqueDirectory: "true"

Replace <file-system-id> with your EFS File System ID.

Apply the file:

kubectl apply -f efs-storage-class.yaml

Create a persistent volume claim (PVC)

Now, let’s request some storage by creating a PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: efs-sc

Apply the PVC:

kubectl apply -f efs-pvc.yaml

Use the EFS PVC in a pod

With the PVC created, you can now mount the EFS storage into a pod. Here’s a sample pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: efs-app
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: "/data"
      name: efs-volume
  volumes:
  - name: efs-volume
    persistentVolumeClaim:
      claimName: efs-pvc

Apply the configuration:

kubectl apply -f efs-pod.yaml

You can verify the setup by checking if the pod can access the mounted storage:

kubectl exec -it efs-app -- ls /data

A note on direct EFS mounting

You can mount EFS directly into pods without using a Persistent Volume (PV) or Persistent Volume Claim (PVC) by referencing the EFS file system directly in the pod’s configuration. This approach simplifies the setup but offers less flexibility compared to using dynamic provisioning with a StorageClass. Here’s how you can do it:

apiVersion: v1
kind: Pod
metadata:
  name: efs-mounted-app
  labels:
    app: efs-example
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    volumeMounts:
    - name: efs-storage
      mountPath: "/shared-data"
  volumes:
  - name: efs-storage
    csi:
      driver: efs.csi.aws.com
      volumeHandle: <file-system-id>
      readOnly: false

Replace <file-system-id> with your EFS File System ID. This method works well for simpler scenarios where direct access is all you need.

Final remarks

Mounting EFS to an EKS cluster gives you a powerful, shared storage solution for Kubernetes workloads. By following these steps, you can ensure that your applications have access to scalable, durable, and highly available storage without needing to worry about complex management or capacity issues.

As you can see, EFS acts like a giant, shared repository that all your applications can tap into. Whether you’re working on machine learning projects, collaborative tools, or any workload needing shared data, EFS and EKS together simplify the whole process.

Now that you’ve walked through mounting EFS on EKS, think about what other applications could benefit from this setup. It’s always fascinating to see how managed services can help reduce the time you spend on the nitty-gritty details, letting you focus on building great solutions.

December 5, 2024 by Fernando SRE Cloud stuff DevOps stuff Kubernetes SRE stuff 0

Comparing AWS S3 and Azure Blob Storage

Big tech companies manage millions of files seamlessly. Think of cloud storage as a giant digital warehouse where you can store almost unlimited stuff. Today, we will explore two of the most popular cloud storage solutions: AWS S3 and Azure Blob Storage. Don’t worry if these names sound intimidating, by the end of this article, you’ll understand them as clearly as you understand saving files on your computer.

The basics of object storage

Imagine a massive library, but instead of organizing books on shelves and in sections, each book lives independently with its unique code and description. That’s essentially how object storage works! When you upload a file, whether it’s a photo, a document, or anything else, it becomes an “object” with three key components:

The file itself (like your vacation photo)
A unique identifier (think of it like the file’s address in the storage system)
Metadata (extra information about the file, such as when it was created or who owns it)

This approach makes storing and retrieving vast amounts of data incredibly easy without worrying about running out of space or losing your files. It’s like having a magical library where books never go missing and you can always find exactly what you’re looking for.

AWS S3, the veteran player

Amazon’s S3 (Simple Storage Service) is like the wise old sage of cloud storage. Launched in 2006, it’s seen it all and done it all. Let’s break down why S3 is so special.

What S3 does well:

Reliability: S3 is like that friend who never forgets anything. It keeps multiple copies of your files across different locations, ensuring an astounding 99.999999999% durability (that’s eleven nines!).
Flexibility: Need different kinds of storage for different use cases? S3 has you covered with various storage classes. It’s like having different types of lockers:
- Standard (for files you use frequently)
- Infrequent Access (for cheaper storage if you don’t need files as often)
- Glacier (super cheap for files you rarely access)
Integration: S3 connects seamlessly with a huge ecosystem of other AWS services and third-party tools. It’s like having a universal adapter that plugs into just about anything.

Where S3 could improve:

Pricing: The pricing can be tricky to predict, kind of like going to a restaurant where every little extra, like the sauce or side dish, has a separate cost.
Feature Overload: With so many features, S3 can feel overwhelming when you’re just getting started, like trying to read an entire encyclopedia in one go.

Azure Blob Storage, the modern challenger

Microsoft’s Azure Blob Storage is like the newer restaurant in town that’s quickly becoming the talk of the neighborhood. It might be younger than S3, but it brings some fresh and exciting ideas to the table.

Azure’s strong points:

User-Friendly: If you’re already familiar with Microsoft products, using Azure Blob Storage will feel like second nature.
Cost-Effective: For data you access frequently, Azure Blob Storage often offers lower prices, making it an attractive option.
Performance: Azure Blob shines when it comes to handling large files and streaming. It’s like having a powerful engine built for heavy lifting.

Room for growth:

Fewer storage tiers: Azure Blob Storage doesn’t offer as many storage tier options as S3. If you love having lots of choices, this might feel a little limiting.
Ecosystem: While growing, Azure’s ecosystem of third-party tools isn’t as expansive as AWS’s, making integration slightly more challenging in certain cases.

Choosing the right option:

Here are some questions to help you decide between S3 and Azure Blob Storage:

What’s your current setup?
- Already using AWS? S3 is the natural choice.
- A heavy Microsoft user? Azure Blob Storage will feel like home.
What’s your budget?
- Frequently accessing your data? Azure may offer a more cost-effective solution.
- Need long-term archival? S3 Glacier’s ultra-low prices for rarely accessed data are hard to beat.
How complex are your needs?
- If you need advanced features, S3’s long history gives it an edge.
- Want simplicity? Azure’s streamlined approach might be a better fit.

The technical showdown

Here’s a quick comparison of the key features:

Feature	AWS S3	Azure Blob Storage
Minimum Storage Time	None	None
Availability	99.99%	99.99%
Durability	99.999999999%	99.999999999%
Storage Classes	6 classes	4 tiers
Max Object Size	5 TB	4.75 TB

In summary

Both S3 and Azure Blob Storage are top-notch options, kind of like choosing between two luxury cars. S3 is like a fully loaded vehicle with every possible feature, while Azure Blob Storage is more like a sleek, modern car that’s easier to drive but still packs a punch.

There’s no universal “best” choice. it all depends on your specific needs. Both services will store your data reliably and scale with you as you grow. The key is to match their strengths with what you need.

Pro Tip: Start small with either service and grow as your needs evolve. Both platforms offer free tiers, so you can get started without spending a dime, perfect for testing the waters.

October 17, 2024 by Fernando SRE Cloud stuff DevOps stuff 0

Storage Classes in Kubernetes, Let’s Manage Persistent Data

One essential aspect in Kubernetes is how to handle persistent storage, and this is where Kubernetes Storage Classes come into play. In this article, we’ll explore what Storage Classes are, their key components, and how to use them effectively with practical examples.
If you’re working with applications that need to store data persistently (like databases, file systems, or even just configuration files), you’ll want to understand how these work.

What is a Storage Class?

Imagine you’re running a library (that’s our Kubernetes cluster). Now, you need different types of shelves for different kinds of books, some for heavy encyclopedias, some for delicate rare books, and others for popular paperbacks. In Kubernetes, Storage Classes are like these different types of shelves. They define the types of storage available in your cluster.

Storage Classes allow you to dynamically provision storage resources based on the needs of your applications. It’s like having a librarian who can create the perfect shelf for each book as soon as it arrives.

Key Components of a Storage Class

Let’s break down the main parts of a Storage Class:

Provisioner: This is the system that will create the actual storage. It’s like our librarian who creates the shelves.
Parameters: These are specific instructions for the provisioner. For example, “Make this shelf extra sturdy” or “This shelf should be fireproof”.
Reclaim Policy: This determines what happens to the storage when it’s no longer needed. Do we keep the shelf (Retain) or dismantle it (Delete)?
Volume Binding Mode: This decides when the actual storage is created. It’s like choosing between having shelves ready in advance or building them only when a book arrives.

Creating a Storage Class

Now, let’s create our first Storage Class. We’ll use AWS EBS (Elastic Block Store) as an example. Don’t worry if you’re unfamiliar with AWS, the concepts are similar for other cloud providers.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Let’s break this down:

name: fast-storage: This is the name we’re giving our Storage Class.
provisioner: ebs.csi.aws.com: This tells Kubernetes to use the AWS EBS CSI driver to create the storage.
parameters: type: gp3: This specifies that we want to use gp3 EBS volumes, which are a type of fast SSD storage in AWS.
reclaimPolicy: Delete: This means the storage will be deleted when it’s no longer needed.
volumeBindingMode: WaitForFirstConsumer: This tells Kubernetes to wait until a Pod actually needs the storage before creating it.

Using a Storage Class

Now that we have our Storage Class, how do we use it? We use it when creating a Persistent Volume Claim (PVC). A PVC is like a request for storage from an application.

Here’s an example of a PVC that uses our Storage Class:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-storage
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-storage
  resources:
    requests:
      storage: 5Gi

Let’s break this down too:

name: my-app-storage: This is the name of our PVC.
accessModes: – ReadWriteOnce: This means a single node can mount the storage as read-write.
storageClassName: fast-storage: This is where we specify which Storage Class to use, it matches the name we gave our Storage Class earlier.
storage: 5Gi: This is requesting 5 gigabytes of storage.

Real-World Use Case

Let’s imagine we’re running a photo-sharing application. We need fast storage for the database that stores user information and slower, cheaper storage for the actual photos.

We could create two Storage Classes:

A “fast-storage” class (like the one we created above) for the database.
A “bulk-storage” class for the photos, perhaps using a different type of EBS volume that’s cheaper but slower.

Then, we’d create two PVCs (Persistent Volume Claim), one for each Storage Class. Our database Pod would use the PVC with the “fast-storage” class, while our photo storage Pod would use the PVC with the “bulk-storage” class.

This way, we’re optimizing our storage usage (and costs) based on the needs of different parts of our application.

In Summary

Storage Classes in Kubernetes provide a flexible and powerful way to manage different types of storage for your applications. By understanding and using Storage Classes, you can ensure your applications have the storage they need while keeping your infrastructure efficient and cost-effective.

Whether you’re working with AWS EBS, Google Cloud Persistent Disk, or any other storage backend, Storage Classes are an essential tool in your Kubernetes toolkit.

June 24, 2024 by Fernando SRE DevOps stuff Kubernetes SRE stuff 0