# p10node Insights - full text > Working notes on reliability, delivery, cloud cost and AI infrastructure, from the engineers who run these systems in production. 7 published articles, newest first. Generated live from the CMS. ## CropText: Hướng Tiếp Cận OCR Web-First Cho Developer Và Content Creator Trong Hệ Sinh Thái P10Node 2026-10-06 · LongP10 · 4 min read · https://p10node.com/insights/croptext-huong-tiep-can-ocr-web-first-cho-developer-va-content-creator-trong-he # CropText: Hướng Tiếp Cận OCR Web-First Cho Developer Và Content Creator Trong Hệ Sinh Thái P10Node Trong kỷ nguyên làm việc số, trích xuất văn bản nhanh từ màn hình (OCR - Optical Character Recognition) đã trở thành một thao tác thiết yếu trong workflow của developer, nhà nghiên cứu dữ liệu và người sáng tạo nội dung. Các ứng dụng desktop truyền thống như **TextSniper** đã giải quyết rất tốt nhu cầu trích xuất ký tự trên hệ điều hành macOS. Tuy nhiên, sự phát triển của các mô hình làm việc đa nền tảng (Cross-platform) và xu hướng tối ưu hóa quy trình trực tiếp trên trình duyệt đã mở ra nhu cầu cho một giải pháp linh hoạt hơn. [CropText](https://app.p10node.com/croptext) ra đời trong hệ sinh thái P10Node nhằm mang lại một góc nhìn mới: ứng dụng OCR theo mô hình **Web-first**, giúp trích xuất văn bản tức thì mà không phụ thuộc vào nền tảng hay cài đặt phần mềm phức tạp. ## 1. Bối Cảnh Và Sự Thay Đổi Trong Nhu Cầu Xử Lý Dữ Liệu Những công cụ OCR dạng ứng dụng cài đặt trực tiếp trên hệ điều hành (Native Desktop Apps) như TextSniper sở hữu ưu điểm hoạt động mượt mà trong môi trường offline của macOS. Dù vậy, người dùng hiện đại thường gặp một số hạn chế về mặt mô hình triển khai: * **Giới hạn hệ điều hành:** Phần lớn các tiện ích native OCR chất lượng cao tập trung vào môi trường macOS, tạo ra khoảng trống trải nghiệm cho người dùng Windows, Linux hoặc làm việc trên nhiều thiết bị cùng lúc. * **Quy trình cài đặt & Cấp quyền:** Các ứng dụng desktop đòi hỏi tải xuống, cấp quyền truy cập màn hình hệ thống (Screen Recording Permissions) — điều đôi khi bị hạn chế bởi chính sách bảo mật doanh nghiệp. * **Xử lý ký tự đặc thù:** Việc trích xuất chính xác các đoạn mã nguồn (code snippet), ký tự đặc biệt trong lập trình hay văn bản tiếng Việt có dấu vẫn là bài toán cần continuous learning từ các mô hình OCR thế hệ mới. ## 2. CropText (P10Node): Giải Pháp OCR Web-First Đa Nền Tảng Được thiết kế định hình theo xu hướng tối ưu hóa thao tác trên Web, [CropText](https://app.p10node.com/croptext) mang đến trải nghiệm linh hoạt cho cộng đồng công nghệ: * **Truy cập tức thì qua trình duyệt:** Sử dụng trực tiếp tại địa chỉ `app.p10node.com/croptext` trên mọi hệ điều hành (Windows, macOS, Linux) mà không cần cài đặt phần mềm bổ sung. * **Tối ưu hóa cho ngữ cảnh Kỹ thuật & Tiếng Việt:** Thuật toán OCR được tinh chỉnh để tăng độ chính xác khi nhận diện tiếng Việt có dấu, cấu trúc dòng mã nguồn, địa chỉ ví Web3 và các bảng dữ liệu kỹ thuật. * **Tích hợp hệ sinh thái P10Node:** Được kết nối liền mạch với các công cụ hỗ trợ công việc khác trên nền tảng P10Node, giúp người dùng xử lý dữ liệu tập trung trong một môi trường duy nhất. * **Mô hình tiếp cận linh hoạt:** Cung cấp trải nghiệm tiếp cận dễ dàng, giảm thiểu rào cản chi phí trả trước cho người dùng cá nhân và nhóm phát triển nhỏ. ## 3. Bảng Phân Tích Đặc Tính Kỹ Thuật | Đặc tính | Công cụ Desktop Truyền thống (VD: TextSniper) | CropText (P10Node) | | :--- | :--- | :--- | | **Mô hình triển khai** | Native Desktop Application | Web-first Application | | **Hệ điều hành hỗ trợ** | Tối ưu chính cho macOS | Đa nền tảng (Mọi OS có Trình duyệt Web) | | **Hình thức truy cập** | Cài đặt tệp thi hành & Cấp quyền OS | Truy cập trực tiếp qua Web URL | | **Tối ưu ngữ cảnh** | Văn bản phổ thông / Đa ngôn ngữ cơ bản | Cấu trúc Code, Tiếng Việt & Dữ liệu Kỹ thuật | | **Mô hình chi phí** | Mua bản quyền phần mềm / Đăng ký gói | Tùy chọn linh hoạt theo hệ sinh thái P10Node | ## 4. Trải Nghiệm Và Đóng Góp Tùy Biến Một công cụ OCR tốt không chỉ dừng lại ở việc chuyển đổi hình ảnh thành chữ, mà là khả năng hòa nhập mượt mà vào workflow hàng ngày của bạn. Nếu bạn đang tìm kiếm một giải pháp OCR nhanh chóng, không rào cản cài đặt và tối ưu tốt cho tiếng Việt cũng như ký tự kỹ thuật, hãy trải nghiệm ngay [CropText trên P10Node App](https://app.p10node.com/croptext). Đội ngũ P10Node luôn sẵn sàng ghi nhận ý kiến đóng góp từ cộng đồng để tiếp tục cải tiến thuật toán nhận diện và hoàn thiện sản phẩm trong các phiên bản tiếp theo. *\*Disclaimer: TextSniper® là thương hiệu đã được đăng ký thuộc sở hữu của bên thứ ba tương ứng. Các thông tin trong bài viết được tổng hợp nhằm mục đích phân tích kỹ thuật và so sánh giải pháp công nghệ khách quan, giúp người dùng lựa chọn công cụ phù hợp với quy trình làm việc.* ## Tự host Headscale để thay thế cho Tailscale Cloud 2026-10-06 · LongP10 · 5 min read · https://p10node.com/insights/tu-host-headscale-de-thay-the-cho-tailscale-cloud # Làm chủ WireGuard Mesh Network: Tự host Headscale thay thế Tailscale Control Plane Tailscale gần như đã trở thành tiêu chuẩn defacto khi xây dựng overlay network Zero-Trust cho hạ tầng hiện đại. Nhờ vào thuật toán đục lỗ NAT (NAT traversal) mượt mà dựa trên WireGuard, việc kết nối hàng chục cluster, server bare-metal, VPS và thiết bị edge trở nên đơn giản hơn bao giờ hết. Tuy nhiên, mô hình của Tailscale là **hybrid open-source**: client mã nguồn mở, nhưng **Control Plane** (bộ não điều chỉnh node, phối hợp khóa public key, cấp phát MagicDNS và ACL) lại là dịch vụ SaaS đóng. Khi hạ tầng mở rộng hoặc đối mặt với các tiêu chuẩn khắt khe về **Sovereign Infrastructure** (Hạ tầng tự chủ), việc phụ thuộc vào SaaS Control Plane phát sinh nhiều rào cản: * Giới hạn số lượng node/user theo tier chi phí của Tailscale Cloud. * Rủi ro tuân thủ (compliance) khi metadata mạng bị lưu trữ ở bên thứ ba. * Phụ thuộc hoàn toàn vào uptime và chính sách thay đổi của nhà cung cấp SaaS. **Headscale** xuất hiện như một lời giải triệt để cho bài toán này: Một open-source Control Plane tương thích 100% với Tailscale Client. ## Kiến trúc: Phân tách Control Plane & Data Plane Để hiểu tại sao Headscale hoạt động mượt mà, cần nhìn lại bản chất mô hình của Tailscale: ``` +-------------------------------------------------------------+ | CONTROL PLANE | | (Headscale - Self-hosted Service) | | - Node Registration & Auth (OIDC) | | - WireGuard Key Exchange & Routing Table Sync | | - MagicDNS & Tailnet Policy (ACLs) | +------------------------------+------------------------------+ | Signaling / Control Only | +------------------------------v------------------------------+ | DATA PLANE | | (Direct P2P Encrypted WireGuard Tunnels) | | | | [ Node A ] <========== P2P Tunnel ==========> [ Node B ] | | ^ ^ | | | | | | +--- (Optional Fallback) ---> [ Custom DERP ]-+ | +-------------------------------------------------------------+ ``` 1. **Data Plane (Direct WireGuard P2P):** Lưu lượng truy cập thực tế giữa các server (Node A $\leftrightarrow$ Node B) diễn ra trực tiếp qua mã hóa WireGuard. Headscale **không bao giờ** chạm vào payload hay dữ liệu mạng của bạn. 2. **Control Plane (Headscale):** Chỉ đóng vai trò "trọng tài" cấp phát IP nội bộ (`100.x.x.x`), phối hợp việc trao đổi public key, đồng bộ cấu hình MagicDNS và đẩy bảng ánh xạ NAT giữa các node. > **Hệ quả kiến trúc quan trọng:** Nếu máy chủ Headscale gặp sự cố tạm thời (downtime), toàn bộ các kết nối P2P hiện hữu trong mạng mesh vẫn hoạt động hoàn toàn bình thường. Bạn chỉ không thể add thêm node mới hoặc nhận thay đổi ACL trong thời gian đó. ## Những lợi ích cốt lõi khi tự host Headscale ### 1. Hạ tầng tự chủ tuyệt đối (Data Sovereignty) Toàn bộ thông tin định tuyến, IP map, topology mạng và thông tin thiết bị nằm hoàn toàn trong database do bạn kiểm soát (PostgreSQL hoặc SQLite). Không có bất kỳ lượng telemetry nào bị lọt ra dịch vụ cloud ngoài. ### 2. Không giới hạn Scale & Chi phí cố định Bạn có thể nối hàng nghìn server, ephemeral container trong CI/CD pipeline hay thiết bị IoT vào Tailnet mà không tốn thêm một xu chi phí bản quyền SaaS. Chi phí duy nhất là tài nguyên máy chủ chạy Headscale binary (tốn chưa tới 100MB RAM). ### 3. Tích hợp OIDC/SSO Nội bộ Headscale hỗ trợ OIDC native. Bạn dễ dàng đấu nối việc xác thực đăng nhập mạng mesh trực tiếp vào hệ thống Identity Provider nội bộ như **Authentik**, **Keycloak** hoặc **Vaultwarden**. ### 4. Chủ động hạ tầng DERP Relay Khi hai node nằm sau hai tầng NAT khắc nghiệt (Symmetric NAT) không thể đục lỗ P2P trực tiếp, lưu lượng sẽ fallback qua DERP Relay. Thay vì dùng DERP public của Tailscale với latency cao, bạn tự dựng các điểm DERP node riêng đặt tại các Datacenter nội địa để tối ưu băng thông và độ trễ. ## Lựa chọn Kiến trúc Triển khai Khuyên dùng Để vận hành Headscale đạt độ tin cậy cấp Production, mô hình bên dưới là chuẩn tối ưu: ``` [ Tailscale Clients ] | v (HTTPS / Port 443) [ Caddy / Nginx Reverse Proxy ] (TLS Termination with Wildcard Cert) | v [ Headscale Process ] <---> [ PostgreSQL Database ] | v [ Identity Provider: Authentik / Keycloak ] (OIDC Authentication) ``` ### 1. Reverse Proxy & Domain Chạy Headscale đằng sau Caddy hoặc Nginx để tự động quản lý TLS Certificate. Headscale sử dụng gRPC và HTTP/2 cho việc sync state realtime, do đó Reverse Proxy cần hỗ trợ WebSocket và HTTP/2. Cấu hình Caddy mẫu: ```caddyfile # Caddyfile configuration for Headscale net.p10node.io { reverse_proxy localhost:8080 { header_up X-Real-IP {remote_host} } } ``` ### 2. File cấu hình Headscale cơ bản (`config.yaml`) ```yaml # Headscale core configuration server_url: https://net.p10node.io:443 listen_addr: 0.0.0.0:8080 metrics_listen_addr: 0.0.0.0:9090 db_type: postgres db_host: postgres-cluster.internal db_port: 5432 db_name: headscale db_user: headscale db_pass: "secure_password_here" ip_prefixes: - 100.64.0.0/10 - fd7a:115c:a1e0::/48 derp: server: enabled: false urls: - https://controlplane.tailscale.com/derp/derpers.json dns_config: nameservers: - 1.1.1.1 base_domain: p10.internal magic_dns: true oidc: only_start_if_oidc_is_available: true issuer: "https://auth.p10node.io/application/o/headscale/" client_id: "headscale-client-id" client_secret: "headscale-client-secret" scope: ["openid", "profile", "email"] ``` ### 3. Kết nối Client Trên các server hoặc máy trạm, việc kết nối tới Headscale Control Plane tự host cực kỳ đơn giản: ```bash # Connect Linux server to self-hosted Headscale tailscale up --login-server=https://net.p10node.io --accept-routes ``` ## Những thực tế kỹ thuật cần đánh đổi (Trade-offs) Tự vận hành hạ tầng đồng nghĩa với việc chấp nhận trách nhiệm kỹ thuật. Headscale không phải là bản sao 1:1 tính năng thương mại của Tailscale: * **Không có UI mặc định:** Headscale thuần túy là CLI binary. Nếu cần giao diện web quản lý user/node, bạn phải tự deploy thêm các dự án community như **Headscale-Admin** hoặc **Headplane**. * **Trách nhiệm sao lưu State:** Bạn phải chủ động cấu hình backup/restore định kỳ cho PostgreSQL database chứa thông tin node và private keys. * **Cấu hình ACLs thủ công:** Khác với giao diện JSON/HUGR trực quan trên Tailscale Cloud, ACLs trong Headscale được định nghĩa qua file YAML trên server và reload thủ công hoặc qua CI/CD. ## Lời kết Việc chuyển từ Tailscale Cloud sang tự host **Headscale** không đơn thuần là bài toán tiết kiệm chi phí. Đây là bước đi chiến lược trong tư duy thiết kế hạ tầng: **Không thỏa hiệp về mặt kiểm soát (Control) và bảo mật Zero-Trust.** Bằng cách làm chủ Control Plane, bạn sở hữu một mạng mesh private hoàn toàn phẳng, kết nối tin cậy giữa các môi trường Cloud, Bare-metal và Edge mà không chịu bất kỳ rào cản hay sự phụ thuộc vào bên thứ ba nào. ## p10logs: xem logs trên Kubernetes 2026-10-06 · LongP10 · 4 min read · https://p10node.com/insights/p10logs-xem-logs-tren-kubernetes Ai làm K8s cũng đều nếm trải cảm giác này: 3h sáng pod crash-loop, gõ `kubectl logs --previous` thì chỉ xem được đúng 1 lần restart ngay trước đó. Pod bị xoá, node bị reschedule là toàn bộ log đi sạch. Các tool xem log trực tiếp như Dozzle hay kubetail rất tiện, nhưng khi scale là dính đạn ngay. Nguyên nhân nằm ở chính kiến trúc: chúng stream log qua `kube-apiserver` → `kubelet` → file log. Mỗi container bạn đang xem là một kết nối TLS được giữ liên tục qua control plane. `kubelet` phải gọi CRI `ContainerStatus` liên tục mỗi giây cho từng stream. Subresource `log` lại không bị giới hạn bởi API Priority & Fairness (APF), stream nào cũng bị kubelet ngắt sau 4 giờ, và bạn chỉ nhìn thấy đúng file `0.log` hiện tại (tối đa 10 MiB). Lag hay treo control plane không phải do UI cùi, mà do kiến trúc stream quá tải. Muốn lưu log lâu dài? Giải pháp kinh điển là dựng Loki + Grafana (ngốn 1.5–7 GiB RAM) hoặc Elastic/SigNoz (≥4 GB RAM) đi kèm hàng đống thứ xịn xò như metrics, dashboard, compactor... Nhưng đôi khi, nhu cầu thực tế chỉ đơn giản là: **"Cho tôi xem lại log của cái pod vừa chết mà không bắt cluster gánh thêm cả tấn infrastructure."** *(VictoriaLogs là ngoại lệ nhẹ hiếm hoi, nếu bạn đang dùng ổn thì cứ tiếp tục).* Đó là lý do mình viết **p10logs**. ![](https://images.viblo.asia/1f237338-0656-4e0d-93a1-191ca73c40ef.gif) ## Architecture & Giải pháp ### 1. Agent (Go, DaemonSet, ~30 MiB RAM) - **Bypass control plane:** Đọc trực tiếp `/var/log/pods` trên node. Các metadata như namespace, pod, container, restart count đều parse từ đường dẫn file nên hoàn toàn không tốn 1 request nào gọi apiserver (nếu bật label enrichment thì chỉ dùng 1 watch/node, scope chặt theo `spec.nodeName`). - **Xử lý edge-case ở cấp filesystem:** - **Rotation:** Theo dõi log rotation của kubelet bằng cặp `inode + hash 16 bytes dòng đầu`. Nguyên nhân: kernel thường tái sử dụng inode của file vừa bị rotate, nếu chỉ dùng `path + inode` thì file mới sinh ra bị coi là trùng và drop sạch (mình dính đạn quả này trên cluster k3s sau ~3 giờ chạy). - **Assembly & Spooling:** Ghép các dòng partial 16 KiB của containerd, gom multiline stack trace, ghi checkpoint ra hostPath. Khi Hub chập chập hoặc nghẽn mạng, Agent tự động spool log ra disk trên node rồi drain dần khi Hub sống lại. ### 2. Hub (Go, StatefulSet + 1 PVC) - **Ingestion pipeline:** `Push` → `WAL fsync` → `Ack` → `Memtable theo stream` → `zstd frame` → `Chunk theo stream/ngày UTC`. - **Indexing nhẹ nhõm:** Seal chunk ở mốc 4 MiB kèm footer chứa time index và trigram bloom filter. Catalog SQLite đóng vai trò là derived state, có thể rebuild hoàn toàn từ log chunks nếu DB hỏng. - **Retention & Offload:** Xoá log theo age (mặc định 7 ngày) hoặc % dung lượng PVC, hỗ trợ override theo namespace. Cần lưu lâu thì offload chunk lạnh lên S3. - **Design choice:** Chạy 1 replica để tối ưu dung lượng và IOPS. Restart không mất dữ liệu, chấp nhận không HA để giữ kiến trúc tối giản nhất có thể. ### 3. Built-in UI & Multi-cluster - **UI nhúng sẵn trong binary Hub:** Cây điều hướng `cluster → namespace → pod → container`, cho phép tail nhiều pod xen kẽ theo timeline thực, có rate-limit server-side, vạch kẻ đánh dấu mốc restart, filter kiểu grep (`word`, `!word`, `"phrase"`, `/regex/`, `key=value`). - **Auth & Multi-cluster out-of-the-box:** Mọi thứ nằm trong 1 Helm chart. Cluster phụ chỉ cần cài Agent, push log về Hub trung tâm qua HTTPS bằng token riêng. Đã tối ưu cho cluster nằm sau NAT/CGNAT vì chỉ cần kết nối outbound (egress). ## Benchmark & Current State - **Benchmark (laptop):** Push 10k dòng/s trên 50 pod liên tục → Agent xài ~44 MiB, Hub xài ~100 MiB RAM, tỉ lệ nén zstd đạt **7.3×** trên disk. - **Idle (kind):** Agent ~18 MiB, Hub ~24 MiB. - **Image:** Distroless ~16 MB (Agent) / 23 MB (Hub), hỗ trợ cả `amd64` và `arm64`. **Trạng thái dự án:** v1.1 (Data format và `/api/v1` đã freeze từ v1.0). Đã pass toàn bộ e2e test trên `kind` (1-node, 3-node hub-spoke, test log rotation, `kill -9` hub để test spool/drain, upgrade Helm bảo toàn data) và đang chạy thực tế trên cluster k3s 3 node của mình. Tuy nhiên, mình chưa test trên các môi trường production quá lớn. ```bash helm install p10logs oci://ghcr.io/p10node/charts/p10logs \ -n p10logs --create-namespace --set global.clusterName=dev kubectl label ns p10logs pod-security.kubernetes.io/enforce=privileged --overwrite kubectl -n p10logs port-forward svc/p10logs-hub 8080:8080 ``` - **Demo live:** [https://demo-p10logs.p10node.org](https://demo-p10logs.p10node.org) (`admin` / `BqJDmpsGRJE85Z0cULFOeoRP`) - **Architecture Spec & Failure Mode Table:** [p10logs/docs/ARCHITECTURE.md](https://github.com/p10node/p10logs/blob/main/docs/ARCHITECTURE.md) ![](https://images.viblo.asia/a82fad4f-e6fe-4630-b87e-1103f060544f.png) ## Nhờ anh em Dev/DevOps góp ý Mình đang cần feedback thực tế từ những người trực tiếp vận hành cluster: 1. **HostPath & Policy:** Agent cần mount `hostPath` (`/var/log/pods`) nên namespace bắt buộc phải set Policy `privileged`. Mức độ này có phải là dealbreaker trong môi trường SecOps/Production của bên bạn không? 2. **Single Replica Hub:** Hub thiết kế 1 replica chạy với PVC để giữ tối giản. Với nhu cầu xem log/debug, việc thiếu HA ở Hub có phải vấn đề lớn không? 3. **Query Experience:** Hiện p10logs chỉ hỗ trợ filter kiểu grep/regex cơ bản. Nếu chuyển từ Loki/VictoriaLogs sang, tính năng query nào bạn cảm thấy thiếu thốn nhất? Mọi gạch đá hay góp ý về mặt kiến trúc đều rất hoan nghênh. ## Tại sao bạn nên dùng Kubernetes thay vì Docker Swarm 2026-09-15 · LongP10 · 6 min read · https://p10node.com/insights/tai-sao-ban-nen-dung-kubernetes-thay-vi-docker-swarm # Docker Swarm Rất Tốt Cho Đến Khi Bạn Lên Production: Tại Sao Kubernetes Vẫn Là Lựa Chọn Bắt Buộc? Khi bắt đầu xây dựng hệ thống phân tán, hầu hết kỹ sư đều bị cuốn hút bởi sự đơn giản của Docker Swarm. Chỉ với một câu lệnh `docker swarm init`, bạn đã có ngay một cluster hoạt động trong vài giây. Không cần cấu hình phức tạp, không cần học hàng tá khái niệm mới, dùng lại toàn bộ file `docker-compose.yml` sẵn có. Tuy nhiên, trong vận hành hạ tầng thực tế (Production), **đơn giản khi bắt đầu không đồng nghĩa với tối ưu khi vận hành lâu dài**. Container Orchestration không chỉ là việc "bật container lên và giữ cho nó chạy". Nó là câu chuyện về quản lý trạng thái (state management), khả năng tự phục hồi (self-healing), tích hợp lưu trữ phân tán, bảo mật phân quyền (RBAC), và quan trọng nhất: **khả năng mở rộng hệ thống theo thời gian**. Dưới đây là những lý do cốt lõi vì sao Kubernetes (K8s) vẫn là chuẩn mực bắt buộc nếu bạn muốn xây dựng một hạ tầng tin cậy, thay vì duy trì Docker Swarm. --- ## 1. Lightweight K8s Đã Xóa Bỏ Lý Do "Kubernetes Phức Tạp & Nặng Nề" Lý do lớn nhất khiến nhiều team ngần ngại chuyển sang Kubernetes là chi phí vận hành Control Plane ban đầu quá lớn và phức tạp. Nhưng góc nhìn đó đã cũ. Với sự phát triển của các bản phân phối Kubernetes tối giản như **k3s** hay **k0s**, bạn hoàn toàn có thể dựng một Production-ready K8s Cluster chỉ trong vài phút trên bare-metal hoặc VPS cấu hình khiêm tốn. Chúng loại bỏ các thành phần phụ thuộc cồng kềnh nhưng vẫn giữ nguyên 100% API chuẩn của Kubernetes. Lợi thế "dễ cài đặt" của Docker Swarm giờ đây không còn là rào cản quyết định nữa, khi mà các công cụ K8s hiện đại đã đơn giản hóa bài toán bootstrap hạ tầng lên rất nhiều. --- ## 2. Bài Toán Stateful Workloads & Sức Mạnh Của Operator Pattern Docker Swarm xử lý các ứng dụng **Stateless** (Web API, Microservices) khá tốt. Nhưng khi đụng đến các ứng dụng **Stateful** (Database clusters như PostgreSQL, MongoDB, hay Distributed Storage như Longhorn, OpenEBS), Swarm bộc lộ hạn chế lớn: * **Lưu trữ persistent:** Swarm thiếu cơ chế quản lý Volume Plugin tự động linh hoạt theo cấu trúc Pod/PersistentVolumeClaim (PVC) như chuẩn CSI (Container Storage Interface) của K8s. * **Operator Pattern:** Trong Kubernetes, bạn không chỉ chạy Database dưới dạng container thuần túy. Bạn dùng **Operator** (như CloudNativePG, Percona Operator). Operator đóng vai trò như một "Senior DBA thu nhỏ" nhúng trực tiếp vào Cluster: tự động failover, replication, backup/restore, auto-tuning mà không cần can thiệp thủ công. Docker Swarm hoàn toàn không có khái niệm tương đương này. Chạy Database hay Stateful Service trên Swarm thường dẫn đến việc phải viết rất nhiều bash script hoặc giải pháp custom bên ngoài để bù đắp cho phần thiếu hụt của Orchestrator. --- ## 3. Kubernetes Là Một "Platform For Platforms" Khả Năng Mở Rộng Không Giới Hạn Docker Swarm là một sản phẩm hoàn chỉnh với bộ tính năng cố định (Fixed feature set). Bạn dùng những gì Docker cung cấp sẵn, và rất khó để mở rộng core engine của nó. Ngược lại, Kubernetes được thiết kế như một **Hệ điều hành cho Distributed Systems** nhờ vào bộ đôi **CRD (Custom Resource Definition)** và **Custom Controller**: * Bạn có thể định nghĩa ra các tài nguyên mới hoàn toàn phù hợp với bài toán của doanh nghiệp (ví dụ: `InternalService`, `DatabaseCluster`, `SecurityPolicy`). * Bạn có thể viết các công cụ TUI/CLI custom, các Agent tự động hóa dựa trên API Machinery mạnh mẽ của Kubernetes. Kubernetes không ép bạn theo một tư duy cố định, nó cung cấp cho bạn khung kiến trúc để xây dựng Internal Developer Platform (IDP) riêng cho đội ngũ kỹ thuật của mình. --- ## 4. Hệ Sinh Thái & Chuẩn Hóa GitOps Một hệ thống Production hiện đại không thể thiếu luồng **GitOps**, observability và quản lý Traffic nâng cao. * **GitOps Standard:** Với Kubernetes, các công cụ như Argo CD hay Flux CD cho phép đưa toàn bộ trạng thái hạ tầng về dạng Declarative Code lưu trên Git. Hệ thống tự động phát hiện lệch cấu hình (drift detection) và sync liên tục. Trên Docker Swarm, việc triển khai GitOps bài bản gặp nhiều hạn chế do thiếu hệ sinh thái hỗ trợ. * **Traffic Management & Ingress:** K8s sở hữu hệ sinh thái Ingress Controller và Service Mesh phong phú (NGINX Ingress, Traefik, Caddy, Envoy, Istio). Việc routing, SSL termination, rate-limiting, canary deployment hay mTLS giữa các service được thực hiện một cách minh bạch theo dạng khai báo (declaratively). * **Cộng đồng & Bảo mật:** Mọi công cụ Security, Observability (Prometheus, Grafana, Datadog), Secret Management (HashiCorp Vault, Infisical) ngày nay đều ưu tiên hỗ trợ Kubernetes đầu tiên. --- ## 5. Rủi Ro Về Sự Phát Triển Của Hệ Sinh Thái (Ecosystem Risk) Thực tế cần nhìn nhận: Docker Swarm hiện tại chỉ ở trạng thái bảo trì và cập nhật nhỏ lẻ. Hầu hết các đổi mới công nghệ trong thế giới Cloud-Native (từ Serverless, Edge Computing, AI Inference orchestration đến Zero-Trust Security) đều diễn ra xung quanh Kubernetes. Đầu tư vào Docker Swarm ở thời điểm hiện tại đồng nghĩa với việc team bạn sẽ phải tự giải quyết tất cả các bài toán nâng cao mà cộng đồng Cloud-Native thế giới đã giải xong từ lâu trên Kubernetes. --- ## Lời Kết | Tiêu chí | Docker Swarm | Kubernetes (k3s / k0s / Upstream) | | :--- | :--- | :--- | | **Độ phức tạp ban đầu** | Rất thấp | Trung bình (Đã giảm mạnh nhờ Lightweight distros) | | **Quản lý Stateful & DB** | Cơ bản, phụ thuộc thao tác tay | Rất mạnh nhờ CSI & Operator Pattern | | **Khả năng mở rộng API** | Hạn chế | Không giới hạn (CRD & Controllers) | | **Hệ sinh thái & GitOps** | Nhỏ, thiếu chuẩn chung | Chuẩn De Facto toàn cầu (Argo CD, Helm...) | | **Phù hợp nhất cho** | Homelab, POC nhanh, hệ thống rất nhỏ | Production, Scaling Long-term, Enterprise | Nếu bạn chỉ cần chạy vài container đơn giản cho một project cá nhân hoặc thử nghiệm nhanh trong vài ngày, Docker Swarm vẫn là một công cụ tốt. Nhưng nếu mục tiêu của bạn là xây dựng **một hệ thống tin cậy, có khả năng mở rộng, tự động hóa cao và sẵn sàng cho các bài toán phức tạp trong tương lai**, việc làm quen và chuẩn hóa trên **Kubernetes** không còn là một lựa chọn tùy thích — đó là hướng đi chiến lược đúng đắn nhất. --- ### Nguồn Tham Khảo 1. **Kubernetes Documentation - Concepts & Architecture:** [https://kubernetes.io/docs/concepts/](https://kubernetes.io/docs/concepts/) 2. **CNCF Cloud Native Landscape:** [https://landscape.cncf.io/](https://landscape.cncf.io/) 3. **Operator Pattern in Kubernetes:** [https://kubernetes.io/docs/concepts/extend-kubernetes/operator/](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) 4. **Lightweight Kubernetes (k3s Architecture):** [https://docs.k3s.io/architecture](https://docs.k3s.io/architecture) 5. **Docker Swarm Documentation:** [https://docs.docker.com/engine/swarm/](https://docs.docker.com/engine/swarm/) ## The three numbers that decide what your inference costs 2026-08-21 · LongP10 · 4 min read · https://p10node.com/insights/gpu-inference-cost-per-thousand-requests Tags: ai, gpu, finops Teams renting GPUs almost always know their monthly bill and almost never know their cost per thousand requests. Those are different metrics, and only the second one tells you whether things are getting better. The bill goes up when you grow. Cost per thousand requests going up while you grow means the platform is getting less efficient, and that is the signal worth alerting on. Three numbers set it. ## 1. Utilisation, measured honestly Not "the GPU is allocated". Not `nvidia-smi` reporting 100 percent, which reports whether a kernel is resident, not whether the device is doing useful work. The number to track is achieved occupancy against the memory bandwidth ceiling, or in practical terms: tokens per second per GPU against what that GPU can do for that model at that batch size. Most teams that have never measured it are between 10 and 30 percent. The gap is nearly always the same thing. Requests arrive one at a time and are served one at a time, so the device spends its life waiting for the next one. ## 2. Batch size, which is really a latency budget Batching is the single largest lever, and it is not free: a request that waits to be batched has waited. Continuous batching in vLLM or TensorRT-LLM changes the shape of the trade considerably, because a new request joins the in-flight batch at the next decode step instead of waiting for the whole batch to finish. Throughput rises several times over with a tail latency cost measured in tens of milliseconds rather than seconds. The decision is not "batch or do not batch". It is: what is the p99 you have actually promised, and how much of it is available to spend here? A chat interface where a human is reading the output can give up 200 ms of time-to-first-token and nobody notices. A synchronous call inside a checkout flow cannot give up 20. Write the number down before tuning anything, because every knob past this point trades against it. ## 3. What happens at zero The largest waste in most inference platforms is not inefficiency during traffic. It is the fleet sitting at idle overnight, at full price, because scale-to-zero was never wired up. The objection is cold start, and it is a real one: pulling a 30 GB model into GPU memory is not a 5-second operation. The mitigations are unglamorous and they work. Keep the weights on a local NVMe cache rather than object storage. Keep one warm replica for the floor and scale the rest. Separate the queue from the workers so a request that arrives during a scale-up waits in line instead of failing. For anything with a business-hours traffic shape, this is routinely a third of the bill. ## The measurement that ties them together One metric, on the same dashboard as latency and error rate: ``` cost per 1k requests = (GPU-hours x hourly rate) / (requests / 1000) ``` Broken out by model and by route, because an average across a 7B model and a 70B model is a number about your traffic mix rather than your efficiency. Then two alerts. One when cost per thousand crosses a threshold, which catches a regression. One when it moves more than 20 percent week over week in either direction, which catches a mix change or a config that silently stopped batching. ## Build versus rent, briefly The question we are asked most often. The arithmetic is less interesting than people expect. Owned hardware wins on steady, predictable, high utilisation, and the crossover is usually somewhere around 60 to 70 percent sustained utilisation over an 18-month horizon, once power, cooling, spares and the engineer who replaces failed cards are counted honestly. Below that, rent. The flexibility is worth more than the discount, and a team that cannot yet keep rented GPUs busy will not keep owned ones busy either. Fix utilisation first; it changes the answer. ## A worked example A recent engagement: an applied-AI team renting far more GPU than they used, serving one request at a time on a fleet sized for peak, with nothing scaling down. Continuous batching, a KV cache that survived between requests in a session, and scale-to-zero on the two lowest-traffic models. Throughput went up 3.1 times on the same budget, and cost per thousand requests fell from $1.04 to $0.31. No new hardware, and no change to the model. ## Cutting cloud spend, in the order that actually works 2026-08-05 · LongP10 · 4 min read · https://p10node.com/insights/cloud-cost-the-order-we-do-it-in Tags: finops, cloud Cost reduction programmes usually start where the button is easiest to press: buy commitments. It works, once, and then the programme stalls, because a three-year commitment on a workload nobody has examined locks in the waste for three years. The order matters more than any individual technique. This is the sequence we run, and the reasoning behind it. ## 1. Attribution, before anything is changed You cannot reduce a number nobody owns. The first week is spent making the bill legible: tags enforced at provisioning time, one account or project per team where the boundary allows it, and a cost per environment that someone recognises as theirs. Not a dashboard for the platform team. A number that lands in the channel of the team that generated it. This step saves nothing on its own and it is the reason everything after it works. In the median engagement the attribution pass alone reveals between 8 and 15 percent of spend belonging to nothing anyone will claim. ## 2. Delete what nobody is using Unattached volumes. Snapshots from a migration finished two years ago. Load balancers in front of nothing. Idle NAT gateways. The staging cluster from a project that shipped in 2024. Log retention set to "forever" on a bucket ingesting 400 GB a day. This is not clever work and it is usually the largest single line in the first month. It is also the safest: nothing is serving traffic, so nothing can break. The only real risk is deleting something that turns out to matter, which is what the attribution pass is for. ## 3. Right-size against observed usage, not requested usage Now the interesting part. Almost every platform we touch has requests set by a nervous engineer at 2 a.m. two years ago, never revisited. The rule is to size against the p99 of observed usage over a full business cycle, with headroom, not against the peak of all time and not against the average. Averages hide the spikes that cause the incidents; all-time peaks include the one bad Tuesday that a retry storm caused and which has since been fixed. On Kubernetes this is where most of the money is. A cluster where every workload requests 2 CPU and uses 200 millicores is paying for a fleet three times larger than it needs, and no amount of commitment discount fixes that. ## 4. Move the work that can tolerate interruption Batch jobs, CI runners, data pipeline stages, anything with a retry and no user waiting on it. Spot and preemptible capacity is 60 to 90 percent cheaper and the engineering cost is a checkpoint and a retry. The mistake here is going too far. Spot for a stateful primary is not a cost optimisation, it is an outage with a discount. The test is simple: if the workload disappearing mid-execution is merely annoying, it belongs on spot. If it requires a human, it does not. ## 5. Fix the architecture that generates the spend The most expensive line on many bills is not compute. It is data moving in the wrong direction: cross-zone traffic between services that should be zone-aware, an egress path through a NAT gateway that should be a private endpoint, a chatty service pair separated by a region boundary for reasons nobody remembers. This is real engineering work and it is where the durable savings live, because it changes the slope of the cost curve rather than its intercept. The savings from steps 2 and 3 are a one-time step down. Step 5 is the one that stops the number growing faster than revenue. ## 6. Now buy the commitments By this point the workload is stable, right-sized and partly on spot, so the baseline you are committing to is the real one. Commitments bought here are typically 30 to 40 percent smaller than the ones the same team would have bought in month one, at the same discount rate, covering a genuinely steady floor. Buying last is not a rule about savings. It is a rule about optionality: every commitment is a bet that your architecture will not improve. ## 7. Put a budget alert in front of every team Everything above decays. A cost programme that ends with a report ends, full stop, and the number climbs back within two quarters. What survives is a per-team budget with an alert that fires in that team's channel, a unit-cost metric on the same dashboard as latency and error rate, and cost as a line item in architecture review. Not a gate. A number people see while the decision is still cheap to change. ## What this looks like in practice The most recent full programme: 62 percent reduction over 14 weeks while traffic tripled, and a $1.9M annual saving. Roughly half of that came from steps 2 and 3, which took three weeks. The other half came from step 5, which took nine, and is the half that is still holding. The commitments were bought in week 12. ## What a reliability assessment actually looks at 2026-07-14 · LongP10 · 4 min read · https://p10node.com/insights/reliability-assessment-what-we-look-at Tags: reliability, sre Every engagement starts the same way: two weeks inside your systems, and a scored report at the end. Teams often expect an infrastructure audit. It is not one. Infrastructure is the easiest part of a platform to inspect and the least likely thing to be the reason you are paging at 3 a.m. Here is the actual shape of it. ## We start with the last ten incidents Not the architecture diagram. The diagram describes what someone intended; the incident history describes what the system does. For each one we want four things: what the customer experienced, when someone first knew, what the fix was, and whether the same failure could happen again tomorrow. That last question is the one that scores. A team with twelve incidents and twelve permanent fixes is in better shape than a team with three incidents and three restarts. The pattern we find most often is not a fragile system. It is a system whose failures are all detected by customers rather than by monitoring. ## Then: what does "up" mean here Ask five people in the same company what counts as an outage and you will usually get five answers, none of them written down. Without that definition there is nothing to measure, so every reliability conversation becomes a matter of opinion and the loudest person wins. An SLO is not a compliance artefact. It is the sentence that ends the argument. Checkout completes in under 800 ms for 99.9% of requests, measured at the edge, over 28 days. Now a change that costs 40 ms has a price, and a quarter spent on reliability work has a finish line. Most platforms we assess have no SLO. A few have thirty, which is the same as none. ## How long from commit to production Lead time is the single most predictive number we collect, and it is predictive of things that sound unrelated to delivery speed. Long lead times force batching. Batching makes every release large, and large releases are the ones that break. Breakage during a large release is hard to attribute, so rollbacks become rare and forward-fixes become the norm, which extends the outage. The team responds by adding more pre-release process, which lengthens lead time further. We have never seen a platform with a nine-day lead time and a healthy incident profile. The two are the same problem seen from different ends. ## Can you deploy on a Friday This is a proxy question and everyone knows it, which is why the answer is honest. What we are really asking is whether a rollback is a routine, automated, sub-minute operation, or a decision that requires a meeting. If it is the first, Friday is an ordinary day. If it is the second, the team has correctly concluded that Friday is dangerous, and the ban on Friday deploys is a rational response to a real risk rather than a cultural failing. Fix the rollback and the ban dissolves on its own. ## What happens when the person who knows leaves Every platform has at least one component that exactly one engineer understands. That is normal. What matters is whether the organisation knows which components those are. We map them explicitly: for each critical service, who can debug it under pressure at 3 a.m. If the answer is one name, that is a finding with a number attached, not a note in an appendix. ## What does it cost, and what is that per unit Cloud spend is an engineering metric. A team that cannot say what a thousand requests cost has no way to tell an efficiency regression from growth, and will find out about both from finance, a quarter late. The unit varies. Cost per thousand requests, per active tenant, per gigabyte ingested, per thousand inferences. Which one it is matters less than having one and watching it. ## Can you restore Backups that have never been restored are not backups. They are a line item. We ask for the last restore drill. If there has not been one, we run it during the assessment, against real data, timed. That number goes in the report, and it is regularly the most surprising line in it. ## What the report is A scored roadmap, prioritised by risk against effort, that your team could execute without us. Every finding has an owner, a rough size, and the sentence explaining why it matters that a non-engineer can read. Roughly a third of the findings, in the median engagement, cost nothing to fix. They are defaults nobody revisited, alerts that fire into a channel nobody reads, a retry policy that turns a slow dependency into an outage. The point of two weeks is not to find everything. It is to find the order. We do the assessment as a fixed-price piece of work, and it stands alone. Plenty of teams take the report and run it themselves. That is a good outcome.