Storage options for a Kubernetes cluster

This article compares the storage capabilities of Amazon Elastic Kubernetes Service (EKS) and Azure Kubernetes Service (AKS). It also describes storage options for workload data on AKS.

Amazon EKS storage options

Amazon EKS provides different types of storage volumes for applications that require data storage. You can use these volumes for temporary and long-lasting storage.

Ephemeral volumes

For applications that require temporary local volumes but don't need to persist data after restarts, use ephemeral volumes. Kubernetes supports different types of ephemeral volumes, such as emptyDir, ConfigMap, downwardAPI, secret, and hostPath. To ensure cost efficiency and performance, choose the most appropriate host volume. In Amazon EKS, you can use gp3 as the host root volume, which costs less than gp2 volumes.

You can also use Amazon EC2 instance stores, which provide temporary block-level storage for EC2 instances. These volumes are physically attached to the hosts and only exist during the lifetime of the instance. To use local store volumes in Kubernetes, you must partition, configure, and format the disks by using Amazon EC2 user data.

Persistent volumes

You typically use Kubernetes to run stateless applications, but sometimes you need persistent data storage. You can use Kubernetes persistent volumes to store data independently from pods so that the data can persist beyond the lifetime of a given pod. Amazon EKS supports different types of storage options for persistent volumes, including Amazon EBS, Amazon Elastic File System (EFS), Amazon FSx for Lustre, and Amazon FSx for NetApp ONTAP.

Use Amazon EBS volumes for block-level storage and for databases and throughput-intensive applications. Amazon EKS users can use the latest generation of block storage gp3 for a balance between price and performance. For higher-performance applications, you can use io2 Block Express volumes.

Amazon EFS is a serverless, elastic file system that you can share across multiple containers and nodes. It automatically grows and shrinks as files are added or removed, which eliminates the need for capacity planning. The Amazon EFS Container Storage Interface (CSI) driver integrates Amazon EFS with Kubernetes.

Amazon FSx for Lustre provides high-performance parallel file storage. Use this type of storage for scenarios that require high-throughput and low-latency operations. You can link this file storage to an Amazon S3 data repository to store large datasets. Amazon FSx for NetApp ONTAP is a fully managed, shared storage solution that's built on NetApp's ONTAP file system.

To optimize storage configurations and manage backups and snapshots, use tools like AWS Compute Optimizer and Velero.

AKS storage options

Applications that run in AKS might need to store and retrieve data. Some application workloads can use local, fast storage on unneeded, empty nodes. But other application workloads require storage that persists on more regular data volumes within the Azure platform. Multiple pods might need to:

• Share the same data volumes.
• Reattach data volumes if the pod is rescheduled on a different node.

The following sections introduce the storage options and core concepts that provide storage to your applications in AKS.

Volume types

Kubernetes volumes represent more than just a traditional disk to store and retrieve information. You can also use Kubernetes volumes to inject data into a pod for its containers to use.

Common volume types in Kubernetes include emptyDirs, secrets, and ConfigMaps.

EmptyDirs

For a pod that defines an emptyDir volume, the volume is created when the pod is assigned to a node. As the name suggests, the emptyDir volume is initially empty. All containers in the pod can read and write the same files in the emptyDir volume, although this volume can be mounted at the same or different paths in each container. When a pod is removed from a node for any reason, the data in the emptyDir is deleted permanently.

Secrets

A secret is an object that holds a small amount of sensitive data, such as a password, token, or key. If you don't use a secret, this information is included in a pod specification or container image. A secret prevents the need to embed confidential data directly in your application code. You can create secrets independently of the pods that use them. This practice reduces the risk of exposing the secret and its data when you create, view, and edit pods. Kubernetes and the applications that run in your cluster can take extra precautions with secrets, such as preventing sensitive data from being written to nonvolatile storage. Secrets are similar to ConfigMaps, but they're specifically designed to store confidential data.

You can use secrets for the following purposes:

• Set environment variables for a container.
• Provide credentials such as SSH keys or passwords to pods.
• Allow the kubelet to pull container images from private registries.

