From Azure Container Apps to Kubernetes: training for engineers

We offer private, instructor-led training for engineers who use Azure Container Apps and need to operate their workloads directly on a Kubernetes platform.

Your team already understands container images and managed revisions. The destination needs explicit release, traffic, and scaling mechanisms, rather than only a replacement manifest for the image.

LearnKube uses a versioned HTTP service and background worker to connect those responsibilities. Your engineers will practice releases, traffic control, and diagnosis of missing platform integrations.

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 by separating images, configuration, and controller resources, so engineers can explain how the application starts and changes on Kubernetes.
  • Preserve release behavior by selecting traffic controls and readiness checks, so the destination can direct requests to the intended version.
  • Diagnose failed scaling by inspecting workload status, metric availability, and controller configuration, so engineers can distinguish missing signals from insufficient capacity.
  • Assign integration ownership by documenting ingress, identity, and event-scaling responsibilities, so the team knows which components the platform must operate.

Container Apps revisions version container settings while the service manages activation and traffic. A Kubernetes Deployment controls a Pod rollout, but traffic allocation, identity, and event-based scaling can require separate components. The team needs to identify its current revision and scale rules before it chooses equivalent behavior for the target cluster.

An image tag identifies the artifact, not the complete release behavior. I want teams to name the traffic controller and scaling signal before they assume a Deployment can replace their current revision workflow.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Activate a revisionDeployments and rollout controlsInspect release readiness
Divide incoming trafficRouting and version selectorsTrace requests by version
React to workload demandMetrics APIs and adaptersDiagnose missing scaling data
Access an Azure dependencyWorkload identity integrationInspect credential delivery

We propose a workshop based on the Container Apps features your team actually uses. The comparison records revision behavior, ingress rules, identities, and scaling signals before selecting Kubernetes components.

The exercises use a service and worker to expose those dependencies. Provider-specific identity and event-scaling examples depend on the target cluster, so the proposed agenda distinguishes core Kubernetes behavior from additional integrations.

This proposed agenda keeps container basics brief. It concentrates on the components and operating responsibilities behind your current managed features.

Day 1

We compare revision expectations with Pods, Deployments, Services, and probes. You will distinguish a successful rollout from the routing decisions that expose a particular version.

  • Deploy two application versions with identifiable responses.
  • Introduce an unready version and inspect which replicas can receive traffic.

Day 2

You will use Helm and compare Kustomize for repeatable workload configuration. We explain controllers, the control plane, and nodes so engineers can locate the component responsible for each action.

  • Package the service and worker configuration as a release.
  • Simulate a node failure and track controller-driven replacement.

Day 3

We examine DNS, Services, ingress controllers, and version selectors. You will compare network policies, service mesh use cases, and workload placement with the features supplied by the source environment.

  • Trace which application version receives a request through the selected route.
  • Diagnose a blocked connection between the worker and its dependency.

Day 4

You will connect HPA behavior to resource, custom, and external metrics. We cover secrets, persistent storage, authentication, and RBAC, and identify where event-driven or identity integrations add separate components.

  • Remove a required metric source and inspect why the workload does not scale as expected.
  • Verify credential delivery and dependency access for the selected destination.

Your revision modes, event sources, and destination integrations can shape the agenda. Get in touch to tailor the workshop to your Container-Apps-to-Kubernetes transition.

When an engineer copies a scaling threshold and expects it to operate immediately, the instructor can trace the metric to its provider. Your team can identify the missing adapter or controller instead of repeatedly changing replica limits.

Asked what he liked most about the course, Tom described how its pace adapted to the group:

The speed was dynamic and based on our desires and capabilities

— Tom, Staff Software Engineer at Bluestaq.

Tell us which Container Apps features you use, which cluster will host the workloads, and who will operate the replacement integrations. We will recommend an agenda for those responsibilities.