Shared Kubernetes ownership for platform and application teams

We offer private, instructor-led training for application teams that operate their services and platform engineers who maintain the shared Kubernetes environment.

Both groups need to connect configuration and symptoms to the right actions. A shared ownership model requires common evidence, not identical administrative access.

LearnKube follows one service through a change and a support handoff. Each group explains the resources it owns and the information another engineer needs to act.

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 application and platform boundary actionable

  • Use a shared ownership model by tracing workload and controller responsibilities, so both groups distinguish technical resource relationships from human operating duties.
  • Apply common handoff conventions by recording the affected resource, observed behavior, and intended change, so requests contain evidence another team can use.
  • Clarify corrective actions by comparing an application change with a platform dependency, so each group knows its permitted action and escalation boundary.
  • Review a service together by checking configuration and support information against shared criteria, so ownership gaps become visible before the next change.

Object ownership and team ownership answer different questions

Kubernetes records owner relationships between resources, while teams can attach operating information through annotations. Neither automatically defines the human support agreement. Application and platform groups need to connect resource behavior to their responsibilities. The course follows a change through those relationships so the handoff includes both technical evidence and the action another owner needs.

An owner reference tells Kubernetes about an object relationship, not which team answers a support request. I want both groups to explain the next action and its owner, rather than rely on the word ownership alone.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Decision to alignCommon basisShared exercise
Workload responsibilityControllers and resource relationshipsTrace a state change
Human support ownerOperating metadata and dutiesReview the service record
Corrective actionConfiguration and permission scopeAssign the next step
Handoff evidenceStatus, events, and dependenciesCompare support requests

Your team is not alone in sharing operating responsibility

MongoDB's internal infrastructure work supports engineering teams that deploy and operate their own services. Its platform remit combines self-service capabilities with investigation of workflow gaps, automation, and education.

For teams sharing that boundary, we recommend a four-day workshop around one service lifecycle and its operating handoffs. The proposed exercises compare application actions, platform actions, and the evidence needed at their boundary.

A recommended four-day workshop around a shared ownership boundary

This proposed agenda follows the same service through release, infrastructure dependencies, and review. The groups compare actions as well as observations.

Day 1

We connect images, Deployments, Services, and health probes to the service. Participants distinguish application requirements from the controller behavior that maintains replicas and routes traffic.

Hands-on exercises

  • Have both groups explain an unready workload using the same observations.
  • Assign the next action for an application configuration problem and a platform-capacity problem.

Day 2

We examine Helm and Kustomize resources alongside the control plane and node architecture. The group separates ownership of workload settings from ownership of shared components.

Hands-on exercises

  • Trace a proposed setting through the resource and controller that use it.
  • Review the support information needed when that controller cannot complete its work.

Day 3

We trace DNS, ingress, Services, policy, and scheduling through the service. Service mesh responsibilities are included where the shared environment requires them.

Hands-on exercises

  • Divide a request-path investigation between application and platform roles.
  • Compare two handoff records and identify which evidence makes the request actionable.

Day 4

We connect persistent storage, credentials, HPA signals, and RBAC to the ownership model. Participants review who defines a requirement, who supplies the capability, and who verifies the result.

Hands-on exercises

  • Map the owners of the service's data, capacity, and permission requirements.
  • Review a change together and record the agreed actions and escalation points.

Your application owners, platform services, and support boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.

Turn an ownership label into a useful action

When both groups call an issue a platform problem, the instructor can trace the required configuration and observed state. The discussion then identifies the resource, permitted action, and evidence needed by the responsible team.

Content, knowledge and enthusiasm of the instructor. The instructor clearly had knowledge well in excess of the material covered.

— Nik, Engineer at Bank of England.

Choose the handoffs that need clearer technical meaning

Tell us which teams operate applications and platform components, which decisions cross that boundary, and what each group can change. We will recommend a shared course focus and handoff exercises.

Discuss your team's training