Tên tôi là Sergey, tôi đến từ ITSumma và tôi muốn cho bạn biết cách chúng tôi tiếp cận vấn đề dư thừa trong Kubernetes. Gần đây, tôi đã thực hiện rất nhiều công việc tư vấn về triển khai các giải pháp devops khác nhau cho nhiều nhóm khác nhau và đặc biệt là hợp tác chặt chẽ với các dự án sử dụng K8. Tại hội nghị Uptime day 4, được dành riêng cho tính dư thừa trong các kiến trúc phức tạp, tôi đã trình bày về tính dư thừa của "khối lập phương", và đây là bài kể lại miễn phí của anh ấy. Tôi sẽ chỉ cảnh báo trước với bạn rằng đây không phải là hướng dẫn trực tiếp cho hành động mà là sự khái quát hóa những suy ngẫm về chủ đề này.
Về nguyên tắc, giám sát và dự phòng là hai công cụ chính để tăng khả năng chịu lỗi của bất kỳ dự án nào. Nhưng trong Cuber, mọi thứ đều tự cân bằng, bạn nói, mọi thứ đều tự cân bằng, và nếu có chuyện gì xảy ra, nó sẽ tự tăng lên... Đó là, trong nghiên cứu sơ bộ đầu tiên về chủ đề này, khi được hỏi ai tiếp cận việc đặt trước K8 như thế nào , Internet đã trả lời tôi “tại sao?” ? Nhiều người cho rằng Cuber là một thứ kỳ diệu có thể giải quyết mọi vấn đề về cơ sở hạ tầng và khiến dự án không bao giờ thất bại. Nhưng... thế giới không như vẻ ngoài của nó.
Trước đây chúng ta đã thực hiện quy trình sao lưu như thế nào? Chúng ta đều sử dụng các nền tảng lưu trữ giống hệt nhau—hoặc ảo hoặc phần cứng. may chủvà chúng tôi đã áp dụng ba phương pháp cơ bản:
- đồng bộ hóa mã và số liệu thống kê
- đồng bộ hóa cấu hình
- sao chép cơ sở dữ liệu
Và thì đấy: bất cứ lúc nào chúng tôi chuyển sang địa điểm dự bị, mọi người đều vui vẻ, chúng tôi đứng dậy và rời đi.
Họ cung cấp cho chúng tôi những gì để tăng tính khả dụng liên tục của ứng dụng kubernetes của chúng tôi? Điều đầu tiên mà tài liệu không chính thức nói là cài đặt nhiều máy, tạo nhiều máy chủ - số lượng của chúng phải đáp ứng các điều kiện để đạt được số đại biểu trong cụm và do đó, etcd, api, MC, bộ lập lịch được cài đặt trên mỗi máy các bậc thầy... Và có vẻ như mọi thứ đều ổn : Nếu một số nút công nhân hoặc nút chính bị lỗi, cụm của chúng tôi sẽ được cân bằng lại và ứng dụng sẽ tiếp tục hoạt động. Có vẻ như phép thuật một lần nữa! Nhưng thường thì cụm của chúng tôi nằm trong cùng một trung tâm dữ liệu và điều này có thể đặt ra một số câu hỏi nhất định. Điều gì sẽ xảy ra nếu một chiếc máy xúc đến đào cáp lên, sét đánh và lũ lụt toàn cầu xảy ra? Mọi thứ đều bị che đậy, cụm của chúng tôi không còn tồn tại. Làm thế nào để tiếp cận các đặt phòng có tính đến khía cạnh này của vấn đề?
Trước hết, bạn phải có một cụm khác ở chế độ chờ nóng, tức là một cụm mà bạn có thể chuyển sang bất kỳ lúc nào. Hơn nữa, theo quan điểm của Cuber, cơ sở hạ tầng phải hoàn toàn giống nhau. Nghĩa là, nếu có bất kỳ plugin không chuẩn nào để làm việc với hệ thống tệp, các giải pháp tùy chỉnh để xâm nhập, thì chúng phải hoàn toàn giống nhau trên hai (hoặc ba hoặc mười, tùy thuộc vào số tiền và sức mạnh của quản trị viên là đủ) cụm. Cần xác định rõ ràng hai bộ ứng dụng (triển khai, bộ trạng thái, bộ nền, cronjob, v.v.): bộ nào trong số chúng có thể chạy ở chế độ chờ liên tục và bộ ứng dụng nào tốt nhất không nên khởi chạy cho đến khi chuyển đổi thực tế.
Vậy cụm dự phòng của chúng ta có nên hoàn toàn giống với cụm chiến đấu của chúng ta không? KHÔNG. Nếu trước đây, khi làm việc với các dự án nguyên khối, với cơ sở hạ tầng phần cứng, chúng tôi duy trì một môi trường gần như giống hệt nhau, thì trong khuôn khổ Cuber, tôi tin rằng điều này không nên xảy ra. Hãy xem tại sao.
Ví dụ: hãy bắt đầu với các thực thể cơ bản của Kubernetes - triển khai - chúng phải giống hệt nhau. Các ứng dụng phải được khởi chạy để có thể chặn quá trình xử lý lưu lượng truy cập bất kỳ lúc nào và cho phép dự án của chúng tôi tiếp tục tồn tại. Nếu chúng ta đang nói về các tệp cấu hình, thì chúng ta cần xem xét liệu chúng có giống nhau hay không. Nghĩa là, nếu chúng ta, những người thông minh, không sử dụng bất kỳ chất bị cấm nào và không giữ căn cứ trong K8, thì trong cấu hình của chúng ta, chúng ta nên có cài đặt để truy cập vào căn cứ chiến đấu (quy trình đặt trước được xây dựng riêng). Theo đó, để cung cấp quyền truy cập vào phiên bản cơ sở dữ liệu dự phòng, chúng ta phải có một tệp cấu hình riêng (configmap). Chúng tôi làm việc theo cách tương tự với các bí mật: mật khẩu để truy cập cơ sở dữ liệu, khóa api; Tại bất kỳ thời điểm nào, chúng ta có thể có bí mật chiến đấu hoặc bí mật dự trữ đang hoạt động. Tổng cộng, chúng tôi đã có hai thực thể kubernetes, các phiên bản sao lưu của chúng không được giống với phiên bản sản xuất. Thực thể tiếp theo đáng tập trung vào là cronjob. Các cronjob trong dự trữ trong mọi trường hợp không được giống hệt với tập hợp các cronjob trong cụm sản xuất! Ví dụ: nếu chúng tôi nâng cao một cụm sao lưu và nâng cấp nó hoàn toàn với tất cả các cronjob được bật, thì mọi người sẽ nhận được hai lá thư từ bạn cùng một lúc thay vì một. Hoặc một số loại đồng bộ hóa dữ liệu với các nguồn bên ngoài sẽ diễn ra hai lần, theo đó chúng ta bắt đầu phát ốm, khóc, la hét và chửi thề.
Mọi người trên Internet đề xuất chúng tôi tổ chức một cụm dự phòng như thế nào? Câu trả lời phổ biến thứ hai sau “tại sao?” - sử dụng Liên đoàn Kubernetes.
Nó là gì? Giả sử đây là một cụm meta lớn. Nếu chúng ta tưởng tượng kiến trúc của Kuber - nơi chúng ta có một master, một số node - thì theo quan điểm của liên đoàn, chúng ta cũng có một master và một số node, chỉ mỗi node là một cluster riêng biệt. Nghĩa là, chúng tôi làm việc với cùng một thực thể, với cùng một nguyên thủy, giống như với một khối lập phương duy nhất, chỉ có điều chúng tôi xoay và xoay không phải bằng máy vật lý của mình mà bằng toàn bộ cụm. Trong khuôn khổ liên đoàn, chúng tôi đã đồng bộ hóa hoàn toàn các nguồn lực liên kết từ cha mẹ đến con cháu. Ví dụ: nếu chúng tôi triển khai một số loại triển khai thông qua liên kết, thì loại triển khai đó sẽ được triển khai cho từng cụm con của chúng tôi. Nếu chúng tôi lấy một số sơ đồ cấu hình, một bí mật và triển khai nó cho liên đoàn, nó sẽ lan sang tất cả các cụm con của chúng tôi; Đồng thời, liên đoàn cho phép chúng tôi tùy chỉnh tài nguyên của mình cho trẻ em. Nghĩa là, chúng tôi đã lấy một số sơ đồ cấu hình, triển khai nó thông qua liên kết và sau đó, nếu chúng tôi cần sửa nội dung nào đó trên các cụm cụ thể, chúng tôi sẽ chỉnh sửa nó trên một cụm riêng biệt và thay đổi này sẽ không được đồng bộ hóa ở bất kỳ đâu.
Liên kết Kubernetes là một công cụ hiện có gần đây và nó không hỗ trợ toàn bộ bộ tài nguyên mà chính K8 cung cấp: tại thời điểm xuất bản một trong những phiên bản đầu tiên của tài liệu, nó nói về việc chỉ hỗ trợ bản đồ cấu hình, triển khai cho một bản sao thiết lập và xâm nhập. Bí mật không được hỗ trợ, làm việc với khối lượng cũng không được hỗ trợ. Bộ quá hạn chế. Đặc biệt nếu chúng tôi muốn giải trí - ví dụ: chuyển tài nguyên của riêng mình sang Kubernetes thông qua định nghĩa tài nguyên tùy chỉnh - chúng tôi sẽ không đẩy chúng vào liên kết. Đó là, giống như ... một giải pháp rất giống với sự thật, nhưng nó khiến chúng ta định kỳ tự bắn vào chân mình. Mặt khác, liên kết cho phép chúng tôi quản lý bản sao của mình một cách linh hoạt. Ví dụ: chúng tôi muốn 10 bản sao ứng dụng của mình đang chạy, theo mặc định liên đoàn sẽ chia con số này theo tỷ lệ cho số cụm. Và tất cả điều này cũng có thể được cấu hình! Nghĩa là, bạn có thể chỉ định rằng bạn cần giữ 6 bản sao ứng dụng của chúng tôi trên cụm chiến đấu và chỉ 4 bản sao ứng dụng của chúng tôi trên cụm dự phòng, để tiết kiệm tài nguyên hoặc để giải trí cho riêng bạn. Điều này cũng khá thuận tiện. Nhưng với liên đoàn, chúng tôi phải sử dụng một số giải pháp mới, triển khai thứ gì đó khi đang di chuyển, buộc bản thân phải suy nghĩ nhiều hơn một chút…
Có cách nào đơn giản hơn để tiếp cận quá trình đặt chỗ của Cuber không? Chúng ta thậm chí có những công cụ gì?
Thứ nhất, chúng tôi luôn có một số loại hệ thống ci / cd, nghĩa là chúng tôi không thực hiện thủ công, chúng tôi không ghi trên máy chủ tạo / áp dụng. Hệ thống tạo yaml cho vùng chứa của chúng tôi.
Thứ hai, có một số cụm, chúng tôi có một hoặc một số sổ đăng ký (nếu chúng tôi thông minh), chúng tôi cũng đã lấy và bảo lưu. Và có một tiện ích kubectl tuyệt vời có thể hoạt động với nhiều cụm cùng một lúc.
Vì vậy: theo tôi, giải pháp đơn giản và đúng đắn nhất để xây dựng cụm sao lưu là triển khai song song nguyên thủy. Có một số loại đường dẫn trong hệ thống ci/cd; Đầu tiên, chúng tôi xây dựng các bộ chứa, thử nghiệm và triển khai các ứng dụng thông qua kubectl cho một số cụm độc lập. Chúng ta có thể xây dựng các phép tính đồng thời cho một số cụm. Theo đó, chúng tôi cũng quyết định việc cung cấp cấu hình ở giai đoạn này. Chúng tôi có thể xác định trước một bộ cấu hình cho cụm chiến đấu của mình, một bộ cấu hình cho cụm dự phòng và ở cấp độ hệ thống ci/cd, chúng tôi có thể triển khai môi trường thực phẩm thành cụm thực phẩm và môi trường dự phòng thành bản sao lưu. cụm. So với liên kết, sau khi xác định tài nguyên được liên kết, bạn không cần phải đi đến từng cụm con và xác định lại nội dung nào đó. Chúng tôi đã làm điều này trước. Chúng ta là những người bạn tuyệt vời.
Nhưng... có... tôi đã viết, có “gốc rễ của mọi tội lỗi”, nhưng thực ra có hai cái. Đầu tiên, hệ thống tập tin. Có một số loại PV hoặc chúng tôi sử dụng bộ nhớ ngoài. Nếu chúng ta lưu trữ các tệp bên trong một cụm thì chúng ta cần tuân theo các thông lệ cũ còn sót lại từ thời cơ sở hạ tầng phần cứng: ví dụ: đồng bộ hóa với lsync. Vâng, hoặc bất kỳ chiếc nạng nào khác mà cá nhân bạn thích. Chúng tôi lăn mọi thứ lên những chiếc xe khác và sống.
Điểm thứ hai và thậm chí còn quan trọng hơn là cơ sở dữ liệu. Nếu chúng ta là những người thông minh và không giữ cơ sở dữ liệu trong một khối lập phương, thì quá trình sao lưu dữ liệu sẽ tuân theo cùng một sơ đồ cũ - sao chép chủ-nô lệ, sau đó chuyển đổi, chúng ta sẽ bắt kịp bản sao và sống tốt. Nhưng nếu chúng ta giữ DB của mình bên trong cụm thì về nguyên tắc, có nhiều giải pháp có sẵn để tổ chức cùng một bản sao chủ-nô lệ và nhiều giải pháp để nâng cao một DB bên trong khối lập phương.
Một tỷ báo cáo đã được đọc về việc sao lưu cơ sở dữ liệu, một tỷ bài báo đã được viết và nói đúng ra, không có gì mới ở đây. Nói chung, hãy theo đuổi ước mơ của bạn, sống như bạn muốn, sáng chế ra một số chiếc nạng phức tạp cho bản thân, nhưng hãy nhớ suy nghĩ xem bạn sẽ bảo lưu tất cả những thứ này như thế nào.
Và bây giờ hãy nói về cách thức, về nguyên tắc, chúng ta sẽ có quá trình chuyển sang địa điểm dự phòng trong trường hợp hỏa hoạn. Đầu tiên, chúng tôi triển khai song song các ứng dụng phi trạng thái. Chúng không ảnh hưởng đến logic kinh doanh của các ứng dụng, dự án của chúng tôi, chúng tôi có thể liên tục giữ cho hai bộ ứng dụng chạy và chúng có thể bắt đầu nhận lưu lượng truy cập. Điều rất quan trọng là phải xem xét quá trình chuyển sang trang dự phòng: bạn có cần xác định lại cấu hình không? Ví dụ: chúng tôi có cụm Kubernetes sản xuất, cụm Kubernetes dự phòng, cơ sở dữ liệu chính bên ngoài và cơ sở dữ liệu chính dự phòng. Chúng tôi có bốn tùy chọn về cách các ứng dụng này trong quá trình sản xuất có thể bắt đầu tương tác với nhau. Cơ sở dữ liệu của chúng tôi có thể chuyển đổi và hóa ra là chúng tôi cần chuyển lưu lượng truy cập trong cụm thực phẩm sang cơ sở mới, nếu không cụm của chúng tôi có thể thất bại - và chúng tôi đã chuyển sang khu dự trữ, nhưng vẫn tiếp tục làm việc với cơ sở dữ liệu thực phẩm, à, thứ ba tùy chọn, khi điều này xảy ra với chúng tôi, nó đã xảy ra và chúng tôi chuyển đổi cả hai ứng dụng, xác định lại cấu hình của mình để các ứng dụng mới hoạt động với cơ sở dữ liệu mới.
Chà, thực ra, có thể rút ra kết luận gì từ tất cả những điều này?
Kết luận thứ nhất: cuộc sống tốt đẹp khi có dự trữ. Nhưng nó đắt. Nhưng lý tưởng nhất là sống với nhiều hơn một nguồn dự trữ. Lý tưởng nhất là bạn thường cần phải sống với một số dự trữ. Thứ nhất, dự trữ ít nhất phải không có ở một DC và thứ hai, ít nhất là ở một máy chủ lưu trữ khác. Nó thường xảy ra - và trong thực tế của tôi, điều này đã xảy ra. Thật không may, tôi không thể nêu tên các dự án, đúng lúc xảy ra hỏa hoạn ở trung tâm dữ liệu... Tôi kiểu: hãy chuyển sang dự trữ! Và các máy chủ dự phòng nằm trong cùng một giá...
Hoặc hãy tưởng tượng rằng Amazon đã bị cấm ở Nga (và điều này đã xảy ra). Và chỉ vậy thôi: việc dự trữ của chúng ta nằm ở một Amazon khác có ích lợi gì? Anh ấy cũng không có sẵn. Vì vậy, tôi nhắc lại: chúng tôi giữ một khoản dự trữ ở mức tối thiểu ở một DC khác và tốt nhất là với một nhà cung cấp dịch vụ lưu trữ khác.
Kết luận thứ hai: nếu ứng dụng của bạn trong Cuber giao tiếp với một số nguồn bên ngoài (đây có thể là cơ sở dữ liệu hoặc một số api bên ngoài), hãy đảm bảo xác định nó là một dịch vụ có Điểm cuối bên ngoài, để không triển khai lại tại thời điểm chuyển đổi 15 ứng dụng của bạn đang hoạt động trên cùng một cơ sở. Xác định cơ sở dữ liệu như một dịch vụ riêng biệt, gõ vào nó như thể nó nằm trong cụm của bạn: nếu bạn có cơ sở dữ liệu, bạn thay đổi IP ở một nơi và tiếp tục sống hạnh phúc.
Và cuối cùng: Tôi yêu thích “khối lập phương”, cũng như các thử nghiệm với nó. Tôi cũng muốn chia sẻ kết quả của những thí nghiệm này và kinh nghiệm cá nhân của tôi nói chung. Đó là lý do tại sao tôi đã ghi lại một loạt hội thảo trực tuyến về K8, chào mừng bạn đến với để biết chi tiết.
Nguồn: www.habr.com
