From self-managed Kubernetes to Azure AKS: training for platform teams

We offer private, instructor-led training for Kubernetes platform engineers who need to adopt Azure AKS after administering their own clusters.

Your team understands Kubernetes resources and operating procedures. Azure identity and infrastructure introduce separate responsibilities, including cluster access, workload credentials, networking, storage, and node maintenance.

LearnKube connects these changes through a representative application on the selected AKS configuration. Your engineers will trace workload behavior and identify the boundary between Azure and Kubernetes decisions.

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

  • Hands-on learning
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    Of respondents applied their new skills at work within 90 days.
  • Deploy the workload on AKS by reviewing its network, storage, and node-pool requirements, so the application uses the destination's actual infrastructure capabilities.
  • Preserve intended permissions by distinguishing operator authentication from workload identity, so applications and engineers receive the access appropriate to their roles.
  • Diagnose integration failures by inspecting Pod events, Azure access results, and network paths, so the team can identify the system responsible for a failed operation.
  • Assign maintenance ownership by documenting upgrades, node pools, credentials, and escalation paths, so Azure-managed components do not obscure continuing team duties.

AKS adds Azure identity and infrastructure behavior around Kubernetes resources. Microsoft Entra integration supports user authentication to the cluster, while Microsoft Entra Workload ID supports applications that access protected external services. These paths do not replace each other's permissions. The team must also account for the cluster's own Azure identity and chosen authorization model.

An engineer's Entra login and a Pod's workload identity solve different problems. I trace the identity presented at the failing boundary before I decide whether the fix belongs in Azure permissions or Kubernetes role bindings.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Authenticate an operatorEntra and cluster authorizationInspect an access failure
Access an Azure serviceWorkload identity federationTrace a workload credential
Provision persistent storageAzure storage integrationDiagnose a provisioning failure
Maintain worker capacityNode pools and upgradesReview workload disruption

We propose a workshop that compares your existing cluster responsibilities with the selected AKS configuration. The team examines identity, network, storage, and node-pool choices before adapting its operating procedures.

The exercises use a representative application and one Azure dependency. They explain which controls govern each request and which responsibilities remain with your engineers during releases, maintenance, and incidents.

This proposed agenda builds on your current Kubernetes experience. It concentrates on Azure integrations and the operating boundaries that change during the move.

Day 1

We review the application's configuration, probes, and rollout requirements on AKS. You will identify dependencies on the selected network, storage, and compute configuration.

  • Deploy a representative workload and inspect its integration-dependent resources.
  • Introduce an unready release and examine the resulting availability and rollback decisions.

Day 2

You will use Helm and compare Kustomize for repeatable AKS configuration. We review the control plane, nodes, and controllers, including the maintenance duties associated with the selected node options.

  • Separate workload configuration from environment-specific AKS settings.
  • Rehearse a controlled node drain and inspect the workload's disruption constraints.

Day 3

We trace Pod traffic, DNS, Services, ingress, and external dependencies through the selected Azure network model. You will examine network policies, service mesh use cases, and node-pool placement.

  • Diagnose an application route that does not reach its intended backend.
  • Inspect a workload that cannot reach a required Azure endpoint or suitable node pool.

Day 4

You will distinguish user, workload, and cluster identities alongside Kubernetes authorization. We cover secrets, persistent storage, autoscaling metrics, and the boundary between replica demand and node capacity.

  • Verify a workload's Azure access through the selected identity configuration.
  • Compare an Azure authorization failure with a Kubernetes RBAC denial and identify the appropriate correction.

Your AKS configuration, Azure dependencies, and platform responsibilities can shape the agenda. Get in touch to tailor the workshop to your self-managed-Kubernetes-to-AKS transition.

When an engineer expects a successful Entra login to grant application access to an Azure service, the instructor can trace the user and workload paths separately. Your team can identify the identity and permission required at each boundary.

The trainer provided detailed, and in-depth knowledge sharing of the subject, providing examples, use cases, and answering questions with real world examples

— Ahjaz, .NET Developer at EDF Trading.

Tell us how you administer Kubernetes today, which AKS integrations and node options you plan to use, and who will own each responsibility. We will recommend exercises for the Azure operating model.