Chào mừng bạn đến với loạt bài Bắt đầu nhanh Kubernetes của chúng tôi. Đây là chuyên mục thường xuyên có những câu hỏi thú vị nhất mà chúng tôi nhận được trực tuyến và trong các khóa đào tạo của mình. Câu trả lời của chuyên gia Kubernetes.
Chuyên gia hôm nay là Daniel Polenchik (). Daniel làm giảng viên và nhà phát triển phần mềm tại .
Nếu bạn muốn câu hỏi của mình được giải đáp ở bài viết tiếp theo, hoặc .
Bỏ lỡ bài viết trước? .
Làm cách nào để kết nối các cụm Kubernetes trong các trung tâm dữ liệu khác nhau?
Ngắn gọn: và tôi cũng khuyên bạn nên đọc về и .
Khá thường xuyên, cơ sở hạ tầng được nhân rộng và phân bổ trên các khu vực khác nhau, đặc biệt là trong các môi trường được kiểm soát.
Nếu một khu vực không khả dụng, lưu lượng truy cập sẽ được chuyển hướng đến khu vực khác để tránh bị gián đoạn.
Với Kubernetes, bạn có thể sử dụng chiến lược tương tự và phân bổ khối lượng công việc trên các khu vực khác nhau.
Bạn có thể có một hoặc nhiều cụm cho mỗi nhóm, khu vực, môi trường hoặc kết hợp các yếu tố này.
Các cụm của bạn có thể được lưu trữ trên các đám mây khác nhau và tại chỗ.
Nhưng bạn lập kế hoạch cơ sở hạ tầng như thế nào cho sự trải rộng về mặt địa lý như vậy?
Bạn có cần tạo một cụm lớn cho nhiều môi trường đám mây trên một mạng không?
Hoặc có nhiều cụm nhỏ và tìm cách kiểm soát, đồng bộ hóa chúng?
Một cụm lãnh đạo
Tạo một cụm trên một mạng không phải là điều dễ dàng.
Hãy tưởng tượng bạn gặp tai nạn, kết nối giữa các phân đoạn cụm bị mất.
Nếu bạn có một máy chủ chính, một nửa số tài nguyên sẽ không thể nhận lệnh mới vì họ sẽ không thể liên lạc với máy chủ chính.
Và đồng thời bạn có các bảng định tuyến cũ (kube-proxy không thể tải xuống cái mới) và không có nhóm bổ sung (kubelet không thể yêu cầu cập nhật).
Tệ hơn nữa, nếu Kubernetes không nhìn thấy nút nào, nó sẽ đánh dấu nút đó là mồ côi và phân phối các nhóm bị thiếu cho các nút hiện có.
Kết quả là bạn có số lượng nhóm gấp đôi.
Nếu bạn tạo một máy chủ chính cho mỗi khu vực, sẽ có vấn đề với thuật toán đồng thuận trong cơ sở dữ liệu etcd. (khoảng biên tập. — Trên thực tế, cơ sở dữ liệu etcd không nhất thiết phải được đặt trên các máy chủ chính. Nó có thể được chạy trên một nhóm máy chủ riêng biệt trong cùng một khu vực. Đúng, đồng thời nhận được điểm lỗi của cụm. Nhưng nhanh chóng.)
sử dụng vvd để thương lượng giá trị trước khi ghi nó vào đĩa.
Nghĩa là, phần lớn các trường hợp phải đạt được sự đồng thuận trước khi trạng thái có thể được ghi vào etcd.
Nếu độ trễ giữa các phiên bản etcd tăng lên đáng kể, như trường hợp của ba phiên bản etcd ở các vùng khác nhau, thì sẽ mất nhiều thời gian để thương lượng một giá trị và ghi nó vào đĩa.
Điều này được phản ánh trong bộ điều khiển Kubernetes.
Người quản lý bộ điều khiển cần thêm thời gian để tìm hiểu về thay đổi và ghi phản hồi vào cơ sở dữ liệu.
Và vì không có một bộ điều khiển mà có nhiều bộ điều khiển, một phản ứng dây chuyền xảy ra và toàn bộ cụm bắt đầu hoạt động rất chậm.
etcd rất nhạy cảm với độ trễ .
Hiện tại không có ví dụ điển hình nào về mạng lớn cho một cụm.
Về cơ bản, cộng đồng nhà phát triển và nhóm cụm SIG đang cố gắng tìm ra cách sắp xếp các cụm giống như cách Kubernetes sắp xếp các vùng chứa.
Tùy chọn 1: liên kết cụm với kubefed
Phản hồi chính thức từ cụm SIG - .
Lần đầu tiên, chúng tôi cố gắng quản lý một tập hợp các cụm dưới dạng một đối tượng bằng công cụ liên kết kube.
Khởi đầu thì tốt, nhưng cuối cùng liên đoàn kube không bao giờ trở nên phổ biến vì nó không hỗ trợ mọi nguồn lực.
Ví dụ: nó hỗ trợ các dịch vụ và phân phối liên kết, nhưng không hỗ trợ StatefulSets.
Ngoài ra, cấu hình liên kết được truyền dưới dạng chú thích và không linh hoạt.
Hãy tưởng tượng bạn có thể mô tả cách phân vùng bản sao cho từng cụm trong liên kết chỉ bằng các chú thích.
Đó là một mớ hỗn độn.
SIG-cluster đã thực hiện rất nhiều công việc sau kubefed v1 và quyết định tiếp cận vấn đề từ một góc độ khác.
Thay vì chú thích, họ quyết định phát hành bộ điều khiển được cài đặt trên các cụm. Nó có thể được tùy chỉnh bằng cách sử dụng Định nghĩa tài nguyên tùy chỉnh (CRD).
Đối với mỗi tài nguyên sẽ là một phần của liên kết, bạn có định nghĩa CRD tùy chỉnh với ba phần:
- định nghĩa tiêu chuẩn về tài nguyên, ví dụ như triển khai;
- tiết diện
placement, nơi bạn xác định cách phân phối tài nguyên trong liên kết; - tiết diện
override, trong đó đối với một tài nguyên cụ thể, bạn có thể ghi đè trọng số và thông số từ vị trí.
Dưới đây là ví dụ về phân phối kết hợp với các phần vị trí và phần ghi đè.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Như bạn có thể thấy, nguồn cung được phân bổ thành hai cụm: cluster1 и cluster2.
Cụm đầu tiên cung cấp ba bản sao và cụm thứ hai được đặt thành 5.
Nếu bạn cần kiểm soát nhiều hơn số lượng bản sao, kubefed2 sẽ cung cấp một đối tượng ReplicaSchedulingPreference mới trong đó các bản sao có thể được tính trọng số:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Cấu trúc và API CRD vẫn chưa hoàn toàn sẵn sàng và công việc tích cực đang được tiến hành trong kho dự án chính thức.
Hãy để mắt đến kubefed2, nhưng hãy nhớ rằng nó chưa phù hợp để sản xuất.
Tìm hiểu thêm về kubefed2 từ trong blog về Kubernetes và trong .
Cách 2: gộp cụm theo kiểu Booking.com
Các nhà phát triển của Booking.com đã không làm việc trên kubefed v2, nhưng họ đã nghĩ ra Shipper - một nhà điều hành giao hàng trên một số cụm, ở một số khu vực và trên một số đám mây.
hơi giống với kubefed2.
Cả hai công cụ đều cho phép bạn tùy chỉnh chiến lược triển khai nhiều cụm của mình (cụm nào được sử dụng và số lượng bản sao mà chúng có).
Nhưng Mục tiêu của người gửi hàng là giảm nguy cơ sai sót trong quá trình giao hàng.
Trong Shipper, bạn có thể xác định một loạt các bước mô tả việc phân chia các bản sao giữa quá trình triển khai trước đó và hiện tại cũng như lưu lượng truy cập đến.
Khi bạn đẩy một tài nguyên vào một cụm, bộ điều khiển Shipper sẽ dần dần triển khai thay đổi đó trên tất cả các cụm đã tham gia.
Ngoài ra, Shipper còn rất hạn chế.
Ví dụ, nó chấp nhận biểu đồ điều khiển làm đầu vào và không hỗ trợ tài nguyên vanilla.
Nói chung thì Shipper hoạt động như thế này.
Thay vì phân phối tiêu chuẩn, bạn cần tạo tài nguyên ứng dụng bao gồm biểu đồ Helm:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper là một lựa chọn tốt để quản lý nhiều cụm, nhưng mối quan hệ chặt chẽ của nó với Helm chỉ gây cản trở.
Điều gì sẽ xảy ra nếu tất cả chúng ta chuyển từ Helm sang hoặc ?
Tìm hiểu thêm về Shipper và triết lý của nó tại .
Nếu bạn muốn tìm hiểu sâu về mã, .
Phương án 3: Gộp cụm “thần kỳ”
Kubefed v2 và Shipper hoạt động với liên kết cụm, cung cấp tài nguyên mới cho các cụm thông qua định nghĩa tài nguyên tùy chỉnh.
Nhưng nếu bạn không muốn viết lại tất cả các bản phân phối, StatefulSets, DaemonSets, v.v. để hợp nhất thì sao?
Làm cách nào để đưa cụm hiện có vào liên kết mà không thay đổi YAML?
, liên quan đến việc lập lịch khối lượng công việc trên các cụm.
Nhưng thay vì nghĩ ra một cách mới để tương tác với cụm và bao bọc tài nguyên trong các định nghĩa tùy chỉnh, bộ lập lịch đa cụm được nhúng vào vòng đời Kubernetes tiêu chuẩn và chặn tất cả các lệnh gọi tạo nhóm.
Mỗi nhóm được tạo ngay lập tức được thay thế bằng một hình nộm.
sử dụng bộ lập lịch nhiều cụm để chặn cuộc gọi và tạo một nhóm giả nhàn rỗi.
Nhóm ban đầu trải qua một chu kỳ lập kế hoạch khác, sau khi thăm dò toàn bộ liên đoàn, quyết định sắp xếp sẽ được đưa ra.
Cuối cùng, nhóm được phân phối đến cụm mục tiêu.
Kết quả là bạn có thêm một nhóm không làm gì cả, chỉ chiếm không gian.
Ưu điểm là bạn không phải viết các tài nguyên mới để kết hợp các nguồn cung cấp.
Mỗi tài nguyên tạo một nhóm sẽ tự động sẵn sàng để được hợp nhất.
Điều này thật thú vị, vì đột nhiên bạn có nguồn cung cấp được phân phối trên nhiều khu vực và thậm chí bạn không nhận thấy. Tuy nhiên, điều này khá mạo hiểm, bởi mọi thứ ở đây đều dựa vào phép thuật.
Nhưng trong khi Shipper đang cố gắng giảm thiểu phần lớn tác động của việc giao hàng, thì công cụ lên lịch nhiều cụm xử lý các nhiệm vụ chung hơn và có lẽ phù hợp hơn cho các công việc hàng loạt.
Nó không có cơ chế phân phối dần dần tiên tiến.
Bạn có thể tìm hiểu thêm về bộ lập lịch nhiều cụm tại .
Nếu bạn muốn đọc về hoạt động của bộ lập lịch nhiều cụm, Admiralty có — quy trình làm việc, sự kiện, CI và CD Kubernetes.
Các công cụ và giải pháp khác
Kết nối và quản lý nhiều cụm là một nhiệm vụ phức tạp và không có giải pháp chung.
Nếu bạn muốn khám phá chủ đề này sâu hơn, đây là một số tài nguyên:
- là công cụ kết nối các mạng lớp phủ của các cụm Kubernetes khác nhau.
- Chuỗi bán lẻ Mục tiêu sử dụng .
- Hãy thử sử dụng IPV6 và .
- Bạn có thể sử dụng lưới dịch vụ, ví dụ .
- Cilium, một plugin giao diện mạng container, cung cấp , cho phép bạn kết hợp một số cụm
Đó là tất cả cho ngày hôm nay
Cảm ơn vì đã đọc đến cuối!
Nếu bạn biết cách kết nối nhiều cụm hiệu quả hơn, .
Chúng tôi sẽ thêm phương pháp của bạn vào các liên kết.
Đặc biệt cảm ơn Chris Nesbitt-Smith () và Vincent de Sme () (kỹ sư đáng tin cậy trong ) để đọc bài viết và chia sẻ những thông tin hữu ích về cách thức hoạt động của liên đoàn.
Nguồn: www.habr.com