From self-managed Kubernetes to Google GKE: training for platform teams

We offer private, instructor-led training for platform engineers who operate Kubernetes and need to move workloads and responsibilities to Google GKE.

Your team knows the Kubernetes API and existing cluster procedures. The selected GKE operating model changes infrastructure control, while Google Cloud identity, networking, and storage introduce additional integration decisions.

LearnKube uses a representative workload to connect those differences. Your engineers will inspect resource requirements, maintenance behavior, and application access on the intended destination.

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.

Match workload requirements to the GKE operating model

  • Deploy a compatible workload by reviewing resource, host-access, and integration requirements, so the application fits the selected GKE compute configuration.
  • Preserve service and data access by examining traffic, storage, and workload identity, so a familiar Kubernetes resource has the Google Cloud capabilities it requires.
  • Diagnose destination-specific failures by comparing admission results, Pod events, IAM decisions, and infrastructure evidence, so engineers can identify the responsible control.
  • Assign continuing operations by documenting maintenance, capacity, data recovery, and escalation duties, so the team understands the responsibilities of its chosen operating model.

The compute model changes the operating assumptions

GKE surrounds Kubernetes workloads with managed infrastructure and Google Cloud integrations. Autopilot manages additional infrastructure settings and applies workload defaults, while Standard provides more direct infrastructure control. Applications can use Workload Identity Federation for Google Cloud access. The team must review its chosen compute model, resource requirements, and identity configuration rather than transfer every node-level assumption unchanged.

I review host access, resource requests, and maintenance assumptions before we choose a compute model. A workload that relied on manual node changes needs a different operating plan when those nodes are managed for the team.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Configure workload capacityCompute model and resource defaultsInspect admitted resource settings
Access Google Cloud APIsWorkload Identity FederationDiagnose denied service access
Maintain node versionsGKE maintenance responsibilitiesReview a disruption scenario
Attach application storageDrivers, access, and placementInspect a volume constraint

How we approach this transition

We propose a workshop based on your current cluster and the GKE operating model you intend to use. The team identifies workload dependencies on node configuration, infrastructure services, and permissions.

The exercises compare those requirements with the selected destination. They distinguish cluster and workload configuration from Google-managed behavior, including the capabilities and constraints relevant to Standard or Autopilot operation.

A recommended four-day workshop for Kubernetes teams adopting GKE

This proposed agenda shortens familiar container and Kubernetes fundamentals. It focuses on the operating assumptions and integrations that change on GKE.

Day 1

We review application configuration, resource requests, probes, and rollout behavior. You will compare the submitted workload with the settings admitted by the chosen GKE configuration.

Hands-on exercises

  • Deploy a representative application and inspect its effective resource settings.
  • Diagnose a release rejected or left unready by a destination requirement.

Day 2

You will use Helm and compare Kustomize for destination-specific resources. We examine control-plane and node responsibilities, release channels, and the maintenance behavior relevant to the selected operating model.

Hands-on exercises

  • Prepare a repeatable release with explicit GKE-dependent settings.
  • Review a workload disruption scenario against replicas, placement, and maintenance controls.

Day 3

We trace DNS, Services, ingress, and Google Cloud traffic integrations. You will examine network policies, service mesh use cases, affinity, and the placement requirements of workloads and storage.

Hands-on exercises

  • Diagnose a service whose Google Cloud traffic path does not reach the application.
  • Inspect a volume or placement requirement that conflicts with available capacity.

Day 4

You will connect Kubernetes service accounts to the selected Google Cloud access model. We cover secrets, persistent storage, RBAC, HPA metrics, and the distinction between workload demand and managed compute capacity.

Hands-on exercises

  • Trace a sample Google Cloud API request to its workload identity and IAM permissions.
  • Compare application load, requested resources, and the capacity response of the selected environment.

Your GKE compute model, Google Cloud dependencies, and operational responsibilities can shape the agenda. Get in touch to tailor the workshop to your self-managed-Kubernetes-to-GKE transition.

Find the node assumption that does not transfer

When an engineer expects to repair a workload by changing its node manually, the instructor can examine the image, resource settings, and platform constraints. Your team can identify a repeatable workload-level correction or a compute requirement that needs review.

The labs were great and the instructor was really knowledgeable.

— Stephen, Senior Application Developer at Baillie Gifford.

Bring the workload dependencies and intended GKE model

Tell us how you operate Kubernetes today, which GKE compute model you plan to use, and who will own workload and infrastructure decisions. We will recommend exercises for that transition.

Discuss your team's training