Trong bài viết này, chúng ta sẽ trả lời những câu hỏi sau:
- Kubernetes là gì?
- Nó sinh ra để giải quyết bài toán hay vấn đề gì?
- Khi nào bạn nên chọn sử dụng Kubernetes? Có những lựa chọn thay thế nào?
Trước khi đi sâu vào và trả lời những câu hỏi này, chúng ta hãy thảo luận ngắn gọn về một số thông tin cơ bản. Điều này sẽ giúp chúng ta hiểu rõ hơn về động lực nằm đằng sau việc thiết kế một hệ thống giống như Kubernetes.
Bối cảnh của các ứng dụng phần mềm trong những ngày đầu
Trong những ngày đầu, các ứng dụng phần mềm được thiết kế và triển khai dưới dạng các ứng dụng nguyên khối (monolithic applications) . Trong các ứng dụng nguyên khối , phiên bản duy nhất thực hiện tất cả các chức năng nghiệp vụ.
Phần lớn các ứng dụng này là ứng dụng phần mềm Doanh nghiệp, có nghĩa là được sử dụng bởi một tổ chức duy nhất. Chúng được triển khai và bảo trì nội bộ, tại chỗ . Các ứng dụng này chủ yếu được sử dụng cho các nhiệm vụ đơn giản như kế toán và thanh toán trong tổ chức.
Thiết kế các ứng dụng như vậy với một tập hợp các tham số không đổi được xác định trước (chẳng hạn như quy mô và yêu cầu của tổ chức), có thể đảm bảo hiệu suất cao và mạnh mẽ. Thời gian ngừng hoạt động để bảo trì đã được chấp nhận vì tính sẵn sàng 24/7 của các ứng dụng này không phải là một yêu cầu quan trọng trong những ngày đó.
Thiên niên kỷ mới đầy đột phá
Những đột phá về công nghệ vào cuối những năm 90 và đầu những năm 2000 đã đẩy giới hạn của những gì có thể có từ một ứng dụng phần mềm. Các ứng dụng phần mềm bắt đầu thực hiện các nhiệm vụ ngày càng phức tạp hơn, như thông minh kinh doanh, quản lý quan hệ khách hàng, v.v.
Để xử lý hiệu quả sự phức tạp này, cơ sở mã của các ứng dụng này đã tăng kích thước . Ngoài ra, sự phát triển theo cấp số nhân của Internet trong khoảng thời gian này đã thêm một chiều hướng hoàn toàn mới và khai sinh ra một loại mới – ứng dụng web .
Có thể truy cập từ mọi nơi trên web, các ứng dụng web này dự kiến sẽ có sẵn suốt ngày đêm mà không cần thời gian chết. Khối lượng công việc trên các ứng dụng web không được xác định trước và chúng được kỳ vọng sẽ đủ khả năng phục hồi để xử lý những biến động bất ngờ về khối lượng công việc.
Sự nổi lên của cloud computing (điện toán đám mây)
Khi kích thước của các ứng dụng và nhu cầu về tính khả dụng của chúng suốt ngày đêm tăng lên, việc duy trì các ứng dụng này tại chỗ trở thành một thách thức. Chi phí và nỗ lực kỹ thuật cần thiết để duy trì phần cứng vật lý không có ý nghĩa kinh tế. Thay vào đó, một giải pháp thay thế mới nhanh chóng trở thành sự lựa chọn phổ biến, đó là các nền tảng điện toán đám mây theo yêu cầu .
Nền tảng điện toán đám mây cung cấp tài nguyên phần cứng vật lý cần thiết để chạy các ứng dụng như một dịch vụ. Các tổ chức này hứa hẹn tính khả dụng và độ tin cậy cao của cơ sở hạ tầng của họ, đồng thời tính phí khách hàng của họ dựa trên số lượng tài nguyên họ đã sử dụng và trong thời gian bao lâu.
Việc không phải duy trì phần cứng vật lý trong thế giới của định luật Moore và tùy chọn trả tiền cho mỗi lần sử dụng, đã thúc đẩy việc áp dụng rộng rãi đám mây. Amazon Web Services (AWS) , Microsoft Azure và Google Cloud là một số Nhà cung cấp Dịch vụ Cloud phổ biến hiện nay.
Các vấn đề về phát triển và triển khai vẫn chưa được giải quyết
Ngay cả khi Cloud xử lý vấn đề phần cứng vật lý , có rất nhiều vấn đề trong vòng đời ứng dụng vẫn chưa được giải quyết – ví dụ như phát triển và triển khai .
- Thời gian xây dựng lớn. Code base quá lớn dẫn đến thời gian xây dựng lớn, tức là thời gian chết lớn để triển khai. Nhưng tính khả dụng cao là một yêu cầu quan trọng và thời gian chết là không thể chấp nhận được.
- Phát triển chậm. Một vấn đề lớn khác với code base lớn, là ảnh hưởng của nó đến tốc độ phát triển. Vì toàn bộ code base được bao gồm trong một phiên bản duy nhất, một đoạn code bị hỏng từ một nhà phát triển trong nhóm, có thể chặn triển khai công việc của hàng trăm nhà phát triển khác. Vào đầu những năm 2000, phương pháp phát triển phần mềm Agile nổi lên, ủng hộ sự phát triển theo hướng tiến hóa, phân phối sớm và cải tiến liên tục. Nhưng phong cách nguyên khối không khuyến khích các nhà phát triển thực hiện những thay đổi gia tăng nhỏ, vì chi phí triển khai mới rất cao.
- Khả năng phục hồi kém . Một ứng dụng web nguyên khối xử lý lỗi ứng dụng rất kém. Trong một ứng dụng nguyên khối, tất cả các chức năng nghiệp vụ được xử lý bởi một phiên bản duy nhất. Một lỗi nghiêm trọng trong việc phát triển một tính năng mới , có thể làm hỏng toàn bộ ứng dụng. Thay vì toàn bộ chức năng không hoạt động, chúng ta muốn một đoạn script trong đó phần hoạt động tốt của ứng dụng vẫn có sẵn mà không bị gián đoạn, trong khi chức năng dễ xảy ra lỗi được sửa.
- Sử dụng tài nguyên thấp. Khi khối lượng công việc để thực hiện một chức năng kinh doanh cụ thể tăng đột ngột, toàn bộ ứng dụng nguyên khối phải được thu nhỏ, để cân bằng khối lượng công việc. Điều này dẫn đến tiêu thụ tài nguyên máy tính dưới mức tối ưu. Trong thế giới đám mây , việc sử dụng tài nguyên dư thừa sẽ gây tốn kém. Thay vào đó, người ta sẽ thích một kịch bản mà chỉ một phần nhỏ của ứng dụng, cần thiết để xử lý các quy mô chức năng kinh doanh cần thiết, dẫn đến việc sử dụng tài nguyên tối ưu.
Microservices
Một nỗ lực kỹ thuật trong toàn ngành để tránh các vấn đề (với phong cách kiến trúc nguyên khối) được thảo luận ở trên, đã dẫn đến sự phát triển của phong cách kiến trúc – Microservices .
Theo phong cách này, ứng dụng được thiết kế như một tập hợp các dịch vụ được ghép nối lỏng lẻo (các ứng dụng nhỏ hơn), thay vì một ứng dụng nguyên khối lớn. Mỗi dịch vụ này đảm nhiệm một chức năng khép kín. Các dịch vụ này liên lạc với nhau bất cứ khi nào cần thiết và làm việc cùng nhau để đáp ứng tất cả các yêu cầu kinh doanh.
Việc phân tách một ứng dụng thành các dịch vụ nhỏ hơn khác nhau giúp dễ hiểu, phát triển và thử nghiệm hơn. Tất cả các vấn đề nêu trên với phong cách nguyên khối đều được giải quyết.
- Chỉ một dịch vụ nhỏ phải được xây dựng lại bất cứ khi nào code được cập nhật, do đó giảm thời gian triển khai. Việc giảm thời gian triển khai khuyến khích việc phân phối và triển khai liên tục.
- Việc phân rã cũng dẫn đến việc ứng dụng trở nên linh hoạt hơn trước các lỗi, vì thời gian ngừng hoạt động chỉ được quan sát đối với các dịch vụ dễ xảy ra lỗi, trong khi các dịch vụ khác vẫn hoạt động đầy đủ .
- Các biến động về khối lượng công việc có thể được xử lý hiệu quả hơn nhiều. Có thể sử dụng tối ưu tài nguyên đám mây, nếu số lượng bản sao của dịch vụ được điều chỉnh động trên mỗi khối lượng công việc.
Những thử thách mới
Mặc dù phong cách Microservices đã giải quyết hầu hết các vấn đề với các ứng dụng tại chỗ nguyên khối, nhưng nó lại đưa ra những thách thức mới.
- Sử dụng dự phòng tài nguyên đám mây. Như đã đề cập trước đó, trong Microservices, việc mở rộng quy mô động các bản sao của dịch vụ là điều cần thiết để sử dụng tối ưu tài nguyên đám mây. Điều này sẽ yêu cầu quyền kiểm soát tinh chỉnh đối với cách sử dụng tài nguyên đám mây. Trong kiến trúc Microservices có quá nhiều bộ phận chuyển động . Việc kiểm soát việc sử dụng tất cả tài nguyên đám mây theo cách thủ công là không khả thi. Vì vậy, thách thức mới là thiết kế một giải pháp kiểm soát việc sử dụng tài nguyên đám mây ở mức độ tinh chỉnh.
- Cơn ác mộng của các hoạt động triển khai. Trong Microservices, chúng ta đang chia một ứng dụng thành nhiều ứng dụng nhỏ hơn. Cần phải cẩn thận để đảm bảo rằng giao tiếp giữa các dịch vụ hiệu quả và ổn định, và hệ điều hành của máy chủ lưu trữ có tất cả các phụ thuộc cần thiết trước khi triển khai.
- Hệ thống hiện có nhiều ứng dụng nhỏ hơn thay vì một. Do đó, cách tiếp cận cần thiết để giám sát ứng dụng tổng thể nên được sửa đổi để xử lý một số lượng lớn các ứng dụng nhỏ hơn. Làm cho toàn bộ quá trình phức tạp hơn nhiều.
- Sự phức tạp này nhanh chóng tăng lên cùng với số lượng dịch vụ và không quá lời khi nói rằng nhiệm vụ thực hiện các hoạt động triển khai trở thành một cơn ác mộng . Một giải pháp mạnh mẽ để xử lý tốt hơn sự phức tạp của các hoạt động triển khai đã trở nên không thể thiếu.
Đổi mới cho những thách thức mới
Các giải pháp cho những thách thức mới này đòi hỏi phải có hai đổi mới chính mới.
Cải tiến quan trọng đầu tiên, trở thành một phần không thể thiếu của giải pháp xử lý việc triển khai các ứng dụng phân tán trên đám mây, là Containerization . Containerization là việc triển khai các ứng dụng bằng cách đóng gói chúng trong một container.
Container là gì
Container là một ảo hóa cấp hệ điều hành , trong đó kernel cho phép tồn tại nhiều cá thể không gian người dùng biệt lập.
Nói một cách đơn giản hơn, bạn có thể nói rằng container là một máy tính ảo đầy đủ chức năng, chạy bên trong một máy tính khác (máy chủ). Mỗi container được cách ly với các container khác và với máy chủ.
Các container có hệ thống tệp riêng. Chúng không thể nhìn thấy các tiến trình của nhau và việc sử dụng tài nguyên tính toán của chúng có thể bị giới hạn. Docker , Containerd và rkt là những ví dụ về hệ thống container.
Tại sao việc chứa ứng dụng lại quan trọng cho việc triển khai?
- Tách ứng dụng và cơ sở hạ tầng. Theo truyền thống, các ứng dụng phần mềm được triển khai trực tiếp trên máy chủ. Điều này có nhược điểm là vướng các tệp thực thi, cấu hình, thư viện và vòng đời của ứng dụng với nhau và với hệ điều hành chủ. Nhưng cách tiếp cận mới này để đóng gói từng ứng dụng và các phần phụ thuộc của nó vào một container cách ly tự túc, khiến ứng dụng hoàn toàn tách rời khỏi hệ điều hành chủ và cơ sở hạ tầng. Nó cho phép triển khai một ứng dụng trên bất kỳ máy chủ nào, trước tiên không cần lo lắng nếu máy chủ đó đã cài đặt tất cả các phần phụ thuộc.
- Cô lập các tài nguyên. Ngoài việc tách ứng dụng khỏi máy chủ lưu trữ, một lợi thế quan trọng hơn nữa với công cụ chứa là sự cô lập các tài nguyên. Nếu nhiều container đang chạy trên một máy chủ, lỗi nghiêm trọng bên trong một container không thể ảnh hưởng đến các container khác hoặc máy chủ.
- So với điều này, khi tất cả các ứng dụng được cài đặt trực tiếp trên máy chủ, một lỗi nghiêm trọng có thể làm hỏng hoặc làm hỏng các ứng dụng khác và trong một số trường hợp có thể làm hỏng toàn bộ máy chủ. Nhưng không có phạm vi cho tình huống như vậy nếu các ứng dụng được triển khai trong container. Việc chứa các ứng dụng mang lại giá trị lớn và sẽ đơn giản hóa rất nhiều sự phức tạp liên quan đến việc phát triển, triển khai và duy trì các ứng dụng phân tán.
- Không lâu trước khi các nhóm kỹ sư khác nhau trong ngành nhận ra những lợi thế của việc chứa các ứng dụng và quyết định rằng mọi ứng dụng được triển khai trong tổ chức của họ đều phải được “chứa”.
Hệ thống điều phối container
Ngay sau khi ngành công nghiệp áp dụng công nghệ hóa container, nhu cầu đổi mới quan trọng thứ hai của chúng ta đã ra đời. Sự đổi mới này là hệ thống điều phối container . Ở cấp độ cao, hệ thống điều phối container cho phép người dùng quản lý hiệu quả việc triển khai các ứng dụng được chứa trong container.
Bộ điều phối container làm gì? Nó nằm ở đâu trong hệ thống? Nó có bao nhiêu trách nhiệm? Nó phải phức tạp như thế nào? Câu trả lời cho mỗi câu hỏi này không xác định và hoàn toàn phụ thuộc vào các lựa chọn của nhóm kỹ sư đã thiết kế hệ thống điều phối container cụ thể đó.
Người ta có thể nói rằng tất cả những gì mà hệ thống điều phối container mang lại là khả năng khởi động và dừng các ứng dụng được chứa trong container, và nó không đủ xứng đáng để trở thành một thành phần riêng biệt trong hệ thống. Nhưng kinh nghiệm của nhiều đội kỹ sư trong ngành đã cho thấy rằng không phải như vậy. Để hiểu tại sao không, chúng ta hãy lùi lại một bước và tóm tắt cuộc thảo luận của chúng ta cho đến nay, đồng thời tóm tắt lại những yêu cầu quan trọng và những vấn đề chưa được giải quyết mà chúng ta đã nêu ra.
- Các ứng dụng xử lý các hoạt động phức tạp quy mô lớn phải có tính khả dụng cao mà không có bất kỳ thời gian chết nào.
- Các ứng dụng phải có khả năng chống chịu với những biến động lớn về khối lượng công việc.
- Việc không sử dụng tối ưu tài nguyên đám mây sẽ dẫn đến chi phí lớn.
- Việc thực hiện các hoạt động triển khai một cách đáng tin cậy, để hỗ trợ sự phát triển tiến hóa là rất quan trọng.
Hầu hết tất cả các tổ chức quy mô lớn trong ngành bắt đầu đối mặt với một số vấn đề ở trên vào cuối những năm 2000 hoặc đầu những năm 2010. Và các nhóm kỹ sư tại các tổ chức này đã nỗ lực để giải quyết những vấn đề này.
Một số nhóm trong số này đã xây dựng một gói phần mềm riêng cho từng vấn đề mà họ gặp phải. Nhưng nhiều nhóm cuối cùng đã nhận ra rằng thiết kế một hệ thống điều phối container, giải quyết tất cả những vấn đề này cùng nhau, là cách tiếp cận tốt nhất . Một hệ thống điều phối container mạnh mẽ và được thiết kế tốt có thể làm cho hệ thống linh hoạt, hiệu quả và hoàn toàn loại bỏ sự phức tạp của các hoạt động triển khai từ người dùng.
Bây giờ chúng ta hiểu rằng nỗ lực kỹ thuật để xây dựng một hệ thống điều phối container là có giá trị. Hãy tập trung vào một trong những nỗ lực như vậy – công việc được thực hiện bởi nhóm kỹ sư tại Google. Trong nhiều năm, nhóm kỹ sư tại Google đã làm việc trên nhiều dự án nội bộ, nhằm giải quyết các vấn đề triển khai.
Ban đầu, họ nhận ra những lợi ích của Containerization , khi thực hiện các hoạt động triển khai ở quy mô lớn. Sau đó, họ tiếp tục thiết kế một hệ thống để tự động hóa việc triển khai, mở rộng và quản lý ứng dụng được container hóa. Nỗ lực thiết kế một hệ thống có thể hoạt động đáng tin cậy ở quy mô của Google, đã mang lại cho nhóm kỹ sư những hiểu biết hữu ích và hiếm có .
Sau khi nhận ra mức độ phổ biến của các vấn đề mà họ đã giải quyết, nhóm kỹ sư của Google đã xem xét việc chuyển đổi công nghệ này và bắt đầu làm việc trên một dự án mới – định hình lại các khái niệm đằng sau các dự án nội bộ của họ, để hoạt động song song với các công nghệ nguồn mở khác.
Năm 2014, Google mở nguồn dự án này với tên Kubernetes .
Kubernetes là gì?
Để trích dẫn tài liệu chính thức:
Kubernetes ( K8s ) là một hệ thống mã nguồn mở để tự động hóa việc triển khai, mở rộng quy mô và quản lý các ứng dụng chứa trong container. Nó nhóm các container tạo nên một ứng dụng thành các đơn vị logic để dễ dàng quản lý và khám phá.
Kubernetes là một hệ thống điều phối container do Google phát triển. Kubernetes được thiết kế để giải quyết hiệu quả nhiều vấn đề mà chúng ta đã nêu trước đó.
- Kubernetes có thể chạy các ứng dụng chứa trong bất kỳ quy mô nào mà không cần thời gian ngừng hoạt động.
- Kubernetes có thể tự “chữa lành” các ứng dụng trong container, giúp chúng có khả năng phục hồi trước các lỗi không mong muốn.
- Kubernetes có thể tự động mở rộng quy mô các ứng dụng được chứa trong container theo khối lượng công việc và đảm bảo sử dụng tối ưu tài nguyên đám mây.
- Kubernetes đơn giản hóa đáng kể quá trình hoạt động triển khai. Với Kubernetes, một hoạt động phức tạp đến đâu, nó có thể được thực hiện một cách đáng tin cậy bằng cách thực hiện một vài lệnh.
Mặc dù Kubernetes ban đầu được thiết kế bởi Google, nhưng giờ đây Kubernetes đã được duy trì bởi Cloud Native Computing Foundation (CNCF) – một nền tảng phần mềm mã nguồn mở dành riêng cho việc biến điện toán đám mây trở nên phổ biến và bền vững. Kể từ khi Kubernetes phát hành lần đầu, cộng đồng mã nguồn mở đã đóng góp rất nhiều vào sự phát triển của nó; thêm các tính năng mới và làm cho Kubernetes mạnh mẽ và hiệu quả hơn.
Kiến thức về Kubernetes là một công cụ không thể thiếu cho bất kỳ ai được giao nhiệm vụ thiết kế một ứng dụng, theo yêu cầu hiện đại. Nhưng trước khi đi sâu vào Kubernetes, chúng ta hãy xem xét những điều như người ta có thể mong đợi từ Kubernetes và khi nào chúng ta nên chọn sử dụng nó . Chúng ta cũng sẽ xem xét một số lựa chọn thay thế cho Kubernetes và chúng khác nhau như thế nào.
Kubernetes muốn giải quyết vấn đề gì?
Kubernetes cung cấp môi trường quản lý tập trung vào container. Nó thay mặt người dùng điều phối cơ sở hạ tầng máy tính, mạng và lưu trữ. Nó loại bỏ nhu cầu điều phối thủ công trực tiếp trong một cụm và tự động hóa quy trình điều phối, để các ứng dụng có tính khả dụng cao và tài nguyên máy tính được sử dụng tối ưu.
- Service discovery and load balancing. Bạn có một ứng dụng bao gồm hàng trăm Microservices và chúng cần giao tiếp với nhau một cách hiệu quả và đáng tin cậy. Kubernetes có thể lo việc đó.
- Horizontal scaling (tự động mở rộng theo chiều ngang). Khối lượng công việc trên ứng dụng của bạn được biết là sẽ tăng đột ngột. Mở rộng quy mô bản sao của một dịch vụ sẽ cân bằng khối lượng công việc của bạn. Nhân rộng nó xuống sau khi tăng giúp chi phí của bạn thấp. Kubernetes có thể làm điều đó cho bạn (quy mô tự động).
- Self healing (Tự phụ hồi). Bất cứ khi nào một trong hàng trăm dịch vụ gặp sự cố do lỗi nghiêm trọng, bạn sẽ muốn tự động tạo một bản sao mới, khỏe mạnh của dịch vụ này. Kubernetes có thể làm điều này cho bạn (tự phục hồi).
- Automated rollouts and rollbacks (Triển khai tự động và khôi phục.) Kubernetes có thể đảm nhận các hoạt động như triển khai phiên bản mới của ứng dụng và khôi phục về phiên bản trước đó. Tất cả các hoạt động này có thể được thực hiện một cách đáng tin cậy chỉ bằng cách thực hiện một vài lệnh từ một dòng lệnh.
- Secret and configuration management (Quản lý các file cấu hình và các file chứa thông tin nhạy cảm). Kubernetes cung cấp các cơ chế tích hợp để lưu trữ và quản lý hiệu quả cấu hình (như các biến môi trường, kết nối cơ sở dữ liệu) trên các môi trường khác nhau (ví dụ: sản xuất, thử nghiệm, phát triển). Nó cũng cho phép lưu trữ dữ liệu cấu hình nhạy cảm, có nghĩa là được giữ bí mật theo cách đặc biệt, để giảm thiểu việc vô tình để lộ dữ liệu đó.
- Storage orchestration (Điều phối lưu trữ). Kubernetes cho phép quản lý hiệu quả dung lượng lưu trữ theo yêu cầu của ứng dụng. Trong Kubernetes, quản lý lưu trữ được chia thành nhiều bước. Bộ nhớ được cấp phát được định cấu hình trước tiên, sau đó yêu cầu được thực hiện bất cứ khi nào ứng dụng trong cụm yêu cầu bộ nhớ này. Kubernetes cung cấp khả năng tích hợp tuyệt vời với các giải pháp lưu trữ khác nhau được hỗ trợ bởi các nhà cung cấp đám mây.
Nhiệm vụ không liên quan đến chức năng cốt lõi
Kubernetes cung cấp một tập hợp lớn các tính năng, tuy nhiên, có nhiều tác vụ không liên quan đến chức năng cốt lõi của nó. Nó được thiết kế để hỗ trợ tích hợp tuyệt vời với các công cụ khác, được mong đợi để thực hiện các nhiệm vụ bên ngoài lãnh thổ Kubernetes.
- Kubernetes không triển khai mã nguồn hoặc xây dựng ứng dụng. Luồng công việc tích hợp, phân phối và triển khai (CI / CD) liên tục không phải là tính năng cốt lõi của Kubernetes. Các công cụ tự động hóa như Jenkins , được tích hợp tuyệt vời với Kubernetes, có thể được sử dụng cho các nhiệm vụ như vậy.
- Kubernetes không cung cấp các dịch vụ cấp ứng dụng, chẳng hạn như message buse, khung xử lý dữ liệu, cơ sở dữ liệu, bộ nhớ đệm và hệ thống lưu trữ dưới dạng dịch vụ tích hợp. Các thành phần này có thể chạy trên Kubernetes và / hoặc có thể được truy cập bởi các ứng dụng chạy trên Kubernetes thông qua các cơ chế di động, chẳng hạn như Open Service Broker .
- Kubernetes không bắt buộc sử dụng các giải pháp lưu trữ log, giám sát hoặc cảnh báo. Mặc dù Kubernetes đi kèm với một số tích hợp như cơ chế thu thập và xuất số liệu(metric), nhưng bạn nên sử dụng các công cụ bên ngoài phù hợp nhất cho mục đích sử dụng cụ thể của bạn. Fluentd là một lựa chọn tốt để xử lý log. Prometheus là một lựa chọn phổ biến để monitoring và alert. Helm và Envoy cũng là những dự án phổ biến, hoạt động tốt với Kubernetes và đơn giản hóa quy trình làm việc. Trang Projects thuộc CNCF là một nơi tốt để tìm thêm các giải pháp như vậy.
Kubernetes đã thành công trong việc tăng thêm giá trị to lớn cho người dùng cuối của mình bằng cách cung cấp một nền tảng mạnh mẽ để điều phối các hoạt động triển khai và khả năng tương tác tuyệt vời với các công cụ bên ngoài.
Kubernetes hiện là nền tảng điều phối container phổ biến nhất thế giới và được sử dụng bởi một số công ty sáng tạo nhất trên thế giới, trong nhiều ngành công nghiệp. Nhưng có một số lưu ý khi làm việc với Kubernetes mà bạn cần lưu ý.
Chú ý với Kubernetes
Sau khi được cấu hình, Kubernetes đơn giản hóa đáng kể khối lượng công việc thủ công trong các hoạt động triển khai. Ưu tiên của Kubernetes nằm ở việc cung cấp tính linh hoạt và khả năng cấu hình cao hơn là dễ sử dụng.
Cấu hình Kubernetes cho môi trường production lớn là một nhiệm vụ phức tạp. Việc định cấu hình và duy trì một hệ thống production một cách chính xác đòi hỏi nhiều thời gian và kinh nghiệm , nhưng con đường học tập được biết là rất dốc.
Nhiều đội đã cố gắng đột ngột chuyển sang Kubernetes mà không được đào tạo bài bản, gặp khó khăn và thường quay lại giải pháp cũ của họ. Bất kỳ nhóm mới nào, trước khi chọn sử dụng Kubernetes, trước tiên nên phân bổ thời gian để tìm hiểu các nguyên tắc cơ bản cần thiết để làm việc với Kubernetes.
Khi quy mô của dự án, được triển khai trên Kubernetes, tăng lên – số lượng cấu hình Kubernetes yêu cầu cũng tăng lên. Trong các dự án lớn, việc duy trì và cập nhật cấu hình Kubernetes tự nó trở thành một nhiệm vụ đầy thách thức.
Sự phức tạp này với quản lý cấu hình của Kubernetes đã là một vấn đề nổi tiếng và các bước đang được thực hiện để phát triển một giải pháp tốt. Kustomize , một giải pháp quản lý cấu hình riêng của Kubernetes, đang được tích cực phát triển. Nhiều nhóm sử dụng các công cụ bên ngoài như Helm , để quản lý cấu hình Kubernetes hiện tại.
Như đã đề cập ở trên, Kubernetes dự kiến sẽ được tích hợp với các công cụ khác . Nó được thiết kế để hỗ trợ các pattern, nơi các công cụ chuyên dụng có thể dễ dàng tích hợp với nó. Việc sử dụng Kubernetes mà không có bất kỳ công cụ bổ sung nào được yêu cầu hoặc sử dụng các công cụ không phù hợp có thể dẫn đến các trải nghiệm tồi tệ.
Các đội nên chủ động khám phá các công cụ có sẵn và chọn những công cụ phù hợp nhất với nhu cầu của mình.
Một lưu ý quan trọng khác khi chọn Kubernetes, đó là nó là một dự án có số lượng thay đổi lớn . Các bản phát hành mới được thực hiện thường xuyên. Mặc dù hiếm gặp, nhưng đôi khi các thay đổi mới có thể không tương thích ngược và có thể gây ra downtime. Vì vậy, chúng ta nên thiết kế một cơ chế kiểm tra để phát hiện các thay đổi phá vỡ ứng dụng, bất cứ khi nào họ cập nhật phiên bản Kubernetes của mình.
Khi nào sử dụng Kubernetes và các lựa chọn thay thế
Kubernetes cung cấp các giải pháp cho điều phối container và những thách thức khác mà người ta phải đối mặt khi làm việc với các ứng dụng được thiết kế theo phong cách kiến trúc Microservices.
Chúng ta đã thảo luận rằng vấn đề triển khai hiệu quả và hiệu quả ứng dụng Microservices quy mô lớn này là mối quan tâm của toàn ngành và nhiều nhóm kỹ sư đã làm việc để giải quyết nó. Nhiều nhóm đã thiết kế phiên bản hệ thống điều phối container của riêng họ.
Chúng ta sẽ thảo luận về một số dự án phổ biến khác nhằm giải quyết các vấn đề tương tự như Kubernetes. Có một số thông tin cơ bản về các dự án này sẽ giúp chúng ta hiểu rõ hơn về vị trí của Kubernetes, và khi nào bạn nên chọn sử dụng nó.
Netflix OSS và Spring Cloud
Mặc dù dự án này không trực tiếp giải quyết vấn đề điều phối container, nhưng có một số chồng chéo giữa các vấn đề được giải quyết ở đây và các giải pháp do Kubernetes đưa ra, vì vậy chúng ta hãy thảo luận ngắn gọn về nó.
Một vài năm trước khi Google phát hành Kubernetes, Netflix đã phát hành một bộ thư viện nhằm xử lý các vấn đề khác nhau mà một người phải đối mặt, đồng thời làm việc với kiến trúc Microservices.
Các thư viện này được xây dựng từ kinh nghiệm và thông tin chi tiết mà nhóm kỹ sư Netflix có được, đồng thời mở rộng cơ sở hạ tầng của họ trên AWS . Spring Framework dựa trên Java sau đó được xây dựng trên đầu các thư viện này và họ đã phát hành Spring Cloud Netflix . Spring Cloud Netflix đã đơn giản hóa rất nhiều quá trình tích hợp thư viện Netflix với các ứng dụng Spring.
Các bản phát hành này nhanh chóng đạt được sức hút và được chấp nhận bởi một số lượng lớn các nhóm đang đấu tranh để có được kiến trúc Microservices của họ. Họ cung cấp các khả năng như khám phá dịch vụ ( Eureka ), định tuyến ( Zuul ), khả năng chịu lỗi ( Hystrix ), v.v. Nhưng việc sử dụng các thư viện này có một số hạn chế.
Hầu hết chúng được viết chủ yếu bằng Java . Các ứng dụng bắt buộc phải biết về các thư viện / dịch vụ này hoặc tương tác với chúng trong thời gian chạy. Điều này khiến việc sử dụng các thư viện / dịch vụ này trong các ứng dụng, được triển khai bằng các ngôn ngữ và khuôn khổ khác, trở nên khó khăn. Cùng với điều này, một mối quan tâm thậm chí còn quan trọng hơn là mã ứng dụng phải kết hợp logic cần thiết để giao tiếp với các thư viện / dịch vụ này.
Mặt khác, Kubernetes không hạn chế lựa chọn ngôn ngữ hoặc khuôn khổ mà ứng dụng được triển khai và mong muốn hướng tới mục đích chung. Các ứng dụng được triển khai trên Kubernetes được container hóa và hoàn toàn không biết về cơ sở hạ tầng triển khai. Khám phá dịch vụ, định tuyến, theo dõi sức khỏe, v.v., được Kubernetes xử lý, cho phép các ứng dụng tập trung vào logic kinh doanh cốt lõi.
Spring Cloud Netflix hiện có rất ít hoạt động phát triển và hầu hết đang ở chế độ bảo trì khi so sánh với Kubernetes, vốn đang rất tích cực.
Docker Swarm
Docker Swarm là giải pháp quản lý cụm và điều phối container được tích hợp với Docker Engine.
Được phát hành vào năm 2015, Docker Swarm là một giải pháp hoàn toàn dành cho môi trường Docker và không yêu cầu bất kỳ phần mềm bổ sung nào, ngoài Docker. Docker Swarm, cho đến ngày nay, không hỗ trợ một tập hợp lớn các chức năng mà Kubernetes cung cấp. Service discovery, load balancing, rolling updates, auto scaling và điều chỉnh trạng thái, cũng có sẵn trong Docker Swarm.
Trong những năm qua, bất kỳ tính năng nào đã được chứng minh là có giá trị lớn trong Kubernetes, sau đó đã được thêm vào Docker Swarm theo cách này hay cách khác. Việc vay mượn các tính năng tốt cho phép Docker Swarm tiếp tục phù hợp và nó vẫn đang được sử dụng bởi nhiều nhóm trên production.
Không giống như Kubernetes, vốn nổi tiếng là khó khăn đối với người mới bắt đầu, Docker Swarm rất đơn giản để sử dụng. Tuy nhiên, Docker Swarm hy sinh khả năng cấu hình và tính linh hoạt để ủng hộ sự đơn giản và dễ sử dụng – một sự lựa chọn khác biệt với Kubernetes.
Do sự lựa chọn này, một hệ sinh thái lớn gồm các giải pháp bên ngoài chuyên biệt tích hợp hoàn toàn với Kubernetes, nhưng không phải với Swarm. Hầu như tất cả các nhà cung cấp dịch vụ đám mây đều hỗ trợ tích hợp tuyệt vời với Kubernetes, nhưng chỉ một số ít hỗ trợ tích hợp trực tiếp với Swarm, đây là một mối quan tâm rất quan trọng nếu bạn đang có kế hoạch triển khai các ứng dụng của mình trên đám mây.
Kubernetes thích hoạt động phát triển lớn và chúng ta thường có thể là nơi đầu tiên tìm thấy các tính năng mới tuyệt vời. Các tính năng này có thể mất một thời gian để có trên Swarm hoặc trong một số trường hợp, Swarm có thể không bao giờ áp dụng các tính năng đó.
Ngoài ra, Docker Swarm chỉ có thể chạy các container Docker, trong khi Kubernetes hỗ trợ nhiều hệ thống container bao gồm Docker. Không giống như Kubernetes, đó là hoàn toàn một dự án cộng đồng, Swarm được duy trì bởi Docker Inc .
Nếu bạn có một nhóm đã sử dụng Docker và rất thoải mái với Docker CLI và bạn không quan tâm đến việc tích hợp với các công cụ bên ngoài hoặc nhà cung cấp đám mây, bạn có thể cân nhắc sử dụng Docker Swarm. Nếu không, hãy chọn Kubernetes.
Marathon trên Apache Mesos
Marathon là khung điều phối container chạy trên DC / OS (Hệ điều hành đám mây phân tán). DC / OS là một hệ điều hành phân tán mã nguồn mở, dựa trên nhân hệ thống phân tán Apache Mesos .
Marathon không thể chạy mà không có DC / OS, do đó chỉ các dự án sử dụng DC / OS mới có thể sử dụng Marathon. Mặt khác, Kubernetes có thể chạy trên DC / OS, cùng với nhiều nền tảng và hệ điều hành khác.
Marathon cung cấp các tính năng như service discovery, load balancing, health checks,, CLI, GUI, v.v. Nhưng Kubernetes cung cấp các phiên bản hoàn thiện hơn của các tính năng này và nhiều tính năng khác không phải là một phần của Marathon.
Marathon có nguồn gốc từ DC / OS, hãy tận dụng lợi thế này và thực hiện các hoạt động hiệu quả và hiệu quả hơn. Kubernetes có khả năng tích hợp tốt hơn với các dịch vụ bên ngoài và các nhà cung cấp đám mây. Chỉ cân nhắc sử dụng Marathon nếu nó cần thiết cho dự án của bạn, nhưng hãy khám phá khả năng sử dụng Kubernetes, vì nó mang lại cho bạn sự linh hoạt hơn.
Yếu tố quan trọng nhất, nơi Kubernetes làm tốt hơn tất cả các lựa chọn thay thế, là hoạt động phát triển. Hoạt động phát triển là một thước đo đáng tin cậy để đo tuổi thọ của dự án và sự hỗ trợ cho nó.
Thực tế là Kubernetes có một cộng đồng nhà phát triển mạnh mẽ đằng sau nó, thường là lý do tại sao hầu hết các nhóm chọn sử dụng nó trong môi trường production của họ.
Tóm lược
Tóm lại, bất kỳ ai quan tâm đến việc thiết kế các ứng dụng quy mô lớn vẫn có tính khả dụng cao và khả năng chịu lỗi, đồng thời tối ưu hóa việc tiêu thụ tài nguyên máy tính, nên xem xét sử dụng Kubernetes để điều phối container, kết hợp với nhóm kỹ sư có kiến thức chuyên môn về cấu hình, bảo trì và cập nhật Kubernetes .
Kubernetes thích hoạt động phát triển lớn nhất và hỗ trợ một hệ sinh thái lớn các công cụ và dịch vụ, điều này khiến nó trở thành lựa chọn tốt cho hầu hết các nhóm.
Trong bài kế tiếp, chúng ta sẽ đi sâu tìm hiểu chi tiết về hoạt động bên trong của Kubernetes.
