Add-ons

Je gehoste control plane heeft geen plan. Je stelt de vorm in (1 tot 3 API-servers, een state-limiet) en zet daar add-ons bovenop.

Deze pagina is de praktische aanvulling op Prijzen. Per add-on vertelt ze wat je krijgt, hoe je hem gebruikt en, waar van toepassing, welk commando je kunt plakken. De API-referentie beschrijft elke API-route die deze pagina noemt.

Je kiest add-ons in het dashboard: in de aanmaakwizard, en later onder Instellingen → Vorm van het cluster. De kaart Add-ons op de clusterpagina toont alleen wat er is geïnstalleerd.

De kubehz-operator vertaalt je keuze naar de bijbehorende Kubermatic-(KKP-)instellingen op je control plane. Je bewerkt KKP nooit rechtstreeks.

Apps zijn geen add-ons

Add-ons zijn control-plane-opties. Software die in je cluster draait, komt uit de app-catalogus op het tabblad Applicaties van het cluster.

Kies een app en een versie, geef optioneel Helm-values mee, en de operator installeert hem (GET /api/catalog/apps, PUT /api/clusters/{id}/apps/{name}). Vandaag bevat de catalogus cert-manager. Meer apps volgen zodra wij ze hebben beoordeeld.

Inbegrepen, geen add-ons

Twee dingen die je als add-on verwacht, zijn geen add-ons, omdat elk gehost control plane ze heeft:

etcd-back-ups: elk gehost control plane bevat geplande snapshots, standaard aan. De details staan hieronder bij etcd-back-ups.
Hoge beschikbaarheid: HA is het aantal API-servers dat je instelt (3 API-servers), geen aparte post. Stel er drie in en je hebt HA.

Add-ons in het kort: elke add-on hieronder is € 0 tot 1 december 2026. De tabel toont de lijstprijzen die daarna ingaan, excl. btw. Consumenten betalen btw bovenop: 22% in Slovenië of het tarief van hun land. De pagina Prijzen toont de prijzen incl. btw.

€ 0 tot 1 december 2026

Add-on	Prijs vanaf 1 december 2026	Maandplafond	Vereist
Cluster-webdashboard (Headlamp)	€ 0,001/uur	€ 0,73/maand	elke vorm
OPA / Gatekeeper	gratis	gratis	elke vorm
etcd-back-ups	inbegrepen	inbegrepen	elk control plane
Auditlogging	€ 0,001/uur	€ 0,73/maand	elke vorm
Monitoring	€ 0,010/uur	€ 7,30/maand	elke vorm
Logging	€ 0,008/uur	€ 5,84/maand	3 API-servers
Toegewijde nodes	€ 0,018/uur	€ 13,14/maand	3 API-servers

Hoe de meter werkt. kubehz factureert elk begonnen uur volledig. De facturering start zodra je de resource aanmaakt. kubehz factureert de resource zolang ze bestaat, in welke staat dan ook. Alleen verwijderen stopt de kosten.

De uurbedragen van één eenheid komen nooit boven haar maandprijs uit. Het €/maand-bedrag is het uurtarief vermenigvuldigd met 730 uur, en het is een maximum, ook in een maand van 31 dagen.

kubehz factureert add-ons apart. Blijft een add-on bestaan nadat je iets anders hebt verwijderd, dan factureert kubehz hem tot je ook de add-on verwijdert. Zie Prijzen.

Eén prijs staat niet in deze lijst, omdat het geen add-on is. Een statische node (een worker-node die je zelf meebrengt) kost € 0,001/uur per node, hooguit € 0,73/maand excl. btw. kubehz factureert hem per uur dat hij Ready meldt.

Een NotReady-node is de enige uitzondering op de regels hierboven: kubehz factureert hem nooit. Zie Statische nodes.

Cluster-webdashboard (Headlamp)

Wat het inschakelt. Een gehost Headlamp-webdashboard voor je cluster. kubehz draait het naast je control plane en publiceert het op een direct bereikbare publieke URL:

text

https://dash-<cluster-id>.kubehz.cloud

Open het vanaf de detailpagina van het cluster in het kubehz-dashboard (knop Dashboard openen). Je logt in met je kubehz-account (dezelfde SSO-login als het platform).

Wat je kunt zien en doen, volgt je Kubernetes-RBAC. Headlamp stuurt jouw eigen identiteitstoken door naar de API-server en heeft zelf geen admin-credentials. Geen kubeconfig, geen proxy, geen tweede wachtwoord.

