Feature: Multi-Attach for io2 block devices

[torredil]

Is this a bug fix or adding new feature?

• New feature
• Closes CSI support attach a volume to multiple instances with amazon EBS Multi-Attach #449

What is this PR about? / Why do we need it?

This PR implements the ability to enable multi-attach for io2 block devices by specifying the ReadWriteMany access mode in PersistentVolumeClaim.spec.accessModes. A few important points to note:

• EBS Multi-Attach does not support standard file systems. Standard file systems such as xfs, ext3, ext4, and NTFS aren't designed to be simultaneously accessed by multiple EC2 instances.
• Simultaneous access to a standard file system can result in data corruption or data loss.
• Multi-Attach is only enabled for io2 block devices.

See the documentation: https://github.com/torredil/aws-ebs-csi-driver/blob/d316ff830997cb38d17e38625cbaeea2e089068a/docs/multi-attach.md

What testing is done?

• Unit tests: make test
• e2e tests:

$ ginkgo run --focus='multi-attach' --v&

Ran 3 of 42 Specs in 82.685 seconds
SUCCESS! -- 3 Passed | 0 Failed | 0 Pending | 39 Skipped

• External.Storage suite

[wmesard]

I think we need some static provisioning test cases.

• If multi-attach is not enabled on an existing volume, obviously mult-attach should fail. So we should have an expected-fail test.
• For this release, I believe that we are only intending to support multi-attach in dynamically provisioned volumes. If that's true, then we should enforce that, and have a test for that enforcement. If we decide that we'll handle the case where a statically provisioned volume has multi-attach enabled, then we should have an expected-success test for that.

[k8s-ci-robot]

@wmesard: changing LGTM is restricted to collaborators

In response to this:

I think we need some static provisioning test cases.

• If multi-attach is not enabled on an existing volume, obviously mult-attach should fail. So we should have an expected-fail test.
• For this release, I believe that we are only intending to support multi-attach in dynamically provisioned volumes. If that's true, then we should enforce that, and have a test for that enforcement. If we decide that we'll handle the case where a statically provisioned volume has multi-attach enabled, then we should have an expected-success test for that.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[torredil]

CI is green and this PR is now ready for another round in the ring : )

cc: @wmesard @ConnorJC3 @AndrewSirenko

[k8s-ci-robot]

@wmesard: changing LGTM is restricted to collaborators

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ConnorJC3]

/lgtm

[AndrewSirenko]

/lgtm

[torredil]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: torredil

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [torredil]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment