AKS Storage

The course is part of these learning paths

AZ-303 Exam Preparation: Technologies for Microsoft Azure Architects
course-steps
28
certification
4
lab-steps
13
description
1
AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
course-steps
18
certification
1
lab-steps
5
description
1
AZ-104 Exam Preparation: Microsoft Azure Administrator
course-steps
20
certification
2
lab-steps
16
play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 42m
Students1490
Ratings
3.7/5
starstarstarstar-halfstar-border

Description

AKS is a super-charged Kubernetes managed service which makes creating and running a Kubernetes cluster a breeze!

This course explores AKS, Azure’s managed Kubernetes service, covering the fundamentals of the service and how it can be used. You’ll first learn about how as a managed service it takes care of managing and maintaining certain aspects of itself, before moving onto the core AKS concepts such as cluster design and provisioning, networking, storage management, scaling, and security. After a quick look at Azure Container Registry, the course then moves on to an end-to-end demonstration that shows how to provision a new AKS cluster and then deploy a sample cloud-native application into it.

For any feedback, queries, or suggestions relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Learn about what AKS is and how to provision, configure and maintain an AKS cluster
  • Learn about AKS fundamentals and core concepts
  • Learn how to work with and configure many of the key AKS cluster configuration settings
  • And finally, you’ll learn how to deploy a fully working sample cloud-native application into an AKS cluster

Intended Audience

  • Anyone interested in learning about AKS and its fundamentals
  • Software Engineers interested in learning about how to configure and deploy workloads into an AKS cluster
  • DevOps and SRE practitioners interested in understanding how to manage and maintain an AKS cluster

Prerequisites

To get the most from this course it would help to have a basic understanding of:

  • Kubernetes (if you’re unfamiliar with Kubernetes, and/or require a refresher then please consider taking our dedicated Introduction to Kubernetes learning path)
  • Containers, containerization, and microservice-based architectures
  • Software development and the software development life cycle
  • Networks and networking

Resources

If you wish to follow along with the demonstrations in part two of this course, you can find all of the coding assets hosted in the following three GitHub repositories:

Transcript

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.

About the Author
Students41680
Labs34
Courses94
Learning paths28

Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.

Jeremy holds professional certifications for both the AWS and GCP cloud platforms.