Kubernetes
A managed Kubernetes cluster: you choose how many control-plane machines and how many workers, and you get a kubeconfig. The control-plane machines are not yours to babysit — they do not appear in your server list.
What runs underneath
Section titled “What runs underneath”| Layer | Technology |
|---|---|
| Node operating system | Talos Linux — immutable, API-driven, no shell and no SSH |
| Kubernetes | Upstream, at the version tied to the Talos release |
| Machine configuration | Talos machine configuration, delivered as a cidata ISO attached to the VM |
| Networking | Nodes live in one subnet of your private network |
| In-browser access | A short-lived kubectl pod inside your own cluster, streamed to the panel |
Talos was chosen for the same reason appliances are locked: a node with no shell has nothing to log into and cannot drift. Upgrades are image swaps, not package upgrades.
Your cluster does not talk to the zone9 API. It has no agent, no webhook and no dependency on the panel. If the panel disappears, your cluster does not notice.
The model you see
Section titled “The model you see”| You choose | The platform manages |
|---|---|
| Number of control-plane machines: 1 or 3 | The control-plane machines themselves |
| Worker count and plans | etcd, certificates, bootstrap |
| Which private network and subnet | Talos configuration and its delivery |
| Kubernetes version, at creation | Node identity and joining |
Workers appear in your server list — you can attach firewalls and public addresses to them, which is what makes a self-managed ingress possible. Control plane machines do not.
One control-plane machine is fine for development. Three gives you etcd quorum and survives losing one. Anything else is refused.
Creating one
Section titled “Creating one”Kubernetes → Küme Oluştur (Kubernetes → Create cluster).
Preconditions
Section titled “Preconditions”| Requirement | Why |
|---|---|
| A subnet with a gateway attached | Nodes must pull container images. This is the single most common cause of a cluster that builds but never becomes ready |
| Enough capacity for control plane and workers | Each is a virtual machine |
Creation takes several minutes: machines are cloned, Talos configuration is generated and
attached, etcd is bootstrapped, and then the panel waits for the nodes to report
Ready to Kubernetes itself before declaring the cluster healthy.
That last step matters. An earlier version marked everything green once the infrastructure steps completed — and a cluster was observed where etcd bootstrapped and a kubeconfig was produced, both of which succeed without a working kubelet, while no node ever came up. The panel showed green and the cluster did not work. Now readiness is measured, and a cluster that is not ready says so along with the reason.
Getting your kubeconfig
Section titled “Getting your kubeconfig”Kubeconfig on the cluster page. It is shown once.
The panel does not hold a certificate authority for your cluster, so it cannot mint short-lived per-user credentials. The file it hands you comes from the cluster itself and carries administrative rights. Rather than store a cluster-admin secret indefinitely, the panel deletes it after showing it to you. If you lose it, retrieve it from the cluster — the machines are yours.
The browser console
Section titled “The browser console”kubectl konsolu (kubectl console) runs kubectl in a short-lived pod inside your
own cluster and streams it to your browser. Nothing is proxied through the panel’s own
credentials, and no long-lived token is created outside the cluster.
Because it is your cluster, you can switch it off: delete the role binding the console uses and the console stops working while your kubeconfig keeps working.
Status and re-verification
Section titled “Status and re-verification”A cluster’s health is measured, not assumed. Because the measurement was historically only taken at the end of the creation job, a cluster whose blocking problem you fixed afterwards could keep showing the old verdict.
Now: opening the cluster page queues a fresh measurement when the status is unsettled, and Yeniden doğrula (Re-verify) asks for one immediately. The measurement creates nothing and repairs nothing — it only looks.
Getting traffic into the cluster
Section titled “Getting traffic into the cluster”The cluster is on a private network. Two supported routes:
Load balancer (recommended). Create a load balancer with a
listener whose target is the cluster and whose port is your ingress controller’s NodePort.
Choose https and a hostname to have TLS terminate at the load balancer,
and your ingress controller never handles certificates. Or choose tcp and pass traffic
through untouched if you prefer cert-manager inside the cluster.
Public address on a worker. Attach an address and a firewall to a specific worker. It works and it is simple, but that worker becomes a single point of failure and its address is tied to a machine.
Walk-through: Expose a cluster to the internet.
Deleting
Section titled “Deleting”Deleting a cluster removes its machines. There is no deletion buffer: when you confirm that a Kubernetes cluster should go, its etcd data is already gone in every sense that matters, and keeping the machines alive would only generate cost.
Limits
Section titled “Limits”- One or three control-plane machines; no other count.
- No cluster autoscaling.
- No managed ingress controller, no managed storage class — install what you prefer.
- A Kubernetes cloud controller manager (so that
Service type=LoadBalancerprovisions a zone9 load balancer automatically) is planned, not shipped. Today you create the load balancer in the panel and point it at a NodePort. - Kubernetes version upgrades are not yet a panel operation.