What I hardened before Aether's first release
Aether is close to its first release. Here are the three decisions behind it: immutable Talos Linux nodes, Harbor proxy caching so image pulls survive registry outages, and CAPI autoscaling that takes a Pending pod to a Ready node in ~80 seconds.
What's landing in the first Aether release: Talos, Harbor proxy caching, and CAPI autoscaling
Aether — the managed Kubernetes platform I have been building on Talos Linux — is close to its first release. Before it goes out, I want to write down the three decisions that shaped this milestone: an immutable node OS, Harbor proxy caching so image pulls never depend on an upstream registry staying up, and Cluster Autoscaler running in CAPI mode so scaling keeps working when scheduling constraints get ugly.
None of these are features in the marketing sense. They are the boring parts that decide whether the platform stays up at 3 AM. That is exactly why they came first.
Why every Aether node runs Talos Linux and Cilium
I rejected the mutable, patch-heavy OS model on day one. Every Aether node runs Talos Linux: read-only, no shell, no SSH, managed entirely through an mTLS API. There is nothing to log into, so there is nothing to drift. A node in staging and a node in production are byte-for-byte the same thing.
Networking is Cilium, handling L2/L4 and native Gateway API routing. I wrote about the isolation model in detail in why Aether runs seven isolation layers for every tenant cluster; the short version is that the node OS and the CNI are the two layers everything else leans on, and I wanted both of them deterministic before building anything on top.
Harbor proxy caching: Kubernetes image pulls without upstream registries
Every platform I have operated has eventually been taken down, or at least slowed down, by someone else's registry. Docker Hub rate limits, a Quay outage, registry.k8s.io having a bad day. The failure is always the same shape: your cluster is healthy, your manifests are correct, and your pods sit in ImagePullBackOff because a server you do not control said no.
In this release, Harbor proxy-cache projects are a native part of the platform. The critical platform and tenant images — CoreDNS, CNI, CSI, metrics-server — pull through local Harbor proxy caches, and Talos worker bootstrap configs point directly at the Aether proxy instead of the upstream registries. After the first pull, the upstream can disappear and the platform keeps provisioning.
The cost is storage and cache hygiene. Proxy caches are one more stateful thing to back up and monitor, and a stale cache can mask an upstream image update if you are careless with tags. I am paying that cost, because the alternative is an external single point of failure sitting in the middle of every node bootstrap.
Cluster Autoscaler in CAPI mode: scaling that survives pod anti-affinity
Kubernetes autoscaling in multi-tenant clusters breaks in a predictable place: the moment complex constraints enter the picture. Strict pod anti-affinity is the classic one. The autoscaler simulates, decides no node would help, and your workload sits in Pending while you pay for a cluster that refuses to grow.
Aether runs Cluster Autoscaler in CAPI mode on the management plane, driven by per-pool CPU and memory budgets, reconciled by the custom controllers I wrote for Aether's control plane. When a pod goes Pending, the scaling loop takes about 80 seconds to go from detection to a fully joined, Ready Talos worker. That is not instant, and I am not going to pretend it is — it includes cloning the VM, booting Talos, and completing the TLS handshake against the cluster's own CA. For a whole new node, under a minute and a half is a number I am comfortable putting in writing.
Node pools carry custom labels and taints configured from the portal, so tenants can steer workloads onto the right pools without touching the management plane. The budgets are the guardrail: a runaway workload can scale a pool to its limit and no further, which keeps one tenant's bad day from becoming everyone's bill.
What this means in practice
The theme across all three is the same: remove the parts of the stack that depend on someone else behaving well. The node OS does not depend on nobody having SSH'd into it. Image pulls do not depend on an upstream registry's rate limiter. Scaling does not depend on the scheduler's constraints staying simple.
There is still work between here and the release — mostly rollout mechanics, not architecture. Once it ships, the next posts will go deeper on the autoscaler tuning and the Harbor setup, because both took more iteration than a paragraph can carry.