Shared Kubernetes tenancy conventions for platform and application teams

We offer private, instructor-led training for platform and application teams that share Kubernetes capacity and need common tenancy and resource conventions.

The groups need to agree what namespace ownership, permitted access, and resource budgets mean. Common controls do not require every workload to use identical settings.

LearnKube uses two reference workloads to connect the shared contract to observable behavior. Participants compare legitimate differences and the effects of their choices on other users.

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.

Give shared capacity a common decision basis

  • Use a shared tenancy model by connecting namespace scope to access and isolation controls, so groups understand what the boundary actually provides.
  • Apply common resource conventions by reviewing requests, limits, quotas, and scaling expectations, so teams distinguish shared constraints from workload choices.
  • Clarify allocation ownership by tracing a capacity or access request through the responsible groups, so participants know who can change the relevant control.
  • Review workloads together by comparing requirements against the same tenancy criteria, so justified differences and shared-platform effects are visible.

Namespace scope does not settle every sharing decision

Teams sharing a cluster need an agreed tenancy model, including who can change resources and how workloads interact. Resource quotas apply within namespaces and do not automatically increase when cluster capacity grows. The workshop connects these mechanisms to shared allocation decisions, while preserving differences in application demand, scaling behavior, and permitted access.

I ask whether two teams mean allocated budget, requested resources, or available node capacity when they say they have space. Those are different quantities, and a shared convention must explain which decision each one supports.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Decision to alignCommon basisShared exercise
Namespace responsibilityAccess and policy scopeCompare permitted actions
Resource budgetRequests, limits, and quotasReview different workload needs
Scaling expectationDemand and available capacityExplain a constrained scale-up
Isolation requirementNetwork and identity controlsAssess intended interactions

Your team is not alone in defining shared platform conventions

ModMed's cloud-engineering remit combines secure multi-tenancy, telemetry standards, deployment patterns, and enterprise-wide practices. Mentoring and the adoption of common approaches connect these responsibilities across engineering groups.

For teams sharing such controls, we recommend a four-day workshop around tenancy, access, and resource decisions. The groups compare controls with workload requirements and identify where a justified exception needs another owner's input.

A recommended four-day workshop around two shared-cluster workloads

This proposed agenda compares two workloads with different needs. The same technical questions help participants distinguish consistent decisions from identical configuration.

Day 1

We connect Pods, Deployments, Services, and probes to the two applications. Participants identify where common release expectations meet different workload behavior.

Hands-on exercises

  • Compare the namespace and health requirements of both examples.
  • Review which release questions need the same answer and which require application-specific evidence.

Day 2

We use Helm and compare Kustomize to expose shared settings and overrides. The group connects generated resources to controllers and the components that administer the tenancy model.

Hands-on exercises

  • Review resource defaults against both applications' requirements.
  • Trace a requested exception to the platform or application owner who must assess it.

Day 3

We trace DNS, Services, ingress, network policies, and placement across the examples. Participants discuss whether mesh or node-separation capabilities affect the intended boundary.

Hands-on exercises

  • Compare permitted connections with the isolation requirements of each workload.
  • Review a placement decision that changes how the workloads share capacity.

Day 4

We examine storage, secrets, RBAC, quotas, and autoscaling signals. The group reviews both workloads using common criteria while recording the rationale for different resource settings.

Hands-on exercises

  • Explain why a scale-up can fail despite unused infrastructure capacity.
  • Present a shared review of access, data, and resource-allocation decisions.

Your workload owners, tenancy conventions, and allocation boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.

Distinguish a shared rule from an identical value

When teams propose the same resource settings for different applications, the instructor can compare demand and quota behavior. Participants can then explain the common decision rule without hiding legitimate workload differences.

The labs - really helpful to get in there and test different setups. I also really enjoyed when Salman spoke about some of the "gotchas"

— Ana, RASC Architect at Research Innovations.

Start with the capacity and access decisions teams share

Tell us which groups share the platform, which tenancy conventions need a common meaning, and who owns allocation or policy changes. We will recommend shared examples and role-specific review exercises.

Discuss your team's training