Kubernetes and Argo CD training for customer support engineers

We offer private, instructor-led training for product support engineers who help customers use GitOps-based Kubernetes delivery.

Your team recognizes the delivery interface. A failed sync and an unhealthy workload are different problems, with different evidence, configuration owners, and corrective actions.

LearnKube connects source configuration, rendered resources, controller behavior, and application health through a representative customer support investigation.

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.

Connect the delivery signal to the Kubernetes behavior

  • Trace a customer release by following source, rendered resources, and live state, so support engineers can explain where delivery stopped or diverged.
  • Preserve the intended configuration by identifying controller ownership and the supported change path, so a manual correction does not conflict with reconciliation.
  • Diagnose sync or health failures by comparing controller evidence with workload state, so the team can separate configuration, permissions, and application causes.
  • Prepare a customer or engineering handoff by recording the relevant revision and observed behavior, so the next owner can reproduce or correct the issue.

Configuration agreement and application health answer different questions

Argo CD's sync status compares live resources with desired configuration. Its health assessment evaluates resource behavior through defined checks. These signals do not establish the same condition. Customer support engineers need to trace the source revision, rendered objects, controller permissions, and workload evidence before deciding whether the problem belongs to delivery configuration or application operation.

I ask whether the problem is agreement with desired configuration or failure of the resulting workload. Repeating a sync cannot fix a missing dependency if the controller is already applying exactly the requested resources.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Customer task or requirementKubernetes decisionPractice
Identify the intended releaseSource revision and rendered resourcesCompare desired and live state
Interpret delivery statusSync and health semanticsExplain two different failures
Correct a configuration problemReconciliation and change ownershipTrace the supported change path
Escalate a reproducible issueResource state and controller evidencePrepare an engineering report

Your team is not alone in customer GitOps support

Akuity supports enterprise and open-source users of its delivery tooling. Its technical support work includes Kubernetes and Argo CD diagnosis, documentation, customer communication, and escalation to product engineering.

For teams responsible for that work, we recommend a four-day workshop connecting Kubernetes mechanisms to GitOps symptoms and useful customer explanations.

A recommended four-day workshop for GitOps support teams

This proposed agenda uses a selected Argo CD example alongside the core Kubernetes course. Engineers connect its sync and health signals to observations they can explain to the customer.

Day 1

We connect Pods, Deployments, Services, probes, and rollouts to the application's behavior. You will distinguish the submitted configuration from its operational result.

Hands-on exercises

  • Deploy a sample release and inspect its workload health.
  • Create a configuration that applies successfully but cannot become ready.

Day 2

You will examine Helm and Kustomize output alongside controller and API responsibilities. We follow configuration from its source to the live objects that Kubernetes operates.

Hands-on exercises

  • Compare a source revision, rendered resources, and live state.
  • Diagnose a reconciliation problem caused by configuration or permissions.

Day 3

We trace DNS, Services, ingress, network policy, mesh interactions, and scheduling. The investigation connects a delivery dashboard's status to the actual workload dependency.

Hands-on exercises

  • Diagnose an unhealthy application route after synchronization.
  • Inspect a placement or policy constraint that prevents the desired workload from operating.

Day 4

You will examine persistent state, secrets, autoscaling, authentication, and RBAC. We document changes that belong in the source configuration and evidence required for escalation.

Hands-on exercises

  • Trace a failed credential or storage dependency to its owner.
  • Prepare a customer explanation with the relevant revision, status, and next action.

Your customer delivery tools, support cases, and configuration ownership can shape the agenda. Get in touch to tailor the workshop to your GitOps support work.

Challenge the assumption that another sync will help

When an engineer repeats synchronization for a workload with unavailable storage, the instructor can compare desired state with claim events. The team can identify the dependency that reconciliation alone cannot provide.

Asked what she liked most about the course, Lucy wrote:

The best materials and trainings so far on the topics

— Lucy, F5.

Bring the customer symptoms and delivery model

Tell us which GitOps workflows your team supports, what evidence it can access, and who owns configuration and product changes. We will recommend investigations for those responsibilities.

Discuss your team's training