Giới thiệu

Việc thiết kế và chạy các ứng dụng có khả năng mở rộng, tính di động và tính chắc chắn trong tâm trí có thể là một thách thức, đặc biệt là khi sự phức tạp của hệ thống phát triển. Kiến trúc của một ứng dụng hoặc hệ thống tác động đáng kể đến cách nó phải được chạy, những gì nó mong đợi từ môi trường của nó và cách nó kết hợp chặt chẽ với các thành phần liên quan. Theo các mẫu nhất định trong giai đoạn thiết kế và tuân thủ một số phương thức hoạt động nhất định có thể giúp chống lại 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.

Mặc dù các mẫu thiết kế phần mềm và các phương pháp phát triển có thể tạo ra các ứng dụng với các đặc điểm mở rộng quy mô, 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 nhóm đóng gói phần mềm và sau đó phân phối, triển khai và mở rộng trên các nền tảng của các máy tính được phân phối. Học cách khai thác sức mạnh của những công cụ này có thể giúp bạn quản lý các ứng dụng với sự linh hoạt, kiểm soát và phản hồi tốt hơn.

Trong hướng dẫn này, chúng tôi sẽ thảo luận một số nguyên tắc và mẫu mà bạn có thể muốn áp dụng để giúp bạn mở rộng quy mô và quản lý khối lượng công việc của mình trên Kubernetes. Trong khi Kubernetes có thể chạy nhiều loại khối lượng công việc, các lựa chọn bạn thực hiện có thể ảnh hưởng đến tính dễ vận hành và khả năng có sẵn khi triển khai. Làm thế nào bạn kiến ​​trúc sư và xây dựng các ứng dụng của bạn, đóng gói các dịch vụ của bạn trong các thùng chứa, và cấu hình quản lý vòng đời và hành vi 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 sản xuất phần mềm, nhiều yêu cầu ảnh hưởng đến các mẫu và kiến ​​trúc 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 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 thay thế cho -sự chia tỷ lệ dọc, cố gắng điều khiển các yếu tố tương tự 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 cho các 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ể kết hợp giao tiếp qua mạng thông qua các API REST được xác định tốt thay vì các chương trình hợp chất lớn hơn giao tiếp thông qua các cơ chế lập trình nội bộ. Phân hủy các ứng dụng nguyên khối thành các thành phần riêng biệt có mục đích làm cho 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 đến cõi 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ể, đám mây bản địa các ứng dụng được thiết kế với một số cân nhắc bổ sung trong tâm trí. Ứng dụng gốc của đám mây là các chương trình theo mô hình kiến ​​trúc microservices có tính khả năng phục hồi, khả năng quan sát và tính năng quản trị được tích hợp sẵn để thích nghi với môi trường được cung cấp bởi các nền tảng được nhóm trong đám mây.

Ví dụ, các ứng dụng bản địa đám mây được xây dựng với các chỉ số báo cáo sức khỏe để cho phép nền tảng quản lý các sự kiện vòng đời nếu một cá thể trở nên không lành mạnh. Họ sản xuất (và sẵn sàng cho xuất khẩu) dữ liệu 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ần khởi động lại và thất bại thường xuyên, các thay đổi về tính khả dụng của phụ trợ và tải cao mà không làm hỏng dữ liệu hoặc trở nên không phản hồi.

