Bài toán Scale hạ tầng Kubernetes: Stack thuần Declarative với Talos Linux và CAPI

Infrastructure-as-Code thực thụ

Trong nhiều năm qua, một định kiến bất thành văn trong ngành công nghệ là: nếu muốn có một môi trường Kubernetes ổn định cho Production, bạn nên nhường quyền kiểm soát hạ tầng cho các nhà cung cấp Public Cloud thông qua các dịch vụ Managed K8s như EKS hoặc AKS. Thế nhưng, đối với các doanh nghiệp cần mở rộng quy mô compute theo chiều ngang, chạy các workload HPC, AI Training qua Slurm, hoặc các Platform Architect muốn tối ưu hóa chi phí phần cứng Bare-metal, thì Public Cloud lại mang đến mức hao phí ảo hóa (virtualization tax) lớn, độ trễ cao và rủi ro vendor lock-in.

Đồng thời, việc tự quản lý một Private Cloud hoặc một cụm Bare-metal từ trước đến nay thường rất rời rạc: chuỗi pipeline kết hợp từ các template Terraform, theo sau là các vòng lặp Ansible, và kết thúc bằng các cấu hình snowflake node sinh ra từ kubeadm.

Một sự thay đổi thầm lặng đang diễn ra trong ngành Platform Engineering. Bằng cách kết hợp Talos Linux và Cluster API (CAPI), chúng ta có thể quản lý phần cứng vật lý và hạ tầng cốt lõi hoàn toàn giống như cách điều phối các container phần mềm. Bài viết này sẽ mổ xẻ triết lý kiến trúc đằng sau một nền tảng Private Cloud vận hành hoàn toàn bằng API, immutable và không cần cấu hình thủ công.

1. Talos Linux

Trước khi điều phối cả một Private Cloud, chúng ta phải giải quyết bài toán ở cấp độ từng Node. Các Linux Distro truyền thống như Ubuntu, RHEL hay Debian là những hệ điều hành đa mục đích được ra đời trước kỷ nguyên container. Các hệ điều hành này luôn kèm theo rất nhiều dịch vụ cồng kềnh như systemd, udev, Python runtime, SSH daemon và các package manager. Trong một stack cloud-native hiện đại, đây chính là nguyên nhân gây ra hiện tượng lệch cấu hình (configuration drift), tạo ra bề mặt tấn công bảo mật lớn và gây lãng phí tài nguyên hệ thống.

Thực tế, các OS vendor cũng nhận ra sự dư thừa này khi chạy compute. Họ từng cố gắng tung ra các phiên bản rút gọn như Ubuntu Core hay CoreOS. Ngay cả các worker node chạy trên các dịch vụ Managed K8s như EKS Optimized AMI của AWS cũng là những phiên bản Linux đã được tinh giản tối đa để phục vụ Kubernetes.

Talos Linux loại bỏ hoàn toàn mô hình vận hành Linux truyền thống này. Triết lý dẫn đường của nó là xem máy chủ như Cattle thay vì nuôi dưỡng như Pet. Đây là một hệ điều hành được kiến trúc từ con số 0 chỉ để chạy container.

Talos Linux is not a Kubernetes distribution, but rather a Linux distribution purpose-built for running upstream Kubernetes.

Talos Linux không phải là một bản phân phối Kubernetes, mà đúng hơn là một bản phân phối Linux được xây dựng chuyên biệt chỉ để chạy upstream Kubernetes.

Các ràng buộc thiết kế Cloud-Native triệt để:

Không Shell, Không Bash, Không SSH: Hệ thống không có môi trường dòng lệnh terminal và bạn không thể đăng nhập vào một Talos node. Các công cụ quét bảo mật gần như tìm thấy 0 lỗi CVE vì hệ thống không chứa các công cụ tiện ích, trình biên dịch hay shell nhị phân để tin tặc khai thác.
Kiến trúc API-First: Vì không có SSH, mọi hoạt động tương tác với node từ đọc log kernel cho đến cấu hình network interface bonding đều diễn ra thông qua giao diện gRPC bảo mật mã hóa mTLS, được quản lý bằng lệnh talosctl tương tự như cách bạn dùng kubectl.
Hệ thống Init dựa trên Go (PID 1): Talos loại bỏ hoàn toàn systemd. Khi kernel khởi động, nó sẽ kích hoạt một tiến trình init tùy biến được viết bằng Go mang tên machined. Tiến trình daemon này chịu trách nhiệm mount root file system ở chế độ read-only, khởi tạo network, chạy containerd và trực tiếp điều khiển kubelet.