The Kubernetes control plane also uses secrets, such as bootstrap token secrets, to help automate node registration.

ConfigMaps

A ConfigMap is a Kubernetes object that you use to store nonconfidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume. You can use a ConfigMap to decouple environment-specific configurations from your container images, which makes your applications easily portable.

ConfigMaps don't provide secrecy or encryption. If you want to store confidential data, use a secret rather than a ConfigMap, or use other partner tools to keep your data private.

You can use a ConfigMap to set configuration data separately from application code. For example, you might develop an application to run on your computer for development and to run in the cloud to handle real traffic. You can write the code to look in an environment variable named DATABASE_HOST. Locally, set that variable to localhost. In the cloud, set it to refer to a Kubernetes service that exposes the database component to your cluster. This approach lets you fetch a container image that runs in the cloud and debug the same code locally if needed.

Persistent volumes

Volumes that are defined and created as part of the pod lifecycle only exist until you delete the pod. Pods often expect their storage to remain if a pod is rescheduled on a different host during a maintenance event, especially in StatefulSets. A persistent volume is a storage resource that the Kubernetes API creates and manages. A persistent volume can exist beyond the lifetime of an individual pod. You can use the following Azure Storage tools to provide the persistent volume:

• Azure disk storage
• Azure Files
• Azure NetApp Files
• Azure Blob Storage
• Azure Container Storage

To decide between Azure disk storage or Azure Files, consider whether your application needs concurrent data access or a specific performance tier.

A cluster administrator can statically create a persistent volume, or the Kubernetes API server can dynamically create a volume. If a pod is scheduled and requests storage that's currently unavailable, Kubernetes can create the underlying Azure disk or file storage and attach it to the pod. Dynamic provisioning uses a storage class to identify what type of resource needs to be created.

If you want a fully managed solution for block-level access to data, consider using Azure Container Storage instead of CSI drivers. Azure Container Storage integrates with Kubernetes to provide dynamic and automatic provisioning of persistent volumes. Azure Container Storage supports Azure disks, ephemeral disks, and Azure Elastic SAN (preview) as backing storage. These options provide flexibility and scalability for stateful applications that run on Kubernetes clusters.

Storage classes

To specify different tiers of storage, such as premium or standard, you can create a storage class.

A storage class also defines a reclaim policy. When you delete a persistent volume, the reclaim policy controls the behavior of the underlying Azure Storage resource. The underlying resource can either be deleted or kept for use with a future pod.

Clusters that use Azure Container Storage have an extra storage class called acstor-<storage-pool-name>. An internal storage class is also created.

For clusters that use CSI drivers, the following extra storage classes are created:

Unless you specify a storage class for a persistent volume, the default storage class is used. Ensure that volumes use the storage that you need when you request persistent volumes.

The default class is the same as the managed-csi class.

For Kubernetes version 1.29 and later, when you deploy AKS clusters across multiple availability zones, AKS uses ZRS to create managed disks within built-in storage classes. ZRS ensures synchronous replication of your Azure managed disks across multiple Azure availability zones in your chosen region. This redundancy strategy enhances the resilience of your applications and helps safeguard your data against datacenter failures.

However, ZRS costs more than LRS. If cost optimization is a priority, you can create a new storage class that has the skuname parameter set to LRS. You can then use the new storage class in your persistent volume claim.

You can create a storage class for other needs by using kubectl. The following example uses premium managed disks and specifies that the underlying Azure disk should be retained when you delete the pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

AKS reconciles the default storage classes and overwrites any changes that you make to those storage classes.

For more information, see StorageClass in Kubernetes.

Persistent volume claims

A persistent volume claim requests storage of a particular storage class, access mode, and size. The Kubernetes API server can dynamically provision the underlying Azure Storage resource if no existing resource can fulfill the claim based on the defined storage class.

The pod definition includes the volume mount after the volume connects to the pod.

After an available storage resource is assigned to the pod that requests storage, the persistent volume is bound to a persistent volume claim. Each persistent volume is associated with one persistent volume claim to ensure dedicated storage.

The following example YAML manifest shows a persistent volume claim that uses the managed-premium storage class and requests an Azure disk that's 5Gi in size:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

