Resource monitoring best practices in Kubernetes - Time & Space Complexity

Time Complexity: Resource monitoring best practices

O(n)

Understanding Time Complexity

When monitoring resources in Kubernetes, it's important to understand how the monitoring process scales as the number of resources grows.

We want to know how the time to collect and process metrics changes as we add more pods or nodes.

Scenario Under Consideration

Analyze the time complexity of this monitoring setup snippet.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-monitor
spec:
  selector:
    matchLabels:
      app: example
  endpoints:
  - port: metrics
    interval: 30s

This snippet defines a ServiceMonitor that collects metrics from all pods labeled with "app: example" every 30 seconds.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Scraping metrics from each pod matching the label selector.
• How many times: Once per pod every 30 seconds, repeated continuously.

How Execution Grows With Input

As the number of pods increases, the monitoring system must scrape more endpoints, increasing the total work.

Input Size (pods)	Approx. Operations (scrapes per interval)
10	10 scrapes
100	100 scrapes
1000	1000 scrapes

Pattern observation: The total scraping work grows directly with the number of pods monitored.

Final Time Complexity

Time Complexity: O(n)

This means the time to complete one monitoring cycle grows linearly with the number of pods being monitored.

Common Mistake

[X] Wrong: "Monitoring time stays the same no matter how many pods there are."

[OK] Correct: Each pod adds an endpoint to scrape, so more pods mean more work and longer monitoring cycles.

Interview Connect

Understanding how monitoring scales helps you design systems that stay reliable as they grow, a key skill in real-world Kubernetes management.

Self-Check

"What if we changed the monitoring interval from 30 seconds to 10 seconds? How would the time complexity change?"

Practice

1. Why is it important to set resource requests and limits in Kubernetes pods?

easy

A. To ensure pods get the resources they need and prevent resource conflicts

B. To make pods run slower and use more CPU

C. To disable monitoring tools automatically

D. To allow unlimited resource usage without restrictions

Solution

1. Step 1: Understand resource requests and limits

   Resource requests define the minimum resources a pod needs, and limits set the maximum it can use.

2. Step 2: Recognize the effect on cluster stability

   Setting these prevents pods from using too many resources and causing conflicts or crashes.

3. Final Answer:

   To ensure pods get the resources they need and prevent resource conflicts -> Option A

4. Quick Check:

   Resource requests and limits = prevent conflicts [OK]

Hint: Requests = minimum, limits = maximum resources [OK]

Common Mistakes:

• Thinking limits slow down pods intentionally
• Believing requests disable monitoring
• Assuming unlimited usage is safe

2. Which command correctly shows current CPU and memory usage of pods in Kubernetes?

easy

A. kubectl monitor pods

B. kubectl get pods --usage

C. kubectl top pods

D. kubectl describe pods --metrics

Solution

1. Step 1: Identify the command for resource usage

   The kubectl top pods command shows CPU and memory usage of pods.

2. Step 2: Check other options for correctness

   Other commands are invalid or do not show usage metrics.

3. Final Answer:

   kubectl top pods -> Option C

4. Quick Check:

   Usage command = kubectl top pods [OK]

Hint: Use 'kubectl top pods' to see pod resource usage [OK]

Common Mistakes:

• Using 'kubectl get pods --usage' which is invalid
• Confusing 'describe' with usage metrics
• Assuming 'kubectl monitor' is a valid command

3. Given this command output:

NAME          CPU(cores)   MEMORY(bytes)
myapp-pod-1   150m         200Mi
myapp-pod-2   300m         400Mi

What is the total CPU usage of both pods?

medium

A. 300m

B. 450m

C. 150m

D. 600m

Solution

1. Step 1: Add CPU usage values from both pods

   150m + 300m = 450m CPU cores.

2. Step 2: Confirm units and sum

   Both values are in millicores (m), so sum is 450m.

3. Final Answer:

   450m -> Option B

4. Quick Check:

   150m + 300m = 450m [OK]

Hint: Add CPU millicores values directly [OK]

Common Mistakes:

• Adding memory values instead of CPU
• Confusing 450m with 600m
• Ignoring units and summing incorrectly

4. You set resource limits on a pod, but kubectl top pods shows usage exceeding those limits. What is the likely cause?

medium

A. The pod has no resource requests set

B. The pod is using burstable QoS and can exceed limits temporarily

C. Resource limits are not enforced by Kubernetes by default

D. The metrics server is not installed or reporting incorrect data

Solution

1. Step 1: Understand resource limits enforcement

   Kubernetes enforces limits strictly; pods cannot exceed set limits.

2. Step 2: Consider metrics server role

   If usage shows above limits, metrics server may be missing or reporting wrong data.

3. Final Answer:

   The metrics server is not installed or reporting incorrect data -> Option D

4. Quick Check:

   Incorrect metrics = wrong usage shown [OK]

Hint: Check metrics server if usage exceeds limits [OK]

Common Mistakes:

• Thinking Kubernetes allows exceeding limits
• Confusing QoS classes with limit enforcement
• Ignoring metrics server installation

5. You want to monitor resource usage trends over time for your Kubernetes cluster. Which approach is best?

hard

A. Set resource requests and limits, then use a monitoring tool like Prometheus

B. Use kubectl top repeatedly and save output manually

C. Only set resource limits without monitoring tools

D. Rely on kubectl describe to check resource usage daily

Solution

1. Step 1: Understand monitoring needs over time

   Manual commands show current usage but not trends or history.

2. Step 2: Use monitoring tools with resource limits

   Setting requests/limits ensures stable usage; tools like Prometheus collect and visualize trends.

3. Final Answer:

   Set resource requests and limits, then use a monitoring tool like Prometheus -> Option A

4. Quick Check:

   Requests + monitoring tool = best practice [OK]

Hint: Combine limits with Prometheus for trend monitoring [OK]

Common Mistakes:

• Relying on manual commands for long-term trends
• Skipping resource requests or limits
• Using describe command for usage stats