Kubernetes components

On a Kubernetes project, components are Helm charts released into your cluster, namespace-scoped to the project. The catalog carries thirty-plus charts — Nexus, Grafana, Loki, VictoriaMetrics and its agent, kube-state-metrics, ingress-nginx, cert-manager, a GitLab runner chart, and more — each entry pinned to a chart version and an app version.

Revisions and re-pinning

Catalog entries are immutable revisions. When the catalog moves, your component says revision N available: pin one component to the latest revision, or the whole project at once. Only the pin moves — the running release changes on your next deploy, never behind your back. A revision whose values cannot express your sizing is refused rather than guessed.

Exposure

Components with a web surface are exposed through the project's ingress controller with per-component hostnames; TLS is part of the exposure story. Where a component has a real UI (Grafana, Nexus…), the platform links to it directly from the project pages.

The monitoring stack

Grafana, VictoriaMetrics, vmagent and kube-state-metrics form a stack the platform understands as one thing: if part of it is missing, the project page offers to complete and deploy the rest in the right order, and dashboards arrive wired to the project's own datasource — including per-component boards (JVM, Kubernetes cluster, log browsing) you can opt into.

Sizing

CPU and memory requests are set per component through the catalog's value paths — the platform maps your numbers onto each chart's own spelling of resources, and refuses combinations the chart cannot express.