When you create a pod definition, you also specify:

• The persistent volume claim to request the desired storage.
• The volume mount for your applications to read and write data.

The following example YAML manifest shows how the previous persistent volume claim can mount a volume at /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

To mount a volume in a Windows container, specify the drive letter and path:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

Ephemeral OS disk

By default, Azure automatically replicates the operating system disk for a virtual machine (VM) to Azure Storage to avoid data loss when the VM is relocated to another host. However, containers aren't designed to have local state persisted, so this behavior provides limited value and drawbacks. These drawbacks include slower node provisioning and higher read and write latency.

In contrast, ephemeral OS disks are stored only on the host machine, like a temporary disk. This configuration provides lower read and write latency and faster node scaling and cluster upgrades.

If you don't request Azure managed disks for the OS, AKS defaults to ephemeral OS disks if possible for a given node pool configuration.

For size requirements and recommendations, see Ephemeral OS disks for Azure VMs. Consider the following sizing considerations:

• If you use the AKS default VM size Standard_DS2_v2 SKU with the default OS disk size of 100 GiB, the default VM size supports ephemeral OS disks but only has a cache size of 86 GiB. This configuration defaults to managed disks if you don't specify it. If you request an ephemeral OS disk, you receive a validation error.

• If you request the same Standard_DS2_v2 SKU with a 60-GiB OS disk, this configuration defaults to ephemeral OS disks. The requested size of 60 GiB is smaller than the maximum cache size of 86 GiB.

• If you select the Standard_D8s_v3 SKU with a 100-GB OS disk, this VM size supports ephemeral OS disks and has a cache size of 200 GiB. If you don't specify the OS disk type, the node pool receives ephemeral OS disks by default.

The latest generation of VM series doesn't have a dedicated cache and only has temporary storage.

• If you select the Standard_E2bds_v5 VM size with the default OS disk size of 100 GiB, the VM supports ephemeral OS disks but only has 75 GB of temporary storage. This configuration defaults to managed OS disks if you don't specify it. If you request an ephemeral OS disk, you receive a validation error.

• If you request the same Standard_E2bds_v5 VM size with a 60-GiB OS disk, this configuration defaults to ephemeral OS disks. The requested size of 60 GiB is smaller than the maximum temporary storage of 75 GiB.

• If you select the Standard_E4bds_v5 SKU with a 100-GiB OS disk, this VM size supports ephemeral OS disks and has 150 GiB of temporary storage. If you don't specify the OS disk type, Azure provisions an ephemeral OS disk to the node pool.

Customer-managed keys

You can manage encryption for your ephemeral OS disk by using your own keys on an AKS cluster. For more information, see Bring your own keys with Azure managed disks in AKS.

Volumes

Kubernetes typically treats individual pods as ephemeral, disposable resources. Applications have different approaches for using and persisting data. A volume represents a way to store, retrieve, and persist data across pods and through the application lifecycle.

Traditional volumes are created as Kubernetes resources that are backed by Azure Storage. You can manually create data volumes to be assigned to pods directly or have Kubernetes automatically create them. Data volumes can use Azure disk storage, Azure Files, Azure NetApp Files, or Blob Storage.

To decide between Azure Files and Azure NetApp Files, see Azure Files and Azure NetApp Files comparison.

Azure disk storage

By default, an AKS cluster comes with precreated managed-csi and managed-csi-premium storage classes that use Azure disk storage. Similar to Amazon EBS, these classes create a managed disk or block device that's attached to the node for pod access.

The disk classes allow both static and dynamic volume provisioning. The reclaim policy ensures that the disk is deleted with the persistent volume. To expand the disk, edit the persistent volume claim.

These storage classes use Azure managed disks with LRS. Data in LRS has three synchronous copies within a single physical location in an Azure primary region. LRS is the least expensive replication option but doesn't provide protection against a datacenter failure. You can define custom storage classes that use ZRS managed disks.

