Okay, welcome back. In this lesson, I'm gonna take you through the various options available when working with storage within AKS.

When it comes to deploying your workloads into AKS, you do so by using pods, which are the basic building blocks for constructing applications within Kubernetes. Pods are mostly expected to be ephemeral, or stateless, to benefit from the Kubernetes distributed systems design and cluster architecture. Being ephemeral allows them to be resilient to restarts, rebalancing, and scale-out and in scenarios.

Having said that, it would be unreasonable to dictate that all pods must be stateless. Meaningful workloads deployed into Kubernetes will naturally have a requirement to track and maintain data. When this is the case, pods need to be able to persist data to a location which has the required levels of durability to either out live container restarts within a pod or to out live pod termination.

To provide persistence to pods, Kubernetes introduces the concepts of volumes and persistent volumes. The main differences between volumes and persistent volumes are the following: A volume decouples the storage from a container. Its lifecycle is coupled to the pod, and it enables safe container restarts and sharing of data between containers within a pod. A persistent volume, on the other hand, decouples the storage from the pod. Its lifecycle is entirely independent of the pod, and it enables safe pod restarts and sharing of data between pods.

Starting with volumes, a volume exists in the context of a pod. Volumes survive container restarts within the same pod, but when a pod ceases to exist, the volume within the same pod also ceases to exist.

Volumes have different backend implementations. Kubernetes has several inbuilt volume types, for example, the EmptyDir, HostPath, Secret and ConfigMap volume types. Additional to these volume types, Kubernetes also supports external provider based volume types including the AKS specific volume types, Azure disk and Azure files.

I'll now quickly cover off each of these volume types so that you know which ones to use and when to use them.

The EmptyDir volume type provides an empty volume that can be mounted to multiple containers at the same time within the same pod. All containers within the same pod mounting the same volume will see the same data stored on it. When the pod is terminated, the EmptyDir volume is also deleted and all data written to it is vaporized with absolutely no ability to ever restore it. The EmptyDir volume type is often used to provide temporary storage space for the pod.

HostPath volume types can be used to provide a volume which mounts down to the host node's file system. Useful at times, but can be considered a security risk. This can be managed through the use of a pod security policy applied at the cluster level and for which can control which allowed host paths can be used. Furthermore, this policy can dictate whether the mounted paths are read-only or not.

The Secret volume type is used as a delivery mechanism for sensitive information such as passwords, tokens, and/or even SSH private keys. A Pod which mounts a Secret volume can read the sensitive information as if it were just a simple file.

The ConfigMap volume type is useful for extracting and decoupling configuration material from container images, and in doing so eases the burden of maintaining configuration. Additionally, with the configuration held externally, container image rebuilds are reduced.

Now, when it comes to AKS, AKS hosted pods can leverage either Azure disk or Azure file based volumes. Both of these volume types are much more durable and persistent than the EmptyDir volume type. When an AKS pod is deleted, the data stored on these volume types is preserved with the volume being simply unmounted.

Another benefit of using Azure disk or Azure file based volumes is the fact that they can be preloaded with data before being mounted into an AKS pod.

I'll dive deeper into both Azure files and Azure disks in the coming slides, but next I wanted to briefly talk about the concept of persistent volumes.

A persistent volume or PV, as already mentioned is completely decoupled from the pod itself. PVs have a lifecycle which is completely independent of a pod's lifecycle, meaning PVs are very durable. A pod references and mounts a PV using a persistent volume claim or PVC.

Persistent volumes can either be pre-created manually or can be dynamically provisioned at the time of pod creation.

As with plain volumes, AKS can create persistent volumes using either Azure disk or Azure files based storage volumes. Let's now dive into the specifics of Azure disks and Azure files. 

Now regardless of whether you choose to create pods with standard volumes or the more durable form, persistent volumes, either can be created using Azure disks or Azure files as their backend storage layer. Azure disks act like a typical storage disk when attached to a pod. Azure disks are mounted as ReadWriteOnce, and therefore can only be attached to a single pod at a time. Azure disks come in two flavors, Premium and Standard. Premium-based Azure disks are SSD backed, providing faster IOPs. Standard-based Azure disks are backed by slower hard disk drives and therefore have slower IOPs.

Azure files provide a fully managed shared storage layer which can be mounted to multiple pods at the same time. Each and every pod that mounts the same Azure files shared storage layer sees and shares all of the data on it at the same time. Like Azure disks, Azure files have the same performance categories, Premium and Standard.

Deciding whether to go with either Azure disks or Azure files for your backend pod storage layer really comes down to whether you want to share the same data to multiple pods at the same time, or instead you require each pod to have its own dedicated and isolated storage area so that data is not shared. Azure files should be used for the shared data option, and Azure disks should be used for the isolated data option.

Okay, that completes this lesson. In this lesson, I introduced you to the various storage options available in Kubernetes and AKS. Kubernetes provides the volume and persistent volume resources, and AKS provides the Azure disks and Azure files storage backend implementations.

Okay, go ahead and close this lesson, and I'll see shortly in the next one.