A Nairotech product · yeke.io
Planned. Approved. Recorded.
Manage your Kubernetes clusters from one console. Every change you start in the UI or by asking the AI becomes a plan first, is applied with your approval and gets recorded.
Why YEKE?
An interactive walkthrough for leaders and teams: watch a change move through its approval gates and see how Community and Enterprise differ.
Open the walkthroughIn Turkish, yeke is the tiller: the lever used to turn a boat’s rudder. YEKE helps you manage your clusters while you choose the direction.
AI assistance
Work with AI. Stay in control.
Ask about your cluster or request a change. AI works within your permissions, and its proposed operations wait for your approval.
- Works within your permissions. AI cannot access Kubernetes resources you cannot access.
- See what is shared. Track data sent to AI. Secret values are never sent to the model.
- Choose your provider. Use your own provider or a local model with Ollama. Set AI access per cluster.
Change management
Review the plan before you apply.
Whether you create the operation or AI proposes it, the change is checked, presented for approval and recorded.
- plan Review the proposed change.
- dry-run Validate without applying.
- guardrail Check the plan against safety rules.
- approval Approve the plan you reviewed.
- apply The result is recorded in the apiserver's own words.
If you use hooks, your system is checked when the plan is created and again at approval.
- Preview the change. If replicas will increase from 3 to 5, review the diff and dry-run result on one card.
- Check risky operations. Built-in policies evaluate actions such as deletion and permission changes. Risky plans require extra approval.
- Approve the plan you reviewed. Review again if the plan changes. Supported reverts follow the same approval flow.
- Connect your approval process. Use hooks to check conditions such as an open change record or maintenance window. These validation hooks are in Enterprise; notification hooks work in every edition.
- See the decision and reason. Your system can block an operation or require extra approval. The reason appears on the card.
- Handle connection failures. Plans stop by default if a hook does not respond. You can configure warning-only behavior instead.
- Find who did what. Filter operations by user, resource or plan.
- Track AI activity too. See what it read, what it sent out and which plan was applied.
- Review the history. Find who changed a replica count in the operation records.
Monitoring · Scan · KubeWorld
Monitoring is built in. Nothing extra to install.
The YEKE agent collects metrics straight from the kubelet with read-only access. You don't need to install Prometheus, Grafana, node-exporter or metrics-server.
All three are free in the Community edition, with no license key.Alerts, scheduled scans and 90-day history are in Enterprise.
- Monitoring. CPU, memory, disk and network for nodes, workloads and storage, with 30 days of history.
- Scan. The “Run scan” button checks the cluster’s health in one pass and reports each finding with its evidence, and with a suggested fix where one applies. It runs on your own AI provider.
- KubeWorld. A live digital twin of your cluster: namespaces are districts, workloads are buildings, pods are windows. Look at the city and you see where the trouble is.
Workload status
See the problem in the status view.
See Pod status alongside the error and its duration, including failures such as CrashLoopBackOff.
Rancher · Lens · Yeke
Where does YEKE fit?
YEKE brings multi-cluster management together with AI assistance and human-approved changes.
| Capability | Rancher | Lens | Yeke |
|---|---|---|---|
| Visual multi-cluster management | ✓web UI | ✓desktop IDE | ✓web UI |
| Monitoring inside the product | —a separately installed Prometheus + Grafana stack | partlybuilt-in Lens Metrics installs a Prometheus stack into the cluster | ✓node · pod · workload history; in agent mode neither Prometheus nor metrics-server is required |
| The product names the root cause | ✓Liz, with the SUSE Observability agent | partlypaid Ask AI, through an external AI tool you pick | ✓“Diagnose” opens with context, “Scan” produces an evidence-backed root-cause report |
| Footprint installed into the cluster | cluster agent, fleet-agent, webhook≈597 MiB in the same measurement; plus a Prometheus stack if monitoring is wanted (≈953 MiB by default) | —a desktop app; basic use installs nothing into the cluster, optional features such as metrics do | one agent≈100 MiB, under 1 mCPU; monitoring included, measured on the same cluster (see the note) |
| Plain-language management | ✓the Liz extension (Rancher Manager 2.13+) | partlypaid Ask AI launches an external AI tool with the cluster context | ✓with the context of the screen you are on |
| Every AI-proposed change goes through approval | ✓Liz asks you to “Confirm” before changes | partlythe chosen AI tool asks, not Lens | ✓dry-run and policy first, then the approval card. A validation Hook, a second approval and a maintenance window when required (Enterprise). The approval is tied to the audit trail |
| Your own Hook can stop the plan at approval time | —an admin picks which Liz tools need confirmation; no Hook that asks an outside system is documented | — | ✓Enterprise (validation Hook); fail-closed by default: if the Hook cannot run, the plan stops |
| What left the cluster, message by message | —the categories of shared data are documented | — | ✓an egress card every turn: how many bytes each part sent, which paths were redacted |
| No second role system on top of Kubernetes RBAC | its own role hierarchyglobal permissions, cluster and project roles; translated into Kubernetes RBAC objects, enforced by Kubernetes | ✓the kubeconfig's permissions; impersonation in paid Cluster Connect | ✓requests go with the person's own Kubernetes identity (impersonation); in agent mode the credential stays in the cluster |
| Installing asks for no account, e-mail or key | ✓the software is open and free | —activation with a Lens ID on first launch | ✓the license is verified offline too |
| Turkish interface | — | — | ✓TR / EN, one click |
The Rancher and Lens cells are written from the vendors' own documentation and were re-checked on 01.10.2026; Rancher's AI rows rest on the documentation for Liz (Rancher AI Assistant). Capabilities may differ in newer releases. The numbers in the footprint row are our own measurements: the three products were installed together on the same empty two-node test cluster; the YEKE 0.63.0 agent (monitoring included) used ≈100 MiB, the components Rancher v2.15.2 installs on import ≈597 MiB, and a default kube-prometheus-stack ≈953 MiB of memory (1 Oct 2026; 15-minute warm-up, 40-minute measurement, medians). Only usage inside the cluster is counted; the Rancher server and YEKE core run outside it. We put no megabytes in the Lens column: we do not publish a figure we have not measured ourselves. Rancher, Lens and YEKE focus on different needs.
The interface
Light or dark. Your choice.
Work in the theme you prefer. YEKE follows your system’s appearance setting.
yeke.io
Try YEKE in your own environment.
Connect your cluster and try your everyday workflows with YEKE. Let’s review what your team needs.