Xin chào, tên tôi là Dmitry Krasnov. Trong hơn XNUMX năm, tôi đã quản lý các cụm Kubernetes và xây dựng các kiến trúc vi dịch vụ phức tạp. Vào đầu năm nay, chúng tôi đã ra mắt dịch vụ quản lý cụm Kubernetes dựa trên Containerum. Nhân cơ hội này, tôi sẽ cho bạn biết Kubernetes là gì và việc tích hợp với nhà cung cấp khác với nguồn mở như thế nào.
Đối với người mới bắt đầu, . Đây là một hệ thống quản lý các container trên một số lượng lớn máy chủ. Nhân tiện, từ tiếng Hy Lạp, nó được dịch là “phi công” hoặc “người lái tàu”. Ban đầu được Google phát triển và sau đó được quyên góp dưới dạng đóng góp công nghệ cho Cloud Native Computing Foundation, một tổ chức phi lợi nhuận quốc tế quy tụ các nhà phát triển, người dùng cuối và nhà cung cấp công nghệ vùng chứa hàng đầu thế giới.
Quản lý số lượng lớn container
Bây giờ chúng ta hãy tìm hiểu xem đây là loại container nào. Đây là một ứng dụng có toàn bộ môi trường - chủ yếu là các thư viện mà chương trình phụ thuộc vào. Tất cả điều này được đóng gói trong kho lưu trữ và được trình bày dưới dạng hình ảnh có thể chạy bất kể hệ điều hành, đã được thử nghiệm và hơn thế nữa. Nhưng có một vấn đề - việc quản lý container trên một số lượng lớn máy chủ là rất khó khăn. Đó là lý do Kubernetes được tạo ra.
Hình ảnh vùng chứa đại diện cho một ứng dụng cùng với các phần phụ thuộc của nó. Ứng dụng, các phần phụ thuộc của nó và hình ảnh hệ thống tệp hệ điều hành được đặt ở các phần khác nhau của hình ảnh, được gọi là các lớp. Các lớp có thể được tái sử dụng cho các vùng chứa khác nhau. Ví dụ: tất cả các ứng dụng trong một công ty có thể sử dụng lớp cơ sở Ubuntu. Khi chạy các container, không cần lưu trữ nhiều bản sao của một lớp cơ sở trên máy chủ. Điều này cho phép bạn tối ưu hóa việc lưu trữ và phân phối hình ảnh.
Khi chúng ta muốn chạy một ứng dụng từ một vùng chứa, các lớp cần thiết sẽ được chồng lên nhau và một hệ thống tệp lớp phủ được hình thành. Một lớp ghi được đặt lên trên, lớp này sẽ bị xóa khi vùng chứa dừng lại. Điều này đảm bảo rằng khi container chạy, ứng dụng sẽ luôn có cùng một môi trường, không thể thay đổi. Điều này đảm bảo khả năng tái tạo môi trường trên các hệ điều hành máy chủ khác nhau. Dù là Ubuntu hay CentOS, môi trường sẽ luôn giống nhau. Ngoài ra, container được cách ly khỏi máy chủ bằng các cơ chế được tích hợp trong nhân Linux. Các ứng dụng trong vùng chứa không nhìn thấy tệp, quy trình của máy chủ và các vùng chứa lân cận. Việc cách ly các ứng dụng khỏi hệ điều hành máy chủ này cung cấp một lớp bảo mật bổ sung.
Có rất nhiều công cụ có sẵn để quản lý container trên máy chủ. Phổ biến nhất trong số đó là Docker. Nó cho phép bạn cung cấp toàn bộ vòng đời của container. Tuy nhiên, nó chỉ hoạt động trên một máy chủ. Nếu bạn cần quản lý các container trên nhiều máy chủ, Docker có thể khiến cuộc sống của các kỹ sư trở nên khó khăn. Đó là lý do Kubernetes được tạo ra.
Nhu cầu về Kubernetes chính xác là do khả năng quản lý các nhóm container trên nhiều máy chủ như một loại thực thể duy nhất. Sự phổ biến của hệ thống mang đến cơ hội xây dựng DevOps hoặc Hoạt động phát triển, trong đó Kubernetes được sử dụng để chạy các quy trình của chính DevOps này.
Hình 1. Sơ đồ biểu diễn cách Kubernetes hoạt động
Tự động hóa hoàn toàn
DevOps về cơ bản là tự động hóa quá trình phát triển. Nói một cách đại khái, các nhà phát triển viết mã để tải lên kho lưu trữ. Sau đó, mã này có thể được tự động thu thập ngay lập tức vào một vùng chứa có tất cả các thư viện, được thử nghiệm và “triển khai” sang giai đoạn tiếp theo - Giai đoạn, rồi ngay lập tức đến Sản xuất.
Cùng với Kubernetes, DevOps cho phép bạn tự động hóa quy trình này để nó diễn ra mà hầu như không có sự tham gia của chính các nhà phát triển. Do đó, quá trình xây dựng nhanh hơn đáng kể vì nhà phát triển không phải thực hiện việc này trên máy tính của mình - anh ta chỉ cần viết một đoạn mã, đẩy mã vào kho lưu trữ, sau đó đường dẫn được khởi chạy, có thể bao gồm quy trình xây dựng, thử nghiệm và triển khai. Và điều này xảy ra với mọi cam kết, vì vậy việc kiểm tra diễn ra liên tục.
Đồng thời, việc sử dụng vùng chứa cho phép bạn chắc chắn rằng toàn bộ môi trường của chương trình này sẽ được đưa vào sản xuất chính xác ở dạng mà nó đã được thử nghiệm. Nghĩa là, sẽ không có vấn đề gì như “có một số phiên bản đang trong quá trình thử nghiệm, một số khác đang trong quá trình sản xuất, nhưng khi chúng tôi cài đặt chúng thì mọi thứ đều thất bại”. Và vì ngày nay chúng ta có xu hướng hướng tới kiến trúc microservice, khi thay vì một ứng dụng khổng lồ lại có hàng trăm ứng dụng nhỏ, để quản lý chúng một cách thủ công, sẽ cần một đội ngũ nhân viên khổng lồ. Đó là lý do tại sao chúng tôi sử dụng Kubernetes.
Ưu, ưu, ưu
Nếu chúng ta nói về những lợi thế của Kubernetes như một nền tảng, thì nó có những lợi thế đáng kể từ quan điểm quản lý kiến trúc microservice.
- Quản lý nhiều bản sao. Điều quan trọng nhất là quản lý vùng chứa trên nhiều máy chủ. Quan trọng hơn, quản lý nhiều bản sao ứng dụng trong vùng chứa dưới dạng một thực thể duy nhất. Nhờ đó, các kỹ sư không phải lo lắng về từng thùng chứa riêng lẻ. Nếu một trong các container gặp sự cố, Kubernetes sẽ thấy điều này và khởi động lại nó.
- Mạng cụm. Kubernetes cũng có cái gọi là mạng cụm với không gian địa chỉ riêng. Nhờ đó, mỗi nhóm có địa chỉ riêng. Subpod được hiểu là đơn vị cấu trúc tối thiểu của một cụm trong đó các container được khởi chạy trực tiếp. Ngoài ra, Kubernetes còn có chức năng kết hợp bộ cân bằng tải và Service Discovery. Điều này cho phép bạn loại bỏ việc quản lý địa chỉ IP thủ công và ủy thác nhiệm vụ này cho Kubernetes. Và việc kiểm tra tình trạng tự động sẽ giúp phát hiện sự cố và chuyển hướng lưu lượng truy cập đến các nhóm đang hoạt động.
- Quản lý cấu hình. Khi quản lý một số lượng lớn ứng dụng, việc quản lý cấu hình ứng dụng trở nên khó khăn. Với mục đích này, Kubernetes có các tài nguyên ConfigMap đặc biệt. Chúng cho phép bạn lưu trữ các cấu hình tập trung và hiển thị chúng trong các nhóm khi chạy ứng dụng. Cơ chế này cho phép chúng tôi đảm bảo tính nhất quán của cấu hình trong ít nhất mười hoặc một trăm bản sao ứng dụng.
- Tập liên tục. Các container vốn là bất biến và khi dừng container, tất cả dữ liệu được ghi vào hệ thống tập tin sẽ bị hủy. Nhưng một số ứng dụng lưu trữ dữ liệu trực tiếp trên đĩa. Để giải quyết vấn đề này, Kubernetes có chức năng quản lý ổ đĩa - Persistent Volumes. Cơ chế này sử dụng bộ nhớ ngoài cho dữ liệu và có thể chuyển bộ nhớ, khối hoặc tệp liên tục vào vùng chứa. Giải pháp này cho phép bạn lưu trữ dữ liệu riêng biệt với các công nhân, giúp lưu dữ liệu đó nếu những công nhân này bị hỏng.
- Cân bằng tải. Mặc dù trong Kubernetes, chúng tôi quản lý các thực thể trừu tượng như Triển khai, StatefulSet, v.v., nhưng cuối cùng các container vẫn chạy trên máy ảo hoặc máy chủ phần cứng thông thường. Chúng không hoàn hảo và có thể sụp đổ bất cứ lúc nào. Kubernetes sẽ thấy điều này và chuyển hướng lưu lượng truy cập nội bộ sang các bản sao khác. Nhưng phải làm gì với lưu lượng truy cập đến từ bên ngoài? Nếu bạn chỉ hướng lưu lượng truy cập đến một trong các công nhân, nếu nó gặp sự cố, dịch vụ sẽ không khả dụng. Để giải quyết vấn đề này, Kubernetes có các dịch vụ như Load Balancer. Chúng được thiết kế để tự động định cấu hình bộ cân bằng đám mây bên ngoài cho tất cả nhân viên trong cụm. Bộ cân bằng bên ngoài này hướng lưu lượng truy cập bên ngoài đến công nhân và tự theo dõi trạng thái của họ. Nếu một hoặc nhiều công nhân không rảnh, lưu lượng truy cập sẽ được chuyển hướng đến những người khác. Điều này cho phép bạn tạo các dịch vụ có tính khả dụng cao bằng Kubernetes.
Kubernetes hoạt động tốt nhất khi chạy kiến trúc microservice. Có thể triển khai hệ thống vào kiến trúc cổ điển, nhưng điều đó là vô nghĩa. Nếu một ứng dụng không thể chạy trên nhiều bản sao thì nó có gì khác biệt - trong Kubernetes hay không?
Kubernetes mã nguồn mở
Kubernetes mã nguồn mở là một điều tuyệt vời: Tôi đã cài đặt nó và nó hoạt động. Bạn có thể triển khai nó trên các máy chủ phần cứng của riêng bạn, trên cơ sở hạ tầng của riêng bạn, cài đặt các bản gốc và chương trình chạy trên đó tất cả các ứng dụng sẽ chạy. Và quan trọng nhất, tất cả điều này là miễn phí. Tuy nhiên, có những sắc thái.
- Đầu tiên là nhu cầu về kiến thức và kinh nghiệm của các quản trị viên và kỹ sư, những người sẽ triển khai và hỗ trợ tất cả những điều này. Vì khách hàng hoàn toàn nhận được quyền tự do hành động trong cụm nên họ phải tự chịu trách nhiệm về hiệu suất của cụm. Và rất dễ dàng để phá vỡ mọi thứ ở đây.
- Thứ hai là thiếu sự tích hợp. Nếu chạy Kubernetes mà không có nền tảng ảo hóa phổ biến, bạn sẽ không nhận được tất cả lợi ích của chương trình. Chẳng hạn như sử dụng các dịch vụ Khối lượng liên tục và Cân bằng tải.
Hình 2. Kiến trúc k8s
Kubernetes từ nhà cung cấp
Tích hợp với nhà cung cấp đám mây cung cấp hai tùy chọn:
- Đầu tiên, một người có thể chỉ cần nhấp vào nút “tạo cụm” và nhận được một cụm đã được định cấu hình và sẵn sàng để sử dụng.
- Thứ hai, nhà cung cấp tự cài đặt cụm và thiết lập tích hợp với đám mây.
Làm thế nào nó xảy ra ở đây. Kỹ sư khởi động cụm chỉ định số lượng công nhân mà anh ta cần và với những thông số nào (ví dụ: 5 công nhân, mỗi công nhân có 10 CPU, 16 GB RAM và 100 GB ổ đĩa). Sau đó nó có quyền truy cập vào cụm đã được hình thành. Trong trường hợp này, các công nhân thực hiện tải sẽ được chuyển giao hoàn toàn cho khách hàng, nhưng toàn bộ mặt phẳng quản lý vẫn thuộc trách nhiệm của nhà cung cấp (nếu dịch vụ được cung cấp theo mô hình dịch vụ được quản lý).
Tuy nhiên, kế hoạch này có nhược điểm của nó. Do mặt phẳng quản lý vẫn thuộc về nhà cung cấp nên nhà cung cấp không cấp quyền truy cập đầy đủ cho khách hàng và điều này làm giảm tính linh hoạt khi làm việc với Kubernetes. Đôi khi, khách hàng muốn thêm một số chức năng cụ thể vào Kubernetes, chẳng hạn như xác thực qua LDAP, nhưng cấu hình mặt phẳng quản lý không cho phép điều này.
Hình 3. Ví dụ về cụm Kubernetes từ nhà cung cấp đám mây
Chọn gì: nguồn mở hay nhà cung cấp
Vậy Kubernetes là mã nguồn mở hay nhà cung cấp cụ thể? Nếu chúng tôi sử dụng Kubernetes nguồn mở thì người dùng sẽ làm những gì họ muốn với nó. Nhưng có khả năng lớn là bạn sẽ tự bắn vào chân mình. Với nhà cung cấp thì điều đó khó khăn hơn vì mọi thứ đều được nghĩ ra và định cấu hình cho công ty. Nhược điểm lớn nhất của Kubernetes nguồn mở là yêu cầu về chuyên gia. Với lựa chọn nhà cung cấp, công ty sẽ thoát khỏi vấn đề đau đầu này, nhưng họ sẽ phải quyết định nên trả tiền cho các chuyên gia của mình hay nhà cung cấp.
Vâng, ưu điểm là rõ ràng, nhược điểm cũng đã biết. Có một điều không đổi: Kubernetes giải quyết rất nhiều vấn đề bằng cách tự động hóa việc quản lý nhiều container. Và nên chọn cái nào, nguồn mở hay nhà cung cấp - mọi người đều tự đưa ra quyết định.
Bài viết được biên soạn bởi Dmitry Krasnov, kiến trúc sư hàng đầu về dịch vụ Containerum của nhà cung cấp #CloudMTS
Nguồn: www.habr.com