What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To monitor complex Kubernetes Deployments, combine workload state, resource and component metrics, application logs and traces, probe behavior, and service-specific telemetry. A green dashboard—or a quick CPU and memory check—cannot establish that an application is healthy. For example, Harbor’s own health and job-queue metrics can reveal registry problems that Pod resource measurements do not.
How do I monitor complex Kubernetes Deployments? Start with the Deployment and its Pods, then correlate cluster signals with application behavior. The sections below give you a practical sequence and show how to add Harbor metrics without assuming one configuration fits every cluster.
What to monitor: connect state, metrics, logs, and traces
Kubernetes observability is built around three complementary signals: metrics are time-series measurements, logs record events over time, and traces connect the timing and relationships of operations across components. Use them alongside Kubernetes object state so you can distinguish a rollout or scheduling problem from an application or dependency failure. Kubernetes describes these observability signals.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →- Deployment and Pod state: Check rollout progress and available replicas, then inspect affected Pods and recent events for scheduling, container-state, or rollout issues.
- Resource and component metrics: Track CPU and memory, plus metrics from relevant Kubernetes components. Kubernetes components expose Prometheus-format metrics; the kubelet also provides endpoints including
/metrics/cadvisor,/metrics/resource, and/metrics/probes. The system metrics reference lists these sources. - Application signals: Collect application metrics, logs, and traces where available. Centralized log collection and trace pipelines help connect activity across workloads and services; choose implementations that suit your environment. Kubernetes observability guidance describes the signal categories.
- Probe and traffic behavior: Monitor startup, liveness, and readiness separately. They control different aspects of startup, container restart behavior, and traffic eligibility.
- Service-specific telemetry: Add metrics from the application or platform itself. Harbor, for example, exposes registry health and queued-work measurements.
Object state tells you what Kubernetes is doing; metrics, logs, and traces help explain why. The value comes from correlating them around the same workload and time window.
#1 Best Overall
Why kubectl top is only a quick check
kubectl top reports limited CPU and memory data for Pods and nodes through the Kubernetes resource metrics pipeline. That is useful for a quick capacity check and supports autoscaling use cases, but Kubernetes explicitly says the resource metrics API is not a replacement for a full monitoring pipeline. A fuller pipeline can collect richer metrics and, with an adapter, supply custom or external metrics to autoscaling mechanisms.
Use kubectl top for a current snapshot when the Metrics API is installed. For historical analysis, richer component and application metrics, or multi-signal troubleshooting, use a monitoring pipeline suited to your requirements. Kubernetes does not prescribe one universal pipeline: its documentation identifies needs, budget, and technical resources as factors in choosing among the available approaches. See the resource metrics pipeline guidance.
Use probes as both health signals and controls
Startup, liveness, and readiness probes answer different questions. A startup probe checks whether an application has started. When configured, Kubernetes waits for it to succeed before running liveness or readiness probes, which can accommodate a longer initialization period. A liveness probe detects a container that should be restarted; a readiness probe determines whether it should receive traffic. Kubernetes documents the three probe types and their behavior.
“Based on the probe results, Kubernetes can restart unhealthy containers or stop sending traffic to containers that are not ready.” — Kubernetes documentation, “Liveness, Readiness, and Startup Probes”
Because probes affect operations as well as visibility, a poorly chosen liveness check can trigger unnecessary restarts, while readiness is what keeps an unready container from receiving traffic. Make each check reflect the application condition it is meant to represent; no single probe configuration is right for every workload. If you collect kubelet metrics, its /metrics/probes endpoint and the probe-result counter in the Kubernetes metrics reference can add probe behavior to your monitoring view.
Add Harbor’s own metrics to the cluster view
Harbor documents Prometheus-format metrics from its exporter, core, jobservice, and registry components. They include runtime and API performance data, in-flight requests, registry measurements, and business data derived from Harbor’s database. Harbor documentation says metrics can be enabled in Harbor v2.2 and later; the endpoint and metrics port or path depend on configuration. Check the documentation for the Harbor version you actually run before applying an example. Harbor’s metrics documentation describes the available telemetry.
Harbor metrics worth watching
harbor_healthreports Harbor’s current status.harbor_upreports running status by component, including core, database, jobservice, portal, Redis, registry, registryctl, and Trivy.harbor_task_queue_sizeandharbor_task_queue_latencyshow queued Harbor jobs and how long they have waited.- Other documented measurements include project and repository counts, quota use, artifact pulls, and artifact totals.
These signals can expose registry-specific health or queued work that generic Pod CPU and memory measurements do not describe. Treat them as another layer to correlate with Harbor’s Kubernetes state, not as a substitute for checking the Pods and their dependencies.
Enable and scrape metrics in Kubernetes
For Harbor installed in Kubernetes, the Harbor documentation describes enabling metrics in the chart’s values.yaml and defining a Prometheus Operator ServiceMonitor that selects Harbor’s Service. The example uses the monitoring.coreos.com/v1 API and a metrics endpoint named metrics. Confirm the installed chart’s Service labels, port name, and scrape configuration; local values and monitoring-stack configuration may differ. Follow the Harbor version’s metrics instructions rather than copying an example without checking those details.
A practical dashboard and triage sequence
- Check rollout and object state. Inspect Deployment progress and available replicas, then examine affected Pods and recent events for scheduling, rollout, or container-state symptoms.
- Compare resource use with capacity. Check Pod CPU and memory alongside node capacity. Use
kubectl topfor a quick view if the Metrics API is installed; use a full metrics pipeline for ongoing and historical analysis. - Inspect probes and restarts. Review readiness and liveness behavior and restart counts. If collected, include probe metrics from the kubelet’s
/metrics/probesendpoint. - Correlate application signals. Compare application metrics and request traces with container and system logs to locate the failing layer or dependency.
- For Harbor, inspect its own status and work queues. Check
harbor_health, component-levelharbor_up, and task queue size and latency alongside the Kubernetes state of Harbor’s Pods. - Choose an operational response. Symptoms may point to restoring capacity, fixing an unhealthy dependency, investigating queued work, or correcting rollout or configuration problems. Tie alerts to a service objective or another condition that has a clear owner and response.
Choose a monitoring approach your team can operate
Kubernetes documentation does not select one monitoring pipeline for all clusters, and the exact PromQL, dashboard panels, alert limits, and deployment configuration depend on your Kubernetes and Harbor versions, chart values, scrape implementation, and service objectives. The sources establish telemetry types and Harbor metric families, not universal thresholds or a ready-to-apply setup for every environment.
When evaluating an approach, compare what it can collect and what your team can maintain—not just a feature list:
- Signal coverage: Does it stop at resource metrics, or include object state, logs, traces, and application-specific measurements?
- Operational ownership: Can your team run collection and storage itself, or is a managed service a better fit for its staffing and control requirements?
- Retention and scale: Does it support the historical retention and multi-cluster scope you need, beyond quick resource inspection?
- Integration: Can it discover Kubernetes targets and scrape Prometheus/OpenMetrics endpoints such as Harbor’s? Does it support any custom metrics API your autoscaling approach requires?
- Actionability: Does each alert identify an owner and a useful response, and is its condition connected to a service objective?
The useful outcome is not simply a green dashboard. It is a set of connected signals that helps an operator identify which layer is failing and what to do next.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
