In-cluster deployment

Note: This guide covers deploying Radar as a pod in your cluster. If you’re running Radar locally but need to understand cluster connection behavior (e.g., using KUBECONFIG to override in-cluster detection), see the Configuration Guide.

• New installation: follow Quick Start, then configure how your team will reach and authenticate to Radar.
• Existing installation: start with Upgrading. The correct workflow depends on whether Helm, Argo CD, Flux, or another system owns the deployment.

​

Quick Start

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update skyhook
helm upgrade --install radar skyhook/radar -n radar --create-namespace

kubectl port-forward svc/radar 9280:9280 -n radar
open http://localhost:9280

​

Installation settings

audit:
  ignoredNamespaces: [kube-system, kube-node-lease, kube-public, "*-system"]
  disabledChecks: []
helm:
  ociSources:
    - oci://ghcr.io/myorg/charts

{
  "version": 1,
  "audit": { "ignoredNamespaces": ["kube-system", "*-system"], "disabledChecks": [] },
  "helmOciSources": ["oci://ghcr.io/myorg/charts"]
}

​

Upgrading

​

Helm

helm list --all-namespaces --filter radar

helm repo update skyhook
helm upgrade radar skyhook/radar \
  --namespace radar \
  --reset-then-reuse-values \
  --wait

​

Argo CD or Flux

• Argo CD Application: if the Application directly references the Radar chart, update its Helm chart targetRevision. Otherwise update the chart or image version in the Git source referenced by the Application, then sync it.
• Flux HelmRelease: update the Radar chart version in the HelmRelease source, usually spec.chart.spec.version, then reconcile the HelmRelease.
• Flux Kustomization: update the Radar chart or image version in the Git source referenced by the Kustomization, then reconcile it.

​

If the manager could not be identified

kubectl get deployment --all-namespaces \
  --selector app.kubernetes.io/name=radar \
  --output yaml

