Nhìn tổng quan các quyết định sớm của Joe Beda về Kubernetes—mô hình khai báo, control loops, Pods, Services và labels—và cách chúng định hình nền tảng ứng dụng hiện đại.
Joe Beda là một trong những người then chốt đằng sau thiết kế ban đầu của Kubernetes—cùng với các nhà sáng lập khác mang bài học từ hệ thống nội bộ của Google ra một nền tảng mở. Ảnh hưởng của ông không phải là chạy theo tính năng thời thượng; mà là chọn các nguyên thủy đơn giản có thể chịu nổi sự hỗn loạn trong môi trường production và vẫn dễ hiểu cho các nhóm hàng ngày.
Những quyết định ban đầu đó là lý do Kubernetes trở thành hơn một “công cụ container”. Nó biến thành một nhân (kernel) có thể tái sử dụng cho nền tảng ứng dụng hiện đại.
“Điều phối container” là tập hợp quy tắc và tự động hóa giữ cho ứng dụng của bạn chạy khi máy hỏng, lưu lượng tăng đột biến, hoặc khi bạn triển khai phiên bản mới. Thay vì một người trực máy chủ, hệ thống sẽ lên lịch container lên máy, khởi động lại khi crash, phân tán để tăng khả năng chịu lỗi và thiết lập mạng để người dùng có thể truy cập.
Trước khi Kubernetes phổ biến, các nhóm thường khâu vá các script và công cụ tùy biến để trả lời những câu hỏi cơ bản:
Những hệ thống DIY đó hoạt động—cho đến khi không còn hoạt động nữa. Mỗi app hoặc nhóm mới thêm logic một lần, và nhất quán vận hành rất khó đạt được.
Bài viết đi qua các lựa chọn thiết kế sớm của Kubernetes ("hình dạng" của Kubernetes) và lý do chúng vẫn ảnh hưởng đến nền tảng hiện đại: mô hình khai báo, controllers, Pods, labels, Services, một API mạnh, trạng thái cluster nhất quán, lập lịch có thể cắm được và khả năng mở rộng. Ngay cả khi bạn không chạy Kubernetes trực tiếp, nhiều khả năng bạn đang dùng một nền tảng xây trên những ý tưởng này—hoặc đang vật lộn với cùng vấn đề.
Trước Kubernetes, “chạy container” thường nghĩa là chạy vài container. Các nhóm ghép các bash script, cron job, golden image và vài công cụ tạm thời để deploy. Khi có sự cố, cách sửa thường nằm trong đầu ai đó—hoặc trong một README không ai tin tưởng. Vận hành là chuỗi các can thiệp một lần: khởi lại process, đổi cấu hình load balancer, dọn disk, và đoán máy nào an toàn để chạm vào.
Container làm việc đóng gói dễ hơn, nhưng không xóa đi phần lộn xộn của production. Ở quy mô, hệ thống thất bại theo nhiều cách hơn và thường xuyên hơn: node biến mất, mạng phân đoạn, image triển khai không đồng đều, và workload lệch so với những gì bạn nghĩ đang chạy. Một deploy “đơn giản” có thể biến thành một chuỗi sự cố—một số instance được cập nhật, một số không, một vài bị kẹt, một vài khỏe nhưng không truy cập được.
Vấn đề thực sự không phải là khởi chạy container. Mà là giữ đúng container chạy, ở đúng hình dạng, bất chấp sự đổi thay liên tục.
Các nhóm cũng đang xoay giữa nhiều môi trường: phần cứng on‑prem, VM, nhà cung cấp cloud sơ khai, và các thiết lập mạng/lưu trữ khác nhau. Mỗi nền tảng có ngôn ngữ và kiểu lỗi riêng. Thiếu một mô hình chung, mỗi lần di chuyển lại phải viết lại công cụ vận hành và đào tạo lại người.
Kubernetes hướng tới cung cấp một cách duy nhất, nhất quán để mô tả ứng dụng và nhu cầu vận hành, bất kể máy nằm ở đâu.
Developer muốn self‑service: deploy không cần ticket, scale không cần xin tài nguyên, rollback không kịch tính. Ops muốn tính dự đoán: health check chuẩn, deploy lặp lại được, và một nguồn chân lý rõ ràng về những gì nên chạy.
Kubernetes không cố gắng làm một scheduler hoa mỹ. Nó muốn là nền tảng cho một hệ ứng dụng đáng tin cậy—biến thực tế lộn xộn thành một hệ thống bạn có thể lý giải.
Một trong những lựa chọn ảnh hưởng nhất là làm cho Kubernetes khai báo: bạn mô tả những gì bạn muốn, và hệ thống làm cho thực tế khớp với mô tả đó.
Bộ điều nhiệt là ví dụ hàng ngày hữu ích. Bạn không bật tắt máy sưởi liên tục. Bạn đặt nhiệt độ mong muốn—ví dụ 21°C—và bộ điều nhiệt liên tục kiểm tra phòng và điều chỉnh máy sưởi để giữ gần mục tiêu đó.
Kubernetes cũng vậy. Thay vì nói với cluster từng bước “khởi chạy container này trên máy kia, rồi khởi động lại khi nó fail,” bạn khai báo kết quả: “Tôi muốn 3 bản sao của app này chạy.” Kubernetes liên tục kiểm tra những gì thực sự chạy và chỉnh sửa sai lệch.
Cấu hình khai báo làm giảm danh sách các bước vận hành ẩn thường nằm trong đầu ai đó hoặc trong runbook cũ nửa vời. Bạn áp dụng cấu hình, và Kubernetes xử lý cơ học—đặt chỗ, khởi động lại, và hòa giải thay đổi.
Nó cũng làm cho việc xem xét thay đổi dễ hơn. Một thay đổi hiển thị dưới dạng diff trong cấu hình, không phải một loạt lệnh ad‑hoc.
Bởi vì trạng thái mong muốn được viết ra, bạn có thể tái sử dụng cách tiếp cận trong dev, staging và production. Môi trường có thể khác, nhưng ý định giữ nhất quán, khiến việc deploy dự đoán được và dễ kiểm toán.
Hệ thống khai báo có đường cong học tập: bạn phải nghĩ theo “cái gì nên đúng” thay vì “tiếp theo tôi làm gì.” Chúng cũng phụ thuộc nhiều vào mặc định tốt và quy ước rõ—nếu không, các nhóm có thể tạo ra cấu hình kỹ thuật đúng nhưng khó hiểu và bảo trì.
Kubernetes không thành công vì chỉ chạy container một lần—mà vì nó giữ chúng chạy đúng theo thời gian. Bước thiết kế lớn là biến “control loops” (controllers) thành động cơ lõi của hệ thống.
Một controller là vòng lặp đơn giản:
Nó giống autopilot hơn là một nhiệm vụ một lần. Bạn không “trông nom” workload; bạn khai báo ý định, và controllers lái cluster trở lại kết quả đó.
Mẫu này là lý do Kubernetes bền bỉ khi mọi thứ đời thực gặp sự cố:
Thay vì coi lỗi là trường hợp đặc biệt, controllers coi đó là “mismatch trạng thái” và sửa theo cùng một cách mỗi lần.
Script tự động truyền thống thường giả định môi trường ổn định: thực thi bước A rồi B rồi C. Trong hệ phân tán, giả định đó thường vỡ. Controllers scale tốt hơn vì chúng idempotent (an toàn chạy lặp lại) và eventually consistent (liên tục cố cho đến khi đạt mục tiêu).
Nếu bạn dùng Deployment, bạn đã dựa vào control loops. Ở dưới, Kubernetes dùng controller ReplicaSet để đảm bảo số pod theo yêu cầu tồn tại—và một controller Deployment để quản lý rolling update và rollback có thể dự đoán được.
Kubernetes có thể chỉ lên lịch “container thôi”, nhưng đội của Joe Beda đã giới thiệu Pods để biểu diễn đơn vị deploy nhỏ nhất mà cluster đặt trên một máy. Ý chính: nhiều ứng dụng thực sự không chỉ là một tiến trình đơn. Chúng là một nhóm nhỏ các tiến trình gắn chặt cần sống cùng nhau.
Pod là một bọc quanh một hoặc nhiều container cùng chia sẻ số phận: chúng khởi động cùng nhau, chạy trên cùng một node, và scale cùng nhau. Điều này làm cho các mẫu như sidecars trở nên tự nhiên—ví dụ log shipper, proxy, config reloader hay agent bảo mật luôn song hành với app chính.
Thay vì dạy mọi app tích hợp các trợ thủ đó, Kubernetes cho phép bạn đóng gói chúng như các container riêng nhưng vẫn hành xử như một đơn vị.
Pods làm hai giả định quan trọng trở nên thực tế:
localhost, đơn giản và nhanh.Những lựa chọn này giảm nhu cầu code glue tùy biến, trong khi vẫn giữ container biệt lập ở mức tiến trình.
Người mới thường nghĩ “một container = một app”, rồi bị vấp bởi khái niệm ở mức Pod: restart, IP và scale. Nhiều nền tảng làm mượt điều này bằng cách cung cấp template có quan điểm sẵn (ví dụ “web service”, “worker”, hoặc “job”) tạo Pod phía sau—nhờ đó các nhóm hưởng lợi từ sidecars và tài nguyên chia sẻ mà không phải nghĩ về cơ chế Pod hàng ngày.
Một lựa chọn sớm nhưng mạnh mẽ là coi labels như metadata hạng nhất và selectors là cách chính để “tìm” các thứ. Thay vì gắn quan hệ cứng (như “ba máy này chạy app của tôi”), Kubernetes khuyến khích mô tả nhóm bằng thuộc tính chung.
Label là cặp key/value đơn giản bạn gắn cho tài nguyên—Pods, Deployments, Nodes, Namespaces, và hơn thế nữa. Chúng hoạt như những “tag” nhẹ và có thể truy vấn:
app=checkoutenv=prodtier=frontendBởi vì labels nhẹ và do người dùng định nghĩa, bạn có thể mô hình hóa thực tế tổ chức: team, trung tâm chi phí, vùng tuân thủ, kênh phát hành, hoặc bất cứ gì quan trọng cho vận hành.
Selectors là truy vấn trên labels (ví dụ “tất cả Pods nơi app=checkout và env=prod”). Điều này tốt hơn danh sách host cố định vì hệ thống tự thích nghi khi Pods được reschedule, scale lên/xuống, hoặc thay thế trong rollout. Cấu hình của bạn giữ ổn định ngay cả khi các instance bên dưới thay đổi liên tục.
Thiết kế này giúp vận hành ở quy mô: bạn không quản lý hàng nghìn danh tính instance—bạn quản lý vài bộ label có ý nghĩa. Đó là tinh thần của loose coupling: các thành phần kết nối tới nhóm có thể thay đổi thành viên một cách an toàn.
Khi labels tồn tại, chúng trở thành ngôn ngữ chung trên nền tảng. Chúng dùng cho định tuyến lưu lượng (Services), ranh giới chính sách (NetworkPolicy), lọc observability (metrics/logs), và thậm chí theo dõi chi phí. Một ý tưởng đơn giản—gắn tag nhất quán—mở ra cả hệ sinh thái tự động hóa.
Kubernetes cần một cách để làm cho mạng trở nên dự đoán được mặc dù các container thay đổi liên tục. Pods bị thay thế, reschedule, và scale—vì vậy IP và máy cụ thể sẽ thay đổi. Ý tưởng lõi của Service là đơn giản: cung cấp “cửa trước” ổn định cho một tập Pods dịch chuyển.
Service cung cấp một IP ảo và tên DNS ổn định (như payments). Đằng sau tên đó, Kubernetes liên tục theo dõi Pods nào khớp selector của Service và định tuyến lưu lượng tương ứng. Nếu một Pod chết và một Pod mới xuất hiện, Service vẫn trỏ đúng mà không cần bạn chạm vào cấu hình ứng dụng.
Cách tiếp cận này loại bỏ nhiều nối dây thủ công. Thay vì gắn IP vào file config, ứng dụng có thể dựa vào tên. Bạn deploy app, deploy Service, và các thành phần khác tìm nó qua DNS—không cần registry custom, không endpoint hard‑code.
Service cũng đưa hành vi cân bằng tải mặc định giữa các endpoint khỏe mạnh. Điều đó nghĩa là các nhóm không cần tự xây (hoặc dựng lại) load balancer cho mỗi microservice nội bộ. Phân phối lưu lượng giảm bán kính thiệt hại khi một Pod lỗi và làm cho rolling update ít rủi ro hơn.
Service tốt cho tầng L4 (TCP/UDP), nhưng không mô hình hóa quy tắc HTTP, TLS termination, hay chính sách edge. Đó là nơi Ingress và ngày càng nhiều Gateway API xuất hiện: chúng dựa trên Services để xử lý hostname, path và điểm vào ngoài tinh tế hơn.
Một trong những lựa chọn sớm lặng lẽ nhưng mang tính cách mạng là coi Kubernetes như một API để xây dựng lên—không phải một công cụ đơn khối để “dùng”. Tư duy API‑first khiến Kubernetes giống nền tảng mà bạn có thể mở rộng, script và quản lý.
Khi API là bề mặt, các đội nền tảng có thể chuẩn hóa cách mô tả và quản lý ứng dụng, bất kể UI, pipeline hay portal nội bộ nào đứng trên. “Deploy một app” trở thành “submit và cập nhật các đối tượng API” (như Deployments, Services, ConfigMaps), điều này là một hợp đồng sạch giữa đội app và nền tảng.
Vì mọi thứ đi qua cùng một API, công cụ mới không cần backdoor đặc quyền. Dashboard, GitOps controllers, engine policy và hệ thống CI/CD đều có thể hoạt động như client API bình thường với quyền giới hạn.
Sự đối xứng này quan trọng: cùng luật, auth, audit và admission control áp dụng cho mọi yêu cầu dù đến từ người, script hay UI nền tảng.
Versioning API cho phép Kubernetes tiến hóa mà không phá mọi cluster hoặc mọi công cụ ngay lập tức. Có thể dàn trải deprecation; tương thích có thể kiểm thử; upgrade có thể lên kế hoạch. Với tổ chức chạy cluster nhiều năm, đó là khác biệt giữa “chúng ta có thể nâng cấp” và “chúng ta kẹt.”
kubectl thực sự đại diện cho gìkubectl không phải là Kubernetes—nó là một client. Mô hình tư duy này đẩy các đội nghĩ theo workflow API: bạn có thể thay kubectl bằng automation, web UI hoặc portal tùy chỉnh, và hệ thống vẫn nhất quán vì hợp đồng là API.
Kubernetes cần một “nguồn sự thật” duy nhất cho trạng thái hiện tại của cluster: Pod nào tồn tại, node nào khỏe, Service trỏ tới đâu, và những đối tượng nào đang được cập nhật. Đó là vai trò của etcd.
etcd là cơ sở dữ liệu cho control plane. Khi bạn tạo Deployment, scale ReplicaSet, hay cập nhật Service, cấu hình mong muốn được ghi vào etcd. Controllers và các thành phần control‑plane khác theo dõi trạng thái lưu trữ đó và làm cho thực tế khớp.
Cluster Kubernetes đầy các phần di chuyển: scheduler, controllers, kubelet, autoscaler và admission checks đều có thể phản ứng đồng thời. Nếu họ đọc các phiên bản “sự thật” khác nhau, bạn sẽ gặp race—như hai thành phần đưa ra quyết định mâu thuẫn về cùng một Pod.
Tính nhất quán mạnh của etcd đảm bảo rằng khi control plane nói “đây là trạng thái hiện tại,” mọi người đều cùng đồng bộ. Sự đồng bộ đó khiến các control loops dự đoán được thay vì rối loạn.
Vì etcd giữ cấu hình và lịch sử thay đổi của cluster, nó cũng là thứ bạn bảo vệ khi:
Đối xử trạng thái control‑plane như dữ liệu quan trọng. Chụp etcd snapshots định kỳ, thử phục hồi, và lưu backup ra ngoài cluster. Nếu dùng managed Kubernetes, tìm hiểu cái nhà cung cấp sao lưu—và phần bạn vẫn phải tự sao lưu (ví dụ persistent volumes và dữ liệu ứng dụng).
Kubernetes không xem “workload chạy ở đâu” là chuyện phụ. Ngay từ đầu, scheduler là một thành phần riêng với nhiệm vụ rõ ràng: khớp Pods với node có khả năng chạy chúng, dựa trên trạng thái cluster hiện tại và yêu cầu của Pod.
Ở mức cao, lập lịch gồm hai bước:
Cấu trúc này cho phép phát triển scheduling mà không cần viết lại mọi thứ.
Một lựa chọn thiết kế then chốt là giữ trách nhiệm rõ ràng:
Vì các trách nhiệm tách biệt, cải tiến ở lĩnh vực này (ví dụ plugin CNI mới) không buộc phải đổi mô hình scheduling.
Nhận biết tài nguyên bắt đầu với requests và limits, cung cấp tín hiệu thực cho scheduler thay vì đoán mò. Từ đó, Kubernetes bổ sung các điều khiển phong phú hơn—node affinity/anti-affinity, pod affinity, priorities và preemption, taints and tolerations, và phân phối theo topology—đều xây trên nền tảng đó.
Cách tiếp cận này cho phép cluster chia sẻ ngày nay: các đội có thể cô lập dịch vụ quan trọng bằng priorities và taints, trong khi mọi người đều hưởng lợi từ tận dụng cao hơn. Với bin‑packing và control topology tốt hơn, nền tảng có thể đặt workload hiệu quả về chi phí mà không hy sinh độ tin cậy.
Kubernetes có thể đã ra với trải nghiệm PaaS đầy đủ—buildpacks, quy tắc định tuyến app, công việc nền, quy ước config và hơn thế. Thay vào đó, Joe Beda và đội sớm giữ lõi tập trung vào lời hứa nhỏ hơn: chạy và phục hồi workload đáng tin cậy, expose chúng và cung cấp API nhất quán để tự động hóa.
Một “PaaS hoàn chỉnh” sẽ ép một workflow và tập đánh đổi duy nhất lên mọi người. Kubernetes nhắm tới một nền tảng cơ sở rộng hơn có thể hỗ trợ nhiều phong cách nền tảng—từ Heroku‑like đơn giản cho developer, quản trị doanh nghiệp, pipeline batch + ML, đến điều khiển hạ tầng cơ bản—mà không khóa chặt triết lý sản phẩm.
Cơ chế mở rộng của Kubernetes tạo ra cách có kiểm soát để phát triển khả năng:
Certificate hoặc Database) trông như bản địa.Điều này nghĩa là đội nội bộ và vendor có thể đóng gói tính năng như add‑on, vẫn dùng primitives Kubernetes như RBAC, namespaces và audit logs.
Với vendor, nó cho phép sản phẩm phân hóa mà không fork Kubernetes. Với nội bộ, nó cho phép “nền tảng trên Kubernetes” phù hợp tổ chức.
Đánh đổi là sự bành trướng hệ sinh thái: quá nhiều CRDs, công cụ chồng chéo, và quy ước không nhất quán. Quản trị—tiêu chuẩn, ownership, versioning và quy tắc deprecation—trở thành phần công việc của nền tảng.
Các lựa chọn sớm của Kubernetes không chỉ tạo ra một scheduler container—mà tạo ra một nhân nền tảng có thể tái sử dụng. Đó là lý do nhiều nền tảng developer nội bộ (IDP) ngày nay cơ bản là “Kubernetes cộng với workflow có quan điểm”. Mô hình khai báo, controllers và API nhất quán cho phép xây các sản phẩm cao hơn—mà không phải tái phát minh việc deploy, reconcile và service discovery mỗi lần.
Vì API là bề mặt sản phẩm, vendor và đội nền tảng có thể chuẩn hóa trên một control plane và xây trải nghiệm khác nhau trên đó: GitOps, quản lý multi‑cluster, policy, service catalog và tự động deploy. Đây là lý do lớn khiến Kubernetes trở thành mẫu số chung cho nền tảng cloud native: tích hợp nhắm vào API, không phải một UI cụ thể.
Dù có trừu tượng, công việc khó nhất vẫn là vận hành:
Hỏi những câu làm sáng tỏ mức độ trưởng thành vận hành:
Một nền tảng tốt giảm tải nhận thức mà không che mờ control plane hoặc làm cho đường thoát trở nên khó chịu.
Một lăng kính thực tế: nền tảng có giúp đội chuyển từ “ý tưởng → dịch vụ chạy được” mà không bắt mọi người phải thành chuyên gia Kubernetes ngay ngày đầu không? Các công cụ trong nhóm “vibe‑coding”—như Koder.ai—đi theo hướng này bằng cách cho phép tạo ứng dụng thật từ chat (web React, backend Go với PostgreSQL, mobile Flutter) rồi lặp nhanh với các tính năng như planning mode, snapshots và rollback. Dù bạn dùng thứ tương tự hay tự xây cổng riêng, mục tiêu giống nhau: giữ các primitive mạnh của Kubernetes trong khi giảm overhead workflow xung quanh chúng.
Kubernetes có thể trông phức tạp, nhưng hầu hết “kỳ quặc” của nó là có chủ đích: đó là tập các nguyên thủy nhỏ thiết kế để ghép vào nhiều loại nền tảng.
Thứ nhất: “Kubernetes chỉ là điều phối Docker.” Kubernetes không chủ yếu về khởi chạy container. Nó là liên tục hòa giải trạng thái mong muốn (cái bạn muốn chạy) với trạng thái thực (cái thực sự đang xảy ra), qua lỗi, rollout và thay đổi nhu cầu.
Thứ hai: “Dùng Kubernetes là bắt buộc phải microservices.” Kubernetes hỗ trợ microservices, nhưng cũng hỗ trợ monolith, job batch và nền tảng nội bộ. Các đơn vị (Pods, Services, labels, controllers, API) là trung lập; kiến trúc là lựa chọn của bạn.
Phần khó thường không phải YAML hay Pods—mà là mạng, bảo mật và sử dụng đa đội: định danh và truy cập, quản lý secrets, policy, ingress, observability, kiểm soát chuỗi cung ứng, và tạo guardrail để các đội có thể ship an toàn mà không vướng chân nhau.
Khi lập kế hoạch, nghĩ theo các cược thiết kế ban đầu:
Map yêu cầu thực tế của bạn tới các primitive Kubernetes và lớp nền tảng:
Workloads → Pods/Deployments/Jobs
Kết nối → Services/Ingress
Vận hành → controllers, policy và observability
Nếu bạn đánh giá hoặc chuẩn hóa, viết bản đồ này ra và thảo luận với các bên liên quan—rồi xây nền tảng tăng dần quanh các khoảng trống, không phải theo xu hướng.
Nếu bạn cũng muốn đẩy nhanh phần “xây” (không chỉ “chạy”), cân nhắc cách workflow delivery chuyển ý định thành dịch vụ có thể deploy. Với một số đội đó là tập template được quản lý; với đội khác là workflow hỗ trợ AI như Koder.ai, có thể tạo dịch vụ ban đầu nhanh rồi xuất mã nguồn để tùy chỉnh sâu hơn—trong khi nền tảng vẫn hưởng lợi từ các quyết định thiết kế lõi của Kubernetes bên dưới.
Điều phối container là phần tự động hóa giúp ứng dụng tiếp tục chạy khi máy chủ hỏng, lưu lượng thay đổi và khi triển khai. Thực tế nó xử lý:
Kubernetes đã phổ biến một mô hình nhất quán để làm việc này trên nhiều môi trường hạ tầng khác nhau.
Vấn đề chính không phải là khởi động container—mà là giữ những container đúng chạy ở đúng trạng thái bất chấp sự thay đổi liên tục. Ở quy mô lớn, hệ thống gặp các lỗi thường xuyên và có xu hướng lệch nhau:
Kubernetes đặt mục tiêu làm cho thao tác vận hành lặp lại được và dự đoán được bằng cách cung cấp một control plane và ngôn ngữ chung.
Trong hệ thống khai báo, bạn mô tả kết quả bạn muốn (ví dụ “chạy 3 bản sao”), và hệ thống liên tục làm cho thực tế khớp với mô tả đó.
Quy trình thực tế:
kubectl apply hoặc GitOps)Điều này giảm các "runbook ẩn" và khiến thay đổi có thể xem xét dưới dạng diff thay vì hàng loạt lệnh rời rạc.
Controller là các vòng lặp điều khiển lặp lại:
Thiết kế này biến các lỗi thường gặp thành việc xử lý theo quy trình thay vì logic xử lý từng trường hợp. Ví dụ, nếu một Pod crash hoặc node biến mất, controller tương ứng chỉ cần nhận thấy “số bản sao ít hơn mong muốn” và tạo bản thay thế.
Kubernetes lên lịch Pods (không phải từng container riêng lẻ) vì nhiều workload thực tế cần các tiến trình trợ giúp chạy chặt với nhau.
Pods cho phép các mẫu như:
localhost)Quy tắc thực hành: giữ Pods nhỏ và có tính kết hợp—chỉ gom các container phải chia sẻ lifecycle, danh tính mạng hoặc dữ liệu cục bộ.
Labels là nhãn nhẹ dạng key/value (ví dụ app=checkout, env=prod). Selectors là các truy vấn trên những label đó để tạo nhóm động.
Điều này quan trọng vì các instance rất nhất thời: Pods tới rồi đi trong quá trình reschedule và rollout. Với labels/selectors, các mối quan hệ ổn định (“tất cả Pods có những label này”) ngay cả khi thành phần thay đổi.
Mẹo vận hành: chuẩn hóa một taxonomy label nhỏ (app, team, env, tier) và ép buộc nó bằng chính sách để tránh hỗn loạn sau này.
Service cung cấp một IP ảo và tên DNS ổn định chuyển tiếp tới một tập Pods thay đổi theo selector.
Dùng Service khi:
Với routing HTTP, TLS termination và quy tắc edge, thường xếp thêm Ingress hoặc Gateway API lên trên Services.
Kubernetes coi API là bề mặt sản phẩm chính: mọi thứ là đối tượng API (Deployments, Services, ConfigMaps...). Công cụ như kubectl, CI/CD, GitOps, dashboard đều là client gọi API.
Lợi ích thực tế:
Nếu bạn xây nền tảng nội bộ, thiết kế workflow quanh các hợp đồng API, không phải quanh một giao diện cụ thể.
etcd là cơ sở dữ liệu cho control plane và là nguồn sự thật cho cluster: khi bạn tạo Deployment, scale ReplicaSet hay cập nhật Service, cấu hình mong muốn được ghi vào etcd. Controllers và thành phần control plane khác theo dõi trạng thái này và làm cho thực tế khớp với nó.
Hướng dẫn thực tế:
Trong managed Kubernetes, tìm hiểu nhà cung cấp sao lưu gì—và phần nào bạn vẫn phải sao lưu riêng (ví dụ persistent volumes và dữ liệu ứng dụng).
Kubernetes giữ lõi nhỏ và cho phép bổ sung tính năng qua mở rộng:
Điều này cho phép “nền tảng trên Kubernetes”, nhưng có thể dẫn tới nhiều công cụ chồng chéo. Để đánh giá một nền tảng dựa trên Kubernetes, hỏi: