# I Run a Fleet of AI Agents Across Three Machines. Here's What Broke.

Kyle Jaejun Lee · KRAFTON · AI Engineer World's Fair 2026: Online Track

> Vận hành đội coding agent trên ba máy: hierarchy CEO→worker, state nằm trong file, reset thay compact, review gateway, năm failure và hướng đi Kubernetes.

Topics: Agents, Coding Agents, Workflow, Distributed Systems

Canonical: https://homus.dev/talks/i-run-a-fleet-of-ai-agents-across-three-machines-heres-what-broke

## 1. Đội agent chạy trên ba máy, mỗi ngày

Kyle mở đầu rất thẳng: anh là Kyle, mỗi ngày anh vận hành một đội (fleet) AI coding agent trải trên ba cái máy, và talk này là câu chuyện về những gì đã hỏng. Và thứ hỏng đầu tiên, như anh nói, là chính anh. Talk này không phải về một tool cụ thể nào, cũng không phải một platform của công ty. Đây là một bản báo cáo thực địa (field report) trung thực từ hệ thống cá nhân mà anh dùng như công cụ làm việc hằng ngày (daily driver): những thứ chạy ngon trên một máy thì vỡ ra sao khi scale lên nhiều máy, cần gì để giữ một setup như vậy sống, và mọi thứ đang hội tụ về đâu.

