Container là một gói phần mềm chứa ứng dụng cùng toàn bộ thư viện và cấu hình nó cần, chạy trong một không gian cách ly trên nhân hệ điều hành dùng chung, nhờ đó chạy giống hệt nhau trên máy lập trình viên, máy thử nghiệm và máy chủ sản xuất. Kubernetes là hệ thống điều phối: nó quyết định container nào chạy trên máy nào, khởi động lại khi hỏng, tăng giảm số bản sao theo tải và cập nhật phiên bản mới mà không ngừng dịch vụ.
Hình ảnh container vận tải biển là phép so sánh được dùng nhiều nhất và khá đúng: trước khi có thùng chuẩn, mỗi loại hàng cần cách bốc xếp riêng; sau khi có thùng chuẩn, cần cẩu, tàu và xe tải chỉ cần biết xử lý một thứ. Container phần mềm làm điều tương tự cho ứng dụng: hạ tầng không cần biết bên trong là Java, Python hay PHP.
Bài này viết cho người ra quyết định hơn là người cài đặt: cơ chế ở mức đủ để hiểu đánh đổi, nguồn gốc, các khái niệm cốt lõi của Kubernetes, và quan trọng nhất là khi nào doanh nghiệp thật sự cần nó.
Cơ chế: container khác máy ảo ở đâu
Máy ảo mô phỏng cả một máy tính, nên mỗi máy ảo mang theo một hệ điều hành đầy đủ, nặng vài gigabyte và khởi động mất cỡ phút. Container không mô phỏng phần cứng; nó dùng chung nhân hệ điều hành của máy chủ và chỉ cách ly ở mức tiến trình. Trên Linux, sự cách ly này dựa vào hai cơ chế của nhân: namespaces cho mỗi container một cái nhìn riêng về tiến trình, mạng, hệ thống tệp, tên máy; và cgroups giới hạn lượng CPU, bộ nhớ, vào ra mà mỗi nhóm tiến trình được dùng.
Hệ quả thực tế là container nhẹ: ảnh container thường chỉ vài chục đến vài trăm megabyte, khởi động trong vài giây hoặc nhanh hơn, và một máy chủ chạy được nhiều container hơn nhiều so với máy ảo. Ảnh container lại bất biến và được đánh phiên bản: bản đã chạy thử là đúng bản sẽ chạy thật, chấm dứt phần lớn câu chuyện "trên máy em chạy được mà".
Đánh đổi nằm ở mức cách ly. Vì dùng chung nhân, một lỗ hổng trong nhân có thể ảnh hưởng mọi container trên máy. Vì vậy trên đám mây công cộng, container của các khách hàng khác nhau thường vẫn được đặt trong các máy ảo riêng, hoặc dùng các dạng máy ảo siêu nhẹ chuyên cho container. Container và máy ảo không thay thế nhau mà thường xếp chồng lên nhau.
Nguồn gốc: từ chroot đến Kubernetes
Container không phải phát minh của thập niên 2010; thứ mới là cách đóng gói và công cụ giúp nó trở nên dễ dùng.
- 1979: lệnh chroot trên Unix cho phép một tiến trình coi một thư mục con là gốc của hệ thống tệp, dạng cách ly sơ khai nhất.
- Năm 2000: FreeBSD Jails mở rộng ý tưởng thành các "nhà tù" cách ly cả tiến trình và mạng; các hệ thống Unix thương mại có tính năng tương tự trong những năm sau đó.
- Giữa thập niên 2000: các kỹ sư Google phát triển cơ chế giới hạn tài nguyên cho nhóm tiến trình, về sau được đưa vào nhân Linux dưới tên cgroups; cùng với namespaces, đây là nền cho container trên Linux.
- 2013: Docker ra đời, đưa ra định dạng ảnh và công cụ dòng lệnh đơn giản, biến container từ kỹ thuật của chuyên gia thành công cụ hằng ngày của lập trình viên.
- 2014–2015: Google công bố mã nguồn Kubernetes, dựa trên kinh nghiệm vận hành hệ thống điều phối nội bộ Borg (được mô tả trong một bài báo năm 2015). Kubernetes được trao cho tổ chức trung lập Cloud Native Computing Foundation; cùng thời gian, Open Container Initiative ra đời để chuẩn hoá định dạng ảnh và môi trường chạy.
- Những năm sau: mọi nhà cung cấp đám mây lớn đều có dịch vụ Kubernetes quản lý, và Kubernetes trở thành lớp chung phổ biến nhất để chạy ứng dụng container.
Các khái niệm cốt lõi của Kubernetes, giải thích không cần dòng lệnh
Cụm, nút và mặt phẳng điều khiển. Một cụm Kubernetes gồm nhiều máy (nút) chạy container, và một mặt phẳng điều khiển ra quyết định cho cả cụm. Trên dịch vụ quản lý, nhà cung cấp vận hành mặt phẳng điều khiển; bạn chỉ lo các nút và ứng dụng.
Pod. Đơn vị nhỏ nhất Kubernetes quản lý, gồm một hoặc vài container luôn chạy cùng nhau, chung địa chỉ mạng. Pod được coi là dùng xong bỏ: hỏng thì thay pod mới, không sửa pod cũ.
Khai báo trạng thái mong muốn. Đây là ý tưởng trung tâm. Bạn không ra lệnh "chạy thêm hai container", mà khai báo "ứng dụng này cần năm bản sao, phiên bản 3.2". Các bộ điều khiển liên tục so trạng thái thực với trạng thái khai báo và tự sửa chênh lệch: một nút chết thì pod được tạo lại ở nút khác, mà không ai phải can thiệp.
Service và Ingress. Pod sinh ra rồi mất liên tục nên địa chỉ thay đổi. Service cho một nhóm pod một địa chỉ ổn định và chia tải giữa chúng; Ingress đưa lưu lượng từ Internet vào đúng service theo tên miền và đường dẫn.
Cập nhật cuốn chiếu và tự co giãn. Phiên bản mới được thay dần từng pod, kiểm tra sức khoẻ trước khi tiếp tục, có thể quay lui nếu lỗi. Bộ tự co giãn tăng số pod khi CPU hay số yêu cầu tăng, và có thể thêm nút khi cụm hết chỗ.
Khi nào cần Kubernetes, khi nào thừa
Kubernetes giải quyết bài toán vận hành nhiều dịch vụ, nhiều đội, tải thay đổi. Với bài toán nhỏ, nó thêm độ phức tạp nhiều hơn giá trị. Bảng dưới gợi ý cách đối chiếu.
| Tình huống | Gợi ý | Lý do |
|---|---|---|
| Một ứng dụng web, một cơ sở dữ liệu, đội 2–5 người | Thường chưa cần; dùng máy ảo, nền tảng chạy ứng dụng quản lý hoặc container đơn giản | Chi phí học và vận hành Kubernetes lớn hơn lợi ích |
| Hàng chục dịch vụ nhỏ, nhiều đội phát hành độc lập | Hợp | Cần một cách triển khai, giám sát, co giãn thống nhất |
| Tải biến động lớn theo giờ hoặc mùa | Hợp nếu ứng dụng không giữ trạng thái | Tự co giãn pod và nút tiết kiệm chi phí |
| Muốn chạy được trên nhiều đám mây hoặc tại chỗ | Hợp ở lớp ứng dụng | Cấu hình triển khai di chuyển được, dù dịch vụ xung quanh thì không |
| Phần mềm đóng gói của bên thứ ba chỉ hỗ trợ cài trên máy chủ | Không nên ép | Rủi ro mất hỗ trợ từ nhà cung cấp phần mềm |
| Cơ sở dữ liệu chính của hệ thống | Cân nhắc kỹ, thường dùng dịch vụ quản lý | Dữ liệu có trạng thái làm vận hành trên Kubernetes khó hơn nhiều |
Một dấu hiệu dùng Kubernetes quá sớm là đội ngũ dành nhiều thời gian sửa cụm hơn phát triển sản phẩm. Dấu hiệu ngược lại, cần Kubernetes mà chưa có, là mỗi dịch vụ được triển khai theo một cách riêng, không ai nắm hết, và mỗi lần phát hành là một buổi tối thức khuya.
Chi phí thật của Kubernetes
Phần mềm Kubernetes miễn phí, nhưng vận hành nó thì không. Chi phí lớn nhất là con người: một cụm chạy sản xuất cần người hiểu mạng trong cụm, lưu trữ, phân quyền, nâng cấp phiên bản theo chu kỳ phát hành khá dày, giám sát và xử lý sự cố. Hệ sinh thái xung quanh như quản lý gói triển khai, lưới dịch vụ, công cụ quan sát, chính sách bảo mật lại thêm nhiều thứ phải học. Doanh nghiệp vừa ở Việt Nam thường gặp khó ở chỗ thị trường lao động có ít kỹ sư vận hành Kubernetes nhiều kinh nghiệm.
Chi phí thứ hai là hạ tầng nhàn rỗi. Cụm cần dư chỗ để chứa pod khi co giãn và khi cập nhật cuốn chiếu; các pod thường được khai báo yêu cầu tài nguyên cao hơn mức dùng thật cho an toàn. Không quản lý, tỷ lệ sử dụng thực của cụm có thể thấp, và việc phân bổ chi phí cụm cho từng đội cũng phức tạp hơn so với máy ảo gắn thẻ.
Chi phí thứ ba là độ phức tạp khi gỡ lỗi: một yêu cầu đi qua ingress, service, nhiều pod, có thể qua lưới dịch vụ, nên tìm nguyên nhân chậm hay lỗi cần công cụ theo dõi phân tán. Dịch vụ Kubernetes quản lý của nhà cung cấp gỡ bớt gánh nặng mặt phẳng điều khiển, còn các nền tảng chạy container không cần quản lý cụm là lựa chọn ở giữa cho đội nhỏ muốn lợi ích của container mà không vận hành Kubernetes.
Ví dụ giả định: một công ty phần mềm bán lẻ ở Đà Nẵng có tám dịch vụ, đội vận hành hai người. Chuyển sang Kubernetes tự dựng, đội mất gần một quý chỉ để ổn định cụm, nâng cấp phiên bản và học công cụ giám sát, trong khi tần suất phát hành chưa tăng. Nếu dùng nền tảng chạy container quản lý cho tám dịch vụ đó, phần lớn lợi ích về môi trường nhất quán và tự co giãn vẫn đạt được với một phần nhỏ công sức. Phép so sánh này nên được làm trên giấy trước khi chọn.
Lộ trình áp dụng hợp lý cho doanh nghiệp vừa
Container và Kubernetes là hai bước khác nhau. Nhiều lợi ích nằm ở bước một, và bước hai chỉ nên làm khi bước một đã ổn.
- Đóng gói ứng dụng thành container và chạy chúng bằng công cụ đơn giản trên máy ảo hoặc nền tảng chạy container quản lý. Riêng bước này đã đem lại môi trường nhất quán và phát hành nhanh hơn.
- Xây quy trình tích hợp và triển khai liên tục: mỗi lần thay đổi mã tự tạo ảnh mới, quét lỗ hổng, chạy kiểm thử, đẩy lên kho ảnh có đánh phiên bản.
- Tách cấu hình và bí mật khỏi ảnh, ghi nhật ký ra đầu ra chuẩn, để ứng dụng không giữ trạng thái trên đĩa cục bộ. Đây là điều kiện để điều phối hoạt động tốt.
- Chỉ khi số dịch vụ và số đội tăng, cân nhắc Kubernetes quản lý, bắt đầu bằng các dịch vụ không trạng thái, giữ cơ sở dữ liệu trên dịch vụ quản lý.
- Dựng nền tảng nội bộ với mẫu triển khai chuẩn, để các đội sản phẩm không phải tự học mọi chi tiết của Kubernetes.
Câu hỏi thường gặp
Docker và Kubernetes khác nhau thế nào?
Docker chủ yếu là công cụ tạo và chạy container trên một máy. Kubernetes điều phối container trên nhiều máy: lập lịch, tự sửa, co giãn, cập nhật. Kubernetes chạy được ảnh container tạo bằng Docker vì cả hai tuân theo chuẩn ảnh chung của Open Container Initiative.
Microservices có bắt buộc phải dùng Kubernetes không?
Không bắt buộc. Microservices là cách chia ứng dụng thành dịch vụ nhỏ; Kubernetes chỉ là một cách phổ biến để vận hành chúng. Ngược lại, một ứng dụng khối lớn vẫn có thể chạy trên Kubernetes, dù khi đó lợi ích ít hơn.
Container có an toàn không?
An toàn ở mức đủ cho đa số ứng dụng nếu cấu hình đúng: không chạy với quyền quản trị, dùng ảnh nền tối giản và được cập nhật, quét lỗ hổng, giới hạn quyền mạng. Do dùng chung nhân, mức cách ly thấp hơn máy ảo, nên các khối lượng của những bên không tin nhau thường được tách bằng máy ảo.
Chạy cơ sở dữ liệu trong Kubernetes có nên không?
Được, và có công cụ hỗ trợ, nhưng đòi hỏi hiểu sâu lưu trữ, sao lưu, khôi phục trong môi trường pod có thể bị di chuyển. Với đội chưa nhiều kinh nghiệm, dùng dịch vụ cơ sở dữ liệu quản lý bên ngoài cụm thường an toàn hơn.
Cloud native nghĩa là gì?
Đó là cách xây ứng dụng tận dụng đặc tính của đám mây: đóng gói container, chia dịch vụ nhỏ, khai báo hạ tầng, tự động co giãn và chịu lỗi. Tổ chức Cloud Native Computing Foundation dùng thuật ngữ này cho cả hệ sinh thái công cụ quanh Kubernetes.