Sau 12 Triết lý ứng dụng

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 trên đám mây là Ứng dụng mười hai yếu tố triết học. Được viết để giúp các nhà phát triển và các nhóm hoạt động 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 đám mây, các nguyên tắc áp dụng rất tốt cho phần mềm sẽ sống trong môi trường nhóm như Kubernetes. Trong khi các ứng dụng nguyên khối có thể hưởng lợi từ việc tuân theo các khuyến nghị này, 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à:

  1. Codebase: Quản lý tất cả mã trong các hệ thống kiểm soát phiên bản (như Git hoặc Mercurial). Các codebase toàn diện ra lệnh cho những gì được triển khai.
  2. Phụ thuộc: Phụ thuộc nên được quản lý hoàn toàn và rõ ràng bởi codebase, hoặc được bán kèm (được lưu trữ với mã) hoặc phiên bản được ghim theo định dạng mà trình quản lý gói có thể cài đặt từ đó.
  3. Cấu hình: Phân tách các tham số cấu hình từ ứng dụng và định nghĩa chúng trong môi trường triển khai thay vì nướng chúng vào chính ứng dụng.
  4. Dịch vụ sao lưu: Các dịch vụ cục bộ và từ xa đều được trừu tượng hóa như 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 thiết lập trong cấu hình.
  5. 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 khỏi quá trình phát hành ứng dụng và quy trình hoạt động của bạn. Giai đoạn xây dựng tạo ra một tạo phẩm 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 việc phát hành.
  6. Quy trình: Các ứng dụng được thực hiện dưới dạng các quá trình không nên dựa vào trạng thái lưu trữ cục bộ. Nhà nước nên được bán cho một dịch vụ ủng hộ như được mô tả trong yếu tố thứ tư.
  7. Cổng ràng buộc: Các ứng dụng nên tự nhiên liên kết với một cổng và lắng nghe các kết nối. Định tuyến và yêu cầu chuyển tiếp phải được xử lý bên ngoài.
  8. Đồng thời: Các ứng dụng nên dựa vào nhân rộng thông qua mô hình quy trình. Chạy đồng thời nhiều bản sao của một ứng dụng, có khả năng trên nhiều máy chủ, cho phép mở rộng quy mô mà không cần điều chỉnh mã ứng dụng.
  9. Disposability: Quá trình sẽ có thể bắt đầu một cách nhanh chóng và ngăn chặn một cách duyên dáng mà không có tác dụng phụ nghiêm trọng.
  10. Tính chẵn lẻ Dev / prod: Các môi trường thử nghiệm, dàn dựng và sản xuất 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à những cơ hội cho sự không tương thích và cấu hình chưa được kiểm tra xuất hiện.
  11. Nhật ký: Các ứng dụng sẽ truyền các bản ghi đến đầu ra 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.
  12. Quy trình quản trị: Các quy trình quản trị một lần nên được chạy với các phiên bản cụ thể và được gửi kèm theo mã quy trình chính.

Bằng cách tuân thủ 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 cách sử dụng một 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, 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, đầu ra và các tính năng quản lý quy trình tiêu chuẩn để chạy dự đoán trong Kubernetes.

Container thành phần ứng dụng

Kubernetes sử dụng các thùng chứa để chạy các ứng dụng được đóng gói, bị cô lập trên các nút 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 hình ảnh vùng chứa và được thực hiện bằng cách sử dụng một thời gian chạy container như Docker. Trong khi 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, nó cũng giúp củng cố nhiều nguyên tắc từ phương pháp ứng dụng hệ số mười hai được thảo luận ở trên, cho phép dễ dàng mở rộng và quản lý.

Ví dụ, các thùng chứa cung cấp sự cách ly giữa môi trường ứng dụng và hệ thống máy chủ bên ngoài, hỗ trợ một cách tiếp cận mạng, hướng dịch vụ để liên lạc 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ị các bản ghi được ghi vào lỗi chuẩn và tiêu chuẩn. Bản thân các thùng chứa khuyến khích đồng thời dựa trên quy trình và giúp duy trì tính chẵn lẻ của dev / prod bằng cách độc lập có thể mở rộng 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 làm cho 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 đóng gói ứng dụng khác nhau. 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 các phương thức khác.

Hầu hết các phương pháp hay nhất về việc đóng gói các ứng dụng của bạn phải làm với 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 thiết lập và chạy từ bên trong một vùng chứa. Nói chung, việc giữ kích thước hình ảnh nhỏ và có thể phối lại cung cấp 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 vùng chứa mới trên một cụm bằng cách giữ cho dấu chân có thể quản lý và sử dụng lại các lớp hiện có giữa các bản cập nhật hình ảnh.

Bước đầu tiên tốt khi tạo hình ảnh vùng chứa 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 sản xuất. Phần mềm xây dựng thường yêu cầu công cụ bổ sung, mất thêm thời gian và tạo các tạo tác có thể không nhất quán từ vùng chứa đến vùng chứa hoặc không cần thiết cho 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 riêng quy trình xây dựng khỏi môi trường thời gian chạy là sử dụng Trình tạo nhiều vùng 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 khi chạy. Điều này làm cho 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 phẩm kết quả thành một hình ảnh mỏng, 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 này, thường là một ý tưởng tốt để xây dựng hình ảnh sản xuất ở trên cùng của hình ảnh cha mẹ tối thiểu. Nếu bạn muốn hoàn toàn tránh các đốm màu được tìm thấy trong các lớp cha mẹ "distro" giống như ubuntu:16.04 (bao gồm môi trường Ubuntu 16.04 hoàn chỉnh), bạn có thể xây dựng hình ảnh của mình scratch • Hình ảnh cơ bản tối thiểu của Docker - là cha mẹ. Tuy nhiên, scratch lớp cơ sở 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 đó, Alpine Linux alpine hình ảnh đã trở nên phổ biến bằng cách là một môi trường cơ sở vững chắc, tối thiểu 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 sản xuất. Tuy nhiên, vì hình ảnh mảnh mai vẫn lý tưởng nên nhiều hình ảnh được tối ưu hóa theo ngôn ngữ cụ thể được xây dựng trên đỉnh của Alpine Linux có sẵn trên Docker Hub. Lợi ích của việc sử dụng một hình ảnh nhỏ hơn cho các ngôn ngữ thông dịch tương tự như các ngôn ngữ biên dịch: Kubernetes sẽ có thể nhanh chóng kéo tất cả các hình ảnh vùng chứa cần thiết lên các nút mới để bắt đầu thực hiện các công việc có ý nghĩa.

Quyết định Phạm vi cho Container và Pods

Trong khi các ứng dụng của bạn phải được chứa để chạy trên một cụm Kubernetes, vỏ trái cây là đơn vị trừu tượng nhỏ nhất mà Kubernetes có thể quản lý trực tiếp. Một pod là một đối tượng Kubernetes bao gồm một hoặc nhiều container kết hợp chặt chẽ. Các thùng chứa trong một nhóm chia sẻ vòng đời và được quản lý với nhau như một đơn vị duy nhất. Ví dụ: các vùng chứa luôn được lên lịch trên cùng một nút, được bắt đầu hoặc dừng lại đồng loạt và chia sẻ tài nguyên như hệ thống tệp và không gian IP.

Ban đầu, có thể khó phát hiện ra cách tốt nhất để chia ứng dụng của bạn thành các vùng chứa và các nhóm. Đ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à mỗi lớp trừu tượng nào cung cấp cho các hệ thống của bạn. Một vài cân nhắc có thể giúp bạn xác định một số điểm đóng gói tự nhiên cho ứng dụng của bạn với mỗi sự trừu tượng này.

Một cách để xác định phạm vi hiệu quả cho các thùng chứa của bạn là tìm kiếm 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 thùng chứa được thiết kế tốt thường được xây dựng để đại diện cho các đơn vị riêng biệt của chức năng thường có thể được sử dụng trong nhiều ngữ cảnh khác nhau. Mức trừu tượng này cho phép nhóm của bạn giải phóng các thay đổi đối với hình ảnh vùng chứa và sau đó triển khai chức năng mới này cho bất kỳ môi trường nào nơi 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 soạn các thùng chứa riêng lẻ, mỗi vùng chứa một hàm đã cho nhưng có thể không hoàn thành toàn bộ quá trình.

Trái ngược với những điều trên, các nhóm thường được xây dựng bằng cách suy nghĩ về những phần nào trong hệ thống của bạn có thể hưởng lợi nhiều nhất từ ​​độc lập sự quản lý. Vì Kubernetes sử dụng các pod làm trừu tượng hóa người dùng nhỏ nhất, đây là những đơn vị nguyên thủy nhất mà các công cụ Kubernetes và API có thể tương tác trực tiếp và kiểm soát. Bạn có thể bắt đầu, dừng và khởi động lại các nhóm hoặc sử dụng các đối tượng cấp cao hơn được xây dựng dựa trên các nhóm để giới thiệu các tính năng quản lý vòng lặp và nhân rộng. Kubernetes không cho phép bạn quản lý các thùng chứa trong một nhóm độc lập, vì vậy bạn không nên nhóm các thùng chứa lại với nhau mà có thể hưởng lợi từ việc quản trị riêng biệt.

