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:
Okay, welcome back. In this lesson, I'm going to introduce you to the Azure container registry, ACR. ACR enables you to create and host your own private Docker container registries directly within Azure.
Creating your own Azure container registry allows you to push container images into it that might be considered private to your organization and for which you wouldn't want to push into a public container registry such as DockerHub.
Creating a new ACR is simple and quick with options to do it either within the Azure web portal or on the command line using the Azure CLI.
The following diagram highlights the typical developer workflow that is used when working with both AKS and ACR. The workflow involves the following sequence: One, the developer creates a Dockerfile on their local workstation containing the build instructions for their container image. Two, the developer performs a docker build locally and tags it. The format of the tag must include the custom ACR hostname. This is used at container push time, instructing the push where to send the container image. Three, the developer performs a docker push of the container image using the tag created in the previous step. When this is completed, the container image that the developer built locally will have just been uploaded into the ACR registry. Four, the developer then creates a Kubernetes YAML manifest file which declares the desired running state for the pods within the AKS cluster. The manifest file references the container image using the same tag created in step two. Five, the developer applies the manifest file into the AKS cluster. Six, AKS now pulls down the container image from ACR authenticating to ACR before the image is pulled down. And seven, AKS finally launches the pods on the worker nodes.
Integrating ACR with AKS can be accomplished multiple ways. The first way is to create a Kubernetes secret encapsulating the authentication credentials for ACR within your cluster, and then have the developer reference this secret within their deployment manifest file using the imagePullSecret property.
The second way is to leverage a Kubernetes service account within the cluster, and then have the developer reference the service account within their deployment manifest file using the serviceAccountName property. A Kubernetes secret is still used, but this time is referenced by the service account. Both this option and the previous option can be used within clusters that run outside of AKS.
The third and final way is to leverage an Azure AD service principal. Unlike the first two approaches, this approach involves integration that happens outside of the cluster. The benefit with this approach is that the deployment manifest only needs to specify the image tag within the image property.
AKS will authenticate to ACR using the service principal. This makes the deployment manifests much simpler. The service principal used and configured within AKS must be granted ACRPull permissions to access the Azure container registry allowing it to pull down any referenced images. This option will only work when the cluster runs within AKS.
Okay, that completes this lesson. In this lesson, I introduced you to ACR and how it can be used to host your own private container registries within Azure. I then showed you three ways in which you can configure authentication between AKS and ACR to allow AKS to pull down container images.
Okay, go ahead and close this lesson, and I'll see shortly in the next one.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).