Tên tôi là Dmitry Sugrobov, tôi là nhà phát triển tại Leroy Merlin. Trong bài viết này, tôi sẽ cho bạn biết lý do tại sao cần có Helm, cách nó đơn giản hóa hoạt động với Kubernetes, những gì đã thay đổi trong phiên bản thứ ba và cách sử dụng nó để cập nhật các ứng dụng trong sản xuất mà không có thời gian ngừng hoạt động.
Đây là bản tóm tắt dựa trên bài phát biểu tại một hội nghị by - nếu bạn không muốn đọc, hãy xem video.
Tại sao chúng tôi sử dụng Kubernetes trong sản xuất
Leroy Merlin là công ty dẫn đầu trong thị trường bán lẻ DIY ở Nga và Châu Âu. Công ty chúng tôi có hơn một trăm nhà phát triển, 33 nhân viên nội bộ và một lượng lớn người ghé thăm các đại siêu thị và trang web. Để làm cho tất cả họ hài lòng, chúng tôi quyết định làm theo các phương pháp tiếp cận tiêu chuẩn ngành. Phát triển các ứng dụng mới sử dụng kiến trúc microservice; sử dụng các thùng chứa để cách ly môi trường và đảm bảo giao hàng phù hợp; và sử dụng Kubernetes để điều phối. Giá của việc sử dụng bộ điều phối đang nhanh chóng trở nên rẻ hơn: số lượng kỹ sư thành thạo công nghệ này đang tăng lên trên thị trường và các nhà cung cấp đang cung cấp dịch vụ Kubernetes.
Tất nhiên, mọi thứ mà Kubernetes làm đều có thể được thực hiện theo những cách khác, chẳng hạn như bằng cách bao gồm một số tập lệnh Jenkins và docker-compose, nhưng tại sao lại phức tạp hóa cuộc sống nếu có một giải pháp làm sẵn và đáng tin cậy? Đó là lý do tại sao chúng tôi đến với Kubernetes và đã sử dụng nó trong sản xuất được một năm nay. Chúng tôi hiện có 24 cụm Kubernetes, cụm lâu đời nhất trong số đó đã hơn một năm tuổi, với khoảng 200 nhóm.
Lời nguyền của file YAML dung lượng lớn trong Kubernetes
Để khởi chạy một vi dịch vụ trong Kubernetes, chúng tôi sẽ tạo ít nhất năm tệp YAML: dành cho Triển khai, Dịch vụ, Ingress, ConfigMap, Secrets - và gửi chúng đến cụm. Đối với ứng dụng tiếp theo, chúng tôi sẽ viết cùng một gói jambs, với gói thứ ba, chúng tôi sẽ viết một gói khác, v.v. Nếu chúng ta nhân số lượng tài liệu với số lượng môi trường, chúng ta sẽ nhận được hàng trăm tệp và điều này vẫn chưa tính đến môi trường động.
Adam Reese, người bảo trì cốt lõi của Helm, đã đưa ra khái niệm "", trông như thế này:
- Sao chép YAML - sao chép tệp YAML.
- Dán YAML - dán nó.
- Fix Indents - sửa lỗi thụt lề.
- Lặp lại - lặp lại lần nữa.
Tùy chọn này hoạt động nhưng bạn phải sao chép tệp YAML nhiều lần. Để thay đổi chu trình này, Helm đã được phát minh.
Mũ bảo hiểm là gì
Đầu tiên, Helm - quản lý gói, giúp bạn tìm và cài đặt các chương trình bạn cần. Để cài đặt, chẳng hạn như MongoDB, bạn không cần phải truy cập trang web chính thức và tải xuống các tệp nhị phân, chỉ cần chạy lệnh helm install stable/mongodb.
Thứ hai, Helm - công cụ mẫu, giúp tham số hóa các tập tin. Hãy quay lại tình huống với các tệp YAML trong Kubernetes. Việc viết cùng một tệp YAML sẽ dễ dàng hơn, thêm một số phần giữ chỗ vào đó, trong đó Helm sẽ thay thế các giá trị. Nghĩa là, thay vì một bộ giàn giáo lớn, sẽ có một bộ mẫu trong đó các giá trị bắt buộc sẽ được thay thế vào đúng thời điểm.
Thứ ba, Helm - bậc thầy triển khai. Với nó, bạn có thể cài đặt, khôi phục và cập nhật ứng dụng. Hãy tìm ra cách để làm điều này.
Cách sử dụng Helm để triển khai các ứng dụng của riêng bạn
Hãy cài đặt ứng dụng khách Helm trên máy tính của bạn theo hướng dẫn chính thức . Tiếp theo, chúng ta sẽ tạo một tập hợp các tệp YAML. Thay vì chỉ định các giá trị cụ thể, chúng tôi sẽ để lại các phần giữ chỗ mà Helm sẽ điền thông tin trong tương lai. Một tập hợp các tệp như vậy được gọi là biểu đồ Helm. Nó có thể được gửi đến máy khách bảng điều khiển Helm theo ba cách:
- chỉ ra một thư mục có mẫu;
- đóng gói kho lưu trữ vào một .tar và trỏ đến nó;
- đặt mẫu vào kho lưu trữ từ xa và thêm liên kết đến kho lưu trữ trong ứng dụng khách Helm.
Bạn cũng cần một tệp có giá trị - value.yaml. Dữ liệu từ đó sẽ được chèn vào mẫu. Chúng ta hãy tạo ra nó quá.
Phiên bản thứ hai của Helm có thêm một ứng dụng máy chủ - Tiller. Nó treo bên ngoài Kubernetes và chờ yêu cầu từ máy khách Helm và khi được gọi, nó sẽ thay thế các giá trị bắt buộc vào mẫu và gửi đến Kubernetes.
Helm 3 đơn giản hơn: thay vì xử lý mẫu trên máy chủ, thông tin hiện được xử lý hoàn toàn ở phía máy khách Helm và gửi trực tiếp đến API Kubernetes. Việc đơn giản hóa này cải thiện tính bảo mật của cụm và tạo điều kiện thuận lợi cho kế hoạch triển khai.
Mọi chuyện diễn ra như thế nào
Chạy lệnh helm install. Hãy cho biết tên của bản phát hành ứng dụng và cung cấp đường dẫn đến value.yaml. Cuối cùng, chúng tôi sẽ chỉ ra kho lưu trữ biểu đồ và tên của biểu đồ. Trong ví dụ, đây lần lượt là “lmru” và “bestchart”.
helm install --name bestapp --values values.yaml lmru/bestchart
Lệnh chỉ có thể được thực hiện một lần, khi được thực hiện lại install Cần sử dụng upgrade. Để đơn giản, thay vì hai lệnh, bạn có thể chạy lệnh upgrade có khóa bổ sung --install. Khi được thực thi lần đầu tiên, Helm sẽ gửi lệnh cài đặt bản phát hành và sẽ cập nhật nó trong tương lai.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Cạm bẫy khi triển khai các phiên bản mới của ứng dụng với Helm
Tại thời điểm này trong câu chuyện, tôi đang chơi Ai là triệu phú với khán giả và chúng tôi đang tìm cách yêu cầu Helm cập nhật phiên bản của ứng dụng. .
Khi tìm hiểu cách thức hoạt động của Helm, tôi rất ngạc nhiên trước hành vi kỳ lạ khi cố gắng cập nhật phiên bản của các ứng dụng đang chạy. Tôi đã cập nhật mã ứng dụng, tải hình ảnh mới lên sổ đăng ký Docker, gửi lệnh triển khai - và không có gì xảy ra. Dưới đây là một số cách không hoàn toàn thành công để cập nhật ứng dụng. Bằng cách nghiên cứu từng chi tiết hơn, bạn bắt đầu hiểu cấu trúc bên trong của nhạc cụ và lý do cho hành vi không rõ ràng này.
Cách 1. Không thay đổi thông tin kể từ lần ra mắt gần đây nhất
Như câu nói đi Helm, “Biểu đồ Kubernetes có thể lớn và phức tạp, vì vậy Helm cố gắng không chạm vào bất cứ thứ gì quá nhiều.” Do đó, nếu bạn cập nhật phiên bản mới nhất của hình ảnh ứng dụng trong sổ đăng ký docker và chạy lệnh helm upgrade, thì sẽ không có chuyện gì xảy ra. Helm sẽ nghĩ rằng không có gì thay đổi và không cần phải gửi lệnh tới Kubernetes để cập nhật ứng dụng.
Ở đây và bên dưới, thẻ mới nhất chỉ được hiển thị làm ví dụ. Khi bạn chỉ định thẻ này, Kubernetes sẽ tải xuống hình ảnh từ sổ đăng ký docker mọi lúc, bất kể tham số imagePullPolicy. Việc sử dụng phiên bản mới nhất trong sản xuất là điều không mong muốn và gây ra tác dụng phụ.
Cách 2. Cập nhật LABEL trong ảnh
Như được viết trong cùng , “Helm sẽ chỉ cập nhật một ứng dụng nếu nó đã thay đổi kể từ lần phát hành trước.” Một tùy chọn hợp lý cho việc này dường như là cập nhật LABEL trong chính hình ảnh docker. Tuy nhiên, Helm không xem xét các hình ảnh ứng dụng và không biết về bất kỳ thay đổi nào đối với chúng. Theo đó, khi cập nhật các nhãn trong image, Helm sẽ không biết về chúng và lệnh cập nhật ứng dụng sẽ không được gửi tới Kubernetes.
Cách 3: Sử dụng chìa khóa --force
Hãy xem hướng dẫn sử dụng và tìm chìa khóa cần thiết. Chìa khóa có ý nghĩa nhất --force. Mặc dù có cái tên rõ ràng nhưng hành vi lại khác với mong đợi. Thay vì buộc phải cập nhật ứng dụng, mục đích thực sự của nó là khôi phục bản phát hành ở trạng thái LỖI. Nếu không sử dụng phím này thì cần thực hiện tuần tự các lệnh helm delete && helm install --replace. Nên sử dụng chìa khóa thay thế --force, tự động thực hiện tuần tự các lệnh này. Thêm thông tin trong này . Để báo Helm cập nhật phiên bản ứng dụng, rất tiếc là phím này sẽ không hoạt động.
Cách 4. Thay đổi nhãn trực tiếp trong Kubernetes
Cập nhật nhãn trực tiếp trong cụm bằng lệnh kubectl edit - ý tưởng tồi. Hành động này sẽ dẫn đến sự không nhất quán về thông tin giữa ứng dụng đang chạy và ứng dụng ban đầu được gửi để triển khai. Hành vi của Helm trong quá trình triển khai trong trường hợp này khác với phiên bản của nó: Helm 2 sẽ không làm gì cả và Helm 3 sẽ triển khai phiên bản mới của ứng dụng. Để hiểu lý do tại sao, bạn cần hiểu cách thức hoạt động của Helm.
Helm hoạt động như thế nào?
Để xác định xem một ứng dụng có thay đổi kể từ lần phát hành gần đây nhất hay không, Helm có thể sử dụng:
- chạy ứng dụng trong Kubernetes;
- giá trị mới.yaml và biểu đồ hiện tại;
- Thông tin phát hành nội bộ của Helm.
Dành cho những người tò mò hơn: Helm lưu trữ thông tin nội bộ về các bản phát hành ở đâu?Bằng cách thực hiện lệnh helm history, chúng ta sẽ nhận được tất cả thông tin về các phiên bản được cài đặt bằng Helm.
Ngoài ra còn có thông tin chi tiết về các mẫu và giá trị đã gửi. Chúng tôi có thể yêu cầu nó:
Trong phiên bản thứ hai của Helm, thông tin này nằm trong cùng không gian tên nơi Tiller đang chạy (kube-system theo mặc định), trong ConfigMap, được đánh dấu bằng nhãn “OWNER=TILLER”:
Khi phiên bản thứ ba của Helm xuất hiện, thông tin được chuyển đến bí mật và đến cùng không gian tên nơi ứng dụng đang chạy. Nhờ đó, có thể chạy đồng thời nhiều ứng dụng trong các không gian tên khác nhau có cùng tên phát hành. Ở phiên bản thứ hai, thật là đau đầu khi các không gian tên bị cô lập nhưng lại có thể ảnh hưởng lẫn nhau.
Helm thứ hai, khi cố gắng tìm hiểu xem có cần cập nhật hay không, chỉ sử dụng hai nguồn thông tin: những gì được cung cấp cho nó bây giờ và thông tin nội bộ về các bản phát hành nằm trong ConfigMap.
Helm thứ ba sử dụng chiến lược hợp nhất ba chiều: ngoài thông tin đó, nó còn tính đến ứng dụng hiện đang chạy trong Kubernetes.
Vì lý do này, phiên bản cũ của Helm sẽ không làm gì cả, vì nó không tính đến thông tin ứng dụng trong cụm, nhưng Helm 3 sẽ nhận các thay đổi và gửi ứng dụng mới để triển khai.
Phương pháp 5. Sử dụng khóa chuyển đổi --recreate-pod
Với một chiếc chìa khóa --recreate-pods bạn có thể đạt được những gì bạn dự định ban đầu bằng chìa khóa --force. Các vùng chứa sẽ khởi động lại và theo chính sách imagePullPolicy: Luôn dành cho thẻ mới nhất (thông tin thêm về điều này trong chú thích cuối trang ở trên), Kubernetes sẽ tải xuống và khởi chạy phiên bản mới của hình ảnh. Điều này sẽ không được thực hiện theo cách tốt nhất: nếu không tính đến Loại triển khai Chiến lược, nó sẽ đột ngột tắt tất cả các phiên bản ứng dụng cũ và bắt đầu khởi chạy các phiên bản ứng dụng mới. Trong quá trình khởi động lại, hệ thống không hoạt động, người dùng sẽ chịu thiệt.
Trong chính Kubernetes, vấn đề tương tự cũng đã tồn tại từ lâu. Và bây giờ, 4 năm sau ngày khai trương , sự cố đã được khắc phục và bắt đầu từ phiên bản 1.15 của Kubernetes, khả năng khởi động lại các nhóm sẽ xuất hiện.
Helm chỉ cần tắt tất cả các ứng dụng và khởi chạy các vùng chứa mới gần đó. Bạn không thể thực hiện việc này trong quá trình sản xuất để không gây ra thời gian ngừng hoạt động của ứng dụng. Điều này chỉ cần thiết cho nhu cầu phát triển và chỉ có thể được thực hiện trong môi trường sân khấu.
Làm cách nào để cập nhật phiên bản ứng dụng bằng Helm?
Chúng ta sẽ thay đổi các giá trị gửi tới Helm. Thông thường, đây là những giá trị được thay thế cho thẻ hình ảnh. Trong trường hợp mới nhất, thường được sử dụng cho các môi trường không hiệu quả, thông tin có thể thay đổi là một chú thích, điều này vô dụng đối với chính Kubernetes và đối với Helm, nó sẽ đóng vai trò là tín hiệu cho thấy nhu cầu cập nhật ứng dụng. Các tùy chọn để điền giá trị chú thích:
- Giá trị ngẫu nhiên sử dụng chức năng tiêu chuẩn -
{{ randAlphaNum 6 }}.
Có một lưu ý: sau mỗi lần triển khai sử dụng biểu đồ có biến như vậy, giá trị chú thích sẽ là duy nhất và Helm sẽ cho rằng có thay đổi. Hóa ra chúng tôi sẽ luôn khởi động lại ứng dụng, ngay cả khi chúng tôi chưa thay đổi phiên bản của nó. Điều này không quan trọng vì sẽ không có thời gian ngừng hoạt động nhưng vẫn gây khó chịu. - Dán hiện tại ngày và giờ -
{{ .Release.Date }}.
Một biến thể tương tự như một giá trị ngẫu nhiên với một biến duy nhất vĩnh viễn. - Một cách đúng đắn hơn là sử dụng tổng kiểm tra. Đây là SHA của hình ảnh hoặc SHA của lần xác nhận cuối cùng trong git -
{{ .Values.sha }}.
Chúng sẽ cần được đếm và gửi đến ứng dụng khách Helm ở bên gọi, chẳng hạn như ở Jenkins. Nếu ứng dụng đã thay đổi thì tổng kiểm tra sẽ thay đổi. Vì vậy, Helm sẽ chỉ cập nhật ứng dụng khi có nhu cầu.
Hãy tóm tắt những nỗ lực của chúng tôi
- Helm thực hiện các thay đổi theo cách ít xâm lấn nhất, do đó, mọi thay đổi ở cấp độ hình ảnh ứng dụng trong Docker Register sẽ không dẫn đến bản cập nhật: sẽ không có gì xảy ra sau khi lệnh được thực thi.
- Ключ
--forceđược sử dụng để khôi phục các bản phát hành có vấn đề và không liên quan đến các bản cập nhật bắt buộc. - Ключ
--recreate-podssẽ cập nhật các ứng dụng một cách mạnh mẽ, nhưng sẽ thực hiện theo cách phá hoại: nó sẽ đột ngột tắt tất cả các vùng chứa. Người dùng sẽ phải chịu đựng điều này; bạn không nên làm điều này trong quá trình sản xuất. - Trực tiếp thực hiện các thay đổi đối với cụm Kubernetes bằng lệnh
kubectl editkhông: chúng tôi sẽ phá vỡ tính nhất quán và hành vi sẽ khác nhau tùy thuộc vào phiên bản Helm. - Với việc phát hành phiên bản mới của Helm, nhiều sắc thái đã xuất hiện. Các vấn đề trong kho Helm được mô tả bằng ngôn ngữ rõ ràng, chúng sẽ giúp bạn hiểu chi tiết.
- Việc thêm chú thích có thể chỉnh sửa vào biểu đồ sẽ làm cho biểu đồ linh hoạt hơn. Điều này sẽ cho phép bạn triển khai ứng dụng một cách chính xác mà không có thời gian chết.
Một tư tưởng “hòa bình thế giới” có tác dụng trong mọi lĩnh vực của cuộc sống: đọc hướng dẫn trước khi sử dụng chứ không phải sau. Chỉ với thông tin đầy đủ thì mới có thể xây dựng được hệ thống đáng tin cậy và khiến người dùng hài lòng.
Các liên kết liên quan khác:
Báo cáo này lần đầu tiên được trình bày tại bởi Giải pháp đám mây Mail.ru. Nhìn các buổi biểu diễn khác và đăng ký nhận thông báo sự kiện trên Telegram .
Nguồn: www.habr.com