- Documentation
- Red Hat OpenShift Service on AWS
- Storage
- Using Container Storage Interface (CSI)
- AWS Elastic Block Store CSI Driver Operator history bug_report picture_as_pdf
- About
- Introduction to ROSA
- Getting started
- Prepare your environment
- Installing, accessing, and deleting ROSA clusters
- Creating a ROSA cluster with STS using the default options
- Creating a ROSA cluster with STS using customizations
- Interactive cluster creation mode reference
- Creating an AWS PrivateLink cluster on ROSA
- Accessing a ROSA cluster
- Configuring identity providers using Red Hat OpenShift Cluster Manager
- Revoking access to a ROSA cluster
- Deleting a ROSA cluster
- Deploying ROSA without AWS STS
- AWS prerequisites for ROSA
- Understanding the ROSA deployment workflow
- Required AWS service quotas
- Configuring your AWS account
- Installing the ROSA CLI
- Creating a ROSA cluster without AWS STS
- Configuring a private cluster
- Deleting access to a ROSA cluster
- Deleting a ROSA cluster
- Command quick reference for creating clusters and users
- ROSA CLI
- Red Hat OpenShift Cluster Manager
- Cluster administration
- Security and compliance
- Authentication and authorization
- Upgrading
- CI/CD
- Add-on services
- Storage
- Registry
- Networking
- Application development
- Backing up and restoring applications
- Logging
- Release notes
- About Logging
- Installing Logging
- Accessing the service logs
- Viewing cluster logs in the AWS Console
- Configuring your Logging deployment
- About the Cluster Logging custom resource
- Configuring the logging collector
- Configuring the log store
- Configuring the log visualizer
- Configuring Logging storage
- Configuring CPU and memory limits for Logging components
- Using tolerations to control Logging pod placement
- Moving the Logging resources with node selectors
- Maintenance and support
- Logging with the LokiStack
- Viewing logs for a specific resource
- Viewing cluster logs in Kibana
- Forwarding logs to third party systems
- Enabling JSON logging
- Collecting and storing Kubernetes events
- Updating Logging
- Viewing cluster dashboards
- Troubleshooting Logging
- Uninstalling Logging
- Exported fields
- Monitoring user-defined projects
- Service Mesh
- Service Mesh 2.x
- About OpenShift Service Mesh
- Service Mesh 2.x release notes
- Service Mesh architecture
- Service Mesh deployment models
- Service Mesh and Istio differences
- Preparing to install Service Mesh
- Installing the Operators
- Creating the ServiceMeshControlPlane
- Adding workloads to a service mesh
- Enabling sidecar injection
- Upgrading Service Mesh
- Managing users and profiles
- Security
- Traffic management
- Metrics, logs, and traces
- Performance and scalability
- Deploying to production
- Federation
- Extensions
- 3scale WebAssembly for 2.1
- 3scale Istio adapter for 2.0
- Troubleshooting Service Mesh
- Control plane configuration reference
- Kiali configuration reference
- Jaeger configuration reference
- Uninstalling Service Mesh
- Service Mesh 1.x
- Service Mesh 1.x release notes
- Service Mesh architecture
- Service Mesh and Istio differences
- Preparing to install Service Mesh
- Installing Service Mesh
- Security
- Traffic management
- Deploying applications on Service Mesh
- Data visualization and observability
- Custom resources
- 3scale Istio adapter for 1.x
- Removing Service Mesh
- Service Mesh 2.x
- Serverless
- Release notes
- About Serverless
- Installing Serverless
- Knative Serving
- Eventing
- Knative Eventing
- Event sources
- Event sinks
- Brokers
- Triggers
- Triggers overview
- Creating triggers from the web console
- Creating triggers from the command line
- Creating a trigger from the Administrator perspective
- List triggers from the command line
- Describe triggers from the command line
- Connecting a trigger to a sink
- Filtering triggers from the command line
- Updating triggers from the command line
- Deleting triggers from the command line
- Channels
- Subscriptions
- Event discovery
- Tuning eventing configuration
- kn-event plugin
- Functions
- Setting up OpenShift Serverless Functions
- Getting started with functions
- Developing Quarkus functions
- Developing Node.js functions
- Developing TypeScript functions
- Using functions with Knative Eventing
- Function project configuration in func.yaml
- Accessing secrets and config maps from functions
- Adding annotations to functions
- Functions development reference guide
- Knative CLI
- Administer
- Security
- Observability
- Integrations
- Removing Serverless
- Serverless support
- Troubleshooting
AWS Elastic Block Store CSI Driver Operator
Overview
Red Hat OpenShift Service on AWS is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for AWS Elastic Block Store (EBS).
Familiarity with persistent storage and configuring CSI volumes is recommended when working with a Container Storage Interface (CSI) Operator and driver.
To create CSI-provisioned PVs that mount to AWS EBS storage assets, Red Hat OpenShift Service on AWS installs the AWS EBS CSI Driver Operator and the AWS EBS CSI driver by default in the openshift-cluster-csi-drivers namespace.
-
The AWS EBS CSI Driver Operator provides a StorageClass by default that you can use to create PVCs. You also have the option to create the AWS EBS StorageClass as described in Persistent storage using AWS Elastic Block Store.
-
The AWS EBS CSI driver enables you to create and mount AWS EBS PVs.
About CSI
Storage vendors have traditionally provided storage drivers as part of Kubernetes. With the implementation of the Container Storage Interface (CSI), third-party providers can instead deliver storage plugins using a standard interface without ever having to change the core Kubernetes code.
CSI Operators give Red Hat OpenShift Service on AWS users storage options, such as volume snapshots, that are not possible with in-tree volume plugins.
|
Red Hat OpenShift Service on AWS defaults to using an in-tree (non-CSI) plugin to provision AWS EBS storage. In future Red Hat OpenShift Service on AWS versions, volumes provisioned using existing in-tree plug-ins are planned for migration to their equivalent CSI driver. CSI automatic migration should be seamless. Migration does not change how you use all existing API objects, such as persistent volumes, persistent volume claims, and storage classes. After full migration, in-tree plugins will eventually be removed in future versions of Red Hat OpenShift Service on AWS. |
For information about dynamically provisioning AWS EBS persistent volumes in Red Hat OpenShift Service on AWS, see Persistent storage using AWS Elastic Block Store.