Increase IOPs along with Volume Size when PVC request size is increased and iopsPerGB is set under storageclass.

[sujithg9]

Feature Request

Description:
When a PVC is resized by updating the request size and the StorageClass has the value "iopsPerGB" set, the volume size is expanded accordingly. However, there is no provision to increase the associated IOPS when the PVC request size is increased. This limits the flexibility and scalability of workloads requiring higher IOPS and increased storage capacity. I know EBS CSI has introduced the annotation-based expansion of IOPS, throughput, and disk-type change. But then if request size is increased and IOPs annotation is added, EBS CSI is going to make two separate volume modification calls to AWS where the second call will hit the 6 hr cool down which is not optimal as both volume size and IOPs have to be expanded at the same time when iopsPerGB is a property under the storage class.

We want the EBS block storage expansion through EBS CSI an atomic operation where we increase both size and IOPs in one go when iopsPerGB is set. So that it won't be done in two separate calls to AWS where we need to wait for 6h cool off period in between.

Proposal:
I would like to propose adding a feature that allows for the expansion of IOPS along with volume size expansion when the PVC request size is increased and the StorageClass has the value "iopsPerGB" set. This enhancement would provide users with a more comprehensive and dynamic storage solution on AWS EBS volumes.

Expected Behavior:
When a user increases the size of a PVC if the StorageClass specifies "iopsPerGB," the AWS EBS CSI driver should automatically adjust the IOPS allocation to maintain the desired IOPS-to-GB ratio, ensuring optimal performance for applications that require higher IOPS.

Additional Context:
Include any additional context or examples that may be relevant to the feature request. This could include use cases, specific workload scenarios, or any related information supporting this feature's need.

/kind feature

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[AndrewSirenko]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[AndrewSirenko]

/remove-lifecycle rotten