Không có APT/DNF: Muốn thêm tính năng? Hãy tự build ISO thông qua Extensions

Vì Talos Linux hướng tới sự bất biến tuyệt đối, hệ thống không có các package manager như apt-get hay dnf. Bạn không thể boot một node lên rồi gõ lệnh cài đặt thêm driver hay các công cụ lưu trữ cấp thấp như iscsid. Để giải quyết, Talos cung cấp công cụ Talos Image Factory giúp đóng gói sẵn các extension cần thiết trực tiếp vào bộ cài ISO.

Các thành phần kỹ thuật cốt lõi:

File YAML machineconfig: Đây là Source of Truth duy nhất. Mọi thông số cấu hình network, disk, tham số kernel, sysctl, flags và patches đều được định nghĩa rõ ràng tại đây.
Immutability Control Loop: Tiến trình machined liên tục đối chiếu trạng thái runtime của hệ thống với file machineconfig đã được xác thực. Nếu một node bị lệch cấu hình, hệ thống sẽ không thực hiện vá lỗi thủ công mà sẽ xóa bỏ hoàn toàn node đó để re-image lập tức từ một image sạch ban đầu.

2. Cluster API (CAPI): Xem Clusters như Pods

Nếu bạn đã biết dùng Kubernetes, bạn sẽ biết cách vận hành Cluster API. CAPI không phát minh ra một cơ chế quản lý mới mà sử dụng chính logic điều phối của Kubernetes (reconciliation loop) để áp dụng xuống tầng quản lý hạ tầng.

Bảng so sánh dưới đây thể hiện mối tương quan 1-1 giữa hai mô hình:

Khái niệm trong Kubernetes	Khái niệm tương đương trong Cluster API (CAPI)	Bản chất
Pod	`Machine`	Đơn vị nhỏ nhất. Pod đại diện cho một container chạy app; `Machine` đại diện cho một máy chủ vật lý/máy ảo chạy hệ điều hành.
ReplicaSet	`MachineSet`	Đảm bảo số lượng. `ReplicaSet` giữ cho số lượng Pod luôn đúng kỳ vọng; `MachineSet` giữ cho số lượng Server luôn đúng số lượng khai báo.
Deployment	`MachineDeployment`	Chiến lược cập nhật. `Deployment` quản lý rolling update phiên bản app; `MachineDeployment` quản lý rolling update phiên bản OS hoặc phiên bản Kubernetes trên cụm server (máy chủ) mà không gây downtime.

Hệ sinh thái Provider tách biệt (Decoupled Ecosystem)

CAPI có thể mở rộng trên bất kỳ hạ tầng nào nhờ vào kiến trúc mô-đun được vận hành bởi các provider độc lập:

Infrastructure Provider (ví dụ: CAPMOX cho Proxmox, CAPA cho AWS, CAPZ cho Azure): Đóng vai trò như các driver hạ tầng. Nhiệm vụ của nó là nhận lệnh từ object Machine trừu tượng, sau đó dịch và gọi API thực tế xuống nhà cung cấp tương ứng.