![Slide tiêu đề I run a fleet of AI agents across three machines. Here's what broke., Kyle Jaejun Lee](https://homus.dev/photos/4kYl2_mqmnQ-0000.jpg)

Slide mở đầu: "I run a fleet of AI agents across three machines. Here's what broke." Phía dưới ghi đây là online talk của AI Engineer World's Fair 2026, người nói là Kyle Jaejun Lee.

Đây là đội của anh: ba cái máy chạy mỗi ngày. Chiếc MacBook là nơi anh làm phần coding nặng và các project cá nhân, và nó sẽ ngủ (sleep), vì, nói cho cùng, nó là laptop. Sau đó là hai máy Linux, cả hai đều headless (không có màn hình, không ai ngồi trước) và luôn bật (always-on). Linux A nhận các task coding chạy dài (long-running). Linux B chạy các side project cá nhân sống ngắn (short-lived). Hai hệ điều hành, và một control plane duy nhất buộc tất cả lại với nhau.

![Sơ đồ The fleet: control plane ở trên, ba hộp MacBook, Linux A, Linux B ở dưới](https://homus.dev/photos/4kYl2_mqmnQ-0008.jpg)

"The fleet": một control plane ở trên cùng nối xuống ba máy. MacBook (macOS, có ngủ) làm heavy coding và personal projects; Linux A (headless, always-on) nhận long-running coding tasks; Linux B (headless, always-on) chạy short-lived personal side projects. Dòng nhãn dưới cùng tóm lại: 3 máy, 2 hệ điều hành, máy ngủ đặt cạnh máy luôn bật.

Anh nhấn mạnh để mọi người hiểu rõ: đây không phải một bản demo dựng lên cho talk này. Đây là thứ anh thật sự dùng cả ngày, mỗi ngày. Và đây là nó đang chạy thật, toàn bộ hệ thống trên một màn hình. Agent thật, việc thật. Với anh, đây là một ngày thứ Ba bình thường.

![The fleet, on screen: dashboard Overlord Gateway và một cửa sổ tmux liệt kê các session](https://homus.dev/photos/4kYl2_mqmnQ-0040.jpg)

"The fleet, on screen": bên trái là dashboard Overlord Gateway (trạng thái Online, 18 agent active, 4 idle, 0 blocked, các nhóm như Control Tower và Infrastructure); bên phải là một cửa sổ tmux liệt kê hàng loạt session và window, phần lớn đang chạy Claude Code, mỗi window gắn với một việc riêng.

## 2. Thứ hỏng đầu tiên không phải cái máy, mà là chính tôi

Kyle kéo câu chuyện về điểm xuất phát, vì trước khi bất kỳ cái máy nào hỏng, anh đã hỏng trước. Lúc mới bắt đầu, chỉ có anh và một cái terminal. Vài pane tmux, vài agent, rồi thêm vài cái nữa, và rất nhanh anh thấy mình ngồi trước bốn, năm, sáu context đang sống cùng một lúc.

![Slide The first thing that broke wasn't a machine. It was me.](https://homus.dev/photos/4kYl2_mqmnQ-0048.jpg)

"The first thing that broke wasn't a machine. It was me.": thứ đầu tiên hỏng không phải một cái máy, mà là chính người vận hành.

Và đây là điều không ai cảnh báo bạn. Đến thời điểm đó, anh không còn là người chạy agent nữa. Anh đã trở thành scheduler, người quyết định ai làm gì. Anh là memory, người phải giữ trong đầu từng agent đang làm gì. Và anh là reviewer, người kiểm tra tất cả mọi thứ. Một con người, ba vai trò, sáu context. Cách đó không scale được.

![Sơ đồ The overload: một hộp me với ba vai scheduler, memory, reviewer, mũi tên tới sáu ô ctx 01 đến ctx 06](https://homus.dev/photos/4kYl2_mqmnQ-0056.jpg)

"The overload": một hộp "me" gánh ba vai scheduler, memory và reviewer, mũi tên chỉ sang sáu ô context từ ctx 01 tới ctx 06. Nhãn dưới ghi: 1 human, 3 roles; 4 đến 6 live contexts.

Rồi anh chiếu cảnh thật: một màn hình chia thành nhiều pane, mỗi pane là một agent đang làm một việc khác, log lỗi chạy xen với báo cáo tiến độ. Đây là mớ hỗn độn đã đánh gục anh (the mess that broke me). Anh đơn giản là không thể giữ trong đầu sáu agent đang làm gì cùng một lúc. Sự chú ý (attention) của chính anh đã trở thành nút thắt cổ chai (bottleneck).

## 3. Insight: biến đống agent thành một tổ chức

Thế là anh tự hỏi một câu hơi lạ: làm thế nào một nhóm nhỏ vài vị điều hành (executive) lại vận hành được một công ty hàng nghìn người? Họ không giữ tất cả trong đầu. Họ tách context ra. Mỗi người chỉ bao giờ nhìn thấy phần (slice) của riêng mình.

![Slide The insight: a few execs run a company of thousands, mũi tên tới separate context, rồi tới hierarchy](https://homus.dev/photos/4kYl2_mqmnQ-0128.jpg)

"The insight": chuỗi ba bước. Vài executive điều hành một công ty hàng nghìn người, nhờ tách context (separate context), và cách tách đó chính là một hierarchy.

Đó là chìa khoá mở ra mọi thứ. Nếu các agent của anh không phải là một đống phẳng (flat pile) thì sao? Nếu chúng là một tổ chức thì sao? Và đó chính là thứ anh xây: một hierarchy gồm CEO, VP, manager và worker.

Kyle xin mọi người nghe kỹ chỗ này: đây là những loại thực thể (entity type) có thật trong hệ thống, không phải một phép ẩn dụ cho vui. Mỗi entity là một agent riêng, có context được giới hạn phạm vi (scoped context) của riêng nó và ranh giới phê duyệt (approval boundary) của riêng nó. Context chảy xuống: mỗi tầng chỉ nhận đúng phần nó cần. Kết quả chảy ngược lên, và anh chỉ review những gì lên tới tầng cao nhất. Thế là thay vì giữ sáu context trong đầu, anh chỉ còn giữ đúng một.

Hierarchy của Kyle: mỗi tầng là một agent riêng với scoped context và approval boundary riêng. Context đi xuống theo từng slice, kết quả đi lên, và người vận hành chỉ review những gì lên tới đỉnh.

## 4. State sống trong file, không bị nhốt trong một model

Vấn đề tiếp theo: state của một agent thật ra nằm ở đâu? Bình thường, nó nằm bên trong context window của model, và cái window đó sẽ đầy. Nên anh dời nó ra ngoài.

Mỗi entity có một workspace riêng trên đĩa. Context dùng chung mà ai cũng phải tuân theo nằm trong thư mục `shared`. State gắn với từng máy nằm dưới `machines`. Và bên trong mỗi workspace có ba thứ: mission (nhiệm vụ), status hiện tại, và một thư mục handoff, chứa sản phẩm công việc thật sự được chuyền tay cho bước sau. State sống trong file. Nó không bị nhốt bên trong một model nào.

Bố cục workspace theo lời Kyle mô tả (tên thư mục gốc chỉ để minh hoạ): context chung ở `shared`, state theo máy ở `machines`, và mỗi entity có mission, status và thư mục handoff của riêng nó.

## 5. Đừng compact, hãy reset

Kyle gọi đây là điều thực tế nhất anh học được trong cả năm. Khi context window đầy, cách xử lý có sẵn là compact: tóm tắt lịch sử lại để lấy chỗ. Anh đã thôi làm vậy. Compact chậm, anh không chọn được thứ gì được giữ lại, và bất cứ thứ gì nó vứt đi là mất luôn.

Nên thay vào đó, anh không compact, anh reset. Reset ở đây nghĩa là ngay bên trong Claude, anh xoá sạch context hoàn toàn, rồi agent chỉ việc đọc lại thư mục handoff và các file lịch sử mà chính nó đã viết cho mình, rồi tiếp tục đúng chỗ nó đã dừng. Context có thể bị xoá, thậm chí cái máy có thể crash, mà công việc vẫn còn, vì nó chưa bao giờ chỉ nằm trong model.

Compact so với reset. Compact nén lịch sử và người dùng không kiểm soát được phần bị bỏ. Reset xoá sạch context rồi cho agent đọc lại handoff và file lịch sử nó tự viết, nên không mất gì.

## 6. Review gateway: một inbox, một điểm kiểm soát

Nhưng vẫn còn một vấn đề: alignment (sự thống nhất về hướng đi). Kế hoạch chảy xuống theo hierarchy, nhưng chúng trôi lệch (drift), và anh chỉ phát hiện được bằng cách tự đi vào từng pane một. Nên anh xây một review gateway.

Bất kỳ tầng nào muốn hành động đều phải nộp plan của nó, rồi block lại. Nó chờ. Không gì chạy cho tới khi anh approve. Và ngay khoảnh khắc anh approve, một hook tự động bắn công việc đi. Một web inbox, một điểm kiểm soát. Anh không bao giờ phải đi vào các cửa sổ làm việc nữa.

![Một approval cycle: inbox Pending Reviews bên trái, trang review một plan bên phải với nút approve và reject](https://homus.dev/photos/4kYl2_mqmnQ-0344.jpg)

"One approval cycle": bên trái là Inbox với danh sách Pending Reviews (ví dụ R6: Durable Dispatch Queue + boot drain, R7: Registry↔Reality Reconcile Loop + cron, R1: Cross-machine Worker); bên phải là trang review một plan, có phần TL;DR viết cho tầng CEO, ô góp ý và hai nút approve (xanh) và reject (đỏ).

Anh cho xem một vòng đầy đủ: một plan đi vào, anh approve, công việc chạy tiếp. Đó là toàn bộ vòng lặp. Và nói thật, anh không tự tay xây cái gateway này. Một team infra bên trong chính đội agent đã xây nó. Agent xây những công cụ dùng để chạy agent. Anh nghĩ đó gần như là toàn bộ ý nghĩa của chuyện này.

Vòng review gateway: tầng nào muốn hành động thì nộp plan và đứng chờ; chỉ khi người vận hành approve thì một hook mới tự động chạy tiếp phần việc.

Trên một máy, tất cả những thứ này chạy rất đẹp. Và rồi nó không còn chạy nữa.

## 7. Một máy không còn đủ: failure 1 và failure 2

![Slide Then one machine wasn't enough.](https://homus.dev/photos/4kYl2_mqmnQ-0400.jpg)

"Then one machine wasn't enough.": phần thứ hai của talk bắt đầu, khi một máy không còn đủ.

Rồi một máy không còn đủ. Năm thứ đã hỏng.

### Failure 1: agent tự làm việc thay vì dispatch xuống

Các agent của anh cứ tự mình làm việc thay vì giao (dispatch) nó xuống cho một worker. Orchestrator đáng lẽ phải uỷ quyền (delegate). Thay vào đó, nó xắn tay áo lên và tự làm task. Sai. Nên anh ép nó: một CLI harness, cùng các skill gọi tới những CLI đó, để việc dispatch trở thành con đường duy nhất nó có thể đi.

![Failure 1: orchestrator layer tự làm việc, CLI harness ép dispatch xuống worker; help của lệnh overlord dispatch và các skill /overlord-ceo, /overlord-team-manager](https://homus.dev/photos/4kYl2_mqmnQ-0408.jpg)

"Failure 1: agents do the work instead of dispatching it". Bên trái: tầng orchestrator tự làm việc (ghi "does the work itself, wrong!"), và CLI harness ép nó dispatch xuống Worker. Bên phải: phần help của lệnh `overlord dispatch` (giao một task cho một team, tự tạo task, trace và báo cho manager; có tuỳ chọn priority low/normal/high/urgent) và hai skill `/overlord-ceo`, `/overlord-team-manager` dùng để gọi các CLI này.

Phần help trên slide cho thấy hình dạng của lệnh đó:

```
Usage: overlord dispatch [options]

Dispatch a task to a team (creates a task + trace, notifies manager)

Arguments:
team              Target team name
message-or-file   Task message or path to a .md file

Options:
--priority   Priority: low/normal/high/urgent (default: "normal")
--from      Sender name (default: "ceo")
-h, --help          display help for command
```

### Failure 2: pane quá nhỏ

Failure thứ hai, theo anh, gần như buồn cười. Khi anh cứ ném thêm task cho các manager, chúng cứ mở thêm ngày càng nhiều pane worker bên trong một cửa sổ duy nhất, tới mức chật cứng, các pane nhỏ đến không đọc nổi. Ngay cả `tmux capture-pane`, thứ anh dùng để đọc nội dung một pane bằng code, cũng không lấy ra được gì có nghĩa từ chúng nữa. Anh đã thật sự hết chỗ để nhìn xem chính đội của mình đang làm gì.

![Failure 2: một cửa sổ tmux chia thành rất nhiều pane nhỏ, chữ bị cắt cụt](https://homus.dev/photos/4kYl2_mqmnQ-0432.jpg)

"Failure 2: panes too small": một cửa sổ tmux bị chia thành hàng chục pane worker, mỗi pane chỉ còn vài dòng chữ bị cắt ngang, không người nào và không script nào đọc được.

## 8. Failure 3, 4, 5: hết RAM, credential đá nhau, laptop chết

### Failure 3: hết bộ nhớ

Failure thứ ba là out of memory. Anh bảo mọi người nhìn vào màn hình: Activity Monitor bị chôn vùi hoàn toàn dưới các process của Claude Code và MCP. Swap gần đầy. Gần như không còn chút bộ nhớ trống nào. Các session cứ chồng lên nhau cho tới khi cái máy không thở nổi nữa.

![Failure 3: Activity Monitor đầy các process Claude Code và process npm exec của một MCP server](https://homus.dev/photos/4kYl2_mqmnQ-0456.jpg)

"Failure 3: out of memory": Activity Monitor với hàng loạt process Claude Code, mỗi cái vài trăm MB, và chồng lên đó là một danh sách dài các process `npm exec` của cùng một MCP server (context7-mcp), mỗi process khoảng 54 MB.

### Failure 4: Git credential đụng nhau

Failure thứ tư là Git credential. Kỳ vọng thì gọn gàng: credential A cho workspace A, credential B cho workspace B, một đối một. Thực tế thì chúng va chạm, bắt chéo, bị gắn nhầm vào workspace khác. Cách sửa là một môi trường sạch, tách biệt hoàn toàn cho từng workspace.

![Failure 4: expected cred A tới workspace A, cred B tới workspace B; reality hai credential bắt chéo nhau](https://homus.dev/photos/4kYl2_mqmnQ-0512.jpg)

"Failure 4: git credentials collide". Bên trái là kỳ vọng "expected 1-to-1": cred A tới workspace A, cred B tới workspace B. Bên phải là thực tế "both collide": hai mũi tên bắt chéo và workspace B bị gạch đi. Dòng cuối: "The fix: clean, separated environment per workspace."

### Failure 5: laptop chết

Và failure thứ năm, cái thật sự đau. MacBook là laptop, nên ngay khoảnh khắc nó mất điện hoặc rớt khỏi mạng, mọi job đang chạy dở chết theo nó. Có một lần, anh đã đẩy quá nhiều worker lên nó tới mức cả cái máy gục luôn. Anh quay lại sau đó, mở nắp lên, và nó đã tự khởi động lại rồi. Mọi thứ đang chạy dở, mất sạch.

![Failure 5: the laptop dies, MacBook mất điện hoặc rớt mạng là mọi job đang chạy dở chết theo](https://homus.dev/photos/4kYl2_mqmnQ-0528.jpg)

"Failure 5: the laptop dies": khi MacBook mất điện hoặc rớt khỏi mạng, mọi job đang chạy dở chết theo nó.

Vì vậy việc đầu tiên anh làm là xây một lệnh boot: chỉ một lệnh `overlord boot`, và cả đội dựng lại ngay lập tức, vì toàn bộ state vẫn nằm sẵn trong file. Nhưng một cái máy có thể biến mất trước mặt bạn như vậy, đó là lúc anh biết một máy sẽ không đủ. Từng failure một trong năm cái đều chỉ về cùng một câu trả lời.

## 9. Thêm máy và chuyển context bằng Git

Thế là anh thêm máy. Đây là cách chia việc: chiếc MacBook đang gánh mọi thứ, cả heavy coding lẫn project cá nhân, nên anh giảm tải cho nó. Task coding chạy dài chuyển sang Linux A, project cá nhân sống ngắn chuyển sang Linux B, cả hai luôn bật. Kết quả là nhiều tài nguyên hơn, phần việc chạy dài cuối cùng cũng rời khỏi laptop, và vẫn chỉ có một control plane trên tất cả.

![The offload: MacBook heavy coding + personal projects chuyển sang Linux A long-running coding tasks và Linux B short-lived personal side projects](https://homus.dev/photos/4kYl2_mqmnQ-0608.jpg)

"The offload": việc trên MacBook (heavy coding + personal projects) được chia sang Linux A (long-running coding tasks) và Linux B (short-lived personal side projects), cả hai headless và always-on. Ba nhãn dưới: more resources, long-running work off the laptop, one control plane.

Nhưng bây giờ anh có context nằm trên một máy mà anh cần ở máy khác. Chuyển nó thế nào? Bằng Git. Anh commit các file context rồi push. Sau đó anh "chọc" (poke) máy kia bằng `tmux send-keys` qua SSH và bảo nó pull. Nó pull về, agent bên đó đọc các file, và tiếp tục đúng chỗ agent đầu tiên đã dừng.

Git mang context bền vững; SSH và `tmux send-keys` chỉ là tín hiệu bảo máy kia kéo về. Agent ở máy đích đọc file và làm tiếp.

Tất nhiên mọi thứ không gọn như thế. Khi hai máy cùng trỏ vào một thư mục và cả hai đều thay đổi nó, bạn sẽ gặp conflict. Cùng một context lặng lẽ tách làm hai phiên bản khác nhau (diverge). Nên anh tách nó ra: thư mục riêng theo từng máy cho state gắn với máy, còn phần dùng chung chỉ được thay đổi qua một pull request. Nghe thì nhàm chán, nhưng chính sự nhàm chán đó ngăn hai cái máy âm thầm bất đồng với nhau.

## 10. Gom gateway về một chỗ, Discord làm router duy nhất

Rồi cái gateway quay lại cắn anh. Bây giờ mỗi máy đều có một gateway, nên anh lại phải kiểm tra nhiều inbox cùng lúc, đúng cái tình trạng anh từng muốn thoát. Nên anh gộp chúng lại. Mọi máy gửi review request qua SSH về một gateway chính, và gateway chính đó sống trên một máy Linux luôn bật. Vì hãy nhớ, chiếc Mac sẽ ngủ. Điểm kiểm soát duy nhất của bạn không thể là một thứ biết ngủ gật.

Từ nhiều inbox về một: mọi máy gửi review request qua SSH về gateway chính đặt trên một máy Linux luôn bật, không đặt trên chiếc Mac có thể ngủ.

Và rồi tới failure mà anh thích nhất trong cả project. Anh đang phát triển trên tất cả các máy, nhảy qua nhảy lại, và tới một lúc anh đi tìm một feature mình đã build, và anh thật sự không nhớ nổi mình đã build nó trên máy nào. Đó là lúc mọi thứ vỡ lẽ: anh cần một nơi duy nhất để điều phối (route) từ đó.

![I forgot which machine I'd built the feature on: Discord làm single router, ba bot mac, linux A, linux B; ảnh chụp server Discord Overlord team](https://homus.dev/photos/4kYl2_mqmnQ-0728.jpg)

"I forgot which machine I'd built the feature on.": Discord làm single router, nối tới ba bot là mac, linux A và linux B. Bên dưới là server Discord "Overlord team" của chính Kyle, nơi bot của từng máy (ovl-mac, ovl-linux) trả lời ngay trong một kênh chung.

Thế là Discord trở thành router duy nhất của anh. Mỗi máy một bot: Mac, Linux A, Linux B. Chiếc điện thoại của anh giờ là cái remote điều khiển toàn bộ đội agent.

## 11. Bốn vấn đề chưa giải, và tại sao câu trả lời là Kubernetes

Vậy bây giờ anh đang ở đâu? Thành thật mà nói, với một đống thứ chưa giải được. Cụ thể là bốn:

- Tính nhất quán (consistency) giữa các máy.

- Trừu tượng hoá những tool chỉ chạy được ở local, hiện vẫn kẹt trên chiếc Mac: các MCP server, cái browser.

- Chuyển giao credential an toàn giữa các instance.

- Quản lý tài nguyên (resource management). Anh thật sự muốn thôi làm người quyết định cái gì chạy ở đâu.

![Four open problems: consistency across machines, abstract away local-only tools, secure credential handoff, resource management](https://homus.dev/photos/4kYl2_mqmnQ-0752.jpg)

"Four open problems": consistency across machines; abstract away local-only tools (MCP và browser chỉ chạy trên Mac); secure credential handoff; resource management (chạy ở đâu cũng được, thôi bận tâm chuyện ở đâu).

Và khi xếp bốn vấn đề đó cạnh nhau, anh nhận ra đây hoàn toàn không phải câu hỏi mới. Một agent chỉ nên khai báo nó cần gì, chứ không phải nó chạy ở đâu. Phía trên nó là orchestrator, review gate và hierarchy logic. Phía dưới nó là compute, secrets và tools. Một scheduler đặt nó vào chỗ, và các cái máy chỉ việc biến mất bên dưới. Đây chính xác là những câu hỏi mà Kubernetes đã trả lời rồi.

![The convergence: an agent declared with a spec, orchestrator review gate logical hierarchy, compute secrets tools, scheduler, machines hidden below](https://homus.dev/photos/4kYl2_mqmnQ-0816.jpg)

"The convergence": từ trên xuống, một agent được khai báo bằng một spec (cần gì, không phải ở đâu); tầng orchestrator, review gate và logical hierarchy; tầng Compute, Secrets, Tools; một scheduler; và dưới cùng là các machine bị giấu đi.

Nên đó là hướng anh đang đi. Anh sẽ không phát minh lại compute, secrets và tools, vì Kubernetes đã làm những thứ đó rất tốt. Anh xếp chúng xuống dưới, và xây orchestration manager của riêng mình ở trên: task orchestration, review flow, context management. Dùng lại những gì đã có, xây phần mới ở trên.

"What I'm building on top": Kubernetes lo compute, secrets và tools ở tầng dưới; phần Kyle tự xây là orchestration manager ở trên, gồm task orchestration, review flow và context management.

Và đó là trạng thái thật của mọi thứ. Trên một máy, anh đã giải xong. Giữa nhiều máy thì vẫn còn thô, vẫn đang xây. Nếu bạn đang chạy agent ở bất kỳ quy mô nào, anh thật lòng rất muốn trao đổi (compare notes), vì đây là phần mà chưa ai giải được. Anh có mặt trên LinkedIn và X, link nằm trong phần mô tả của video. Anh cảm ơn mọi người rất nhiều.

## Sources and links

- Trang talk chính thức: [ai.engineer/talks/4kYl2_mqmnQ](https://ai.engineer/talks/4kYl2_mqmnQ)

- Kyle Jaejun Lee trên X: [x.com/kyleleee_119](https://x.com/kyleleee_119) · GitHub: [github.com/cooco119](https://github.com/cooco119) · LinkedIn: linkedin.com/in/jjlee-swe

- tmux (pane, `capture-pane`, `send-keys`): [github.com/tmux/tmux/wiki](https://github.com/tmux/tmux/wiki)

- Claude Code: [tài liệu chính thức](https://docs.claude.com/en/docs/claude-code/overview)

- Model Context Protocol (MCP): [modelcontextprotocol.io](https://modelcontextprotocol.io)

- Kubernetes: [kubernetes.io/docs/concepts/overview](https://kubernetes.io/docs/concepts/overview/)