# Platform integrations: cert-manager, Istio, Karpenter & KEDA

Beyond [GitOps](https://klustr.dev/docs/gitops/) and [Gateway API](https://klustr.dev/docs/gateway-api/), Klustr promotes a
few more CRD families from the generic [Custom Resources](https://klustr.dev/docs/custom-resources/)
browser to first-class, typed views. Each sidebar group appears only when its
CRDs are detected in an active context, so nothing clutters a cluster that
doesn't run it. Each reads its CRDs at the API version the cluster serves, so it
tracks whichever release the cluster runs.

A **Ready** column reads the same in every integration: **Ready**, **Not ready**
or **Unknown**, from the resource's Ready condition.

All mutating actions below respect a context's
[read-only mode](https://klustr.dev/docs/getting-started/#read-only-mode).

## cert-manager

Shown when the `cert-manager.io` CRDs are present.

- **Certificates** — ready state and expiry at a glance.
- **Issuers / ClusterIssuers** — the one-of spec (`acme` / `ca` / `selfSigned` /
  `vault` / `venafi`) is collapsed into a single **Type** column; ACME issuers
  also show their server and email.
- **Issuance chain** — a Certificate's detail drills down the full chain,
  `Certificate → CertificateRequest → Order → Challenge`, each as a tab whose
  rows deep-link into the matching detail. When issuance is stuck, this is where
  you see which step failed and why.
- **Renew** — one click, no `cmctl` on your PATH.

## Istio

Shown when the `networking.istio.io` CRDs are present.

- **VirtualServices**, **DestinationRules** and **PeerAuthentications**,
  watch-backed.

## Karpenter

Shown when the `karpenter.sh` CRDs are present.

- **NodePools** — weight, node class, consolidation policy, CPU / memory limits
  and current usage, node count and ready state.
- **NodeClaims** — provisioning status for the nodes Karpenter is bringing up.
- **EC2NodeClasses** — shown when the AWS provider's `karpenter.k8s.aws` CRDs are
  present: readiness, AMI family, IAM role and instance profile, and the subnets,
  security groups and AMIs the selector terms resolved to, each AMI with its
  requirements. A NodePool's or NodeClaim's node class opens its EC2NodeClass.

## KEDA

KEDA has **no dedicated sidebar group** — its ScaledObjects stay in the generic
CRD browser. What Klustr adds is enrichment of the HPAs KEDA manages.

A KEDA-managed HPA is a vanilla HorizontalPodAutoscaler whose metrics are all
`External` and named `s0-…`, `s1-…` — without help they render as a wall of
identical "external" rows. Klustr maps each back to its ScaledObject trigger and
relabels it with the real trigger type plus the metadata that predicts scaling
(Prometheus metric + threshold, cron schedule, Kafka topic + lag, and so on).

Find it under **Config → HorizontalPodAutoscalers**: open a KEDA-owned HPA and
the Targets read as real triggers instead of opaque external metrics.