ZRS synchronously replicates your Azure managed disk across three Azure availability zones in your region. Each availability zone is a separate physical location that has independent power, cooling, and networking. ZRS disks provide at least 99.9999999999% of durability over a given year. A ZRS managed disk can be attached by a VM in a different availability zone. ZRS disks aren't available in all Azure regions. For more information, see ZRS options for Azure disks to improve availability.

To mitigate the risk of data loss, use AKS backup to take regular backups or snapshots of disk storage data. Or you can use partner solutions, like Velero or Azure Backup, that have built-in snapshot technology.

You can use Azure disk storage to create a Kubernetes DataDisk resource. You can use the following disks types:

• Premium SSD (recommended for most workloads)
• Premium SSD v2
• Azure Ultra Disk Storage
• Standard SSD
• Azure Standard HDD

An Azure disk is mounted as ReadWriteOnce, so it's only available to a single node. For storage volumes that pods on multiple nodes can access simultaneously, use Azure Files.

Premium SSD v2 disks

Premium SSD v2 disks are designed for input/output(I/O)-intense enterprise workloads. They provide consistent submillisecond disk latency, high input/output operations per second (IOPS), and high throughput. You can independently configure the performance (capacity, IOPS, and throughput) of Premium SSD v2 disks at any time. So you easily improve cost efficiency while meeting performance needs. For more information about how to configure a new or existing AKS cluster to use Azure Premium SSD v2 disks, see Use Premium SSD v2 disks on AKS.

Ultra Disk Storage

Ultra Disk Storage is an Azure managed disk tier that provides high throughput, high IOPS, and consistent low-latency disk storage for Azure VMs. Use Ultra Disk Storage for data-intensive and transaction-heavy workloads. Like other disk storage SKUs and Amazon EBS, Ultra Disk Storage mounts one pod at a time and doesn't provide concurrent access.

To enable Ultra Disk Storage on your AKS cluster, use the flag --enable-ultra-ssd.

Be aware of Ultra Disk Storage limitations, and select a compatible VM size. Ultra Disk Storage has LRS replication.

Bring your own keys (BYOK)

Azure encrypts all data in a managed disk at rest, including the OS and data disks of an AKS cluster. By default, data is encrypted with Microsoft-managed keys. For more control over encryption keys, you can supply customer-managed keys to provide encryption at rest for both the OS and data disks in AKS clusters. For more information, see BYOK with Azure managed disks in AKS and Server-side encryption of Azure disk storage.

Azure Files

Disk storage can't provide concurrent access to a volume, but you can use Azure Files to mount a Server Message Block (SMB) version 3.1.1 share or NFS version 4.1 share that's backed by Azure Storage. This process provides network-attached storage that's similar to Amazon EFS. Azure Files has two storage options:

• Azure Files Standard storage backs the file share with regular hard disk drives (HDDs).

• Azure Files Premium storage backs the file share with high-performance solid-state drives (SSDs). The minimum file share size for Premium is 100 GB.

Azure Files has the following storage account replication options to protect your data if failure occurs:

• Standard_LRS: Standard LRS
• Standard_GRS: Standard geo-redundant storage (GRS)
• Standard_ZRS: Standard ZRS
• Standard_RAGRS: Standard read-access GRS (RA-GRS)
• Standard_RAGZRS: Standard read-access geo-zone-redundant storage (RA-GZRS)
• Premium_LRS: Premium LRS
• Premium_ZRS: Premium ZRS

To optimize costs for Azure Files, purchase Azure Files capacity reservations.

Azure NetApp Files

Azure NetApp Files is an enterprise-class, high-performance, metered file storage service that runs on Azure and supports volumes by using NFS (NFSv3 or NFSv4.1), SMB, and dual protocol (NFSv3 and SMB or NFSv4.1 and SMB) volumes. Kubernetes users have two options for using Azure NetApp Files volumes for Kubernetes workloads:

• Create Azure NetApp Files volumes statically. Create volumes outside of AKS via the Azure CLI or the Azure portal. After creation, these volumes are exposed to Kubernetes by creating a PersistentVolume. Statically created Azure NetApp Files volumes have many limitations. For example, they can't be expanded and they need to be overprovisioned. We don't recommend statically created volumes for most use cases.

