Why cluster monitoring matters in Kubernetes - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to check the status of all pods in the default namespace.

Kubernetes

kubectl get pods -n [1]

Drag options to blanks, or click blank then click option'

Adefault

Bproduction

Ckube-system

Dmonitoring

Attempts:

3 left

💡 Hint

Common Mistakes

Using a wrong namespace name like 'kube-system' when checking default pods.

The default namespace is the standard namespace where pods run if no other namespace is specified.

2fill in blank

medium

Complete the command to describe a pod named 'web-server' in the 'default' namespace.

Kubernetes

kubectl [1] pod web-server -n default

Drag options to blanks, or click blank then click option'

Acreate

Blist

Cdelete

Ddescribe

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'list' or 'create' which do not show pod details.

The describe command shows detailed information about a specific pod.

3fill in blank

hard

Fix the error in the command to get logs from a pod named 'api-server'.

Kubernetes

kubectl logs [1]

Drag options to blanks, or click blank then click option'

A-n default

Bapi-server

Cget pods

Ddescribe api-server

Attempts:

3 left

💡 Hint

Common Mistakes

Adding extra commands like 'get pods' or 'describe' after 'logs'.

The kubectl logs command requires the pod name as the argument to fetch logs.

4fill in blank

hard

Fill both blanks to create a command that watches pod status changes every 2 seconds.

Kubernetes

watch --[1]=[2] kubectl get pods -n default

Drag options to blanks, or click blank then click option'

Ainterval

Btimeout

C2s

D5s

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'timeout' instead of 'interval' or wrong time values.

The --interval=2s option makes the watch command refresh the pod status every 2 seconds.

5fill in blank

hard

Fill all three blanks to create a command that labels all pods with 'env=prod' in the 'default' namespace.

Kubernetes

kubectl label pods -n default [1] [2]=[3]

Drag options to blanks, or click blank then click option'

A--all

Benv

Cprod

D--selector

Attempts:

3 left

💡 Hint

Common Mistakes

Using '--selector' instead of '--all' to select pods.

The --all flag selects all pods, and env=prod sets the label key and value.

Practice

1. Why is cluster monitoring important in Kubernetes?

easy

A. It removes unused containers automatically.

B. It helps detect problems early and keeps the system healthy.

C. It replaces the need for backups.

D. It automatically scales the cluster without user input.

Solution

1. Step 1: Understand the purpose of monitoring

   Monitoring tracks system health and performance to spot issues early.

2. Step 2: Compare options with monitoring goals

   Only early problem detection and health maintenance match monitoring's purpose.

3. Final Answer:

   It helps detect problems early and keeps the system healthy. -> Option B

4. Quick Check:

   Monitoring = Early problem detection [OK]

Hint: Monitoring = spotting problems early to keep system healthy [OK]

Common Mistakes:

• Confusing monitoring with automatic scaling
• Thinking monitoring replaces backups
• Assuming monitoring deletes containers

2. Which command is used to check the status of nodes in a Kubernetes cluster for monitoring?

easy

A. kubectl get nodes

B. kubectl describe service

C. kubectl get pods

D. kubectl logs

Solution

1. Step 1: Identify command to list nodes

   The command kubectl get nodes lists all cluster nodes and their status.

2. Step 2: Eliminate other commands

   kubectl get pods lists pods, not nodes; kubectl describe service shows service details; kubectl logs shows logs of pods.

3. Final Answer:

   kubectl get nodes -> Option A

4. Quick Check:

   Nodes status = kubectl get nodes [OK]

Hint: Nodes status command is 'kubectl get nodes' [OK]

Common Mistakes:

• Using 'kubectl get pods' to check nodes
• Confusing logs with node status
• Describing services instead of nodes

3. Given the output below from kubectl top nodes, what does it indicate?

NAME           CPU(cores)   MEMORY(bytes)
node-1         250m        512Mi
node-2         900m        1Gi
node-3         100m        256Mi

medium

A. node-3 has the highest CPU usage.

B. node-1 is using the most memory.

C. All nodes have equal resource usage.

D. node-2 is under heavy CPU and memory load compared to others.

Solution

1. Step 1: Analyze CPU and memory usage per node

   node-2 shows 900m CPU and 1Gi memory, which is higher than node-1 and node-3.

2. Step 2: Compare usage values

   node-3 has lowest CPU (100m), node-1 has moderate CPU (250m), node-2 is highest in both CPU and memory.

3. Final Answer:

   node-2 is under heavy CPU and memory load compared to others. -> Option D

4. Quick Check:

   Highest CPU and memory = node-2 [OK]

Hint: Highest CPU and memory usage means heavy load [OK]

Common Mistakes:

• Mistaking 100m as highest CPU
• Assuming equal resource usage
• Confusing memory units

4. You set up cluster monitoring but notice no metrics appear when running kubectl top nodes. What is the most likely cause?

medium

A. Nodes are offline.

B. kubectl command is outdated.

C. Metrics-server is not installed or running.

D. Pods are not labeled correctly.

Solution

1. Step 1: Understand what provides metrics for 'kubectl top'

   The metrics-server collects resource usage data for nodes and pods.

2. Step 2: Identify why metrics might be missing

   If metrics-server is missing or not running, kubectl top shows no data.

3. Final Answer:

   Metrics-server is not installed or running. -> Option C

4. Quick Check:

   Missing metrics = metrics-server issue [OK]

Hint: No metrics? Check if metrics-server is running [OK]

Common Mistakes:

• Blaming kubectl version without checking metrics-server
• Assuming nodes are offline without verification
• Thinking pod labels affect node metrics

5. You want to improve cluster reliability by setting up alerts for high CPU usage on nodes. Which approach best supports this goal?

hard

A. Use Prometheus to monitor node metrics and configure alert rules for CPU thresholds.

B. Manually check node CPU usage daily with kubectl top nodes.

C. Restart nodes periodically to prevent high CPU usage.

D. Disable monitoring to reduce overhead and avoid false alerts.

Solution

1. Step 1: Identify monitoring tool for alerts

   Prometheus collects metrics and supports alerting rules for conditions like high CPU.

2. Step 2: Evaluate options for reliability

   Manual checks are slow and error-prone; restarting nodes blindly is not a solution; disabling monitoring removes visibility.

3. Final Answer:

   Use Prometheus to monitor node metrics and configure alert rules for CPU thresholds. -> Option A

4. Quick Check:

   Automated alerts = Prometheus + alert rules [OK]

Hint: Automate alerts with Prometheus for reliable monitoring [OK]

Common Mistakes:

• Relying on manual checks only
• Restarting nodes without cause
• Disabling monitoring to avoid alerts