Het kost € 0,001/uur, hooguit € 0,73/maand excl. btw, op elke vorm. Je kunt het uitvinken in de wizard en onder Instellingen → Vorm. De aanmaakwizard vinkt geen enkele add-on voor je aan: deze vink je zelf aan.

Headlamp verving in juli 2026 de verouderde upstream-kubernetes-dashboard achter deze add-on: zelfde optie, zelfde prijs, een betere toegangsroute.

Liever een lokale app? Headlamp desktop opent hetzelfde cluster met je gedownloade kubeconfig, zonder add-on. Zo krijg je ook een dashboard voor self-hosted clusters.

Terugvaloptie: kubectl proxy. Draait op je cluster nog de oude in-cluster kubernetes-dashboard, dan bereik je die nog steeds via de service-proxy van de API-server. De proxy authenticeert met je eigen kubeconfig:

Download de kubeconfig van het cluster uit het kubehz-dashboard (detailpagina van het cluster).
Start een lokale proxy naar de API-server:
bash
```
kubectl --kubeconfig ./kubeconfig proxy
```

Open de service-proxy-URL van het dashboard in je browser:

text

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

De proxy neemt je kubeconfig over. Het dashboard ziet precies wat je met kubectl zou zien, en niet meer.

OPA / Gatekeeper

Wat het inschakelt. OPA Gatekeeper-policyhandhaving in je cluster. Gatekeeper toetst resources bij admissie aan policies die je schrijft als ConstraintTemplate + Constraint-objecten.

Het is gratis en beschikbaar op elke vorm. De operator koppelt deze add-on aan opaIntegration.enabled van KKP. De Gatekeeper-componenten draaien in je cluster.

Hoe je het gebruikt. Zodra de add-on aan staat, pas je een ConstraintTemplate toe (die definieert een herbruikbare regel) en daarna een Constraint (die past de regel toe op specifieke kinds). De klassieker om te beginnen is “elke namespace moet een owner-label hebben”:

Toon de volledige ConstraintTemplate + Constraint YAML

yaml

# 1. De template: een herbruikbare "required labels"-regel.
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
# 2. De constraint: vereis een `owner`-label op elke Namespace.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["owner"]

Sla beide documenten op als required-labels.yaml en pas ze daarna toe:

bash

kubectl apply -f required-labels.yaml

Hoe handhaving eruitziet. Daarna weigert de admission-webhook een namespace zonder owner-label:

console

$ kubectl create namespace demo
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied
the request: [ns-must-have-owner] you must provide labels: {"owner"}

Maak de namespace in plaats daarvan meteen mét het label aan, en Gatekeeper laat hem toe:

bash

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    owner: platform-team  # elke waarde — de policy vereist alleen de sleutel
EOF

etcd-back-ups

Wat het inschakelt. Geplande snapshots van de etcd van je control plane, de datastore achter elk object in je cluster (Deployments, Secrets, CRD’s, alles).

Elk gehost control plane bevat ze, standaard aan. Er is niets te kopen of in te schakelen. De operator levert een EtcdBackupConfig van KKP voor je cluster.

Schema en bewaring. Back-ups draaien elke 6 uur (cron 0 */6 * * *). kubehz bewaart de laatste 20 snapshots en ruimt oudere automatisch op. Het schrijft de snapshots naar door kubehz beheerde objectopslag in de EU. Je beheert geen bucket.

Eenmalige snapshots en herstel. Naast het schema kun je zelf een snapshot maken, vóór een riskante wijziging, en herstellen vanaf elke snapshot die je hebt. Beide zijn selfservice: gebruik de sectie Back-ups op de clusterpagina, of de API.

In de API maakt POST /api/clusters/{id}/snapshots met een name een snapshot, somt GET ze op, verwijdert DELETE .../snapshots/{name} er een, en herstelt de herstelactie op een snapshot die snapshot.

Een herstel is een KKP-EtcdRestore op je control plane. De API-server is niet beschikbaar gedurende de minuten die het herstel duurt, en elk object dat sinds de snapshot is gewijzigd, is weg. Wil je dat iemand meekijkt, vraag het dan in de chat voordat je op de knop drukt.

Auditlogging

Wat het inschakelt. Kubernetes-API-auditlogging op je control plane: een registratie van wie wat tegen de API-server heeft gedaan (requests, subjecten, werkwoorden, resources).

Het kost € 0,001/uur, hooguit € 0,73/maand excl. btw, op elke vorm. De operator koppelt deze add-on aan auditLogging van KKP met een vaste policy-preset.