• Create Azure NetApp Files volumes dynamically through Kubernetes. This is the preferred method to create multiple volumes directly through Kubernetes by using Astra Trident. Astra Trident is a CSI-compliant dynamic storage orchestrator that helps provision volumes natively through Kubernetes.

For more information, see Configure Azure NetApp Files for AKS.

Blob Storage

The Blob Storage CSI driver is a CSI specification-compliant driver that AKS uses to manage the lifecycle of Blob Storage. The CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes.

Adopt and use the CSI so that AKS can write, deploy, and iterate plug-ins. The plug-ins expose new storage systems or improve existing storage systems in Kubernetes. CSI drivers in AKS eliminate the need to modify the core Kubernetes code and wait for its release cycles.

When you mount Blob Storage as a file system into a container or pod, you can use it with applications that handle large amounts of unstructured data, such as:

• Log file data.
• Images, documents, and streaming video or audio.
• Disaster recovery data.

Applications can access the data on the object storage via BlobFuse or the NFS 3.0 protocol. Before the introduction of the Blob Storage CSI driver, the only option was to manually install an unsupported driver to access Blob Storage from your application that runs on AKS. A Blob Storage CSI driver that's enabled on AKS has two built-in storage classes: azureblob-fuse-premium and azureblob-nfs-premium.

To create an AKS cluster that has CSI drivers support, see CSI drivers on AKS. For more information, see Compare access to Azure Files, Blob Storage, and Azure NetApp Files with NFS.

Azure HPC Cache

HPC Cache accelerates access to your data for high-perforance computing tasks and provides the scalability of cloud solutions. If you choose this storage solution, make sure to deploy your AKS cluster in a region that supports HPC Cache.

NFS server

For shared NFS access, you should use Azure Files or Azure NetApp Files. You can also create an NFS server on an Azure VM that exports volumes.

This option only supports static provisioning. You must provision the NFS shares manually on the server. You can't provision NFS shares automatically on AKS.

This solution is based on infrastructure as a service (IaaS) rather than platform as a service (PaaS). You manage the NFS server, including OS updates, high availability, backups, disaster recovery, and scalability.

Azure Container Storage

Azure Container Storage is a cloud-based volume management, deployment, and orchestration service that's built natively for containers. It integrates with Kubernetes so that you can dynamically and automatically provision persistent volumes to store data for stateful applications that run on Kubernetes clusters.

Azure Container Storage uses existing Azure Storage offerings for actual data storage and provides a volume orchestration and management solution that's purposely built for containers. Azure Container Storage supports the following backing storage:

• Azure disks: Provide granular control of storage SKUs and configurations. Azure disks suit tier-1 and general purpose databases.

• Ephemeral disks: Use local storage resources on AKS nodes (NVMe or temp SSD). Ephemeral disks suit applications that don't have data durability requirements or that have built-in data replication support. AKS discovers the available ephemeral storage on AKS nodes and acquires them for volume deployment.

• Elastic SAN: Provision on-demand, fully managed resources. Elastic SAN suits general purpose databases, streaming and messaging services, continuous integration and continuous delivery environments, and other tier-1 or tier-2 workloads. Multiple clusters can access a single storage area network (SAN) concurrently. However persistent volumes can only be attached by one consumer at a time.

Previously, to provide cloud storage for containers, you needed individual CSI drivers to adapt storage services intended for IaaS-centric workloads. This method created operational overhead and increased the risk of problems related to application availability, scalability, performance, usability, and cost.

Azure Container Storage is derived from OpenEBS, an open-source solution that provides container storage capabilities for Kubernetes. Azure Container Storage provides a managed volume orchestration solution via microservice-based storage controllers in a Kubernetes environment. This feature enables true container-native storage.

Azure Container Storage suits the following scenarios:

• Accelerate VM-to-container initiatives: Azure Container Storage surfaces the full spectrum of Azure block storage offerings that were previously only available for VMs and makes them available for containers. This storage includes ephemeral disk storage, which provides extremely low latency for workloads like Cassandra. It also includes Elastic SAN, which provides native iSCSI and shared provisioned targets.

