Shared Kubernetes capacity decisions for platform and application teams

We offer private, instructor-led training for workload owners and platform engineers who need a common basis for Kubernetes resource and capacity decisions.

The groups need to relate demand, requests, limits, scaling, and ownership to the same measures. Common resource reasoning does not mean identical settings for every application.

LearnKube compares two workloads and the signals used to assess them. Participants explain their configuration choices and review how those choices affect scheduling, scaling, and shared capacity.

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.

Use the same definitions when discussing capacity

  • Use a shared resource model by distinguishing demand, requests, limits, and node capacity, so teams can interpret the same measurements consistently.
  • Apply common review conventions by explaining resource settings against workload evidence, so different values have a visible rationale.
  • Clarify capacity ownership by separating application configuration, scaling policy, and infrastructure supply, so the responsible group can assess each requested change.
  • Review workloads together by comparing their resource and scaling assumptions, so allocation and cost discussions use a common technical basis.

A resource value influences more than one decision

Teams need to distinguish requests and limits from observed usage and available infrastructure. For CPU utilization targets, the HPA calculation relates usage to requests, so a request change can also change scaling behavior. The course compares these relationships across workloads, helping groups explain allocation choices without treating one resource value as a universal default.

I ask what a utilization percentage is relative to before teams compare their graphs. If the denominator changes with the workload configuration, the same percentage can support different conclusions about demand and the next capacity decision.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Decision to alignCommon basisShared exercise
Resource requestScheduling and measured demandCompare workload evidence
Runtime limitResource-specific enforcementExplain the chosen constraint
Scaling expectationMetrics and target calculationReview a request change
Capacity responsibilityReplicas and infrastructure supplyAssign the next decision

Your team is not alone in sharing capacity decisions

Bybit's SRE leadership remit includes shared capacity models, resource-request review, application or business cost visibility, and knowledge-sharing practices. Kubernetes expertise forms part of that broader infrastructure work.

For teams discussing Kubernetes capacity, we recommend a four-day workshop around common measurements and role-specific decisions. The examples connect configuration choices to the metrics and operating responsibilities that make allocation discussions useful.

A recommended four-day workshop around two workload profiles

This proposed agenda compares workloads with different demand. Participants use common questions while preserving configuration justified by each application's behavior.

Day 1

We connect images, Deployments, Services, and probes to the workloads' behavior under load. Participants distinguish a resource-related symptom from a complete explanation of its cause.

Hands-on exercises

  • Compare the health and demand evidence available for both workloads.
  • Identify which release and resource assumptions need application-owner input.

Day 2

We use Helm and compare Kustomize to inspect requests, limits, and replicas. The group relates those settings to scheduler, controller, and node responsibilities.

Hands-on exercises

  • Review a common resource default against both workload profiles.
  • Explain the platform and application decisions required by an override.

Day 3

We examine traffic, DNS, Services, ingress, policy, and placement alongside demand. Service mesh resource considerations are included when relevant to the shared environment.

Hands-on exercises

  • Compare application pressure with the capacity and placement available to its replicas.
  • Review a proposed capacity change using observations from both teams.

Day 4

We connect HPA calculations, persistent dependencies, secrets, and RBAC to the resource model. Participants distinguish workload settings from infrastructure supply and ownership information used in cost discussions.

Hands-on exercises

  • Observe how a CPU request change affects a utilization-based scaling calculation.
  • Present a shared workload review with evidence, rationale, and the responsible owner for each decision.

Your workload owners, resource-review practices, and capacity boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.

Ask which quantity each team is comparing

When a platform engineer and an application owner use different meanings of utilization, the instructor can inspect the metric and its denominator. The group can then compare evidence before choosing requests, targets, or infrastructure capacity.

Went from zero understanding to feeling like I have a good fundamental understanding of what K8s is and how to use it.

— Brian, Developer at Baillie Gifford.

Bring the capacity decisions your groups share

Tell us which teams request and provide resources, which measures need a common interpretation, and how allocation responsibilities differ. We will recommend a technical course focus and shared review exercises.

Discuss your team's training