Clusters and infrastructure

These commands manage the clusters of your organization and what each cluster runs on: its node pools, domains, registries and secrets. They find a resource by its name, within the linked cluster or the one --cluster names.

Prerequisites

• The Edka CLI, signed in with edka login.
• To create a cluster or a node pool: a Hetzner project connected to your organization.
• Write access, granted at sign-in, and a role in your organization that may change clusters.

Create a cluster

edka clusters create staging --wait --merge-kubeconfig --use

clusters create creates a cluster on Hetzner with the console’s defaults: deletion protection on, a daily etcd backup at a random time between 00:00 and 06:00 UTC, the K3s version Edka recommends, and one node pool named default. Edka creates the servers in your Hetzner project.

Flag	Sets	Default
--location	Hetzner location of the control plane and the default pool	fsn1
--master-type	Server type of the control plane	cx23
--ha	Three control plane servers instead of one	off
--node-type	Server type of the default node pool	cx23
--nodes	Servers in the default node pool	1
--k3s-version	K3s version	the one Edka recommends
--no-etcd-backup	Skip the daily etcd backup
--no-protect	Leave deletion protection off

--data and --field set request fields that have no flag, such as worker_node_pools or nat_gateway_enabled.

Before it creates anything, the command shows the estimated monthly price and asks for confirmation. --yes skips the question, and --dry-run prints the request and the price instead. With --wait, it prints the provisioning progress until the cluster is active, up to 30 minutes. --merge-kubeconfig then adds the cluster to your kubeconfig, and --use switches kubectl to it.

Inspect, protect and delete clusters

edka clusters list
edka clusters get production             # Summary, control plane and node pools
edka clusters protect production
edka clusters unprotect staging
edka clusters delete staging

delete deletes a cluster with its servers, volumes and data. It asks you to type the cluster’s name, and refuses a protected cluster until you run unprotect. To remove a disconnected or satellite cluster from Edka and leave its servers alone, use the API command:

edka api clusters delete staging --field remove_from_edka_only:=true

Use kubectl

Edka issues your own kubeconfig for a cluster once. clusters kubeconfig downloads it into the kubeconfig kubectl uses, or into a new file:

edka clusters kubeconfig production --merge --use
edka clusters kubeconfig production --output-file ~/.kube/production.yaml

--merge adds the cluster, context and user as edka-<organization>-<cluster>, replaces what an earlier merge wrote for the same cluster, and keeps the rest of the file. It writes to the first file in KUBECONFIG that exists, or to ~/.kube/config, and keeps the previous version with an .edka-backup suffix. --use makes the new context kubectl’s current one. --output-file writes a new file that only you can read.

Since Edka issues the kubeconfig once, the command checks the destination before it downloads. If the merge still fails, it saves the kubeconfig to a new private file next to the target. To get a new kubeconfig, --rotate revokes the previous one and issues another, after you confirm:

edka clusters kubeconfig production --rotate --merge

For a single command, edka run --kubeconfig sets KUBECONFIG to a kubeconfig that expires after an hour, and deletes it when the command exits. It leaves the one-time download available:

edka run --cluster production --kubeconfig -- kubectl get pods -A

Node pools

edka nodepools list                      # Pools of the linked cluster, or of every cluster
edka nodepools get workers               # Servers, autoscaling, labels, taints, what is pinned to it
edka nodepools add workers --type cx33 --nodes 2 --wait
edka nodepools add burst --type cpx32 --min 0 --max 5
edka nodepools scale workers --nodes 4 --wait
edka nodepools delete workers

nodepools add adds a Hetzner Cloud node pool, in the cluster’s location unless --location names another. --nodes sets how many servers it has. --min and --max make it autoscale between them instead, for the life of the pool. --label key=value sets a node label, and --taint key=value:effect a taint with the effect NoSchedule, PreferNoSchedule or NoExecute.

nodepools scale sets the servers of a pool. For a smaller pool, Edka drains the servers it removes, then deletes them. --min and --max turn autoscaling on for a pool with a set number of servers. nodepools delete drains the servers, then deletes them. Edka refuses to delete a pool while a deployment, app, database or other resource is pinned to it, and the error names them.

add, scale and delete show the change and ask for confirmation, or take --yes. --dry-run prints the request instead. --wait prints the cluster’s events until the pool has its servers, up to 20 minutes.

Edka applies one node pool change to a cluster at a time. It refuses a change while another runs, and one based on pools that changed after the command read them. Change the node pools of a cluster with a metal pool in the console.

Domains

edka domains add '*.example.com' --apex  # A wildcard, with example.com on its certificate
edka domains get '*.example.com'         # The certificate and the DNS records to create
edka domains verify '*.example.com' --wait
edka domains add app.example.com         # A hostname, validated over HTTP
edka domains list
edka domains delete app.example.com

domains add adds a hostname or a wildcard to a cluster, on the traffic class --class names or on the cluster’s default one. Quote a wildcard so the shell leaves the * alone. Let’s Encrypt validates a wildcard over DNS. It validates a hostname over HTTP, which needs a public traffic class, or over DNS with --validation dns-01. --apex adds the hostname a wildcard is under to its certificate, such as example.com for *.example.com.

add and get print the DNS records the domain needs: the CNAME that validates its certificate over DNS, and an A, AAAA or CNAME record for each address of the traffic class. For a domain validated over DNS, create the records, then run verify. With --wait, it prints the DNS and certificate status until the certificate is ready. A hostname validated over HTTP needs no verify. Edka issues its certificate once the hostname reaches the cluster.

See Domains and TLS for traffic classes and certificates.

Registries

A registry is the credentials of a container registry, stored for your organization.

edka registries add ghcr --type github-registry --url ghcr.io --username octocat
edka registries apply ghcr               # Let the linked cluster pull from it
edka registries default ghcr             # The registry Git deployments use when they name none
edka registries list
edka registries remove ghcr              # Delete its pull secrets from the cluster
edka registries delete ghcr

registries add stores credentials for Docker Hub (docker-hub), GitHub (github-registry), Google Artifact Registry (google-artifact), Amazon ECR (aws-ecr), or any other registry (custom). It reads the password or token at a hidden prompt, or from stdin, never from an argument. --replace stores new credentials for an existing registry, and the clusters that use it get them.

registries apply creates the registry’s pull secret in every namespace of a cluster, and remove deletes those secrets. registries default sets the registry a Git deployment builds to and pulls from when it names none. --own sets the cluster’s own registry instead, and --none leaves the cluster without one. delete refuses a registry a cluster still uses, and names the clusters.

The registry that runs in a cluster has commands of its own:

edka registries images                   # Its address, storage and repositories
edka registries tags api
edka registries delete-tags api v1 v2

A registry deletes an image with every tag it has, so delete-tags refuses when a tag you didn’t name shares an image with one you named. --force deletes those tags too.

Kubernetes secrets

edka secrets manages the Kubernetes secrets Edka created in a cluster, which deployments, apps and cron jobs read. A secret lives in a namespace, default unless --namespace names another.

edka secrets list                        # Secrets and their keys
edka secrets set database PASSWORD --namespace shop
edka secrets set tls-ca --from-file ca.crt=./ca.crt
edka secrets get database --namespace shop
edka secrets unset database OLD_PASSWORD --namespace shop
edka secrets delete database --namespace shop

set creates the secret, or changes the keys it names and keeps the others. It reads each value at a hidden prompt, or one value from stdin, and --from-file KEY=path takes the content of a file. list and get show keys, never values. A pod that reads the secret as environment variables gets a new value when it restarts.

For the variables and secrets of a deployment, use edka env, described in Deploy from the terminal.