Skip to content
Edka infrastructure automation platform Edka infrastructure automation platform Edka
SYS.DOCS // DOCS

Kubernetes Add-ons Management

Add-ons are the operators, controllers, and storage classes your cluster runs on. Most are installed automatically: when you deploy an app, provision a database, enable a gateway, or turn on another platform feature, Edka installs the add-ons it depends on for you. You rarely need to install them by hand.

You can still browse, install, and manage every add-on directly from Cluster Settings → Add-ons, and some are also managed from workflow-specific surfaces such as Gateway, Databases, GitOps, or Registry.

So the catalog covers both:

  • supporting add-ons that Edka installs automatically when a higher-level workflow needs them (the common case)
  • add-ons you install directly when the add-on itself is the feature you want

This page tracks the add-ons currently supported in the platform and explains where each one fits.

Networking add-ons

Section titled “Networking add-ons”
  • Envoy Gateway: managed Gateway API controller for public and private Gateway classes
  • NGINX Ingress: deprecated ingress controller. Migrate to Gateway API with Envoy Gateway
  • Tailscale Operator: private tailnet exposure for workloads and Gateway classes
  • MetalLB: private VIP allocation on the cluster private subnet
  • Cloudflare Connector: Cloudflare Zero Trust routing for the cluster private subnet

Security and certificate add-ons

Section titled “Security and certificate add-ons”
  • cert-manager: certificate lifecycle automation
  • Let’s Encrypt ClusterIssuer: preconfigured issuer used by Edka TLS flows that depend on public Let’s Encrypt issuance
  • Edka DNS-01 Webhook: cert-manager DNS-01 webhook used for wildcard and hostname certificates validated through DNS
  • External Secrets: sync secrets from external providers into Kubernetes
  • Reflector: replicate selected secrets into additional namespaces when higher-level Edka flows need that wiring

Database and data-service add-ons

Section titled “Database and data-service add-ons”

GitOps and delivery add-ons

Section titled “GitOps and delivery add-ons”

Operations, observability, and registry add-ons

Section titled “Operations, observability, and registry add-ons”
  • Metrics Server: pod and node resource metrics for autoscaling and runtime visibility
  • Node Exporter: required monitoring add-on that exports host filesystem, inode, CPU, memory, and network metrics for node dashboards and infrastructure alert packs
  • Local Path Storage Class: Rancher local-path dynamic storage class for node-local persistent volumes
  • Longhorn: distributed block storage operator providing replicated and RWX (ReadWriteMany) persistent volumes
  • Edka Agent: in-cluster agent for inventory, control plane snapshots, and automatic image updates
  • Zot Registry: in-cluster container registry that Edka manages from the Registry surface

How Edka manages them

Section titled “How Edka manages them”

Installed directly

Section titled “Installed directly”

These are commonly installed because they are the primary feature:

  • Envoy Gateway
  • Tailscale Operator
  • MetalLB
  • Cloudflare Connector
  • cert-manager
  • External Secrets
  • CloudNative PG
  • MOCO
  • ClickHouse Operator
  • Flux Operator
  • Zot Registry
  • Local Path Storage Class

Installed as dependencies or supporting components

Section titled “Installed as dependencies or supporting components”

These are often installed automatically when Edka needs them for a workflow:

  • Let’s Encrypt ClusterIssuer
  • Edka DNS-01 Webhook
  • Reflector
  • Barman Cloud CNPG Plugin
  • Edka Agent
  • GitHub Actions Runner Controller
  • Node Exporter

Some supporting components are required or effectively system-managed once the cluster depends on them. Edka may block uninstall while workloads, GitOps, domains, secret stores, backups, or inventory features still depend on the add-on.

Required add-on versions

Section titled “Required add-on versions”

cert-manager, Edka Agent, Metrics Server, and Node Exporter run on every cluster. When Edka supports a newer version of one of them, it upgrades the add-on on each connected cluster, usually within 10 minutes. An add-on that already runs a newer version keeps it.

If an upgrade fails, the add-on shows as failed on the cluster’s Add-ons page and keeps its previous version. Select Update to run the upgrade again.

A storage add-on can’t be uninstalled while a persistent volume claim uses one of its storage classes, including claims created with kubectl, Helm or GitOps:

  • Local Path Storage Class. Without the provisioner, new claims on local-path stay Pending, and deleting a claim leaves its data on the node.
  • Longhorn. Uninstalling removes Longhorn and the volumes it manages, so the claims lose their data.

The add-on card lists the claims as dependents. Delete them, or the workloads that own them, first.

A database operator stays installed while its databases exist: CloudNative PG for PostgreSQL, MOCO for MySQL and ClickHouse Operator for ClickHouse. Remove the databases first.

Workflow-specific entry points

Section titled “Workflow-specific entry points”
  • Gateway manages Envoy Gateway, Tailscale Operator, MetalLB, and Cloudflare Connector in context.
  • Registry manages the in-cluster Zot registry.
  • Databases queues CloudNative PG, Barman Cloud CNPG Plugin, MOCO, and ClickHouse Operator when PostgreSQL, MySQL, or ClickHouse runtimes need them.
  • Domains relies on cert-manager, the Edka DNS-01 Webhook, and Reflector for DNS-01 certificates and legacy ingress namespace wiring.
  • GitOps relies on Flux Operator while enabled.
  • Secrets installs External Secrets with the first store, and keeps it while stores or synced secrets exist.
  • Actions manages GitHub Actions Runner Controller and ARC runner scale sets from the cluster Actions view.
  • Observability installs Node Exporter when node metrics are enabled and uses those host metrics for node dashboards and infrastructure alert packs.
Section titled “Related docs”