7 lý do tại sao Kubernetes lại lý tưởng cho CI/CD pipeline

Kubernetes

Sa Phạm

2176

16-02-2022

Ngoài việc cải thiện các quy trình DevOps truyền thống, tốc độ, hiệu quả và khả năng phục hồi là những ưu điểm vượt trội của DevOps - Kubernetes giải quyết các vấn đề mới nảy sinh với kiến trúc ứng dụng dựa trên container và microservices. Nói một cách khác, Kubernetes củng cố các mục tiêu DevOps đồng thời cho phép các quy trình công việc mới phát sinh với kiến trúc microservices.

Kubernetes là một nền tảng mã nguồn mở mạnh mẽ, là thế hệ tiếp theo để tự động hóa việc triển khai, mở rộng quy mô và quản lý các container ứng dụng trên các cụm máy chủ. Nó có thể chạy bất kỳ workload nào. Kubernetes cung cấp trải nghiệm người dùng (UX) đặc biệt dành cho nhà phát triển (Developer) và tốc độ triển khai nhanh chóng. Ngay từ đầu, cơ sở hạ tầng của Kubernetes hứa hẹn sẽ cho phép các tổ chức triển khai ứng dụng nhanh chóng trên quy mô lớn và phát triển các tính năng mới dễ dàng trong khi chỉ sử dụng các tài nguyên cần thiết.

Dưới đây là 7 tính năng giúp Kubernetes trở thành nền tảng lý tưởng cho các kỹ sư DevOps thiết lập và quản lý các ứng dụng được đóng gói thông qua các CI/CD pipeline (Continuous Integration/Continuous Delivery).

1. Khối xây dựng mạnh mẽ

Kubernetes sử dụng Pods làm đơn vị triển khai cơ bản. Các pod đại diện cho một nhóm gồm một hoặc nhiều container sử dụng cùng một storage và network. Mặc dù các pod thường chỉ được sử dụng để chạy một container duy nhất, nhưng chúng đã được sử dụng theo một số cách sáng tạo, bao gồm cả như một phương tiện để xây dựng lưới service.

Việc sử dụng phổ biến nhiều container trong một pod duy nhất tuân theo một mẫu sidecar. Với mẫu này, một container sẽ chạy bên cạnh ứng dụng cốt lõi của bạn để cung cấp một số giá trị bổ sung. Điều này thường được sử dụng cho các yêu cầu ủy quyền hoặc thậm chí xử lý xác thực.

Với những khối xây dựng mạnh mẽ này, việc vẽ bản đồ các service có thể đã chạy trong một máy ảo trước khi container hóa thành nhiều container chạy trong cùng một pod trở nên khá đơn giản.

2. Việc khám phá service được đơn giản hóa

Trong một ứng dụng nguyên khối, các service khác nhau đều có mục đích riêng, nhưng tính năng tự ngăn chặn sẽ tạo điều kiện thuận lợi cho giao tiếp. Trong kiến trúc microservices, các microservices cần phải giao tiếp với nhau - user service cần phải giao tiếp với post service và address service, v.v. Tìm ra cách các service này có thể giao tiếp đơn giản và nhất quán không phải là điều dễ dàng.

Với Kubernetes, một kỹ sư DevOps định nghĩa một service - ví dụ, một user service. Bất cứ thứ gì chạy trong cùng một Kubernetes namespace đó đều có thể gửi yêu cầu đến service đó và Kubernetes tìm ra cách định tuyến yêu cầu cho bạn, giúp cho việc quản lý microservices dễ dàng hơn.

3. Cấu hình tập trung, dễ đọc

Kubernetes hoạt động trên mô hình khai báo: Bạn mô tả trạng thái mong muốn và Kubernetes sẽ cố gắng đạt được trạng thái đó. Kubernetes có các tệp YAML dễ đọc được sử dụng để mô tả trạng thái bạn muốn đạt được. Với cấu hình Kubernetes YAML, bạn có thể xác định bất kỳ thứ gì từ bộ cân bằng tải ứng dụng đến một nhóm các pod để chạy ứng dụng của mình. Một cấu hình triển khai có thể có ba bản sao của một trong các container Docker của ứng dụng và hai biến môi trường khác nhau. Cấu hình dễ đọc này có thể được lưu trữ trong kho lưu trữ Git, vì vậy bạn có thể xem bất kỳ lúc nào cấu hình thay đổi. Trước khi có Kubernetes, thật khó để biết điều gì đang thực sự xảy ra với các hệ thống được kết nối với nhau trên các máy chủ.