Bởi vì nhiều tính năng và trừu tượng của Kubernetes đối phó trực tiếp với các nhóm, nên việc sắp xếp các mục cần được chia tỷ lệ với nhau thành một nhóm duy nhất và tách riêng các phần đó sẽ được chia tỷ lệ một cách độc lập. Ví dụ: tách máy chủ web của bạn khỏi máy chủ ứng dụng của bạn trong các nhóm khác nhau cho phép bạn chia tỷ lệ từng lớp một cách độc lập khi cần. Tuy nhiên, việc gộp máy chủ web và bộ điều hợp cơ sở dữ liệu vào cùng một nhóm có thể có ý nghĩa nếu bộ điều hợp cung cấp chức năng cần thiết mà máy chủ web cần để hoạt động chính xác.

Nâng cao chức năng của Pod bằng cách gộp các vùng chứa hỗ trợ

Với điều này trong tâm trí, những loại container nên được đóng gói trong một nhóm duy nhất? Nói chung, thùng chứa chính chịu trách nhiệm hoàn thành các chức năng cốt lõi của nhóm, nhưng các vùng chứa bổ sung có thể được xác định là sửa đổi hoặc mở rộng vùng chứa chính hoặc giúp nó kết nối với môi trường triển khai duy nhất.

Ví dụ, trong một pod máy chủ web, một thùng chứa Nginx có thể lắng nghe các yêu cầu và phục vụ nội dung trong khi một thùng chứa liên quan cập nhật các tệp tĩnh khi một kho lưu trữ thay đổi. Có thể muốn đóng gói cả hai thành phần này trong một vùng chứa duy nhất, nhưng có những lợi ích đáng kể để triển khai chúng dưới dạng các vùng chứa riêng biệt. Cả thùng chứa máy chủ web và trình chứa kho lưu trữ đều có thể được sử 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 nhóm khác nhau và mỗi nhóm có thể được phát triển để khái quát hóa hành vi của chúng để làm việc với các thùng chứa đồng hành khác nhau.

Brendan Burns và David Oppenheimer đã xác định ba mẫu chính để đóng gói các thùng chứa 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 vùng chứa. Các trường hợp 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 thùng chứa với nhau trong một nhóm:

  • Sidecar: Trong mẫu này, container thứ cấp mở rộng và tăng cường chức năng cốt lõi của thùng chứa chính. Mẫu này liên quan đến việc thực hiện các hàm không chuẩn hoặc tiện ích trong một vùng chứa riêng biệt. Ví dụ: một vùng chứa chuyển tiếp nhật ký hoặc đồng hồ cho 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 nhóm mà không thay đổi đáng kể trọng tâm chính của nó.
  • Đại sứ: Mô hình đại sứ sử dụng một thùng chứa bổ sung để trừu tượng các tài nguyên từ xa cho thùng chứa chính. Vùng chứa chính kết nối trực tiếp với container đại sứ mà lần lượt kết nối và tóm tắt các nhóm tài nguyên bên ngoài phức tạp tiềm tàng, 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 vùng chứa chính để phù hợp với các tiêu chuẩn mà các bên bên ngoài mong đợi. Adapter container cho phép truy cập đồng bộ vào các dịch vụ tập trung ngay cả khi các ứng dụng mà chúng phục vụ chỉ có thể hỗ trợ các giao diện không tương thích.

Trích xuất cấu hình vào ConfigMaps và bí mật

Trong khi cấu hình ứng dụng có thể được đưa vào các hình ảnh vùng chứa, 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 tham số cấu hình thời gian chạy, Kubernetes cung cấp hai đối tượng được gọi là ConfigMapsBí mật.

ConfigMaps là một cơ chế được sử dụng để lưu trữ dữ liệu có thể được tiếp xúc với các nhóm và các đối tượng khác khi chạy. Dữ liệu được lưu trữ trong ConfigMaps có thể được trình bày dưới dạng biến môi trường hoặc được gắn kết dưới dạng tệp trong nhóm. 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ể tiêm cấu hình lúc chạy bằng ConfigMaps và sửa đổi hành vi của các thành phần của bạn mà không cần phải xây dựng lại hình ảnh vùng chứa.