Welke preset geldt. kubehz schakelt de auditpolicy-preset recommended in. Dit gebalanceerde niveau legt de beveiligingsrelevante operaties vast zonder het volume van een volledige request/response-stroom. Je kunt de preset niet wijzigen: er is geen policy-editor per cluster.

Waar de events heen gaan. De API-server op je control plane zendt de auditevents uit. Kies op de clusterpagina, of met PUT /api/clusters/{id}/audit-delivery, een aflevering voor ze:

webhook post elke batch naar een HTTPS-endpoint van jou (met een optionele CA-bundel).
s3 schrijft ze naar een S3-compatibele bucket die je zelf bezit (endpoint, bucket, prefix, access key).
none houdt ze alleen op het control plane.

Om de events te doorzoeken, combineer je deze add-on met Logging. Logging geeft je een plek om ze op schaal te lezen.

Monitoring

Wat het inschakelt. Metrics per cluster: kubehz verzamelt ze in je cluster en stuurt ze naar het kubehz-platform. Het kost € 0,010/uur, hooguit € 7,30/maand excl. btw, op elke vorm.

Je schakelt het in via het kubehz-dashboard: in de add-on-opties van de wizard als je het cluster aanmaakt, of later onder Instellingen → Vorm van het cluster. Een Prometheus draait in je cluster en voedt het platform. Je draait of schaalt hem niet zelf.

Wat de kosten dekken. De platformkant: multi-tenant metricsopslag met 15 dagen bewaring, het querypad van het dashboard en alerting. kubehz draait en beheert dat allemaal.

Aan jouw kant draait een monitoring-agent op je eigen workers: 2 replica’s die samen 220m CPU en 532 MiB geheugen aanvragen (zie Workercapaciteit). Het bedrag betaalt ons backend en onze opslag, niet jouw compute.

Wat kubehz verzamelt. Cluster- en node-gezondheid, en het resourcegebruik van control plane en workloads (de standaard Kubernetes-/cAdvisor-/kube-state-signalen). Je krijgt CPU-, geheugen-, pod- en node-metrics door de tijd zonder eigen Prometheus.

Waar je het ziet. De metrics verschijnen in de sectie Monitoring op de clusterpagina in het kubehz-dashboard.

Alerting. Dezelfde sectie bevat ook je alertregels en receivers:

Een regelgroep is een Prometheus-regelbestand voor metrics of logs (PUT /api/clusters/{id}/monitoring/rules/{name} met de YAML in data).
Een receiver is een webhook-URL of een email-adres (PUT .../monitoring/receivers/{name}).

Abonneer je eigen account op de alertmails van het cluster met de schakelaar op dezelfde pagina, of met POST /api/clusters/{id}/alerts/subscription.

Logging

Wat het inschakelt. Logaggregatie per cluster, op basis van Loki, via dezelfde platformstack. Het kost € 0,008/uur, hooguit € 5,84/maand excl. btw, en het vereist de vorm met drie API-servers.

Net als monitoring schakel je het in via het kubehz-dashboard: in de add-on-opties van de wizard als je het cluster aanmaakt, of later onder Instellingen → Vorm van het cluster. Een collector in promtail-stijl draait in je cluster en stuurt pod-logs naar de Loki van het platform. Loki draai je niet zelf.

Wat de kosten dekken. De platformzijdige ingest, de 7 dagen logopslag en het querypad achter de logbrowser van het dashboard. kubehz draait en beheert dat allemaal.

De collector op je nodes is van jou: op elke workernode vraagt hij 60m CPU en 74 MiB geheugen aan. Het bedrag betaalt ons backend en onze opslag.

Bewaring. De add-on bevat 7 dagen logbewaring: je kunt de logs van de laatste week opvragen, oudere data verloopt.

Waar je het ziet. Logs verschijnen in het kubehz-dashboard naast monitoring. De uitrol van de logbrowser in het dashboard loopt nog. Vandaag geeft de add-on je het verzamelen en de 7-dagen-bewaring.

Logging is ook de natuurlijke metgezel van Auditlogging: het geeft je een plek om de auditevents te lezen.

Toegewijde nodes

Wat het inschakelt. Plaatst je control plane op toegewijd bare metal in de kubehz-vloot in plaats van op gedeelde cloud-VM’s. Het control plane krijgt stabielere, geïsoleerde prestaties.

Het kost € 0,018/uur, hooguit € 13,14/maand excl. btw, en het vereist de vorm met drie API-servers. De operator verplaatst je control plane naar metal-class-nodes (een plaatsingswijziging, geen resize).