• Simplify volume management with Kubernetes: Azure Container Storage provides volume orchestration via the Kubernetes control plane. This feature simplifies the deployment and management of volumes within Kubernetes, without the need to switch between different control planes.

• Reduce the total cost of ownership: To improve cost efficiency, increase the scale of persistent volumes that are supported for each pod or node. To reduce the storage resources needed for provisioning, dynamically share storage resources. Scale-up support for the storage pool itself isn't included.

Azure Container Storage provides the following key benefits:

• Scale out stateful pods rapidly: Azure Container Storage mounts persistent volumes via network block storage protocols, such as NVMe-oF or iSCSI. This capability ensures fast attachment and detachment of persistent volumes. You can start small and deploy resources as needed to ensure that your applications aren't starved or disrupted during initialization or in production. When a pod respawns across the cluster, the associated persistent volume must be rapidly moved to the new pod to maintain application resiliency. By using remote network protocols, Azure Container Storage tightly couples with the pod lifecycle to support highly resilient, high-scale stateful applications on AKS.

• Improve performance for stateful workloads: Azure Container Storage enables superior read performance and provides near-disk write performance by using NVMe-oF over RDMA. This capability allows you to cost-effectively meet performance requirements for various container workloads, including tier-1 I/O-intensive, general-purpose, throughput-sensitive, and dev/test workloads. Accelerate the attach and detach time of persistent volumes and minimize pod failover time.

• Orchestrate Kubernetes-native volumes: Create storage pools and persistent volumes, capture snapshots, and manage the entire lifecycle of volumes by using kubectl commands without switching between toolsets for different control plane operations.

Partner solutions

Like Amazon EKS, AKS is a Kubernetes implementation, and you can integrate partner Kubernetes storage solutions. Here are some examples of partner storage solutions for Kubernetes:

• Rook turns distributed storage systems into self-managing storage services by automating Azure Storage administrator tasks. Rook delivers its services via a Kubernetes operator for each storage provider.

• GlusterFS is a free and open-source scalable network filesystem that uses common off-the-shelf hardware to create large, distributed storage solutions for data-heavy and bandwidth-intensive tasks.

• Ceph provides a reliable and scalable unified storage service that has object, block, and file interfaces from a single cluster that's built from commodity hardware components.

• MinIO multicloud object storage lets enterprises build AWS S3-compatible data infrastructure on any cloud. It provides a consistent, portable interface to your data and applications.

• Portworx is an end-to-end storage and data management solution for Kubernetes projects and container-based initiatives. Portworx provides container-granular storage, disaster recovery, data security, and multicloud migrations.

• Quobyte provides high-performance file and object storage that you can deploy on any server or cloud to scale performance, manage large amounts of data, and simplify administration.

• Ondat delivers a consistent storage layer across any platform. You can run a database or any persistent workload in a Kubernetes environment without having to manage the storage layer.

Kubernetes storage considerations

Consider the following factors when you choose a storage solution for Amazon EKS or AKS.

Storage class access modes

In Kubernetes version 1.21 and later, by default AKS and Amazon EKS storage classes use CSI drivers only.

Different services support storage classes that have different access modes.

Dynamic vs. static provisioning

Dynamically provision volumes to reduce the management overhead of statically creating persistent volumes. Set an appropriate reclaim policy to eliminate unused disks when you delete pods.

Backup

Choose a tool to back up persistent data. The tool should match your storage type, such as snapshots, Azure Backup, Velero or Kasten.

Cost optimization

To optimize Azure Storage costs, use Azure reservations if the service supports them. For more information, see Cost management for a Kubernetes cluster.

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal authors:

• Paolo Salvatori | Principal System Engineer
• Laura Nicolas | Senior Cloud Solution Architect

Other contributors:

• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Technical Writer

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• Training: Azure Storage services
• Training: Store data in Azure
• Training: Introduction to Kubernetes
• Training: Introduction to Azure NetApp Files

Related resources

• AKS for Amazon EKS professionals
• Kubernetes identity and access management
• Kubernetes monitoring and logging
• Secure network access to Kubernetes
• Cost management for Kubernetes
• Kubernetes node and node pool management
• Cluster governance