Nếu hạ tầng nằm trên Public Cloud, CAPI sẽ gọi API đến AWS (qua CAPA) hoặc Azure (qua CAPZ) để tự động spin up các EC2 Instance hoặc Azure VM làm node. Nếu chạy On-premise, nó sẽ ra lệnh trực tiếp xuống Proxmox thông qua API Token để cấp phát VM theo yêu cầu. Từ đó, một Management Cluster có thể quản lý vòng đời của tất cả các loại cluster khác nhau.
Bootstrap Provider (ví dụ: CABPT cho Talos, CABPK cho Kubeadm): Đóng vai trò như bộ cấu hình khởi tạo hệ điều hành nhằm biến một máy thô vừa boot OS thành một Kubernetes Node chính thức.
- Đối với Talos Linux (CABPT): Quá trình này tự động hóa lệnh talosctl apply-config. CAPI sẽ tự động biên dịch các khai báo cấu hình từ file YAML của Cluster thành dữ liệu machineconfig, sau đó bơm trực tiếp file này xuống node. Hệ điều hành Talos nhận file, tự cấu hình kernel và khởi chạy kubelet mà không cần bất kỳ script bash nào.
- Đối với Kubeadm (CABPK): Bootstrap Provider sẽ tạo ra một đoạn Cloud-init script. Khi OS boot lên, đoạn script này sẽ chạy tuần tự các lệnh shell để cài đặt containerd, cấu hình mạng, tải về binary của kubeadm/kubelet, và cuối cùng thực thi lệnh kubeadm join để kéo node đó về cụm.
Control Plane Provider (ví dụ: KCP cho Kubeadm, CACPPT cho Talos): Đóng vai trò cung cấp Control Plane cho cụm. Một cluster không thể hoạt động nếu thiếu Control Plane, bởi nếu không có các thành phần cốt lõi như kube-apiserver để nhận lệnh hay etcd để lưu trữ trạng thái, các worker node do Infrastructure Provider cấp phát sẽ không thể điều phối workload.
- Đối với Kubeadm Control Plane: CAPI sẽ dùng KCP controller để spin up các máy chủ thông thường, sau đó chạy lệnh kubeadm init trên node đầu tiên để khởi tạo cụm etcd và các file manifest tĩnh cho các thành phần core. Với các node tiếp theo, KCP tiếp tục chạy lệnh kubeadm join --control-plane để ghép nối chúng thành một cụm High Availability.
- Đối với Talos Linux (sử dụng CACPPT): Vì Talos không có Kubeadm lẫn shell bash để chạy lệnh init, CAPI sẽ phối hợp với CACPPT để đẩy một cấu hình machineconfig đặc biệt với role Control Plane xuống các node được chỉ định. Thay vì phụ thuộc vào một kịch bản cài đặt tuần tự, các daemon ngầm của chính hệ điều hành Talos trên các node này sẽ tự động thiết lập mạng lưới gRPC bảo mật để tự bắt tay, tự bầu chọn và khởi tạo cụm etcd (Native Bootstrapping) ngay từ tầng core hệ điều hành.

3. Thay đổi mô hình tư duy: Mở rộng hạ tầng theo tư duy Cattle, không phải Pet

Để hiểu rõ giá trị của bộ đôi Talos Linux và Cluster API, chúng ta cần nhìn vào cách chúng định nghĩa lại phép ẩn dụ kinh điển trong ngành DevOps: Pets vs. Cattle.

Pets: Là những máy chủ được đặt những cái tên độc nhất như db-prod-01, k8s-master-old. Chúng được các kỹ sư chăm bẵm cẩn thận, cấu hình riêng lẻ, và khi gặp sự cố, kỹ sư sẽ lập tức SSH vào để đọc log, chạy các lệnh vá lỗi tạm thời để cứu sống chúng.
Cattle: Là các máy chủ hoàn toàn giống nhau, không cần tên riêng và được đối xử như một tập hợp tài nguyên ẩn danh như worker-pool-7b4f5. Khi một máy chủ gặp sự cố, bạn không cần điều tra hay debug mà có thể hủy diệt nó ngay lập tức để các controller tự động tạo ra một con khác thay thế y hệt.

Bước đột phá từ CAPI + Talos: Triệt tiêu tư duy Pet

Khi kết hợp Talos Linux và Cluster API, bạn hoàn toàn tước bỏ khả năng biến một máy chủ thành Pet:

Bạn không thể sửa lỗi trực tiếp trên node: Vì Talos không có SSH hay bash shell, không có cơ chế nào để bạn log in vào và tung ra một bản vá tạm thời. Bạn không thể cài thêm gói phần mềm bị thiếu hay sửa đổi file cấu hình local trực tiếp trên đĩa.
Thay thế Atomic qua MachineDeployment: Nếu một máy chủ vật lý bị kernel panic hoặc không vượt qua bước health check của CAPI, controller MachineDeployment sẽ lập tức xóa bỏ object Machine, ra lệnh cho lớp hạ tầng thu hồi tài nguyên và khởi tạo một máy chủ mới dựa trên đúng blueprint machineconfig ban đầu.

5. Lựa chọn Kiến trúc: Khi nào chọn Managed K8s, khi nào chọn Talos + CAPI?