Bí mật 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 nhóm và các thành phần khác khi cần thiết. Bí mật là 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 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 bình 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 và 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 khi đang di chuyển bằng cách sửa đổi ConfigMap hoặc Secret. Điều này cho bạn cơ hội thay đổi hành vi thời gian hoạt động của các nhóm và các đối tượng Kubernetes khác mà không sửa đổi các định nghĩa Kubernetes của các tài nguyên.

Thực hiện các đầu dò sẵn sàng và khả năng sống

Kubernetes bao gồm rất nhiều chức năng vượt trội để quản lý các vòng đời thành phần và đảm bảo rằng các ứng dụng của bạn luôn luôn lành mạnh và có sẵn. Tuy nhiên, để tận dụng được những tính năng này, Kubernetes phải hiểu cách nó nên theo dõi và giải thích sức khỏe của ứng dụng của bạn. Để làm như vậy, Kubernetes cho phép bạn xác định livenesssẵ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 một container có còn sống hay đang hoạt động hay không. Kubernetes có thể định kỳ chạy các lệnh trong vùng chứa để kiểm tra hành vi ứng dụng cơ bản hoặc có thể gửi yêu cầu mạng HTTP hoặc TCP đến một vị trí được chỉ định để xác định xem quá trình có sẵn và có thể phản hồi như mong đợi hay không. Nếu một thăm dò liveness thất bại, Kubernetes khởi động lại vùng chứa để cố gắng thiết lập lại chức năng trong nhóm.

Các đầu dò sẵn sàng là một công cụ tương tự được sử dụng để xác định liệu một nhóm có sẵn sàng phân phát lưu lượng truy cập hay không. Các ứng dụng trong một container có thể cần phải 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 máy khách hoặc chúng có thể cần phải tải lại khi được thông báo về một cấu hình mới. Khi một đầu dò sẵn sàng không thành công, thay vì khởi động lại vùng chứa, Kubernetes ngừng tạm thời gửi yêu cầu tới nhóm. Điều này cho phép các pod hoàn thành việc khởi tạo hoặc bảo trì các thói quen của nó mà không ảnh hưởng đến sức khỏe của cả nhóm.

Bằng cách kết hợp các đầu dò liveness và sẵn sàng, bạn có thể hướng dẫn Kubernetes tự động khởi động lại các nhóm hoặc loại bỏ chúng khỏi các nhóm phụ trợ. 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à sức khỏe của các ứng dụng của bạn mà không cần thêm 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ế vỏ, chúng tôi cũng đã đề cập rằng các đối tượng Kubernetes khác xây dựng trên các nguyên thủy này để cung cấp chức năng nâng cao hơn. A triển khai, một đối tượng ghép như vậy, có lẽ là đối tượng Kubernetes được xác định và điều khiển phổ biến nhất.

Các triển khai là các đối tượng phức hợp xây dựng trên các thành phần cốt lõi khác của Kubernetes để bổ sung các khả năng bổ sung. Họ bổ sung khả năng quản lý vòng đời cho các vật trung gian gọi là bản sao, giống như khả năng thực hiện cập nhật cán, quay lại phiên bản cũ hơn và chuyển đổi giữa các tiểu bang. Những bản sao này cho phép bạn xác định các mẫu pod để quay lên và quản lý nhiều bản sao của một thiết kế một nhóm. Điều này giúp bạn dễ dàng mở rộng cơ sở hạ tầng của mình, quản lý các yêu cầu về tính khả dụng và tự động khởi động lại nhóm trong trường hợp không thành công.

Những 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 sự trừu tượng hóa tương đối đơn giản. Trong khi nhóm là các đơn vị cuối cùng chạy các tải công việc bạn xác định, chúng không phải là các đơn vị mà bạn thường nên cung cấp và quản lý. Thay vào đó, hãy nghĩ về các nhóm 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à quy tắc nhập để quản lý quyền truy cập vào lớp ứng dụng

