From Cloud Foundry to Kubernetes: training for developers

We offer private, instructor-led training for developers who use Cloud Foundry and need to deploy applications on a Kubernetes-based platform.

Your team already knows cf push, routes, buildpacks, and service bindings. The move requires decisions about who will build images, configure releases, provide credentials, and manage traffic routes.

LearnKube connects your current workflow to Kubernetes through a sample application. Your engineers will practice the steps from a built image to a reachable, supportable release.

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.

Make the deployment workflow explicit

  • Deploy the application by defining its image, workload resources, and runtime configuration, so engineers can repeat the release on Kubernetes.
  • Preserve routes and dependencies by configuring traffic and credential delivery, so the application remains reachable and can access its services.
  • Diagnose failed releases by inspecting image pulls, Pod logs, and readiness, so developers distinguish build, startup, and routing problems.
  • Agree on platform responsibilities by documenting build, release, and support ownership, so developers know which capabilities the destination provides.

Make the steps behind a push visible

Cloud Foundry combines several application-delivery steps in cf push, including staging and deployment. Kubernetes-based platforms can offer similar features, but Kubernetes itself needs runnable container images and declared resources. Engineers must identify which build, release, routing, and credential services the destination provides before choosing their deployment workflow.

I want developers to name the steps their platform performs before they write their first Kubernetes manifests. Replacing cf push means deciding who builds each image, supplies the credentials, and makes the new release reachable.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Push application sourceImage build and releaseDeploy a versioned image
Map an application routeServices and ingressTrace the public route
Bind a backing serviceCredentials and endpoint configurationConnect an application dependency
Scale application instancesReplicas and autoscaling metricsObserve scaling under load

How we approach this transition

We propose a workshop around a representative application and one backing service. Your team maps the steps that Cloud Foundry handles today to the capabilities of the Kubernetes destination.

This comparison shows which tasks stay automated and which ones your team needs to configure. The exercises cover releases, dependency access, and support responsibilities for developers and the platform team.

A recommended four-day workshop for application teams

This proposed agenda makes the release workflow clear. It connects Kubernetes basics to the tasks your developers already perform in Cloud Foundry.

Day 1

We explain container images and runtime configuration, then show how they relate to Pods, Deployments, and Services. You will compare application health checks with probes and rollout behavior.

Hands-on exercises

  • Deploy a versioned image with explicit runtime configuration.
  • Introduce a startup failure and restore the previous release.

Day 2

You will compare Helm and Kustomize for application configuration. We explain controllers, the control plane, and nodes to help developers understand recovery beyond a single instance.

Hands-on exercises

  • Package an application's release configuration for two environments.
  • Simulate a node failure and observe replica replacement.

Day 3

We connect application routes to DNS, Services, ingress, and TLS configuration. You will discuss network policies, service mesh use cases, and placement decisions on shared nodes.

Hands-on exercises

  • Trace an application request from ingress to a Pod.
  • Diagnose a blocked connection to a backing service.

Day 4

You will compare service binding expectations with secrets, endpoint configuration, and platform integrations. We explain persistent storage, autoscaling, authentication, and RBAC.

Hands-on exercises

  • Supply dependency credentials and verify application access.
  • Generate application load and observe metrics-based replica changes.

Your build workflow, backing services, and platform-support responsibilities can shape the agenda. Get in touch to tailor the workshop to your Cloud-Foundry-to-Kubernetes transition.

Find the missing step in a familiar workflow

If an engineer applies a Deployment and expects the platform to build the image, the instructor can trace the release from source to registry. Your team can see where its build service ends and Kubernetes begins.

I really liked how well everything was structured and how a lot of concepts would fall back towards previous lessons to paint a bigger picture on how kubernetes operates as a whole.

— Jonathan, Software Engineer at Coinbase.

Start with your application delivery workflow

Tell us how you use Cloud Foundry, which capabilities the Kubernetes platform will provide, and who will own builds and operations. We will recommend exercises for those changes.

Discuss your team's training