Can Rook pick up an additional block storage device if it's encrypted by AWS?

How does it work?
1

Hello, I’m looking to perform a kurl installation on an existing cluster (EKS). The people I’m working worth have a hard requirement where all block storage devices needed to be encrypted. They’re planning on encrypting it through AWS. Would this create issues when Rook is looking for that additional storage device? I know Rook requires an unformatted, unpartitioned disk, but would this encryption method interfere with this in anyway?

Thanks!

2

Hi Michael,

Thank you for reaching out with your question.

I wanted to clarify a few points to ensure we’re on the same page. kURL is a Kubernetes installer that sets up a new cluster on virtual machines or bare-metal servers using kubeadm. It creates a fresh Kubernetes environment from scratch. On the other hand, Amazon EKS is a managed Kubernetes service that provides you with an existing cluster hosted on AWS.

Because of this fundamental difference, you can’t use kURL to install onto an existing EKS cluster—they serve similar purposes but in different contexts. If you’re working with EKS, kURL isn’t applicable. Instead, you would deploy your applications directly onto EKS using tools like Helm or KOTS.

Regarding Rook :

  • Rook is a storage orchestrator that provides distributed storage solutions, in this case Ceph, within Kubernetes.
  • In the context of EKS, AWS already offers robust storage solutions such as Amazon EBS (Elastic Block Store) and Amazon EFS (Elastic File System).
  • These AWS services provide encrypted, distributed, and resilient storage out of the box, which aligns with what Rook aims to offer.
  • Because EKS integrates seamlessly with these AWS storage services, there’s typically no need to deploy Rook on an EKS cluster.
  • If there’s still a desire to use Rook on EKS, setting it up would be the responsibility of the cluster administrators, including handling any storage configurations or encryption requirements.

In essence, just as kURL and EKS don’t typically go together because they both aim to provide the Kubernetes infrastructure, Rook and EKS don’t usually go together either . EKS already provides the storage capabilities that Rook is designed to deliver.

If your team requires persistent storage on EKS, leveraging AWS’s native storage services is generally the recommended approach. These services are managed by AWS, offer high availability and durability, and meet encryption and compliance requirements.

Please let me know if this helps clarify things or if you have any further questions.

3

Thank you! This answers my question beautifully and thoroughly! Much appreciated :slight_smile: