From Google Cloud Run to Kubernetes: training for application teams

We offer private, instructor-led training for application engineers who use Google Cloud Run and need to operate containerized services on Kubernetes.

Your team already builds container images. Request concurrency and managed scaling defaults do not transfer with the image, and the destination needs explicit traffic and identity decisions.

LearnKube uses a sample API under changing load to connect those controls. Your engineers will investigate request handling, resource demand, and the signals that drive replica changes.

Discuss your team's training

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

Preview: course-wide figures are not yet available.

  • Hands-on learning
    60%
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    86%
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    92%
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    95%
    Of respondents applied their new skills at work within 90 days.

Rebuild the operating model around the container

  • Deploy the API by defining workload resources, health checks, and routes, so the service can accept requests through the destination platform.
  • Preserve request behavior by examining concurrency, timeouts, and scaling signals, so replica changes reflect the application's actual capacity needs.
  • Diagnose degraded service by comparing request behavior with Pod metrics, readiness, and endpoints, so engineers distinguish application pressure from traffic or capacity problems.
  • Assign platform responsibilities by documenting ingress, identity, metrics, and node ownership, so the team knows which managed behaviors need explicit replacements.

Replica count is not a request-handling contract

Cloud Run uses concurrency settings as part of its managed request-handling and scaling model. A Kubernetes Deployment maintains replicas, while an HPA changes their number from metrics. Those resources do not establish the application's concurrency limit or reproduce Cloud Run's traffic behavior. Scaling to zero requires an explicit design for the destination.

Replica count does not tell me how many requests one process can handle. I start with application concurrency and a useful pressure metric, then decide how the cluster will add capacity.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Handle concurrent requestsApplication limits and resourcesApply concurrent load
Reach a service versionServices and ingress routingTrace requests to replicas
Scale with demandHPA metrics and capacityCompare load and replicas
Access a cloud serviceWorkload identity integrationDiagnose denied access

How we approach this transition

We propose a workshop around a containerized API and the request behavior it must preserve. Your team identifies its concurrency requirements, external dependencies, and current traffic controls.

The exercises separate application limits from Kubernetes replica management. We examine the selected destination's metrics, ingress, and identity integrations rather than assume that Cloud Run's operational defaults appear automatically on another platform.

A recommended four-day workshop for Cloud Run teams

This proposed agenda builds on your container experience. It emphasizes the relationship between requests, workload resources, and cluster capacity.

Day 1

We connect the existing image to Pods, Deployments, and Services. You will examine startup and readiness behavior, then compare rollout status with the responses that clients actually receive.

Hands-on exercises

  • Deploy the API with explicit ports, resource requests, and probes.
  • Release an unhealthy version and investigate its effect on client requests.

Day 2

You will use Helm and compare Kustomize for environment configuration. We explain controllers, the control plane, and kubelets through failures that replace application instances.

Hands-on exercises

  • Package the workload and route configuration for two environments.
  • Simulate a node failure and observe the API's recovery behavior.

Day 3

We trace requests through DNS, ingress, Services, and Pods. You will discuss network policies, service mesh use cases, and placement rules, including capacity shared with other applications.

Hands-on exercises

  • Diagnose a request that reaches the cluster but not the intended application.
  • Inspect a placement failure that prevents additional replicas from starting.

Day 4

You will compare application load with CPU and custom metrics used by the HPA. We cover configuration, secrets, persistent state, authentication, and RBAC, with provider identity treated as a separate integration.

Hands-on exercises

  • Change request concurrency and inspect latency, resource use, and replica behavior.
  • Verify access to an external dependency through the destination's credential mechanism.

Your request patterns, cloud dependencies, and scaling requirements can shape the agenda. Get in touch to tailor the workshop to your Cloud-Run-to-Kubernetes transition.

Separate a concurrency limit from a scaling signal

When an engineer expects more replicas to resolve every slow request, the instructor can vary concurrency and inspect the application process. The exercise connects request behavior to resources and metrics instead of treating replica count as the only control.

Go ahead, and actually do all the labs! They're fun and you learn the things you normally don't.

— Christian, DevOps Engineer at BMW.

Bring the request behavior you need to preserve

Tell us how your services use Cloud Run, what the Kubernetes destination must provide, and who will own traffic and capacity. We will recommend exercises for those decisions.

Discuss your team's training