Kubernetes training for air-gapped customer delivery teams

We offer private, instructor-led training for vendor field and support engineers who install and maintain Kubernetes software in restricted customer environments.

Your team knows the normal delivery process. Restricted connectivity and customer-controlled access change the process, including artifact availability, diagnostics, update validation, and who can execute each step.

LearnKube uses an installation with controlled dependencies to connect Kubernetes behavior to a repeatable delivery and support procedure.

Discuss your team's training

Learning in practice

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 delivery work within the customer's boundaries

Prepare a repeatable deployment by identifying images, configuration, and platform prerequisites, so the delivery does not rely on unapproved downloads or hidden dependencies.
Preserve update and recovery options by checking artifact availability and required state, so replacement workloads can run under the same restrictions.
Diagnose with permitted evidence by selecting observations the customer can authorize or execute, so limited remote access does not force unsupported guesses.
Define the delivery handoff by documenting dependencies, verification steps, and operating owners, so the customer can maintain the agreed process.

Dependencies include the tools needed to investigate failure

Restricted environments require explicit image availability and pull policies, including dependencies used by installation and diagnostic tools. Kubernetes permissions also determine who can collect evidence or change resources. Vendor engineers need a delivery process that respects both boundaries, with customer-executable checks and a clear record of the artifacts needed for updates and recovery.

I ask whether the diagnostic procedure works under the same restrictions as the product. If the proposed fix starts with an unavailable image or unauthorized command, the support process has its own missing dependency.
— Daniele Polencic, LearnKube founder and Kubernetes instructor

Customer task or requirement	Kubernetes decision	Practice
Supply approved artifacts	Registries, digests, and dependencies	Inspect the delivery bundle
Replace a workload	Image and storage availability	Rehearse a constrained replacement
Collect useful diagnostics	Identity and permitted observations	Prepare customer-executable checks
Maintain the installation	Update and ownership records	Review the support handoff

Your team is not alone in restricted customer delivery

Capital One Software supports Databolt in self-hosted and air-gapped customer environments. Its support work includes reproducing Kubernetes environments, controlled image delivery, patch validation, and incidents with limited access.

For engineers facing those constraints, we recommend a four-day workshop focused on explicit dependencies, authorized diagnosis, and repeatable customer procedures.

A recommended four-day workshop for restricted environments

This proposed agenda uses agreed artifact and access constraints in a lab. The exercises connect Kubernetes delivery behavior to the customer's documented operating requirements.

Day 1

Images, workloads, and restricted startup

We connect container packaging to Pods, Deployments, Services, and probes. You will inspect which artifacts and configuration the application needs to start.

Hands-on exercises

Deploy a sample workload using an approved image source.
Diagnose an unavailable artifact without assuming public-registry access.

Day 2

Templates and complete dependency records

You will use Helm and compare Kustomize while identifying chart and image dependencies. We trace controllers and node behavior to expose requirements hidden by the original lab environment.

Hands-on exercises

Review a release bundle for undeclared dependencies.
Rehearse replacement on capacity that lacks the original node's cached image.

Day 3

Constrained network paths and observations

We examine DNS, ingress, policies, mesh interactions, and placement. The exercise distinguishes a product requirement from an investigation requiring customer-controlled access.

Hands-on exercises

Trace a required connection through the permitted network path.
Prepare a bounded diagnostic request for a customer engineer to execute.

Day 4

State, credentials, capacity, and updates

You will examine storage, secrets, metrics, authentication, and RBAC under the selected restrictions. We connect those mechanisms to update and recovery verification.

Hands-on exercises

Verify data and credential availability after replacement.
Review an update procedure and its remaining customer-owned prerequisites.

Your customer restrictions, artifact processes, and support boundaries can shape the agenda. Get in touch to tailor the workshop to your air-gapped delivery work.

Investigate without assuming a different environment

When an engineer proposes downloading a debugging image during an incident, the instructor can apply the lab's connectivity and permission constraints. The team can design an evidence request that the customer can actually perform.

The challenges and web based content, mixed with the instructors not just reading the content but being engaged start to finish.
— Vinnie, Solutions Architect at F5.

Start with the delivery process and its restrictions

Tell us what your team installs, which access and artifact constraints customers impose, and who operates updates afterward. We will recommend exercises around that delivery process.

Discuss your team's training