Ngoài việc định cấu hình các container ứng dụng đang chạy trong cụm hoặc các endpoint có thể được sử dụng để truy cập chúng, Kubernetes có thể trợ giúp quản lý cấu hình. Kubernetes có một khái niệm gọi là ConfigMap nơi bạn có thể xác định các biến môi trường và tệp cấu hình cho ứng dụng của mình. Tương tự, các đối tượng được gọi là secret chứa thông tin nhạy cảm và giúp xác định cách ứng dụng của bạn sẽ chạy. Các secret hoạt động giống như ConfigMaps, nhưng ít bị che khuất hơn và ít hiển thị hơn đối với người dùng cuối.

4. Source of Truth theo thời gian thực

Với sức mạnh triển khai tích hợp của Kubernetes, bất kỳ ai cũng có thể triển khai và kiểm tra trạng thái phân phối bằng lịch sử triển khai không giới hạn của Kubernetes: lịch sử kubectl rollout.

API Kubernetes cung cấp source of truth theo thời gian thực về trạng thái triển khai. Bất kỳ nhà phát triển nào có quyền truy cập vào cụm đều có thể nhanh chóng tìm ra điều gì đang xảy ra với việc phân phối hoặc xem tất cả các lệnh được ban hành. Nhật ký kiểm tra hệ thống vĩnh viễn này được lưu giữ ở một nơi vì mục đích bảo mật và lịch sử. Bạn có thể dễ dàng tìm hiểu về các lần triển khai trước đó, xem điểm tương đồng giữa các lần triển khai hoặc quay trở lại bất kỳ phiên bản nào được liệt kê.

5. Khả năng health check đơn giản

Đây là một vấn đề lớn trong vòng đời ứng dụng của bạn, đặc biệt là trong giai đoạn triển khai. Trước đây, các ứng dụng thường không có tính năng tự động khởi động lại nếu chúng gặp sự cố; thay vào đó, ai đó đã phân trang vào lúc nửa đêm và phải khởi động lại chúng. Mặt khác, Kubernetes có tính năng health check tự động và nếu một ứng dụng không phản hồi vì bất kỳ lý do gì, bao gồm hết bộ nhớ hoặc chỉ bị khóa, Kubernetes sẽ tự động khởi động lại nó.

Để làm rõ, Kubernetes kiểm tra xem ứng dụng của bạn có đang chạy hay không, nhưng nó không biết cách kiểm tra xem nó có đang chạy chính xác hay không. Tuy nhiên, Kubernetes giúp việc thiết lập health check cho ứng dụng của bạn trở nên đơn giản. Bạn có thể kiểm tra tình trạng của ứng dụng theo hai cách:

1. Sử dụng liveness probe để kiểm tra xem ứng dụng có chuyển từ trạng thái khỏe mạnh sang không khỏe hay không. Nếu nó thực hiện quá trình chuyển đổi đó, nó sẽ cố gắng khởi động lại ứng dụng cho bạn.
2. Sử dụng readiness probe để kiểm tra xem ứng dụng có sẵn sàng chấp nhận lưu lượng truy cập hay không sẽ không loại bỏ các container đang hoạt động trước đó cho đến khi các container mới hoạt động tốt. Về cơ bản, readiness probe là tuyến phòng thủ cuối cùng ngăn một container bị hỏng tồn tại.

Cả hai probe đều là những công cụ hữu ích và Kubernetes giúp chúng dễ dàng cấu hình.

Ngoài ra, rất hiếm khi xảy ra trường hợp khôi phục nếu bạn có một readiness probe được định cấu hình thích hợp. Nếu tất cả các lần kiểm tra tình trạng không thành công, một lệnh one-line duy nhất sẽ khôi phục việc triển khai đó cho bạn và đưa bạn trở lại trạng thái ổn định. Nó không hay được sử dụng, nhưng nó ở đó nếu bạn cần.

6. Rolling Updates và Native Rollback

