EEdukron DevOps Library
KubernetesAdvanced17 submodules

Azure Kubernetes Service Engineering

Design and operate AKS clusters with appropriate node pools, networking, registry access, Entra integration, managed identity, secret delivery, ingress, scaling, upgrades, monitoring, and security.

How this module works

From concept to production evidence

Keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Learning outcomes

  • Explain AKS-managed and customer-managed responsibilities
  • Design node pools and networking
  • Integrate ACR, Entra ID, managed identity, and Key Vault
  • Choose ingress and autoscaling approaches
  • Plan upgrades, monitoring, and security

Flow diagram

Azure Kubernetes Service Engineering end-to-end flow

Use this sequence as the operating backbone for every submodule note and hands-on exercise.

  1. 01
    Design clusterAzure Kubernetes Service Engineering stage 1: design cluster with an auditable result before the next stage begins.
  2. 02
    Provision network and identityAzure Kubernetes Service Engineering stage 2: provision network and identity with an auditable result before the next stage begins.
  3. 03
    Create node poolsAzure Kubernetes Service Engineering stage 3: create node pools with an auditable result before the next stage begins.
  4. 04
    Integrate platform servicesAzure Kubernetes Service Engineering stage 4: integrate platform services with an auditable result before the next stage begins.
  5. 05
    Deploy and scale workloadsAzure Kubernetes Service Engineering stage 5: deploy and scale workloads with an auditable result before the next stage begins.
  6. 06
    Monitor, secure, and upgradeAzure Kubernetes Service Engineering stage 6: monitor, secure, and upgrade with an auditable result before the next stage begins.

Official Microsoft reference

Architecture diagrams from Microsoft documentation

Use these diagrams beside the original Edukron notes and flows to compare the learning model with the official product and architecture view.

Official Microsoft architecture for building and deploying AKS applications with Azure Pipelines, ACR, security, and observability.

Azure Pipelines CI/CD architecture for AKS

The architecture connects PR validation, CI, container registries, staged AKS deployment, promotion, security scanning, Key Vault, Azure Monitor, Prometheus, Grafana, and Log Analytics.

Integrated hands-on lab

Build a production AKS baseline

  1. Choose network and private-access design
  2. Create system and user node pools
  3. Integrate ACR and workload identity
  4. Configure ingress, secrets, and autoscaling
  5. Test monitoring and upgrade procedure

Complete module contents

17 full submodule notes

Read in order
01

AKS architecture

AKS architecture defines the major responsibilities, boundaries, and control flow that engineers use before selecting an implementation detail within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
02

AKS clusters

AKS clusters provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
03

Node pools

Node pools provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
04

System/User node pools

System/User node pools provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
05

AKS networking

AKS networking governs how a request is named, addressed, routed, filtered, transported, protected, and delivered to a healthy endpoint within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
06

Azure CNI

Azure CNI provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
07

Kubenet

Kubenet provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
08

ACR integration

ACR integration provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
09

Entra integration

Entra integration provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
10

Managed Identity

Managed Identity controls which actor may perform which action on which resource, under which conditions, with evidence that can be reviewed later within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
11

Key Vault integration

Key Vault integration controls which actor may perform which action on which resource, under which conditions, with evidence that can be reviewed later within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
12

Application Gateway

Application Gateway governs how a request is named, addressed, routed, filtered, transported, protected, and delivered to a healthy endpoint within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
13

Ingress

Ingress governs how a request is named, addressed, routed, filtered, transported, protected, and delivered to a healthy endpoint within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
14

Autoscaling

Autoscaling provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
15

AKS upgrades

AKS upgrades provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
16

AKS monitoring

AKS monitoring turns service behavior into evidence that supports detection, diagnosis, capacity decisions, and measurable reliability within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes
17

AKS security

AKS security controls which actor may perform which action on which resource, under which conditions, with evidence that can be reviewed later within Azure Kubernetes Service Engineering. It is not an isolated definition: its value appears when it supports keep platform and application responsibilities explicit, isolate system workloads, select a networking model before address exhaustion becomes a constraint, integrate Azure services through identity, and upgrade through tested rings.

Open full notes