Triển khai cho phép bạn cung cấp và quản lý các bộ nhóm có thể hoán đổi cho nhau để mở rộng các ứng dụng của bạn và đáp ứng nhu cầu của người dùng. Tuy nhiên, việc định tuyến lưu lượng truy cập đến các nhóm được cung cấp là một mối quan tâm riêng biệt. Khi các nhóm được hoán đổi như một phần của các bản cập nhật, khởi động lại hoặc di chuyển do lỗi máy chủ, các địa chỉ mạng trước đây được liên kết với nhóm đang chạy sẽ thay đổi. Kubernetes dịch vụ 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 nhóm động của nhóm và kiểm soát quyền truy cập vào các lớp khác nhau trong 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 định tuyến đến các bộ nhóm. Việc chuyển tiếp lưu lượng truy cập từ khách hàng bên ngoài hay quản lý kết nối giữa một số thành phần nội bộ, dịch vụ cho phép bạn kiểm soát lưu lượng truy cập sẽ như thế nào. 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 tới các nhóm liên quan, ngay cả khi môi trường thay đổi và thay đổi cảnh quan mạng.

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 người tiêu dùng dự định cho từng nhóm quả. 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, clusterIP loại dịch vụ cho phép bạn kết nối với bộ nhóm bằng địa chỉ IP ổn định chỉ có thể định tuyến từ 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 nhóm các nhóm đượ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 tùy chọn bổ sung DNS cho phép Kubernetes cung cấp tên DNS cho các dịch vụ. Điều này cho phép các nhóm và các đối tượng khác giao tiếp với các dịch vụ theo tên thay vì theo đị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ể làm cho nó đơn giản hơn để nối các thành phần hoặc xác định tương tác mà không biết địa chỉ IP dịch vụ trước thời hạn.

Phơi bày dịch vụ cho tiêu dùng công

Nếu giao diện có thể truy cập công khai, tùy chọn tốt nhất của bạn thường là cân bằng tải loại dịch vụ. Điều này sử dụng API của nhà cung cấp đám mây 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 cho nhóm dịch vụ thông qua địa chỉ IP được hiển thị 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 tới các nhóm 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 nội bộ của bạn.

Vì kiểu 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ó có khả năng trở nên đắt đỏ khi trưng ra các dịch vụ Kubernetes công khai bằng phương pháp này. Để giúp giảm bớt điều này, Kubernetes xâm nhập các đối tượng có thể được sử dụng để mô tả cách định tuyến các loại yêu cầu khác nhau cho các dịch vụ khác nhau dựa trên một bộ quy tắc xác định trước. 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 định tuyến đến dịch vụ B. Các đối tượng Ingress cung cấp cách mô tả cách hợp lý định tuyến luồng yêu cầu đến mục tiêu của chúng dịch vụ dựa trên các mẫu được xác định trước.

Các quy tắc Ingress phải được diễn giải 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 như một nhóm, thực hiện các quy tắc xâm nhập và chuyển tiếp lưu lượng truy cập đế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ó thể được sử dụng để giảm thiểu số lượng 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 hoàn toàn có thể xác định các đối tượng ad-hoc để triển khai ngay lập tức vào cụm của bạn. Mặc dù điều này có thể hữu ích để nhanh chóng triển khai tài nguyên khi học Kubernetes, nhưng có những hạn chế đối với phương pháp này khiến cho việc quản lý sản xuất lâu dài trở nên không mong muốn.

Một trong những vấn đề chính với quản lý cấp bách 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 làm cho nó khó khăn hoặc không thể phục hồi trong trường hợp thất bạ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 thay, Kubernetes cung cấp một cú pháp khai báo thay thế cho phép bạn định nghĩa đầy đủ các tài nguyên trong các tệp 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 tệp cấu hình này trong kho kiểm soát phiên bản là một cách đơn giản để theo dõi các thay đổi và tích hợp với các quá trình xem xét được sử dụng cho các phần khác của tổ chức của bạn. Quản lý dựa trên tệp cũng làm cho nó đơn giản để thích nghi với các mẫu hiện có cho 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ó. Việc lưu trữ các định nghĩa đối tượng Kubernetes của bạn trong các thư mục được phiên bản cho phép bạn duy trì một bản chụp 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ể 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 gốc rễ của các thay đổi không mong muốn được giới thiệu cho hệ thống của bạn.

Phầ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à tìm hiểu 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ể gây 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 các hoạt động 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 trội và hiểu cách một số tính năng nhất định có thể làm giảm bớt một số thách thức liên quan đến triển khai phức tạp có thể giúp cải thiện trải nghiệm của bạn trên nền tảng.