Để xây dựng xa hơn ý tưởng về source of truth theo thời gian thực và khả năng health check, một tính năng chính khác của Kubernetes là Rolling Update với tính năng Native Rollback nói trên. Việc triển khai có thể và nên thường xuyên mà không thể thay đổi. Trước khi có Kubernetes, nếu bạn muốn triển khai một cái gì đó, một mô hình triển khai phổ biến liên quan đến việc máy chủ lấy mã ứng dụng mới nhất và khởi động lại ứng dụng của bạn. Quá trình này khá rủi ro vì một số tính năng không tương thích ngược - nếu xảy ra sự cố trong quá trình triển khai, phần mềm sẽ không khả dụng. Ví dụ: nếu máy chủ tìm thấy mã mới, nó sẽ kéo các bản cập nhật đó vào và cố gắng khởi động lại ứng dụng bằng mã mới. Nếu có gì đó không thành công trong đường dẫn đó, ứng dụng có thể đã “chết”.

Các quy trình làm việc này đã có vấn đề cho đến khi Kubernetes xuất hiện. Kubernetes giải quyết vấn đề này với khả năng khôi phục triển khai giúp loại bỏ các cửa sổ bảo trì lớn và lo lắng về downtime. Kể từ Kubernetes 1.2, đối tượng triển khai là một bản kê khai khai báo chứa mọi thứ đang được phân phối, bao gồm số lượng bản sao đang được triển khai và phiên bản của hình ảnh phần mềm. Các mục này được trừu tượng hóa và chứa trong một khai báo triển khai. Việc triển khai dựa trên tệp kê khai như vậy đã thúc đẩy quy trình làm việc CD mới và là một best practice đang phát triển với Kubernetes.

Trước khi Kubernetes tắt các container ứng dụng hiện có, nó sẽ bắt đầu tạo các container mới. Chỉ khi những cái mới được thiết lập và chạy chính xác thì nó mới thoát khỏi bản phát hành ổn định cũ. Giả sử Kubernetes không bắt được một triển khai không thành công - ứng dụng đang chạy, nhưng nó đang ở một số loại trạng thái lỗi mà Kubernetes không phát hiện ra. Trong trường hợp này, các kỹ sư DevOps có thể sử dụng một lệnh Kubernetes đơn giản để hoàn tác việc triển khai đó. Hơn nữa, bạn có thể định cấu hình nó để lưu trữ ít nhất hai thay đổi hoặc nhiều bản sửa đổi tùy thích và bạn có thể quay lại lần triển khai cuối cùng hoặc nhiều lần triển khai trước đó, tất cả chỉ bằng một lệnh Kubernetes tự động, đơn giản. Toàn bộ khái niệm này là một người thay đổi cuộc chơi. Các khuôn khổ điều phối khác không thể xử lý quá trình này một cách liền mạch và hợp lý như Kubernetes.

7. Giám sát đơn giản hóa

Mặc dù bề ngoài có vẻ như việc giám sát Kubernetes sẽ khá phức tạp, nhưng đã có rất nhiều sự phát triển trong không gian này. Mặc dù Kubernetes và container thêm một số mức độ phức tạp vào cơ sở hạ tầng của bạn, nhưng chúng cũng đảm bảo rằng tất cả các ứng dụng của bạn đang chạy trong các nhóm và triển khai nhất quán. Tính nhất quán này cho phép các công cụ giám sát trở nên đơn giản hơn theo nhiều cách.

Prometheus là một ví dụ về một công cụ giám sát mã nguồn mở đã trở nên rất phổ biến trong hệ sinh thái gốc đám mây. Công cụ này cung cấp khả năng giám sát và cảnh báo nâng cao với các Kubernetes integration.

Khi theo dõi Kubernetes, có một số thành phần chính cần theo dõi: Kubernetes Nodes (máy chủ); Triển khai hệ thống Kubernetes, chẳng hạn như DNS hoặc mạng; và tất nhiên, chính ứng dụng của bạn. Có nhiều công cụ giám sát sẽ đơn giản hóa việc giám sát từng thành phần này.

>> Có thể bạn quan tâm: Đánh giá 5 công cụ Kubernetes CI/CD phổ biến nhất hiện nay