Khi tạo cụm Kubernetes, các câu hỏi có thể nảy sinh: cần cấu hình bao nhiêu nút công nhân và loại nút nào? Điều gì tốt hơn cho cụm tại chỗ: mua một số máy chủ mạnh mẽ hoặc sử dụng hàng tá máy cũ trong trung tâm dữ liệu của bạn? Sẽ tốt hơn nếu sử dụng XNUMX phiên bản lõi đơn hoặc XNUMX phiên bản lõi tứ trên đám mây?
Câu trả lời cho những câu hỏi này có trong bài viết. trong bản dịch của lệnh .
Công suất cụm
Nói chung, cụm Kubernetes có thể được coi là một "siêu nút" lớn. Tổng sức mạnh tính toán của nó là tổng sức mạnh của tất cả các nút cấu thành của nó.
Có một số cách để đạt được mục tiêu dung lượng cụm mong muốn của bạn. Ví dụ: chúng ta cần một cụm có tổng công suất 8 lõi xử lý và 32 GB RAM vì một bộ ứng dụng yêu cầu rất nhiều tài nguyên. Sau đó, bạn có thể cài đặt hai nút có bộ nhớ 16 GB hoặc bốn nút có bộ nhớ 8 GB, hai bộ xử lý lõi tứ hoặc bốn nút lõi kép.
Đây chỉ là hai cách có thể để tạo một cụm:
Cả hai tùy chọn đều tạo ra một cụm có cùng dung lượng, nhưng cấu hình dưới cùng có bốn nút nhỏ hơn và cấu hình trên cùng có hai nút lớn hơn.
Lựa chọn nào tốt hơn?
Để trả lời câu hỏi này, chúng ta hãy xem xét ưu điểm của cả hai lựa chọn. Chúng tôi đã tóm tắt chúng trong một bảng.
Một số nút lớn
Nhiều nút nhỏ
Quản lý cụm dễ dàng hơn (nếu tại chỗ)
Tự động điều chỉnh tỷ lệ mượt mà
Rẻ hơn (nếu tại chỗ)
Giá hơi khác một chút (trên đám mây)
Có thể chạy các ứng dụng sử dụng nhiều tài nguyên
Sao chép đầy đủ
Tài nguyên được sử dụng hiệu quả hơn (ít chi phí hơn cho trình nền hệ thống
Khả năng chịu lỗi cụm cao hơn
Xin lưu ý rằng chúng tôi chỉ đang nói về các nút công nhân. Việc chọn số lượng và kích thước của các nút chính là một chủ đề hoàn toàn khác.
Vì vậy, hãy thảo luận chi tiết hơn về từng điểm trong bảng.
Tùy chọn đầu tiên: một số nút lớn
Tùy chọn cực đoan nhất là một nút công nhân cho toàn bộ dung lượng cụm. Trong ví dụ trên, đây sẽ là một nút công nhân duy nhất có 16 lõi CPU và 16 GB RAM.
Ưu điểm
Điểm cộng số 1. Quản lý dễ dàng hơn
Việc quản lý một vài máy sẽ dễ dàng hơn quản lý toàn bộ đội máy. Việc tung ra các bản cập nhật và bản sửa lỗi sẽ nhanh hơn và đồng bộ hóa dễ dàng hơn. Số lần thất bại về số lượng tuyệt đối cũng ít hơn.
Xin lưu ý rằng tất cả những điều trên áp dụng cho phần cứng, máy chủ của bạn chứ không áp dụng cho các phiên bản đám mây.
Tình hình lại khác trên đám mây. Ở đó, việc quản lý được xử lý bởi nhà cung cấp dịch vụ đám mây. Do đó, việc quản lý mười nút trên đám mây không khác nhiều so với việc quản lý một nút.
Định tuyến lưu lượng và phân phối tải giữa các nhóm trên đám mây : lưu lượng truy cập từ Internet được gửi đến bộ cân bằng tải chính, bộ cân bằng tải này sẽ chuyển tiếp lưu lượng truy cập đến cổng của một trong các nút (dịch vụ NodePort đặt cổng trong phạm vi 30000-32767 trong mỗi nút cụm). Các quy tắc do kube-proxy đặt ra sẽ chuyển hướng lưu lượng truy cập từ nút đến nhóm. Đây là giao diện của mười nhóm trên hai nút:
Ưu điểm số 2: Chi phí cho mỗi nút ít hơn
Một chiếc xe mạnh mẽ sẽ đắt hơn nhưng mức tăng giá không nhất thiết phải tuyến tính. Nói cách khác, một máy chủ 10 lõi có bộ nhớ XNUMX GB thường rẻ hơn XNUMX máy chủ lõi đơn có cùng dung lượng bộ nhớ.
Nhưng lưu ý rằng quy tắc này thường không hoạt động trong các dịch vụ đám mây. Trong cơ chế định giá hiện tại của tất cả các nhà cung cấp dịch vụ đám mây lớn, giá tăng tuyến tính theo công suất.
Do đó, trên đám mây, bạn thường không thể lưu trên các máy chủ mạnh hơn.
Ưu điểm số 3: Bạn có thể chạy các ứng dụng sử dụng nhiều tài nguyên
Một số ứng dụng yêu cầu máy chủ mạnh mẽ trong một cụm. Ví dụ: nếu hệ thống máy học yêu cầu bộ nhớ 8 GB, bạn sẽ không thể chạy nó trên các nút 1 GB mà chỉ có thể chạy với ít nhất một nút công nhân lớn.
Nhược điểm
Nhược điểm số 1. Nhiều nhóm trên mỗi nút
Nếu cùng một nhiệm vụ được thực hiện trên ít nút hơn thì mỗi nút sẽ tự nhiên có nhiều nhóm hơn.
Đây có thể là một vấn đề.
Lý do là mỗi mô-đun đưa ra một số chi phí cho thời gian chạy vùng chứa (ví dụ: Docker), cũng như kubelet và cAdvisor.
Ví dụ: kubelet thường xuyên thăm dò tất cả các vùng chứa trên một nút để tìm khả năng tồn tại—càng nhiều vùng chứa thì kubelet càng phải làm nhiều việc hơn.
CAdvisor thu thập số liệu thống kê sử dụng tài nguyên cho tất cả các vùng chứa trên một nút và kubelet thường xuyên truy vấn thông tin này và cung cấp thông tin đó qua API. Một lần nữa, nhiều vùng chứa hơn có nghĩa là nhiều công việc hơn cho cả cAdvisor và kubelet.
Nếu số lượng mô-đun tăng lên, nó có thể làm chậm hệ thống và thậm chí làm giảm độ tin cậy của nó.
Trong kho Kubernetes một số các nút đó chuyển đổi giữa các trạng thái Sẵn sàng/Chưa sẵn sàng vì việc kiểm tra kubelet thường xuyên đối với tất cả các vùng chứa trên một nút mất quá nhiều thời gian.
Vì lý do này Kubernetes . Tùy thuộc vào hiệu suất của nút, bạn có thể chạy nhiều nhóm hơn trên mỗi nút, nhưng thật khó để dự đoán liệu sẽ có vấn đề hay mọi thứ sẽ hoạt động tốt. Đó là giá trị thử nghiệm công việc trước.
Nhược điểm số 2. Hạn chế về nhân rộng
Quá ít nút sẽ hạn chế mức độ nhân rộng ứng dụng hiệu quả. Ví dụ: nếu bạn có một ứng dụng có tính sẵn sàng cao với năm bản sao nhưng chỉ có hai nút thì mức độ sao chép hiệu quả của ứng dụng sẽ giảm xuống còn hai.
Năm bản sao chỉ có thể được phân phối trên hai nút và nếu một trong số chúng bị lỗi, nó sẽ gỡ bỏ nhiều bản sao cùng một lúc.
Nếu bạn có năm nút trở lên, mỗi bản sao sẽ chạy trên một nút riêng biệt và lỗi của một nút sẽ loại bỏ tối đa một bản sao.
Do đó, yêu cầu về tính sẵn sàng cao có thể yêu cầu số lượng nút tối thiểu nhất định trong cụm.
Nhược điểm số 3. Hậu quả tồi tệ hơn của thất bại
Với số lượng nút ít, mỗi lỗi sẽ gây ra hậu quả nghiêm trọng hơn. Ví dụ: nếu bạn chỉ có hai nút và một trong số chúng bị lỗi thì một nửa số mô-đun của bạn sẽ biến mất ngay lập tức.
Tất nhiên, Kubernetes sẽ di chuyển khối lượng công việc từ nút bị lỗi sang nút khác. Nhưng nếu có ít thì có thể không có đủ dung lượng trống. Kết quả là một số ứng dụng của bạn sẽ không khả dụng cho đến khi bạn hiển thị nút bị lỗi.
Vì vậy, càng nhiều nút thì tác động của lỗi phần cứng càng ít.
Nhược điểm #4: Nhiều bước tự động hóa quy mô hơn
Kubernetes có hệ thống tự động mở rộng quy mô cụm cho cơ sở hạ tầng đám mây, cho phép bạn tự động thêm hoặc xóa các nút tùy thuộc vào nhu cầu hiện tại của bạn. Với các nút lớn hơn, việc tự động điều chỉnh quy mô trở nên đột ngột và rắc rối hơn. Ví dụ: trên hai nút, việc thêm một nút bổ sung sẽ ngay lập tức tăng dung lượng cụm lên 50%. Và bạn sẽ phải trả tiền cho những tài nguyên đó, ngay cả khi bạn không cần chúng.
Do đó, nếu bạn định sử dụng quy mô cụm tự động, các nút càng nhỏ thì bạn sẽ nhận được quy mô linh hoạt hơn và tiết kiệm chi phí hơn.
Bây giờ chúng ta hãy xem xét những ưu điểm và nhược điểm của một số lượng lớn các nút nhỏ.
Tùy chọn thứ hai: nhiều nút nhỏ
Ưu điểm của phương pháp này về cơ bản xuất phát từ những nhược điểm của phương án ngược lại với một số nút lớn.
Ưu điểm
Ưu điểm số 1: Ít tác động của thất bại hơn
Càng nhiều nút thì càng có ít nhóm trên mỗi nút. Ví dụ: nếu bạn có một trăm mô-đun trên mười nút thì mỗi nút sẽ có trung bình mười mô-đun.
Bằng cách này, nếu một trong các nút bị lỗi, bạn chỉ mất 10% khối lượng công việc. Rất có thể chỉ một số lượng nhỏ bản sao sẽ bị ảnh hưởng và toàn bộ ứng dụng sẽ vẫn hoạt động.
Ngoài ra, các nút còn lại có thể sẽ có đủ tài nguyên trống để xử lý khối lượng công việc của nút bị lỗi, do đó Kubernetes có thể tự do lên lịch lại các nhóm và ứng dụng của bạn sẽ trở lại trạng thái hoạt động tương đối nhanh chóng.
Ưu điểm số 2: Sao chép tốt
Nếu có đủ nút, bộ lập lịch Kubernetes có thể gán các nút khác nhau cho tất cả các bản sao. Bằng cách này, nếu một nút bị lỗi, chỉ một bản sao sẽ bị ảnh hưởng và ứng dụng sẽ vẫn khả dụng.
Nhược điểm
Nhược điểm số 1. Khó kiểm soát
Số lượng lớn các nút khó quản lý hơn. Ví dụ: mỗi nút Kubernetes phải giao tiếp với tất cả các nút khác, nghĩa là số lượng kết nối tăng theo phương trình bậc hai và tất cả các kết nối này cần phải được theo dõi.
Bộ điều khiển nút trong Trình quản lý bộ điều khiển Kubernetes thường xuyên đi qua tất cả các nút trong cụm để kiểm tra tình trạng - càng nhiều nút thì bộ điều khiển càng tải nhiều.
Tải trọng trên cơ sở dữ liệu etcd cũng tăng lên - mỗi lệnh gọi kubelet và kube-proxy đối với etcd (thông qua API), mà etcd sẽ phát các bản cập nhật đối tượng.
Nói chung, mỗi nút công nhân áp đặt tải bổ sung lên các thành phần hệ thống của nút chính.
Kubernetes chính thức hỗ trợ các cụm với . Tuy nhiên, trên thực tế đã có 500 nút .
Để quản lý số lượng lớn nút công nhân, bạn nên chọn nút chính mạnh hơn. Ví dụ: kube-up kích thước VM chính xác cho nút chính tùy thuộc vào số lượng nút công nhân. Nghĩa là, càng có nhiều nút công nhân thì các nút chính càng hoạt động hiệu quả hơn.
Để giải quyết những vấn đề cụ thể này, có những phát triển đặc biệt, chẳng hạn như . Hệ thống này cho phép bạn bỏ qua các hạn chế và xây dựng các cụm với số lượng nút công nhân khổng lồ.
Nhược điểm #2: Thêm chi phí chung.
Trên mỗi nút công nhân, Kubernetes chạy một tập hợp các trình nền hệ thống - chúng bao gồm thời gian chạy vùng chứa (chẳng hạn như Docker), kube-proxy và kubelet, bao gồm cả cAdvisor. Họ cùng nhau tiêu thụ một lượng tài nguyên cố định nhất định.
Nếu bạn có nhiều nút nhỏ thì tỷ lệ chi phí trên mỗi nút sẽ lớn hơn. Ví dụ: hãy tưởng tượng rằng tất cả các trình nền hệ thống trên một nút cùng nhau sử dụng 0,1 lõi CPU và 0,1 GB bộ nhớ. Nếu bạn có một nút mười lõi với bộ nhớ 10 GB thì trình nền sẽ tiêu thụ 1% dung lượng cụm. Mặt khác, trên mười nút lõi đơn có bộ nhớ 1 GB, các trình tiện ích sẽ chiếm 10% dung lượng của cụm.
Do đó, càng ít nút thì cơ sở hạ tầng được sử dụng càng hiệu quả.
Nhược điểm số 3. Sử dụng nguồn lực kém hiệu quả
Trên các nút nhỏ, có thể các khối tài nguyên còn lại quá nhỏ để có thể gán bất kỳ khối lượng công việc nào, vì vậy chúng vẫn không được sử dụng.
Ví dụ: mỗi nhóm yêu cầu 0,75 GB bộ nhớ. Nếu bạn có mười nút, mỗi nút có 1GB bộ nhớ, bạn có thể chạy mười nhóm, để lại mỗi nút có 0,25GB bộ nhớ chưa sử dụng.
Điều này có nghĩa là 25% bộ nhớ của toàn bộ cụm bị lãng phí.
Trên một nút lớn có bộ nhớ 10 GB, bạn có thể chạy 13 mô-đun này - và sẽ chỉ có một đoạn 0,25 GB không được sử dụng.
Trong trường hợp này, chỉ có 2,5% bộ nhớ bị lãng phí.
Do đó, tài nguyên được sử dụng tối ưu hơn trên các nút lớn hơn.
Một số nút lớn hay nhiều nút nhỏ?
Vậy cái nào tốt hơn: một vài nút lớn trong một cụm hay nhiều nút nhỏ? Như mọi khi, không có câu trả lời rõ ràng. Phần lớn phụ thuộc vào loại ứng dụng.
Ví dụ: nếu một ứng dụng yêu cầu bộ nhớ 10 GB thì các nút lớn hơn là một lựa chọn hiển nhiên. Và nếu ứng dụng yêu cầu sao chép gấp mười lần để có tính sẵn sàng cao thì hầu như không đáng mạo hiểm khi đặt các bản sao chỉ trên hai nút - phải có tối thiểu mười nút trong cụm.
Trong các tình huống trung gian, hãy đưa ra lựa chọn dựa trên ưu điểm và nhược điểm của từng phương án. Có lẽ một số lập luận phù hợp với tình huống của bạn hơn những lập luận khác.
Và không nhất thiết phải làm cho tất cả các nút có cùng kích thước. Không có gì ngăn cản bạn thử nghiệm trước với các nút có cùng kích thước, sau đó thêm các nút có kích thước khác vào chúng, kết hợp chúng thành một cụm. Các nút công nhân trong cụm Kubernetes có thể hoàn toàn không đồng nhất. Vì vậy, bạn có thể thử kết hợp những ưu điểm của cả hai phương pháp.
Không có một công thức duy nhất nào, và mỗi tình huống đều có những sắc thái riêng và chỉ có quá trình sản xuất mới cho thấy sự thật.
Bản dịch do nhóm nền tảng đám mây chuẩn bị .
Thông tin thêm về Kubernetes: .
Nguồn: www.habr.com