Radar automatically discovers and displays any Custom Resource Definition (CRD) in your cluster — no configuration needed. For popular tools, Radar provides dedicated detail views, topology edges, smart table columns, and AI-optimized summaries for seamless integration.
Karpenter is the standard node autoscaler for Kubernetes, replacing Cluster Autoscaler on AWS (EKS), Azure (AKS NAP), and generic clusters.
Topology: Full provisioning chain — NodePool → NodeClaim → Node → Pod. See which NodePool owns which NodeClaims, which Nodes they provisioned, and what Pods are running on them. NodePool → NodeClass edges show the provider-specific configuration each pool uses.
Karpenter in Topology View — NodePool → NodeClaim provisioning chain
NodePool Detail View:
- Status conditions (Ready)
- Clickable NodeClass reference (EC2NodeClass, AKSNodeClass, or generic)
- Resource limits (CPU, memory)
- Disruption policy and consolidation settings
- Instance requirements (types, zones, architectures)
- Template labels applied to provisioned nodes
NodePool Detail View — Status, related NodeClaims, and full specification
NodeClaim Detail View:
- Provisioning timeline with timestamps
- Status conditions (Initialized, Launched, Registered, Ready)
- Instance type, capacity, and zone
- Requirements (instance types, architectures, OS)
- Clickable Node and NodeClass references
NodeClass Detail View (EC2NodeClass, AKSNodeClass, etc.):
- AMI selector terms and aliases
- Block device mappings (volume type, size, encryption)
- IAM role configuration
- Subnet and security group discovery tags
- Instance metadata options (IMDS configuration)
Resource Browser: Smart columns show status, NodeClass reference, limits, and disruption policy at a glance.
NodePool Resource Browser — Status, NodeClass, limits, and disruption policy at a glance
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| NodePool | karpenter.sh/v1 |
Yes | Yes | Yes |
| NodeClaim | karpenter.sh/v1 |
Yes | Yes | Yes |
| EC2NodeClass | karpenter.k8s.aws/v1 |
Yes | Yes | Yes |
| AKSNodeClass | karpenter.azure.com/v1alpha2 |
Yes | Generic | Yes |
| GCPNodeClass | karpenter.gcp.compute.com/v1alpha1 |
Yes | Generic | Yes |
All provider-specific NodeClass variants are automatically detected and supported.
KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF graduated project that scales workloads based on external event sources — queues, streams, cron schedules, Prometheus metrics, and 60+ other triggers.
Topology: ScaledObject → target workload (Deployment, StatefulSet, or Rollout). See which workloads are managed by KEDA and trace the scaling relationship.
KEDA in Topology View — ScaledObject → Deployment → Pod scaling chain
ScaledObject Detail View:
- Status conditions (Ready, Active, Paused, Fallback)
- Target workload reference
- Min/Max/Idle replica configuration
- Polling interval and cooldown period
- Trigger list with type and metadata
- Generated HPA name
- Pause state detection (supports all 3 annotation variants)
ScaledObject Detail View — Status conditions, target workload, triggers, and replica configuration
ScaledJob Detail View:
- Status conditions
- Job target reference
- Scaling strategy (default, custom, accurate, eager)
- Success/failure limits
- Trigger list
TriggerAuthentication Detail View:
- Pod identity provider and configuration
- Secret references with linked Secret navigation
- Environment variable mappings
- External secret providers (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager)
Resource Browser: Smart columns show status, target workload, trigger count, and replica range at a glance.
ScaledObject Resource Browser — Status, target workload, trigger count, and replica range
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| ScaledObject | keda.sh/v1alpha1 |
Yes | Yes | Yes |
| ScaledJob | keda.sh/v1alpha1 |
Yes | Yes | Yes |
| TriggerAuthentication | keda.sh/v1alpha1 |
— | Yes | Yes |
| ClusterTriggerAuthentication | keda.sh/v1alpha1 |
— | Yes | Yes |
VPA automatically adjusts CPU and memory requests/limits for pods based on observed usage.
Topology: VPA nodes appear in the Resources view with EdgeUses edges to target workloads, grouped in the Scalers section alongside HPA and KEDA.
Detail View: Target workload, update mode, per-container resource recommendations (target, lower bound, upper bound, uncapped), resource policy, and conditions.
Problem Detection: Alerts for unsupported configurations, missing recommendations, and low confidence scores.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| VerticalPodAutoscaler | autoscaling.k8s.io/v1 |
Yes | Yes | — |
Gateway API is the next-generation Kubernetes networking API, replacing Ingress with more expressive routing, traffic splitting, and multi-tenant support.
Topology: Full network path — GatewayClass → Gateway → HTTPRoute/GRPCRoute/TCPRoute/TLSRoute → Service → Pod. Visualize how traffic flows from the gateway controller through routes to your backend services.
Gateway API in Topology View — GatewayClass → Gateway → HTTPRoute → Service traffic path
Gateway Detail View: Listeners, addresses, attached routes, and status conditions.
GatewayClass Detail View: Controller name, description, parameters reference, and status conditions.
HTTPRoute Detail View: Rules with path/header matching, backend references, filters, and weights.
GRPCRoute Detail View: Service/method matching, backend references, and filters.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| GatewayClass | gateway.networking.k8s.io/v1 |
Yes | Yes | Yes |
| Gateway | gateway.networking.k8s.io/v1 |
Yes | Yes | Yes |
| HTTPRoute | gateway.networking.k8s.io/v1 |
Yes | Yes | Yes |
| GRPCRoute | gateway.networking.k8s.io/v1 |
Yes | Yes | Yes |
| TCPRoute | gateway.networking.k8s.io/v1alpha2 |
Yes | Yes | Yes |
| TLSRoute | gateway.networking.k8s.io/v1alpha2 |
Yes | Yes | Yes |
Traefik is a modern reverse proxy and ingress controller for Kubernetes, with dynamic configuration, middleware chains, and advanced traffic management via CRDs.
Topology: Full Traefik routing path — IngressRoute → Middleware → Service (or TraefikService → Service) with TLS and transport configuration edges. See how traffic flows from entrypoints through middleware chains and weighted/mirroring TraefikServices to backend Kubernetes Services. Both Resources and Traffic view modes are supported.
IngressRoute / IngressRouteTCP / IngressRouteUDP Detail View:
- Entry points and TLS configuration (secret, cert resolver, TLS options/stores)
- Route match expressions with priority and kind badges
- Per-route services with port, weight, and ServersTransport links
- Per-route middleware references with cross-namespace indicators
- Aggregated middleware chain with numbered ordering
- Alert banners for no-route or no-service configurations
Resource Browser: Smart columns show entry points, hosts (extracted from match expressions), route summaries, TLS status, and middleware counts. All 10 Traefik kinds have dedicated table columns — Middleware shows type, TraefikService shows type and targets, ServersTransport shows insecure/serverName, TLSOption shows min TLS version.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| IngressRoute | traefik.io/v1alpha1 |
Yes | Yes | — |
| IngressRouteTCP | traefik.io/v1alpha1 |
Yes | Yes | — |
| IngressRouteUDP | traefik.io/v1alpha1 |
Yes | Yes | — |
| Middleware | traefik.io/v1alpha1 |
Yes | Generic | — |
| MiddlewareTCP | traefik.io/v1alpha1 |
Yes | Generic | — |
| TraefikService | traefik.io/v1alpha1 |
Yes | Generic | — |
| ServersTransport | traefik.io/v1alpha1 |
Yes | Generic | — |
| ServersTransportTCP | traefik.io/v1alpha1 |
Yes | Generic | — |
| TLSOption | traefik.io/v1alpha1 |
Yes | Generic | — |
| TLSStore | traefik.io/v1alpha1 |
Yes | Generic | — |
Contour is a Kubernetes ingress controller using Envoy proxy, providing a powerful HTTPProxy CRD with route delegation, weighted routing, TLS termination, and TCP proxying.
Topology: Full Contour routing path — HTTPProxy (root) → HTTPProxy (child, via delegation) → Service, with TLS secret configuration edges. Root proxies with spec.virtualhost appear as entry points; child proxies referenced via spec.includes are connected via delegation edges. Both Resources and Traffic view modes are supported.
Contour in Topology View — HTTPProxy → Service routing with delegation
HTTPProxy Detail View:
- Status banner for invalid or orphaned proxies
- Virtual host FQDN and TLS configuration with clickable Secret links
- Routes with prefix/header conditions and backend services (name, port, weight)
- Delegation includes with cross-namespace indicators and condition prefixes
- TCP proxy services for passthrough configurations
- Status conditions (Valid/Invalid/Orphaned)
Resource Browser: Smart columns show FQDN, route count, include count, TLS status (shield icon), and validity status at a glance.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| HTTPProxy | projectcontour.io/v1 |
Yes | Yes | Yes |
cert-manager automates TLS certificate management — issuing, renewing, and revoking certificates from Let's Encrypt, Vault, Venafi, and other issuers.
Topology: Certificate → Issuer/ClusterIssuer edges show which issuer manages each certificate. The full provisioning chain (Certificate → CertificateRequest → Order → Challenge) is connected via owner references.
cert-manager in Topology View — Certificate → CertificateRequest provisioning chain
Certificate Detail View:
- Status conditions (Ready) with color-coded expiry warnings
- Validity period with progress bar (green → yellow → red as expiry approaches)
- Subject, DNS names, issuer reference
- Renewal time and last failure
Dashboard: Certificate health card showing healthy/warning/critical/expired certificate counts across all namespaces.
TLS Secret Parsing: Click any TLS Secret to see the X.509 certificate details — subject, issuer, validity dates, SANs — parsed directly from the secret data.
Certificate Detail View — Validity progress bar, DNS names, issuer reference, and status conditions
Certificate Resource Browser — Ready status, domains, issuer, and expiry date at a glance
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Certificate | cert-manager.io/v1 |
Yes | Yes | — |
| CertificateRequest | cert-manager.io/v1 |
Yes | Yes | — |
| Issuer | cert-manager.io/v1 |
Yes | Yes | — |
| ClusterIssuer | cert-manager.io/v1 |
Yes | Yes | — |
| Order | acme.cert-manager.io/v1 |
Yes | Yes | — |
| Challenge | acme.cert-manager.io/v1 |
Yes | Yes | — |
Prometheus Operator simplifies Prometheus setup on Kubernetes, providing CRDs for defining monitoring targets, alerting rules, and scrape configurations declaratively.
ServiceMonitor Detail View:
- Status conditions
- Job label and scrape endpoint configuration (port, path, interval, scheme)
- Service selector (matchLabels)
- Namespace selector scope
PrometheusRule Detail View:
- Rule group breakdown with per-group rule counts
- Alert rules vs recording rules summary
- Group evaluation intervals
PodMonitor Detail View:
- Pod metrics endpoint configuration (port, path, interval, scheme)
- Pod selector (matchLabels)
- Namespace selector scope
Resource Browser: Smart columns show status, endpoint count, selectors, and job labels at a glance.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| ServiceMonitor | monitoring.coreos.com/v1 |
— | Yes | — |
| PodMonitor | monitoring.coreos.com/v1 |
— | Yes | — |
| PrometheusRule | monitoring.coreos.com/v1 |
— | Yes | — |
| Alertmanager | monitoring.coreos.com/v1 |
— | Generic | — |
Trivy Operator continuously scans your cluster for vulnerabilities, misconfigurations, exposed secrets, and license compliance issues.
VulnerabilityReport Detail View: Severity breakdown (Critical/High/Medium/Low), affected images, and CVE counts.
ConfigAuditReport Detail View: Pass/fail checks with severity levels.
Resource Browser: Smart columns show severity counts and scan status at a glance.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| VulnerabilityReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ConfigAuditReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ExposedSecretReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ClusterComplianceReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| SbomReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| RbacAssessmentReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ClusterRbacAssessmentReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| InfraAssessmentReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ClusterInfraAssessmentReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
| ClusterSbomReport | aquasecurity.github.io/v1alpha1 |
— | Yes | — |
Sealed Secrets encrypts Kubernetes Secrets so they can be safely stored in Git. The controller decrypts them in-cluster at deploy time.
SealedSecret Detail View: Encrypted data keys, template metadata, and the target Secret's scope and namespace.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| SealedSecret | bitnami.com/v1alpha1 |
— | Yes | — |
See the main README for GitOps integration details.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| GitRepository | source.toolkit.fluxcd.io/v1 |
Yes | Yes | — |
| OCIRepository | source.toolkit.fluxcd.io/v1beta2 |
Yes | Yes | — |
| HelmRepository | source.toolkit.fluxcd.io/v1 |
Yes | Yes | — |
| Kustomization | kustomize.toolkit.fluxcd.io/v1 |
Yes | Yes | Yes |
| HelmRelease | helm.toolkit.fluxcd.io/v2 |
Yes | Yes | Yes |
| Alert | notification.toolkit.fluxcd.io/v1beta3 |
— | Yes | — |
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Application | argoproj.io/v1alpha1 |
Yes | Yes | Yes |
| ApplicationSet | argoproj.io/v1alpha1 |
— | Generic | — |
| AppProject | argoproj.io/v1alpha1 |
— | Generic | — |
Argo Rollouts provides progressive delivery strategies including blue-green and canary deployments.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Rollout | argoproj.io/v1alpha1 |
Yes | Yes | Yes |
Argo Workflows is a container-native workflow engine for orchestrating parallel jobs on Kubernetes.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Workflow | argoproj.io/v1alpha1 |
— | Yes | — |
| WorkflowTemplate | argoproj.io/v1alpha1 |
— | Yes | — |
| CronWorkflow | argoproj.io/v1alpha1 |
— | Generic | — |
Istio is the most widely adopted service mesh, providing traffic management, security (mTLS), and observability for microservices.
Topology: Full Istio traffic path — IstioGateway → VirtualService → Service, and DestinationRule → Service configuration edges. See how traffic flows through gateway listeners, virtual service routing rules, and into backend services.
VirtualService Detail View:
- HTTP/TCP/TLS routing rules with match conditions
- Destinations with weight distribution bars
- Fault injection and traffic mirroring detection (AlertBanner warnings)
- Retry policies, timeouts, and CORS settings
- Gateway references with clickable links
DestinationRule Detail View:
- Target service host with clickable link
- Traffic policy: connection pool (TCP/HTTP limits), load balancer algorithm, outlier detection (ejection settings), TLS mode
- Subset definitions with labels and per-subset traffic policy overrides
Gateway Detail View (networking.istio.io):
- Server configurations with port, protocol, and hosts
- TLS settings per server (mode, credential references)
- Workload selector labels
ServiceEntry Detail View:
- Hosts, location (MESH_EXTERNAL/MESH_INTERNAL), resolution strategy
- Ports with protocol badges
- Endpoint addresses with port mappings and labels
PeerAuthentication Detail View:
- mTLS mode with color-coded badges (STRICT/PERMISSIVE/DISABLE)
- Scope indicator (workload-scoped vs namespace-wide)
- Port-level mTLS overrides
AuthorizationPolicy Detail View:
- Action badge (ALLOW/DENY/CUSTOM/AUDIT) with rule breakdown
- Source principals, namespaces, IP blocks
- Operation matching (hosts, ports, methods, paths)
- Deny-all and allow-nothing detection (AlertBanner)
Resource Browser: Smart columns show status badges, hosts, gateways, route counts, mTLS modes, actions, and load balancer algorithms at a glance.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| VirtualService | networking.istio.io/v1 |
Yes | Yes | — |
| DestinationRule | networking.istio.io/v1 |
Yes | Yes | — |
| Gateway | networking.istio.io/v1 |
Yes | Yes | — |
| ServiceEntry | networking.istio.io/v1 |
— | Yes | — |
| PeerAuthentication | security.istio.io/v1 |
— | Yes | — |
| AuthorizationPolicy | security.istio.io/v1 |
— | Yes | — |
Velero provides backup and restore capabilities for Kubernetes cluster resources and persistent volumes.
Backup Detail View:
- Phase with color-coded badge, start/completion timestamps, duration
- Progress bar during in-progress backups (items backed up percentage)
- Scope filters: included/excluded namespaces and resources, label selectors
- Storage location and volume snapshot locations
- Options: TTL, snapshot volumes, default filesystem backup
- Error/warning detection (AlertBanner for failed or partial backups with validation errors)
Restore Detail View:
- Phase badge, source backup reference, duration
- Progress bar during in-progress restores
- Scope filters: included/excluded namespaces and resources
- Restore options: PV restoration, existing resource policy
- Error detection (AlertBanner for failed or partial restores)
Schedule Detail View:
- Cron schedule (monospace), last backup timestamp
- Pause state detection (AlertBanner when paused)
- Validation failure detection (AlertBanner)
- Backup template: storage location, TTL, namespace/resource filters, snapshot settings
BackupStorageLocation Detail View:
- Phase (Available/Unavailable), last validation and sync times
- Provider configuration: bucket, prefix, region, access mode
- Provider-specific config key-value pairs
VolumeSnapshotLocation Detail View:
- Provider name and configuration parameters
Resource Browser: Smart columns show phase badges, storage location, namespace counts, duration, expiry (with color-coded warnings), and error/warning counts.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Backup | velero.io/v1 |
— | Yes | — |
| Restore | velero.io/v1 |
— | Yes | — |
| Schedule | velero.io/v1 |
— | Yes | — |
| BackupStorageLocation | velero.io/v1 |
— | Yes | — |
| VolumeSnapshotLocation | velero.io/v1 |
— | Yes | — |
External Secrets Operator (ESO) synchronizes secrets from external providers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager, and more) into Kubernetes Secrets.
ExternalSecret Detail View:
- Sync status badge, last sync time, refresh interval
- Store reference with clickable link and kind indicator
- Secret mappings table (secret key → remote key, property, version)
- Data sources with type badges
- Target secret configuration and creation policies
- Sync failure detection (AlertBanner when Ready condition is False)
ClusterExternalSecret Detail View:
- Overview: provisioned vs failed namespace counts
- Namespace selection: explicit list or label selector
- Provisioned namespaces (green badges)
- Failed namespaces with per-namespace error details (AlertBanner)
- ExternalSecret spec: refresh interval, store reference, data/source counts
SecretStore / ClusterSecretStore Detail View:
- Provider with color-coded badge (AWS orange, Azure/GCP blue, Vault purple, etc.)
- Provider-specific details: region, vault URL, project ID, authentication method
- Connection status with reason and last transition
- Retry settings
- Readiness detection (AlertBanner when not Ready)
Resource Browser: Smart columns show sync status, store reference, provider type, refresh interval, and last sync time.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| ExternalSecret | external-secrets.io/v1beta1 |
— | Yes | — |
| ClusterExternalSecret | external-secrets.io/v1beta1 |
— | Yes | — |
| SecretStore | external-secrets.io/v1beta1 |
— | Yes | — |
| ClusterSecretStore | external-secrets.io/v1beta1 |
— | Yes | — |
CloudNativePG (CNPG) is the Kubernetes operator for PostgreSQL, covering the full lifecycle from bootstrapping to monitoring, with high availability, automated failover, and backup management.
Cluster Detail View:
- Phase, instances ready/desired, primary instance, image version
- Instance node distribution (which K8s nodes run each PostgreSQL instance)
- Storage configuration: data size, storage class, WAL storage
- Backup configuration: destination, retention policy, last successful backup, recovery point
- Monitoring: PodMonitor integration, custom query ConfigMaps
- Replication settings (for replica clusters)
- PostgreSQL parameters
- Health detection (AlertBanner for degraded clusters, failover/switchover in progress)
Backup Detail View:
- Phase, backup method, duration, start/stop timestamps
- Cluster reference with clickable link
- Destination path and server name
- Recovery target
- Failure detection (AlertBanner with error message)
ScheduledBackup Detail View:
- Cron schedule, last/next schedule timestamps
- Suspension detection (AlertBanner when paused)
- Backup configuration: cluster reference, method, owner reference settings
Pooler Detail View:
- Type (read-write/read-only) with colored badge, pool mode
- Instances ready/desired
- Cluster reference with clickable link
- PgBouncer parameters
- Degraded state detection (AlertBanner when not all instances ready)
Resource Browser: Smart columns show status, instance counts (with degraded highlighting), primary instance, image tag, storage size, cluster reference, and schedule expressions.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Cluster | postgresql.cnpg.io/v1 |
— | Yes | — |
| Backup | postgresql.cnpg.io/v1 |
— | Yes | — |
| ScheduledBackup | postgresql.cnpg.io/v1 |
— | Yes | — |
| Pooler | postgresql.cnpg.io/v1 |
— | Yes | — |
Kyverno is a Kubernetes-native policy engine for validation, mutation, generation, and image verification — no new language required, policies are written as Kubernetes resources.
Policy / ClusterPolicy Detail View:
- Failure action badge (Enforce in red, Audit in yellow)
- Configuration: background scanning, webhook timeout, failure policy, schema validation
- Rule type summary (validate/mutate/generate/verifyImages counts)
- Individual rules with type badges and match/exclude indicators
- Auto-generated rules list
PolicyReport / ClusterPolicyReport Detail View:
- Visual result bar chart (pass/fail/warn/error/skip proportions)
- Scope and source information
- Individual results with status badges, severity levels, policy/rule names
- Expandable details: message, category, source, affected resources
- Problem detection (AlertBanner for failures or errors)
Resource Browser: Smart columns show status (colored by worst outcome), failure action, rule counts, and pass/fail/warn/error/skip breakdowns.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Policy | kyverno.io/v1 |
— | Yes | — |
| ClusterPolicy | kyverno.io/v1 |
— | Yes | — |
| PolicyReport | wgpolicyk8s.io/v1alpha2 |
— | Yes | — |
| ClusterPolicyReport | wgpolicyk8s.io/v1alpha2 |
— | Yes | — |
Knative extends Kubernetes with serverless capabilities: scale-to-zero, request-driven autoscaling, event-driven architectures, and simplified service deployment.
Topology: Full Knative Serving chain — Route → KnativeService → Configuration → Revision → Deployment → Pod. Eventing flow — PingSource → Broker → Trigger → subscriber target. See how traffic is split across revisions, which configurations are active, and how events flow from sources through brokers to triggers.
Knative in Topology View — Serving chain and Eventing flow
KnativeService Detail View:
- Status with URL and ingress readiness
- Latest ready and latest created revision links
- Scaling configuration (min/max scale, concurrency, timeout)
- Traffic split across revisions with percentage bars
- Container template (image, ports, env, resources)
- Conditions (Ready, RoutesReady, ConfigurationsReady)
KnativeService Detail View — URL, scaling, traffic splits, and conditions
Revision Detail View:
- Container image with tag
- Concurrency model and container concurrency limit
- Timeout and scaling bounds (min/max)
- Traffic percentage (active vs inactive)
- Conditions (Ready, ContainerHealthy, ResourcesAvailable, Active)
Route Detail View:
- URL and domain
- Traffic targets with revision names and percentage distribution
- Conditions (Ready, AllTrafficAssigned, IngressReady)
Configuration Detail View:
- Latest created and latest ready revision references
- Generation tracking
- Conditions (Ready)
Broker Detail View:
- Address (internal URL for event delivery)
- Delivery configuration (dead letter sink, retry, backoff)
- Conditions (Ready, Addressable, FilterReady, IngressReady, TriggerChannelReady)
Trigger Detail View:
- Broker reference
- Subscriber target (service, URI, or Kubernetes reference)
- Event filter attributes
- Delivery configuration (dead letter sink)
- Conditions (Ready, BrokerReady, SubscriberResolved, DependencyReady)
Source Detail Views (PingSource, ApiServerSource, ContainerSource, SinkBinding):
- Sink target reference
- Source-specific configuration:
- PingSource: cron schedule, data payload, content type
- ApiServerSource: API resources watched, event mode, service account
- ContainerSource: container image and arguments
- SinkBinding: subject reference (Deployment, Job, etc.)
- Conditions (Ready, Deployed, SinkProvided)
Networking Detail Views (Ingress, Certificate, ServerlessService):
- KnativeIngress: ingress class, visibility, TLS hosts, rules with path/host routing
- KnativeCertificate: domain names, DNS names, not-after expiry
- ServerlessService: mode (Proxy/Serve), network status
Flow Detail Views (Sequence, Parallel):
- Sequence: ordered list of steps with subscriber references
- Parallel: branches with filter and subscriber configurations
- Reply/channel template settings
Resource Browser: Smart columns show status, URLs, latest revisions, traffic splits, schedules, sinks, brokers, subscribers, and filters at a glance.
| CRD | Group | Topology | Detail View | AI Summary |
|---|---|---|---|---|
| Service | serving.knative.dev/v1 |
Yes | Yes | — |
| Configuration | serving.knative.dev/v1 |
Yes | Yes | — |
| Revision | serving.knative.dev/v1 |
Yes | Yes | — |
| Route | serving.knative.dev/v1 |
Yes | Yes | — |
| DomainMapping | serving.knative.dev/v1beta1 |
— | Yes | — |
| Broker | eventing.knative.dev/v1 |
Yes | Yes | — |
| Trigger | eventing.knative.dev/v1 |
Yes | Yes | — |
| EventType | eventing.knative.dev/v1beta2 |
— | Yes | — |
| Channel | messaging.knative.dev/v1 |
— | Yes | — |
| InMemoryChannel | messaging.knative.dev/v1 |
— | Yes | — |
| Subscription | messaging.knative.dev/v1 |
— | Yes | — |
| PingSource | sources.knative.dev/v1 |
Yes | Yes | — |
| ApiServerSource | sources.knative.dev/v1 |
Yes | Yes | — |
| ContainerSource | sources.knative.dev/v1 |
Yes | Yes | — |
| SinkBinding | sources.knative.dev/v1 |
Yes | Yes | — |
| Sequence | flows.knative.dev/v1 |
— | Yes | — |
| Parallel | flows.knative.dev/v1 |
— | Yes | — |
| Ingress | networking.internal.knative.dev/v1alpha1 |
— | Yes | — |
| Certificate | networking.internal.knative.dev/v1alpha1 |
— | Yes | — |
| ServerlessService | networking.internal.knative.dev/v1alpha1 |
— | Yes | — |
OpenCost is a CNCF tool for Kubernetes cost monitoring, exposing cloud provider pricing and workload resource allocation as Prometheus metrics.
Radar discovers if Opencost metrics are available in the already-discovered Prometheus. If OpenCost is installed and scraping into Prometheus, cost data appears automatically with no additional configuration. The integration is passive and read-only.
Resource Costs
Dashboard Cost Card: Cluster hourly cost and projected monthly cost, top 5 most expensive namespaces with a horizontal bar chart. Clicking navigates to the full Cost Insights view.
Cost Insights View (/cost):
- Header: cluster hourly/monthly cost, efficiency %, idle cost projection
- Resource cost split bar: CPU / Memory / Storage percentage breakdown
- Cost trend chart with 6h/24h/7d range selector and per-namespace hover tooltips
- Namespace breakdown table (sortable by cost, efficiency, CPU/memory split) — click any row to expand per-workload costs on demand
- Node costs table: instance type, region, and hourly/monthly pricing per machine
- Efficiency color coding: green (50%+), amber (25–50%), red (below 25%)
- OpenCost (or Kubecost) deployed in your cluster, with it's metrics being scraped by Prometheus
OpenCost cost data is not CRD-based — no custom resources are required. Cost views appear automatically when metrics are detected; they are hidden when no OpenCost metrics are found in Prometheus.
Radar automatically discovers and displays every CRD installed in your cluster — no configuration or plugins required. Resources appear in the sidebar, can be filtered and searched, and show full YAML with syntax highlighting in the detail drawer. The integrations above add richer presentation, but every CRD is browsable out of the box.