• meta.helm.sh/release-name and meta.helm.sh/release-namespace identify the underlying Helm release.
• argocd.argoproj.io/tracking-id or argocd.argoproj.io/instance points to Argo CD ownership.
• helm.toolkit.fluxcd.io/* and kustomize.toolkit.fluxcd.io/* point to Flux ownership.

​

Verify or roll back

kubectl rollout status deployment/radar --namespace radar --timeout 5m

​

Exposing with Gateway API

# values.yaml
httpRoute:
  enabled: true
  parentRefs:
    - name: public-gateway
  hostnames:
    - radar.your-domain.com

​

Exposing with Ingress

​

Ingress without authentication

Warning: Only use this behind a trusted private network boundary. Anyone who can reach Radar can use the permissions granted to its ServiceAccount. For shared or externally reachable installations, configure authentication before exposing the ingress.

# values.yaml
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: radar.your-domain.com
      paths:
        - path: /
          pathType: Prefix

helm upgrade --install radar skyhook/radar \
  -n radar -f values.yaml

​

Subpath Ingress (No Strip-Prefix)

# values.yaml
basePath: /radar

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: tools.your-domain.com
      paths:
        - path: /radar
          pathType: Prefix

basePath: /radar
auth:
  oidc:
    redirectURL: https://tools.your-domain.com/radar/auth/callback           # not /auth/callback
    postLogoutRedirectURL: https://tools.your-domain.com/radar/              # not /
    # With backchannelLogout, the URI registered at the IdP is likewise
    # https://tools.your-domain.com/radar/auth/backchannel-logout

​

With ingress basic authentication

1. Create the auth secret:
   # Install htpasswd if needed: brew install httpd (macOS) or apt install apache2-utils (Linux)
   
   # Create the file and enter the password when prompted
   htpasswd -cB auth admin
   
   # Create the secret
   kubectl create secret generic radar-basic-auth \
     --from-file=auth \
     -n radar
   
   rm auth  # Clean up local file
   
2. Configure ingress:
   # values.yaml
   ingress:
     enabled: true
     className: nginx
     annotations:
       nginx.ingress.kubernetes.io/auth-type: basic
       nginx.ingress.kubernetes.io/auth-secret: radar-basic-auth
       nginx.ingress.kubernetes.io/auth-realm: "Radar"
     hosts:
       - host: radar.your-domain.com
         paths:
           - path: /
             pathType: Prefix
   
3. Deploy:
   helm upgrade --install radar skyhook/radar \
     -n radar -f values.yaml
   

​

With TLS (HTTPS)

# values.yaml
ingress:
  enabled: true
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  hosts:
    - host: radar.your-domain.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: radar-tls
      hosts:
        - radar.your-domain.com

​

DNS Setup

1. Get your ingress IP:
   kubectl get ingress -n radar
   
2. Create a DNS A record pointing your domain to the ingress IP.

radar.<cluster-name>.<domain>

​

RBAC

• Pods, Services, ConfigMaps, Events, Namespaces, Nodes, ServiceAccounts, Endpoints
• Deployments, DaemonSets, StatefulSets, ReplicaSets
• Ingresses, NetworkPolicies, Jobs, CronJobs, HPAs, PVCs
• Kubernetes 1.37 Workloads, PodGroups, CompositePodGroups, PodCertificateRequests, and ClusterTrustBundles when the API server advertises them; the scheduling APIs are feature-gated
• Pod logs (enabled by default)

​

Opt-in Permissions

Node management (cordon, uncordon, drain) is available via the MCP server and API. These operations require patch on nodes, list on pods, and create on pods/eviction, which are not included in the default ClusterRole. The read-only drain plan (POST /api/nodes/{name}/drain-plan) needs get on nodes, list on pods and list on poddisruptionbudgets; without the last one the plan is still returned, marked as not having evaluated PodDisruptionBudgets. Note the defaults differ when deleteEmptyDirData is omitted from the request body: the drain plan assumes false, while the drain itself (and the MCP manage_node drain) assumes true - API callers should always send the field explicitly. Add the grants via rbac.additionalRules or use per-user authentication so each user’s own RBAC governs node operations.

# values.yaml
rbac:
  secrets: false      # Keep disabled unless needed
  podExec: true       # Enable terminal feature
  podLogs: true       # Enable log viewer (default)
  portForward: true   # Enable port forwarding
  helm: false         # Enable Helm write operations (broad permissions)

# values.yaml
debug:
  image: my-registry.internal/busybox:1.36

​

CRD Permissions

rbac:
  crdGroups:
    all: false          # get/list/watch on every API group and resource, including Secrets
    # Individual groups (default true unless noted):
    argo: true          # argoproj.io
    calico: true        # projectcalico.org, crd.projectcalico.org
    certManager: true   # cert-manager.io
    flux: true          # *.toolkit.fluxcd.io
    istio: true         # networking.istio.io, security.istio.io
    karpenter: true     # karpenter.sh, karpenter.k8s.aws, karpenter.azure.com, karpenter.k8s.gcp
    keda: true          # keda.sh
    knative: true       # serving, eventing, sources, messaging, flows, networking.internal (.knative.dev)
    prometheus: true    # monitoring.coreos.com
    traefik: true       # traefik.io
    velero: true        # velero.io
    # ... and 25+ more (see values.yaml for full list)
  additionalCrdGroups: []   # Add custom API groups
  additionalRules: []       # Arbitrary extra ClusterRole rules

​

Graceful RBAC Degradation

• Namespaced resources (Pods, Deployments, Services, …) are filtered by namespace: read access is granted in any namespace where the user has list-pods or list-deployments. Secrets are gated independently - a user sees Secret objects (including Helm release storage) only in namespaces where their own RBAC grants list secrets, even when they have broader access in that namespace. RBAC objects and webhook configurations are likewise re-checked per user. Other cached resource types are visible within a namespace once the user has workload-read access there.
• Cluster-scoped resources (Nodes, PVs, StorageClasses, ClusterRoles, cluster-scoped CRDs, …) are gated per-kind via SubjectAccessReview. Cluster-wide pod visibility does NOT imply Node visibility - every cluster-scoped read goes through its own RBAC check, with results cached per user.

# Custom Role granting access to a single namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: radar-viewer
  namespace: my-team
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "services", "deployments", "daemonsets", "statefulsets",
                "replicasets", "jobs", "cronjobs", "configmaps", "events",
                "ingresses", "persistentvolumeclaims", "resourcequotas"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: radar-viewer
  namespace: my-team
subjects:
  - kind: ServiceAccount
    name: radar
    namespace: radar
roleRef:
  kind: Role
  name: radar-viewer
  apiGroup: rbac.authorization.k8s.io

​

Authentication

# values.yaml
auth:
  mode: proxy

# values.yaml
auth:
  mode: oidc
  oidc:
    issuerURL: https://accounts.google.com
    clientID: your-client-id
    clientSecret: your-client-secret
    redirectURL: https://radar.example.com/auth/callback

​

Security Considerations

1. Authentication: Always enable authentication when exposing via ingress. Use built-in auth (proxy or OIDC mode) or basic auth (shown above) at minimum.
2. RBAC scope: The default ClusterRole grants cluster-wide read access. For namespace-restricted access, set rbac.create: false and create a custom Role/RoleBinding. Radar will gracefully adapt to the available permissions.
3. Privileged features: Terminal (podExec) and port forwarding grant significant access. Only enable these in trusted environments or when using per-user authentication.
4. Network access: Consider using NetworkPolicies to restrict which pods can reach Radar.

​

Timeline Storage: memory vs sqlite vs postgres

• memory (default): events live in-process, lost on pod restart. Lowest footprint; pick this if you only need recent activity (last few hours).
• sqlite: events persist to a PVC across restarts. Multi-day audit trail; pick this for long-running in-cluster deployments where you care about history surviving pod cycles. Requires persistence.enabled=true.
• postgres: events persist in an externally managed PostgreSQL database. Pick this for durability across restarts and rolling updates, or when you want to avoid the single-PVC constraint. Use a dedicated database per Radar deployment. The DSN must be provided via an existing Kubernetes Secret (timeline.postgres.existingSecret); Helm never touches the credential.

​

PostgreSQL requirements

• PostgreSQL 14+ (tested against 17).
• A dedicated database and a user with DDL permissions so Radar can create/update the radar_timeline_* tables, indexes, and migrations on first startup.
• sslmode and other TLS settings are controlled through the DSN string.
• The DSN is read from a Secret; never put it in Helm values or config.json.
• Restart the Radar Deployment after rotating the Secret because Kubernetes does not refresh environment variables in running containers.
• There is no built-in import path from SQLite to PostgreSQL. Migrating historical events is not supported.
• An unreachable PostgreSQL costs you the timeline, not the rest of Radar. Cluster views keep working, the Timeline page says the database can’t be reached and points to the logs, which have the connection error (so does the diagnostics overlay), and Radar reconnects on its own once the database answers. Radar logs when the database becomes unreachable, how soon it tries again, and when it answers again, naming the database’s host, port, name and user (never the password) with the driver’s error; search the logs for [timeline]. Events that occur while it is down are not recorded and are not recovered later; the dropped count in diagnostics shows how many. Radar never falls back to an in-memory timeline, because that looks healthy and then loses everything on the next restart.
• Because the rest of Radar keeps working and /api/health stays healthy, an outage is easy to miss. Alert on Radar’s /metrics instead: radar_timeline_available is 0 while the database can’t be reached (checked at most every 5s, with a 2s limit on each check), and radar_timeline_dropped_events_total{reason="store_unavailable"} and {reason="store_failed"} count the changes lost to it. For example, radar_timeline_available == 0 held for 5 minutes. The reason itself is not in the metrics, because it names the database host; it is in the Timeline page and the diagnostics overlay.
• Verified TLS modes: require and verify-full.

​

Configuration Reference

​

Troubleshooting

​

Pod not starting

kubectl logs -n radar -l app.kubernetes.io/name=radar
kubectl describe pod -n radar -l app.kubernetes.io/name=radar

​

Ingress not working

kubectl get ingress -n radar -o yaml
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

​

Node drain requests time out

nginx.ingress.kubernetes.io/proxy-read-timeout: "150"
nginx.ingress.kubernetes.io/proxy-send-timeout: "150"

​

Changes fail with “Radar refused this request”

• Configure the proxy to keep the original Host header.
• Tell Radar the address you open it at. In the Helm chart:
  trustedOrigins:
    - http://radar.internal
  
  Outside Helm, set RADAR_TRUSTED_ORIGINS or pass --trusted-origins. Use the scheme and host exactly as they appear in your browser’s address bar, with the port if there is one. Separate several with commas. A trusted origin can do everything Radar’s own page can: read, make changes and open pod terminals (and, on a local install, the local terminal). List only addresses that serve Radar. This setting does not cover the MCP endpoint at /mcp, which has its own RADAR_MCP_TRUSTED_ORIGINS.

kubectl logs -n radar -l app.kubernetes.io/name=radar | grep '\[origin\] refused'

​

Metrics charts show “Prometheus not connected”

• no Prometheus service found in cluster - nothing matched the well-known names or labels. Set traffic.prometheusUrl.
• No working Prometheus endpoint found. Candidate services could not be reached - candidates exist but their Service addresses did not answer from Radar’s pod. In-cluster Radar does not fall back to port-forwarding. Check endpoint health and network access, or configure a reachable traffic.prometheusUrl. This does not mean Prometheus is absent.
• Prometheus candidate monitoring/prometheus-server:9090 was unreachable, and NetworkPolicy monitoring/… isolates ingress to its pods with no rule admitting radar/… - Radar found the reason. When a probe fails at the network level, Radar evaluates the core NetworkPolicy objects it can see in its own namespace and the candidate’s against its own pod and the candidate’s published endpoints, and names the policies only when they deny the connection outright (an egress denial on Radar’s side is reported the same way). It stays silent whenever the answer is uncertain: MY_POD_NAME/MY_POD_NAMESPACE unset, a namespace-scoped install that cannot list policies in the candidate’s namespace, an endpoint it cannot resolve, a hostNetwork pod, or a probe that was refused rather than unreachable. Two limits: this is the policy’s declared intent - a CNI that does not enforce NetworkPolicy (kindnet) will still pass the traffic - and Cilium/Calico CRD policies are not evaluated.
• Prometheus headers are configured but no Prometheus URL is set - see traffic.prometheusHeadersFromEnv above.

​

Basic auth prompt not appearing

kubectl get secret radar-basic-auth -n radar -o jsonpath='{.data.auth}' | base64 -d
# Should show: username:<password-hash>

​

Uninstalling

helm uninstall radar -n radar