Đây vẫn là bài toán chọn đúng công cụ cho đúng mục đích sử dụng.

Mô hình 1: Managed Kubernetes (EKS, AKS, GKE)

Tối ưu cho: Các ứng dụng web hoặc microservices tiêu chuẩn, các workload ở mức độ vừa phải, doanh nghiệp cần tốc độ Time-to-Market nhanh và không muốn bận tâm về hạ tầng vật lý.

Điểm mạnh:
- Day-0 mượt mà: khởi tạo cụm production-ready nhanh chóng thông qua các Terraform module có sẵn của provider.
- Ủy thác Control Plane: toàn bộ công tác vận hành Control Plane (etcd, kube-apiserver) do Cloud Provider chịu trách nhiệm.
- Ecosystem sẵn có: tự động kết nối mượt mà với các dịch vụ storage, Load Balancer và IAM của Cloud.
Điểm yếu:
- Virtualization Tax: lớp ảo hóa (hypervisor) tạo ra latency nhất định, không tối ưu tuyệt đối cho compute.
- Chi phí ẩn: Bị ràng buộc bởi chi phí băng thông (egress tax) và các giới hạn API của nhà cung cấp theo thời gian.

Mô hình 2: Talos Linux + Cluster API (Private Cloud / Bare-Metal)

Tối ưu cho: Điện toán hiệu năng cao (HPC), điều phối Slurm workload với Slinky, các hệ thống AI/ML đòi hỏi hiệu năng phần cứng tối đa, và các đội ngũ muốn tự chủ hoàn toàn chi phí.

Điểm mạnh:
- Hiệu năng Bare-metal thuần túy: chạy trực tiếp trên silicon, tận dụng 100% sức mạnh phần cứng mà không bị tiêu hao qua tầng hypervisor.
- Tự chủ Private Cloud: khi được đầu tư phát triển bài bản, stack CAPI + Talos sở hữu năng lực điều phối cả bare-metal lẫn virtualized workload cùng khả năng tự động hóa việc sizing hạ tầng. Mẹo thiết kế kiến trúc Hybrid: Bạn hoàn toàn có thể đặt Management Cluster trên Public Cloud để tận dụng hạ tầng HA sẵn có của họ bằng cách rải các node nằm trên nhiều Availability Zone hoặc Region khác nhau. Tuy nhiên, hãy đặc biệt lưu ý ranh giới về Network Latency giữa các vùng để không vượt quá giới hạn của etcd (thường yêu cầu độ trễ khứ hồi dưới 10ms-20ms để duy trì trạng thái ổn định).
- Bảo mật Zero-Drift: OS Immutable loại bỏ hoàn toàn bề mặt tấn công nhờ việc lược bỏ SSH/Shell, đảm bảo các node không bao giờ bị lệch cấu hình.
- Mã nguồn mở 100%: toàn bộ stack công nghệ từ CAPI cho đến Talos Linux đều là mã nguồn mở, không lo ngại chính sách thay đổi license đột ngột từ các hãng công nghệ lớn. Bạn tự do tùy biến và scale up hệ thống lên hàng ngàn node mà không tốn chi phí bản quyền.
Điểm yếu:
- Rào cản Day-0 lớn: đòi hỏi đội ngũ phải có kinh nghiệm vận hành phần cứng (Inventory, BMC) và tư duy GitOps sâu sắc.
- Gánh vác trạng thái (State): bạn phải tự chịu trách nhiệm thiết kế độ sẵn sàng cao (HA) cho cụm dữ liệu trạng thái cốt lõi của hệ thống.

Kết luận: Hãy ngừng chăm bẵm các máy chủ của bạn

Là các Platform Engineer, chúng ta cần chấm dứt việc đối xử với hạ tầng như những thực thể mỏng manh cần đến sự can thiệp thủ công qua SSH mỗi khi có sự cố xảy ra.

Bằng cách xây dựng kiến trúc nền tảng dựa trên Talos Linux và Cluster API, chúng ta bóc tách hoàn toàn sự cồng kềnh và tính dễ tổn thương từ các thao tác thủ công trên hệ điều hành Linux truyền thống. Thứ còn lại cuối cùng chính là một hệ thống quản lý qua API sạch sẽ, bảo mật, hiệu năng cao và vận hành hoàn toàn theo mô hình declarative kết hợp GitOps.