Live-migratie bij omschakelen. Toegewijd is omkeerbaar. Als je het aanzet (of uitzet), start de operator een live-migratie van het control plane naar de metal-pool (of eraf). De operator verplaatst de workload: je bouwt het cluster niet opnieuw.

Capaciteitsgating (het eerlijke deel). Bare metal is een schaarse pool, en we beperken die bewust. Daarom is toegewijd capaciteitsgated bij provisioning. Staat de metal-pool op zijn ondergrens, dan kun je de optie misschien een tijdje niet bestellen, zelfs op een cluster met drie API-servers.

Dat is bewust: we voegen metal toe als de vraag het rechtvaardigt. De optie vereist de vorm met drie API-servers, zodat wegwerp-clusters de schaarse capaciteit niet opsouperen. Is de optie bij je poging niet beschikbaar, dan gaat ze weer open zodra we capaciteit toevoegen.

Workercapaciteit

Sommige add-ons draaien pods op je gehoste workers, en die pods vragen CPU en geheugen aan. Voordat kubehz zo’n add-on inschakelt, controleert het of de worker pools de systeempods plus alle gekozen add-ons kunnen dragen. De controle telt deze requests:

Op je workers	CPU	Geheugen	Geteld
Systeempods op elke node	175m	114 MiB	per workernode
Systeempods voor het cluster	320m	484 MiB	eenmaal per cluster
Monitoring (2 agent-replica’s)	220m	532 MiB	eenmaal per cluster
Logging (collector)	60m	74 MiB	per workernode
OPA / Gatekeeper	200m	1024 MiB	eenmaal per cluster
cert-manager (app-catalogus)	60m	160 MiB	eenmaal per cluster

Het cluster-webdashboard, auditlogging, etcd-back-ups en toegewijde nodes draaien naast het control plane. Op je workers hebben ze niets nodig.

De regel. De pools moeten minstens 1,5 keer de som van deze requests bieden, voor CPU en voor geheugen. De 50% marge dekt gebruik boven de requests, de extra pod tijdens een rolling update en de fout in de schatting.

kubehz schat wat één node biedt uit zijn servertype: vCPU’s × 1000m min 400m CPU, en 93% van zijn geheugen min 500 MiB. Een pool met autoscaling telt met zijn minimale aantal nodes.

Voorbeeld. Eén worker met 2 vCPU’s en 4 GB (cpx22 of cax11) biedt 1600m CPU en 3309 MiB. De systeempods plus monitoring hebben (175 + 320 + 220) × 1,5 = 1073m CPU en (114 + 484 + 532) × 1,5 = 1695 MiB nodig. Eén zo’n worker is genoeg.

Wanneer kubehz controleert. Als je een cluster met workers en add-ons aanmaakt, een add-on toevoegt, een catalogus-app installeert of een cluster zonder workers zijn eerste workers geeft. Op een cluster dat al workers heeft, weigert deze controle nooit een poolwijziging (afschalen, nieuw type, verwijderen).

Statische pools beoordeelt kubehz niet (hun grootte is onbekend). Als de Hetzner-catalogus niet beschikbaar is, laat kubehz de wijziging ook door.

Als het niet past. kubehz weigert de wijziging met ADDON_NEEDS_CAPACITY. De helptekst noemt wat de add-ons en de systeempods nodig hebben, wat de pools bieden en een voorbeeldpool die genoeg is (bijvoorbeeld 2 × cax11).

Kies een groter servertype, voeg workers toe of verwijder een add-on. Elke gehoste worker heeft daarnaast minstens 2 vCPU’s nodig: zie Servertypes.

Volgende stappen

Prijzen: de volledige add-on-prijslijst.
Gehoste control plane: de vorm en het gehoste pad in het geheel.
Worker pools: pools, scaling en autoscaling op je cluster.
Dashboard en account: waar je add-ons omschakelt en de kubeconfig downloadt.

Documentstatus

Aspect	Detail
Staat	add-ons live, met snapshots, herstel, auditaflevering en alerting als selfservice. Logbrowser in het dashboard: uitrol loopt
Laatst herzien	2026-10-30

Add-ons ​

Cluster-webdashboard (Headlamp) ​

OPA / Gatekeeper ​

etcd-back-ups ​

Auditlogging ​

Monitoring ​

Logging ​

Toegewijde nodes ​

Workercapaciteit ​

Volgende stappen ​

Documentstatus ​