We offer private, instructor-led training for implementation and support engineers who install their software in Kubernetes clusters owned by customers.
Your engineers know the product. The customer controls important parts of its execution environment, including permissions, ingress, storage, capacity, and policy.
LearnKube uses a representative installation to connect those dependencies to prerequisite checks, configuration decisions, diagnosis, and customer acceptance.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
Helm values shape the resources submitted for an installation. The customer's controllers, permissions, and infrastructure then determine how those resources operate. A successful submission does not prove that the product is usable. Engineers must connect readiness, endpoints, and dependency access to the customer's acceptance checks and assigned responsibilities.
I ask what evidence makes the installation acceptable to the customer. A release can exist while its Pods lack storage or a usable route, so the completion check must follow the actual application path.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Customer task or requirement | Kubernetes decision | Practice |
|---|---|---|
| Confirm deployment prerequisites | APIs, access, and integrations | Review a target environment |
| Supply customer configuration | Values and rendered resources | Inspect the resulting manifests |
| Establish product availability | Readiness and service endpoints | Verify the application path |
| Resolve an installation blocker | Product and platform ownership | Prepare a focused escalation |
Arize's On-Prem team deploys software in customer environments and defines infrastructure requirements with customers. Its work includes Kubernetes installations across cloud and on-prem platforms, plus configuration, networking, and performance diagnosis.
For engineers responsible for that work, we recommend a four-day workshop focused on prerequisites, observable application behavior, and the boundary between product support and customer platform ownership.
The proposed exercises use a representative application. Product-specific examples depend on the selected environment and available teaching material.
Day 1
We connect images, Pods, Deployments, Services, and probes to the installation procedure. You will inspect the conditions that distinguish created resources from a usable product.
Hands-on exercises
Day 2
You will use Helm and compare Kustomize, then trace control-plane and node behavior. We distinguish a configuration error from a missing platform integration.
Hands-on exercises
Day 3
We examine DNS, ingress, network policies, service mesh interactions, and scheduling constraints. Each investigation identifies which customer or vendor team can make the required change.
Hands-on exercises
Day 4
You will inspect persistent data, secrets, metrics, authentication, and RBAC. We connect the final configuration to the operating evidence the customer needs after acceptance.
Hands-on exercises
Your product prerequisites, customer platforms, and support boundaries can shape the agenda. Get in touch to tailor the workshop to your customer installation work.
When an engineer changes chart values to compensate for a missing storage provisioner, the instructor can inspect the resulting claim and events. The team can explain which customer prerequisite remains unmet.
Asked what he liked most about the course, Will wrote:
course material and the labs
— Will, Consultant on NGINX implementations at F5.
Tell us what your team installs, which cluster conditions customers control, and how acceptance and support are divided. We will recommend exercises around those delivery decisions.