Ứng dụng kiến trúc cho Kubernetes
Việc thiết kế và chạy các ứng dụng có tính đến khả năng mở rộng, tính di động và tính mạnh mẽ có thể là một thách thức, đặc biệt là khi độ phức tạp của hệ thống ngày càng tăng. Kiến trúc của một ứng dụng hoặc hệ thống ảnh hưởng đáng kể đến cách nó phải chạy, những gì nó mong đợi từ môi trường của nó và mức độ liên kết chặt chẽ của nó với các thành phần liên quan. Tuân theo một số mẫu nhất định trong giai đoạn thiết kế và tuân theo các thông lệ hoạt động nhất định có thể giúp khắc phục một số vấn đề phổ biến nhất mà các ứng dụng gặp phải khi chạy trong môi trường phân tán cao.Trong khi các mẫu thiết kế phần mềm và phương pháp luận phát triển có thể tạo ra các ứng dụng với các đặc điểm mở rộng phù hợp, thì cơ sở hạ tầng và môi trường ảnh hưởng đến hoạt động của hệ thống được triển khai. Các công nghệ như Docker và Kubernetes giúp các group đóng gói phần mềm và sau đó phân phối, triển khai và mở rộng quy mô trên các nền tảng của máy tính phân tán. Học cách khai thác tốt nhất sức mạnh của các công cụ này có thể giúp bạn quản lý các ứng dụng với tính linh hoạt, khả năng kiểm soát và khả năng đáp ứng cao hơn.
Trong hướng dẫn này, ta sẽ thảo luận một số nguyên tắc và mô hình mà bạn có thể cần áp dụng để giúp bạn mở rộng và quản lý dung lượng công việc của bạn trên Kubernetes. Mặc dù Kubernetes có thể chạy nhiều loại dung lượng công việc, nhưng các lựa chọn bạn đưa ra có thể ảnh hưởng đến sự dễ vận hành và các khả năng có sẵn khi triển khai. Cách bạn kiến trúc và xây dựng các ứng dụng của bạn , đóng gói dịch vụ của bạn trong containers cũng như cấu hình hành vi và quản lý vòng đời trong Kubernetes có thể ảnh hưởng đến trải nghiệm của bạn.
Thiết kế cho khả năng mở rộng ứng dụng
Khi production phần mềm, nhiều yêu cầu ảnh hưởng đến các mẫu và kiến trúc mà bạn chọn sử dụng. Với Kubernetes, một trong những yếu tố quan trọng nhất là khả năng mở rộng quy mô theo chiều ngang , điều chỉnh số lượng bản sao giống hệt nhau của ứng dụng của bạn để phân phối tải và tăng tính khả dụng. Đây là một giải pháp thay thế cho vertical partitioning , cố gắng thao túng các yếu tố giống nhau bằng cách triển khai trên các máy có tài nguyên lớn hơn hoặc ít hơn.
Đặc biệt, microservices là một mẫu thiết kế phần mềm hoạt động tốt để triển khai có thể mở rộng trên các cụm. Các nhà phát triển tạo ra các ứng dụng nhỏ, có thể ghép nối giao tiếp qua mạng thông qua các API REST được xác định rõ thay vì các chương trình phức hợp lớn hơn giao tiếp thông qua các cơ chế lập trình nội bộ. Việc phân chia các ứng dụng nguyên khối thành các thành phần riêng lẻ rời rạc giúp bạn có thể mở rộng từng chức năng một cách độc lập. Phần lớn sự phức tạp và thành phần thường tồn tại ở cấp ứng dụng được chuyển sang lĩnh vực hoạt động, nơi nó có thể được quản lý bởi các nền tảng như Kubernetes.
Ngoài các mẫu phần mềm cụ thể, các ứng dụng gốc cloud được thiết kế với một số cân nhắc bổ sung. Các ứng dụng root trên cloud là các chương trình tuân theo mô hình kiến trúc microservices với các tính năng quản trị, khả năng quan sát và khả năng phục hồi tích hợp để thích ứng với môi trường được cung cấp bởi các nền tảng group trong cloud .
Ví dụ: các ứng dụng root cloud được xây dựng với các chỉ số báo cáo tình trạng để cho phép nền tảng quản lý các sự kiện trong vòng đời nếu một version trở nên không lành mạnh. Họ production (và sẵn sàng xuất khẩu) dữ liệu đo từ xa mạnh mẽ để cảnh báo các nhà khai thác về các vấn đề và cho phép họ đưa ra quyết định sáng suốt. Các ứng dụng được thiết kế để xử lý các lỗi và khởi động lại thường xuyên, các thay đổi về tính khả dụng của chương trình backend và tải cao mà không làm hỏng dữ liệu hoặc không phản hồi.
Sau triết lý ứng dụng 12 yếu tố
Một phương pháp phổ biến có thể giúp bạn tập trung vào các đặc điểm quan trọng nhất khi tạo ứng dụng web sẵn sàng cho cloud là triết lý Ứng dụng mười hai nhân tố . Được viết để giúp các nhà phát triển và group vận hành hiểu được những phẩm chất cốt lõi được chia sẻ bởi các dịch vụ web được thiết kế để chạy trên cloud , các nguyên tắc này áp dụng rất tốt cho phần mềm sẽ sống trong một môi trường group như Kubernetes. Mặc dù các ứng dụng nguyên khối có thể được hưởng lợi từ việc tuân theo các khuyến nghị này, nhưng các kiến trúc microservices được thiết kế xung quanh các nguyên tắc này hoạt động đặc biệt tốt.
Tóm tắt nhanh về Mười hai yếu tố là:
- Codebase: Quản lý tất cả mã trong hệ thống kiểm soát version (như Git hoặc Mercurial). Cơ sở mã quy định toàn diện những gì được triển khai.
- Phần phụ thuộc: Phần phụ thuộc phải được quản lý hoàn toàn và rõ ràng bởi cơ sở mã, được cung cấp (được lưu trữ cùng với mã) hoặc version được ghim ở định dạng mà trình quản lý gói có thể cài đặt.
- Cấu hình: Tách các tham số cấu hình khỏi ứng dụng và xác định chúng trong môi trường triển khai thay vì nướng chúng vào chính ứng dụng.
- Dịch vụ backup : Các dịch vụ local và từ xa đều được tóm tắt là các tài nguyên có thể truy cập mạng với các chi tiết kết nối được cài đặt trong cấu hình.
- Xây dựng, phát hành, chạy: Giai đoạn xây dựng ứng dụng của bạn phải hoàn toàn tách biệt với các quy trình hoạt động và phát hành ứng dụng của bạn. Giai đoạn xây dựng tạo ra một tạo tác triển khai từ mã nguồn, giai đoạn phát hành kết hợp tạo tác và cấu hình, và giai đoạn chạy thực hiện bản phát hành.
- Quy trình: Các ứng dụng được thực hiện dưới dạng các quy trình không nên dựa vào trạng thái lưu trữ local . Trạng thái nên được download một dịch vụ hỗ trợ như được mô tả trong yếu tố thứ tư.
- Cổng kết nối : Các ứng dụng phải liên kết nguyên bản với một cổng và lắng nghe các kết nối. Định tuyến và chuyển tiếp yêu cầu phải được xử lý bên ngoài.
- Đồng thời: Các ứng dụng nên dựa vào việc mở rộng quy mô thông qua mô hình quy trình. Chạy nhiều bản sao của một ứng dụng đồng thời, có khả năng trên nhiều server , cho phép mở rộng quy mô mà không cần điều chỉnh mã ứng dụng.
- Khả năng sử dụng một lần: Các quy trình phải có thể bắt đầu nhanh chóng và dừng lại một cách nhẹ nhàng mà không có tác dụng phụ nghiêm trọng.
- Tính ngang bằng của nhà phát triển / sản phẩm: Môi trường thử nghiệm, dàn dựng và production của bạn phải khớp chặt chẽ và được đồng bộ hóa. Sự khác biệt giữa các môi trường là cơ hội để xuất hiện sự không tương thích và cấu hình chưa được kiểm tra.
- Nhật ký: Các ứng dụng nên truyền log đến kết quả tiêu chuẩn để các dịch vụ bên ngoài có thể quyết định cách xử lý chúng tốt nhất.
- Quy trình quản trị: Các quy trình quản trị một lần nên được chạy dựa trên các bản phát hành cụ thể và được gửi kèm theo mã quy trình chính.
Bằng cách tuân theo các nguyên tắc được cung cấp bởi Mười hai yếu tố, bạn có thể tạo và chạy các ứng dụng bằng mô hình phù hợp với môi trường thực thi Kubernetes. Mười hai yếu tố khuyến khích các nhà phát triển tập trung vào trách nhiệm chính của ứng dụng của họ, xem xét các điều kiện hoạt động và giao diện giữa các thành phần và sử dụng các đầu vào, kết quả và các tính năng quản lý quy trình tiêu chuẩn để chạy có thể dự đoán được trong Kubernetes.
Các thành phần ứng dụng chứa đựng
Kubernetes sử dụng các container để chạy các ứng dụng đóng gói, cô lập trên các node cụm của nó. Để chạy trên Kubernetes, các ứng dụng của bạn phải được đóng gói trong một hoặc nhiều containers images và được thực thi bằng thời gian chạy containers như Docker. Mặc dù việc chứa các thành phần của bạn là một yêu cầu đối với Kubernetes, nhưng nó cũng giúp củng cố nhiều nguyên tắc từ phương pháp ứng dụng mười hai yếu tố được thảo luận ở trên, cho phép dễ dàng mở rộng và quản lý.
Ví dụ: containers cung cấp sự cách ly giữa môi trường ứng dụng và hệ thống server bên ngoài, hỗ trợ cách tiếp cận theo hướng dịch vụ, nối mạng để giao tiếp giữa các ứng dụng và thường lấy cấu hình thông qua các biến môi trường và hiển thị log được ghi theo lỗi chuẩn và chuẩn ra. Bản thân các containers khuyến khích sự đồng thời dựa trên quy trình và giúp duy trì tính ngang bằng của nhà phát triển / sản phẩm bằng cách có thể mở rộng độc lập và đóng gói môi trường thời gian chạy của quy trình. Những đặc điểm này giúp bạn có thể đóng gói các ứng dụng của bạn để chúng chạy trơn tru trên Kubernetes.
Hướng dẫn về Tối ưu hóa Vùng chứa
Tính linh hoạt của công nghệ container cho phép nhiều cách khác nhau để đóng gói một ứng dụng. Tuy nhiên, một số phương pháp hoạt động tốt hơn trong môi trường Kubernetes so với những phương pháp khác.
Hầu hết các phương pháp hay nhất về việc chứa các ứng dụng của bạn đều liên quan đến việc xây dựng hình ảnh, nơi bạn xác định cách phần mềm của bạn sẽ được cài đặt và chạy từ bên trong một containers . Nói chung, việc giữ kích thước hình ảnh nhỏ và có thể ghép lại mang lại một số lợi ích. Hình ảnh được tối ưu hóa kích thước có thể giảm thời gian và tài nguyên cần thiết để khởi động một containers mới trên một cụm bằng cách giữ cho dấu chân có thể quản lý được và sử dụng lại các lớp hiện có giữa các lần cập nhật hình ảnh.
Bước đầu tiên tốt khi tạo containers images là cố gắng hết sức để tách các bước xây dựng của bạn khỏi hình ảnh cuối cùng sẽ được chạy trong quá trình production . Phần mềm xây dựng thường yêu cầu thêm công cụ, mất thêm thời gian và tạo ra các tạo tác có thể không nhất quán từ containers này sang containers khác hoặc không cần thiết đối với môi trường thời gian chạy cuối cùng tùy thuộc vào môi trường. Một cách để tách quá trình xây dựng khỏi môi trường thời gian chạy một cách rõ ràng là sử dụng các bản dựng nhiều giai đoạn Docker . Cấu hình xây dựng nhiều giai đoạn cho phép bạn chỉ định một hình ảnh cơ sở để sử dụng trong quá trình xây dựng của bạn và xác định một hình ảnh khác để sử dụng trong thời gian chạy. Điều này giúp bạn có thể xây dựng phần mềm bằng cách sử dụng một hình ảnh với tất cả các công cụ xây dựng được cài đặt và sao chép các tạo tác thu được vào một hình ảnh mỏng, được sắp xếp hợp lý sẽ được sử dụng mỗi lần sau đó.
Với loại chức năng có sẵn, thường là một ý tưởng hay nếu bạn xây dựng hình ảnh production bên trên hình ảnh root tối thiểu. Nếu bạn muốn tránh hoàn toàn sự cồng kềnh được tìm thấy trong các lớp mẹ kiểu “distro” như ubuntu:16.04 (bao gồm môi trường Ubuntu 16.04 khá hoàn chỉnh), bạn có thể xây dựng hình ảnh của bạn bằng scratch - hình ảnh cơ sở tối thiểu nhất của Docker - như là hình ảnh root . Tuy nhiên, lớp cơ sở scratch không cung cấp quyền truy cập vào nhiều công cụ cốt lõi và thường sẽ phá vỡ các giả định về môi trường mà một số phần mềm nắm giữ. Thay vào đó, hình ảnh alpine Alpine Linux đã trở nên phổ biến nhờ là một môi trường cơ sở tối thiểu, vững chắc cung cấp một bản phân phối Linux nhỏ nhưng đầy đủ tính năng.
Đối với các ngôn ngữ thông dịch như Python hoặc Ruby, mô hình thay đổi một chút vì không có giai đoạn biên dịch và trình thông dịch phải có sẵn để chạy mã trong quá trình production . Tuy nhiên, vì hình ảnh mỏng vẫn là lý tưởng, nhiều hình ảnh được tối ưu hóa theo ngôn ngữ cụ thể được xây dựng trên Alpine Linux có sẵn trên Docker Hub . Các lợi ích của việc sử dụng hình ảnh nhỏ hơn cho các ngôn ngữ được thông dịch cũng tương tự như cho các ngôn ngữ biên dịch: Kubernetes sẽ có thể nhanh chóng kéo tất cả các containers images cần thiết vào các node mới để bắt đầu thực hiện công việc có ý nghĩa.
Quyết định phạm vi cho containers và vỏ
Trong khi các ứng dụng của bạn phải được container để chạy trên một cụm Kubernetes, vỏ quả là những đơn vị nhỏ nhất của sự trừu tượng mà Kubernetes có thể quản lý trực tiếp. Một group là một đối tượng Kubernetes bao gồm một hoặc nhiều containers được ghép nối chặt chẽ. Các containers trong một group chia sẻ một vòng đời và được quản lý cùng nhau như một đơn vị duy nhất. Ví dụ: các containers luôn được lên lịch trên cùng một nút, được bắt đầu hoặc dừng đồng thời và chia sẻ tài nguyên như hệ thống file và không gian IP.
Lúc đầu, có thể khó tìm ra cách tốt nhất để phân chia các ứng dụng của bạn thành các containers và group . Điều này làm cho điều quan trọng là phải hiểu cách Kubernetes xử lý các thành phần này và những gì mỗi lớp trừu tượng cung cấp cho hệ thống của bạn. Một số cân nhắc có thể giúp bạn xác định một số điểm tự nhiên của tính đóng gói cho ứng dụng của bạn với mỗi điểm trừu tượng này.
Một cách để xác định phạm vi hiệu quả cho containers của bạn là tìm kiếm các ranh giới phát triển tự nhiên. Nếu hệ thống của bạn hoạt động bằng kiến trúc microservices, các containers được thiết kế tốt thường được xây dựng để thể hiện các đơn vị chức năng rời rạc thường được dùng trong nhiều ngữ cảnh khác nhau. Mức độ trừu tượng này cho phép group của bạn phát hành các thay đổi đối với containers images và sau đó triển khai chức năng mới này cho bất kỳ môi trường nào mà những hình ảnh đó được sử dụng. Các ứng dụng có thể được xây dựng bằng cách tạo các containers riêng lẻ mà mỗi containers đáp ứng một chức năng nhất định nhưng có thể không hoàn thành toàn bộ quá trình một mình.
Ngược lại với những điều trên, các group thường được xây dựng bằng cách suy nghĩ xem phần nào trong hệ thống của bạn có thể được hưởng lợi nhiều nhất từ việc quản lý độc lập. Vì Kubernetes sử dụng group làm phần trừu tượng nhỏ nhất hướng tới user nên đây là những đơn vị nguyên thủy nhất mà các công cụ và API Kubernetes có thể trực tiếp tương tác và kiểm soát. Bạn có thể bắt đầu, dừng và khởi động lại group hoặc sử dụng các đối tượng cấp cao hơn được xây dựng dựa trên group để giới thiệu các tính năng nhân rộng và quản lý vòng đời. Kubernetes không cho phép bạn quản lý các containers trong một group một cách độc lập, vì vậy bạn không nên group các containers với nhau mà có thể có lợi từ việc quản trị riêng biệt.
Bởi vì nhiều tính năng và phần tóm tắt của Kubernetes xử lý trực tiếp với các group , nên việc group các mục nên chia tỷ lệ lại với nhau trong một group duy nhất và tách các mục nên chia tỷ lệ một cách độc lập. Ví dụ: tách web server của bạn khỏi server ứng dụng của bạn trong các group khác nhau cho phép bạn mở rộng từng lớp một cách độc lập nếu cần. Tuy nhiên, việc gộp web server và bộ điều hợp database vào cùng một group có thể có ý nghĩa nếu bộ điều hợp cung cấp chức năng thiết yếu mà web server cần để hoạt động bình thường.
Nâng cao chức năng của Pod bằng cách đóng gói các container hỗ trợ
Với suy nghĩ này, những loại container nào nên được đóng gói trong một group duy nhất? Nói chung, containers chính chịu trách nhiệm thực hiện các chức năng cốt lõi của group , nhưng các containers bổ sung có thể được xác định để sửa đổi hoặc mở rộng containers chính hoặc giúp nó kết nối với một môi trường triển khai duy nhất.
Ví dụ: trong group web server , containers Nginx có thể lắng nghe các yêu cầu và phân phối nội dung trong khi containers được liên kết cập nhật các file tĩnh khi repository thay đổi.Có thể hấp dẫn để đóng gói cả hai thành phần này trong một container duy nhất, nhưng có những lợi ích đáng kể khi triển khai chúng dưới dạng các container riêng biệt. Cả containers web server và trình kéo repository đều được dùng độc lập trong các ngữ cảnh khác nhau. Chúng có thể được duy trì bởi các group khác nhau và mỗi group có thể được phát triển để tổng quát hóa hành vi của họ để hoạt động với các containers đồng hành khác nhau.
Brendan Burns và David Oppenheimer đã xác định ba mẫu chính để đóng gói các container hỗ trợ trong bài báo của họ vềcác mẫu thiết kế cho các hệ thống phân tán dựa trên container . Những điều này đại diện cho một số trường hợp sử dụng phổ biến nhất để đóng gói các container với nhau trong một group :
- Sidecar: Trong mẫu này, containers phụ mở rộng và nâng cao chức năng cốt lõi của containers chính. Mẫu này liên quan đến việc thực thi các chức năng không chuẩn hoặc tiện ích trong một containers riêng biệt. Ví dụ: một containers chuyển tiếp log hoặc theo dõi các giá trị cấu hình được cập nhật có thể tăng cường chức năng của group mà không làm thay đổi đáng kể trọng tâm chính của group .
- Ambassador: Mẫu đại sứ sử dụng một containers bổ sung để tóm tắt các tài nguyên từ xa cho containers chính. Vùng chứa chính kết nối trực tiếp với containers đại sứ, từ đó kết nối và tóm tắt các group tài nguyên bên ngoài phức tạp tiềm ẩn, như một cụm Redis phân tán. Vùng chứa chính không phải biết hoặc quan tâm đến môi trường triển khai thực tế để kết nối với các dịch vụ bên ngoài.
- Bộ điều hợp: Mẫu bộ điều hợp được sử dụng để dịch dữ liệu, giao thức hoặc giao diện của containers chính để phù hợp với các tiêu chuẩn mà các bên bên ngoài mong đợi. Vùng chứa bộ điều hợp cho phép truy cập thống nhất vào các dịch vụ tập trung ngay cả khi các ứng dụng mà chúng phân phối có thể chỉ hỗ trợ các giao diện không tương thích.
Extract cấu hình thành Sơ đồ cấu hình và Bí mật
Mặc dù cấu hình ứng dụng có thể được đưa vào các containers images , nhưng tốt nhất là làm cho các thành phần của bạn có thể cấu hình trong thời gian chạy để hỗ trợ triển khai trong nhiều ngữ cảnh và cho phép quản trị linh hoạt hơn. Để quản lý các thông số cấu hình chạy, Kubernetes Mời hai đối tượng gọi ConfigMaps và bí mật.
ConfigMaps là một cơ chế được sử dụng để lưu trữ dữ liệu có thể được hiển thị với group và các đối tượng khác trong thời gian chạy. Dữ liệu được lưu trữ trong ConfigMaps có thể được trình bày dưới dạng các biến môi trường hoặc được mount dưới dạng file trong group . Bằng cách thiết kế các ứng dụng của bạn để đọc từ các vị trí này, bạn có thể đưa cấu hình vào thời gian chạy bằng ConfigMaps và sửa đổi hành vi của các thành phần mà không cần phải xây dựng lại containers images .
Secrets là một loại đối tượng Kubernetes tương tự được sử dụng để lưu trữ an toàn dữ liệu nhạy cảm và cho phép chọn lọc các group và các thành phần khác truy cập khi cần thiết. Bí mật là một cách thuận tiện để chuyển tài liệu nhạy cảm đến các ứng dụng mà không cần lưu trữ chúng dưới dạng văn bản thuần túy ở các vị trí dễ truy cập trong cấu hình thông thường của bạn. Về mặt chức năng, chúng hoạt động giống như ConfigMaps, vì vậy các ứng dụng có thể tiêu thụ dữ liệu từ ConfigMaps và Secrets bằng cách sử dụng cùng một cơ chế.
ConfigMaps and Secrets giúp bạn tránh đặt cấu hình trực tiếp trong các định nghĩa đối tượng Kubernetes. Bạn có thể ánh xạ khóa cấu hình thay vì giá trị, cho phép bạn cập nhật cấu hình nhanh chóng bằng cách sửa đổi Bản đồ cấu hình hoặc Bí mật.Điều này mang lại cho bạn cơ hội thay đổi hành vi thời gian chạy hoạt động của group và các đối tượng Kubernetes khác mà không cần sửa đổi các định nghĩa Kubernetes về tài nguyên.
Triển khai các đầu dò về sự sẵn sàng và tính sống
Kubernetes bao gồm rất nhiều chức năng tiện ích để quản lý vòng đời của các thành phần và đảm bảo các ứng dụng của bạn luôn hoạt động tốt và khả dụng. Tuy nhiên, để tận dụng các tính năng này, Kubernetes phải hiểu cách nó sẽ theo dõi và diễn giải tình trạng ứng dụng của bạn. Để làm như vậy, Kubernetes cho phép bạn xác định liveness và sự sẵn sàng đầu dò.
Các đầu dò Liveness cho phép Kubernetes xác định liệu một ứng dụng trong containers có còn tồn tại và đang hoạt động hay không. Kubernetes có thể định kỳ chạy các lệnh bên trong containers để kiểm tra hành vi ứng dụng cơ bản hoặc có thể gửi các yêu cầu mạng HTTP hoặc TCP đến một vị trí được chỉ định để xác định xem quy trình có khả dụng và có thể đáp ứng như mong đợi hay không. Nếu một đầu dò độ sống thực không thành công, Kubernetes sẽ khởi động lại containers để cố gắng cài đặt lại chức năng trong group .
Đầu dò mức độ sẵn sàng là một công cụ tương tự được sử dụng để xác định liệu một group có sẵn sàng phục vụ lưu lượng truy cập hay không. Các ứng dụng trong một containers có thể cần thực hiện các thủ tục khởi tạo trước khi chúng sẵn sàng chấp nhận các yêu cầu của khách hàng hoặc chúng có thể cần reload khi được thông báo về cấu hình mới. Khi một thăm dò mức độ sẵn sàng không thành công, thay vì khởi động lại containers , Kubernetes tạm thời ngừng gửi các yêu cầu đến group . Điều này cho phép group hoàn thành quy trình khởi tạo hoặc bảo trì mà không ảnh hưởng đến sức khỏe của cả group .
Bằng cách kết hợp các thăm dò mức độ sống và mức độ sẵn sàng, bạn có thể hướng dẫn Kubernetes tự động khởi động lại các group hoặc xóa chúng khỏi các group backend . Việc cấu hình cơ sở hạ tầng của bạn để tận dụng các khả năng này cho phép Kubernetes quản lý tính khả dụng và tình trạng của các ứng dụng của bạn mà không cần các hoạt động bổ sung.
Sử dụng triển khai để quản lý quy mô và tính khả dụng
Trước đó, khi thảo luận về một số nguyên tắc cơ bản về thiết kế pod, ta cũng đã đề cập rằng các đối tượng Kubernetes khác xây dựng dựa trên các nguyên bản này để cung cấp chức năng nâng cao hơn. Một triển khai , một đối tượng ghép như vậy, có lẽ là đối tượng Kubernetes được định nghĩa và thao tác phổ biến nhất.
Triển khai là các đối tượng kết hợp xây dựng trên các bản root Kubernetes khác để thêm các khả năng bổ sung. Chúng bổ sung khả năng quản lý vòng đời cho các đối tượng trung gian được gọi là bản sao , như khả năng thực hiện cập nhật luân phiên, khôi phục về các version trước đó và chuyển đổi giữa các trạng thái. Các bản sao này cho phép bạn xác định các mẫu group để tạo và quản lý nhiều bản sao của một thiết kế group duy nhất. Điều này giúp bạn dễ dàng mở rộng cơ sở hạ tầng của bạn , quản lý các yêu cầu về tính khả dụng và tự động khởi động lại group trong trường hợp không thành công.
Các tính năng bổ sung này cung cấp một khung quản trị và khả năng tự phục hồi cho phần trừu tượng group tương đối đơn giản. Mặc dù group là đơn vị cuối cùng chạy dung lượng công việc bạn xác định, chúng không phải là đơn vị mà bạn thường nên cung cấp và quản lý. Thay vào đó, hãy nghĩ về group như một khối xây dựng có thể chạy các ứng dụng một cách mạnh mẽ khi được cung cấp thông qua các đối tượng cấp cao hơn như triển khai.
Tạo dịch vụ và luật nhập để quản lý quyền truy cập vào các lớp ứng dụng
Việc triển khai cho phép bạn cung cấp và quản lý các bộ group có thể swap cho nhau để mở rộng ứng dụng của bạn và đáp ứng nhu cầu của user .Tuy nhiên, định tuyến lưu lượng truy cập đến các group được cung cấp là một mối quan tâm riêng. Vì các group được swap như một phần của cập nhật lần lượt, được khởi động lại hoặc bị di chuyển do lỗi server lưu trữ, nên các địa chỉ mạng được liên kết trước đó với group đang chạy sẽ thay đổi. Các dịch vụ Kubernetes cho phép bạn quản lý sự phức tạp này bằng cách duy trì thông tin định tuyến cho các group group động và kiểm soát quyền truy cập vào các lớp khác nhau của cơ sở hạ tầng của bạn.
Trong Kubernetes, các dịch vụ là các cơ chế cụ thể kiểm soát cách lưu lượng truy cập được chuyển đến các group group . Cho dù chuyển tiếp lưu lượng truy cập từ các client bên ngoài hay quản lý kết nối giữa một số thành phần bên trong, các dịch vụ đều cho phép bạn kiểm soát cách lưu lượng truy cập. Kubernetes sau đó sẽ cập nhật và duy trì tất cả thông tin cần thiết để chuyển tiếp kết nối đến các group liên quan, ngay cả khi môi trường thay đổi và bối cảnh mạng thay đổi.
Truy cập dịch vụ nội bộ
Để sử dụng hiệu quả các dịch vụ, trước tiên bạn phải xác định đối tượng khách hàng dự định cho từng group group . Nếu dịch vụ của bạn sẽ chỉ được sử dụng bởi các ứng dụng khác được triển khai trong cụm Kubernetes của bạn, thì loại dịch vụ clusterIP cho phép bạn kết nối với một group group sử dụng địa chỉ IP ổn định chỉ có thể định tuyến từ bên trong cụm. Bất kỳ đối tượng nào được triển khai trên cụm đều có thể giao tiếp với group các group được sao chép bằng cách gửi lưu lượng truy cập trực tiếp đến địa chỉ IP của dịch vụ. Đây là loại dịch vụ đơn giản nhất, hoạt động tốt cho các lớp ứng dụng nội bộ.
Một addon DNS tùy chọn cho phép Kubernetes cung cấp tên DNS cho các dịch vụ. Điều này cho phép group và các đối tượng khác giao tiếp với các dịch vụ bằng tên thay vì bằng địa chỉ IP. Cơ chế này không thay đổi đáng kể việc sử dụng dịch vụ, nhưng các định danh dựa trên tên có thể giúp việc kết nối các thành phần hoặc xác định các tương tác trở nên đơn giản hơn mà không cần biết trước địa chỉ IP của dịch vụ.
Tiếp xúc Dịch vụ cho Tiêu dùng Công cộng
Nếu giao diện phải có thể truy cập , tùy chọn tốt nhất của bạn thường là loại dịch vụ cân bằng tải . Điều này sử dụng API của nhà cung cấp cloud cụ thể của bạn để cung cấp bộ cân bằng tải, cung cấp lưu lượng truy cập đến các group dịch vụ thông qua địa chỉ IP được công khai. Điều này cho phép bạn định tuyến các yêu cầu bên ngoài đến các group trong dịch vụ của bạn , cung cấp kênh mạng được kiểm soát cho mạng cụm bên trong của bạn.
Vì loại dịch vụ cân bằng tải tạo ra một bộ cân bằng tải cho mọi dịch vụ, nên việc hiển thị các dịch vụ Kubernetes một cách công khai bằng phương pháp này có thể trở nên tốn kém. Để giúp giảm bớt điều này, các đối tượng xâm nhập Kubernetes được dùng để mô tả cách định tuyến các loại yêu cầu khác nhau đến các dịch vụ khác nhau dựa trên một bộ luật được định nghĩa . Ví dụ: các yêu cầu cho “example.com” có thể chuyển đến dịch vụ A, trong khi các yêu cầu cho “sammytheshark.com” có thể được chuyển đến dịch vụ B. Các đối tượng Ingress cung cấp cách mô tả cách định tuyến một cách hợp lý stream yêu cầu hỗn hợp đến mục tiêu của chúng dịch vụ dựa trên các mẫu được định nghĩa .
Các luật xâm nhập phải được giải thích bởi bộ điều khiển xâm nhập - thường là một số loại cân bằng tải, như Nginx - được triển khai trong cụm dưới dạng một group , thực hiện các luật xâm nhập và chuyển tiếp lưu lượng đến các dịch vụ Kubernetes tương ứng.Hiện tại, loại đối tượng xâm nhập đang ở giai đoạn thử nghiệm, nhưng có một số triển khai hoạt động được dùng để giảm thiểu số lượng bộ cân bằng tải bên ngoài mà chủ sở hữu cụm được yêu cầu chạy.
Sử dụng cú pháp khai báo để quản lý trạng thái Kubernetes
Kubernetes cung cấp khá nhiều tính linh hoạt trong việc xác định và kiểm soát các tài nguyên được triển khai cho cụm của bạn. Sử dụng các công cụ như kubectl , bạn có thể xác định theo thứ bậc các đối tượng đặc biệt để triển khai ngay lập tức cho cụm của bạn . Mặc dù điều này có thể hữu ích cho việc triển khai nhanh chóng các tài nguyên khi học Kubernetes, nhưng có những hạn chế đối với cách tiếp cận này khiến nó không được mong muốn đối với việc quản trị production lâu dài.
Một trong những vấn đề lớn với quản lý mệnh lệnh là nó không để lại bất kỳ bản ghi nào về những thay đổi bạn đã triển khai cho cụm của bạn . Điều này gây khó khăn hoặc không thể khôi phục trong trường hợp lỗi hoặc theo dõi các thay đổi hoạt động khi chúng được áp dụng cho hệ thống của bạn.
May mắn là Kubernetes cung cấp một cú pháp khai báo thay thế cho phép bạn xác định đầy đủ tài nguyên trong các file văn bản và sau đó sử dụng kubectl để áp dụng cấu hình hoặc thay đổi. Lưu trữ các file cấu hình này trong repository lưu trữ kiểm soát version là một cách đơn giản để theo dõi các thay đổi và tích hợp với các quy trình đánh giá được sử dụng cho các bộ phận khác trong tổ chức của bạn. Quản lý dựa trên file cũng giúp dễ dàng điều chỉnh các mẫu hiện có với các tài nguyên mới bằng cách sao chép và chỉnh sửa các định nghĩa hiện có. Lưu trữ các định nghĩa đối tượng Kubernetes của bạn trong các folder được tạo version cho phép bạn duy trì ảnh chụp nhanh về trạng thái cụm mong muốn của bạn tại mỗi thời điểm. Điều này có thể là vô giá trong các hoạt động khôi phục, di chuyển hoặc khi theo dõi nguyên nhân root rễ của những thay đổi không mong muốn được đưa vào hệ thống của bạn.
Kết luận
Quản lý cơ sở hạ tầng sẽ chạy các ứng dụng của bạn và học cách tận dụng tốt nhất các tính năng được cung cấp bởi môi trường dàn nhạc hiện đại có thể là điều khó khăn. Tuy nhiên, nhiều lợi ích được cung cấp bởi các hệ thống như Kubernetes và các công nghệ như container trở nên rõ ràng hơn khi thực tiễn phát triển và hoạt động của bạn phù hợp với các khái niệm mà công cụ được xây dựng xung quanh. Kiến trúc hệ thống của bạn bằng cách sử dụng các mẫu Kubernetes vượt trội và hiểu cách một số tính năng nhất định có thể giảm bớt một số thách thức liên quan đến việc triển khai rất phức tạp có thể giúp cải thiện trải nghiệm của bạn khi chạy trên nền tảng.
Các tin liên quan
