A Nairotech product · yeke.io
Say it.
See the plan.
Approve it.
Yeke manages your Kubernetes clusters through a full visual console and plain language. The model runs under your own Kubernetes identity; every change it proposes goes through the same approval chain as a change you make by hand.
Kubernetes takes its name from the Greek κυβερνήτης: helmsman. Its logo is a seven-spoke ship's wheel. In Turkish, yeke is the tiller — the lever that turns the rudder. That is where our name comes from. The helm stays in your hands; Yeke only carries your word to the rudder.
The AI layer
The AI sits inside the approval chain.
In most tools the AI is a chat window bolted onto the side of the console. In Yeke the model speaks with your Kubernetes identity, every step it takes is written to the audit trail, and every byte that leaves shows up on screen.
- The model acts as you. Who it acts for is verified at the apiserver; it cannot do anything you could not do yourself. "You are acting as [email protected] [yeke-operators] on this cluster."
- What left, message by message. Body size, destination host and how many paths were
redacted sit under every answer;
Secretvalues never reach the model at all. What left core: 127.0.0.1 · 11.6 KiB · 0 paths redacted - What the model reads is in the open too. Every
k8s_list/k8s_getit calls stays in the chat as a chip; one click opens that list on screen. - Egress is set per cluster.
off · local-only · allowed— a high-sensitivity cluster can keep AI switched off entirely, while a dev cluster can turn it on against a local Ollama.
The operation path and guardrails
There is one way to apply.
plan → guardrail → dry-run → approval → apply — the order is the
same for everyone. The operation you build by hand and the operation the model proposes both
take this path; there is no side door for the AI.
- The plan shows the diff. What will change — field by field, before and after:
spec.replicas 3 → 5. The dry-run runs at the apiserver and its result is written on the card. - 11 built-in CEL policies classify every request:
namespace-delete,system-namespace,rbac-binding-write,scale-to-zero,irreversible-storage… On the approval card, a destructive step cannot be approved until you type the target's name yourself. - Approval goes to the content, not to the button. Every refresh produces a new plan summary, and an apply request carrying the old one is rejected. The plan's identity is frozen the moment it is built: the same person must create it, approve it and apply it.
- Reverting is a plan too and goes through the same approval card. The result
is recorded in the apiserver's own words:
applied · HTTP 200 · rv 122835.
applied · HTTP 200 · rv 122835 —
the apiserver's answer, with "Revert" one key away.- Every record carries two identities. Both the YEKE user and the Kubernetes identity in the cluster: who asked for it, and who the apiserver saw.
- The AI leaves a trail too.
ai.turn_started,ai.read,ai.egress,plan.created,plan.dry_run— what the model read, what it sent out, how the plan was born: all of it in a read-only trail. - It is ready for the hard question. "Who changed this replica count, when, and under which plan?" is one click away: filter by target, by actor, by plan.
revertible badge and the AI layer's own event stream. Everything leaves a trail.The status column
We don't paint 0/3 green.
If 0 of 3 replicas are up, the row is red and the reason sits right next to it:
CrashLoopBackOff, and for how many hours. The status families (ready / partial /
failing) are painted with measured contrast; both themes read just as clearly.
Rancher · Lens · Yeke
The others, and us.
Rancher set the bar for multi-cluster management, Lens for developer experience; we learned plenty from both. Where Yeke parts ways is that the AI is built inside the approval chain.
| Capability | Rancher | Lens | Yeke |
|---|---|---|---|
| Full visual multi-cluster management | ✓the industry standard | ✓desktop IDE | ✓web, ~390 kB gzip |
| Plain-language management — built in, not an add-on | — | —separate AI assistant | ✓with the context of the screen you are on |
| AI changes go through human approval | — | — | ✓plan → guardrail → dry-run → approval |
| Per-message egress transparency and Secret redaction | — | — | ✓"what left core: 11.6 KiB · 0 paths" |
| Operation safety: mandatory dry-run + typed approval + frozen plan identity | partlywith external policy tools | — | ✓11 built-in CEL policies |
| Identity: impersonation verified at the apiserver + a declared authority ceiling | its own RBAC layer | whatever the kubeconfig says | ✓"who am I acting as?" is asked of the apiserver |
| Where the credential sits is known | — | — | ✓in agent mode the credential never reaches the central service |
| Turkish interface | — | — | ✓TR / EN, one click |
The comparison covers built-in capabilities as they appear in each product's public documentation (August 2026). Rancher and Lens are excellent tools in their own fields; the table only shows where the built-in capabilities part ways.
Harvester · VMware vSphere
From a bare hypervisor to a cluster ready for production.
Yeke does not only manage clusters that already exist; it connects to the Harvester and VMware vSphere APIs and brings up VMs, installs an HA control plane, adds and removes nodes. The same AI reads the provisioning output: a diagnosis and a fix arrive through the same approval chain.
Connect the hypervisor
A Harvester or vSphere API address plus credentials. Yeke discovers the resource pool, the networks and the storage.
Plan the topology
"3 control-plane + 5 workers, HA" — the plan card shows VM sizes, the IP plan and the cost; the approval is yours.
Watch it build
VMs come up, Kubernetes is installed; every step streams a live log. If a step fails, the diagnosis and a suggestion land in the chat.
Hand it to inventory
The cluster is on the inventory, the agent is installed, identity mapping is ready — it is handed over ready for production.
› provision the production-dc cluster: 3 control-plane + 5 workers, on vSphere/dc-1 plan op-01M4… built · 8 VMs · 24 vCPU · 96 GiB · dry-run: the resource pool has room ✓ approved — [email protected] · 2026-08-03 14:12 ✓ vm/cp-1 cp-2 cp-3 ready · 94 s ✓ control-plane HA up · etcd healthy · 3/3 ! vm/worker-4: disk attach timed out yeke: datastore-2 looks read-only; a fix plan that moves worker-4 to datastore-1 is ready — [open the approval card] ✓ production-dc recorded on the inventory · kubeconfig handed over · agent connected
The interface
Built for the night shift too.
Every colour role (text, border, status, accent) goes through its own contrast measurement on light and on dark: the word "ready" still reads on white, and the alarm red does not shout at 3 a.m. The theme follows your system setting.
yeke.io
Introduce your clusters to Yeke.
Let's start a pilot with a setup that takes under an hour: your cluster, your RBAC, your provider key. On day one you will already be asking more than "how many pods are there?".