Triển khai K8s Cluster vào đăng ký người dùng Azure Stack Hub

Chào mừng đến với Phần 2 của loạt bài viết gồm ba phần trên blog về việc chạy các ứng dụng chứa trong hệ sinh thái lai của Microsoft Azure. Phần 1 cung cấp nền tảng khái niệm và bối cảnh cần thiết cho các nỗ lực thực hành được ghi lại trong phần 2 và 3. Bài viết này trình bày chi tiết về thử nghiệm mà chúng tôi đã thực hiện với công cụ AKS và Azure Monitor cho các container trong phòng thí nghiệm của Dell Technologies.

Sau đây là các liên kết tới tất cả các bài viết trong loạt bài này:

Phần 1: Chạy các ứng dụng chứa trong hệ sinh thái kết hợp của Microsoft Azure  – Cung cấp tổng quan về các khái niệm được đề cập trong loạt bài viết trên blog.

Phần 2: Triển khai K8s Cluster vào đăng ký người dùng Azure Stack Hub  – Thiết lập máy ảo AKS engine, triển khai cụm bằng AKS engine và đưa cụm lên Azure Monitor để chứa.

Phần 3: Triển khai Docker Container Registry tự lưu trữ  – Sử dụng một trong các mẫu Azure Stack Hub QuickStart để thiết lập container registry và đẩy hình ảnh vào registry này. Sau đó, kéo các hình ảnh này từ registry vào cụm K8s được triển khai với AKS engine trong Phần 2.

Giới thiệu về phòng thí nghiệm thử nghiệm

Trước khi tiến hành với kết quả thử nghiệm với công cụ AKS và Azure Monitor cho container, chúng tôi muốn bắt đầu bằng cách cung cấp một chuyến tham quan phòng thí nghiệm mà chúng tôi đã sử dụng để thử nghiệm tất cả các khả năng liên quan đến container trên Azure Stack Hub. Vui lòng tham khảo hai bảng sau. Bảng đầu tiên liệt kê phần cứng và phần mềm Dell EMC cho Microsoft Azure Stack. Bảng thứ hai trình bày chi tiết các nhóm tài nguyên khác nhau mà chúng tôi đã tạo để sắp xếp hợp lý các thành phần trong kiến ​​trúc. Các nhóm tài nguyên đã được cung cấp thành một đăng ký người dùng duy nhất. 

Vui lòng tham khảo đồ họa sau để có cái nhìn tổng quan về kiến ​​trúc.

Điều kiện tiên quyết

Tất cả các hướng dẫn từng bước và các hiện vật mẫu được sử dụng để triển khai công cụ AKS đều có thể được tìm thấy trong Tài liệu người dùng Azure Stack Hub và GitHub . Chúng tôi không có ý định lặp lại những gì đã viết – trừ khi chúng tôi muốn nêu bật cụ thể một khái niệm chính. Thay vào đó, chúng tôi sẽ chia sẻ những bài học mà chúng tôi đã học được trong khi theo dõi tài liệu.   

Chúng tôi quyết định thử nghiệm kịch bản được hỗ trợ trong đó AKS engine triển khai tất cả các hiện vật cụm vào một nhóm tài nguyên mới thay vì triển khai cụm vào một VNET hiện có. Chúng tôi cũng đã chọn triển khai một cụm dựa trên Linux bằng tệp mô hình API kubernetes-azurestack.json có trong kho lưu trữ GitHub của AKS engine . AKS engine không thể triển khai cụm K8s dựa trên Windows vào Azure Stack Hub tại thời điểm viết bài này (tháng 11 năm 2019). Không cố gắng sử dụng tệp kubernetes-windows.json trong kho lưu trữ GitHub vì tệp này sẽ không hoạt động đầy đủ.  

Việc giải quyết các điều kiện tiên quyết cho công cụ AKS rất đơn giản:  

• Đảm bảo hệ thống Azure Stack Hub hoàn toàn hoạt động bình thường bằng cách chạy Test-Azure Stack .
• Đã xác minh đủ bộ nhớ, dung lượng lưu trữ và địa chỉ IP công cộng có sẵn trên hệ thống.   
• Đã xác minh rằng hạn ngạch được nhúng trong các ưu đãi đăng ký của người dùng cung cấp đủ dung lượng cho tất cả các tính năng của Kubernetes.
• Đã sử dụng phân phối thị trường để tải xuống các mục thư viện phù hợp. Chúng tôi đảm bảo khớp phiên bản của công cụ AKS với phiên bản chính xác của AKS Base Image. Trong quá trình thử nghiệm, chúng tôi đã sử dụng công cụ AKS v0.43.0, phụ thuộc vào phiên bản 2019.10.24 cho AKS Base Image.
• Thu thập tên và ID của đăng ký người dùng Azure Stack Hub được tạo trong phòng thí nghiệm.   
• Đã tạo dịch vụ chính Azure AD (SPN) thông qua Cổng thông tin Azure công khai, nhưng cũng cung cấp liên kết để sử dụng phương tiện theo chương trình nhằm tạo SPN.  
• Chỉ định SPN cho vai trò Người đóng góp của đăng ký người dùng.
• Tạo khóa SSH và tệp khóa riêng bằng PuTTY Key Generator (PUTTYGEN) cho mỗi máy ảo Linux được sử dụng trong quá trình thử nghiệm. Chúng tôi đã liên kết phần mở rộng tệp PPK với PUTTYGEN trên máy trạm quản lý để các tệp khóa riêng đã lưu được mở trong PUTTYGEN để dễ dàng sao chép và dán. Chúng tôi đã sử dụng các khóa này với PuTTY và WinSCP trong suốt quá trình thử nghiệm.

Tại thời điểm này, chúng tôi đã xây dựng một máy khách Linux VM để chạy công cụ dòng lệnh AKS engine được sử dụng để triển khai và quản lý cụm K8s. Sau đây là thông số kỹ thuật của máy ảo được cung cấp: 

• Nhóm tài nguyên: demoaksengine-rg
• Kích thước VM: DS1v2 chuẩn (1 vcpu + bộ nhớ 3,5 GB)
• Đĩa được quản lý: Đĩa được quản lý mặc định 30 GB
• Hình ảnh: Mục thư viện Ubuntu 16.04-LTS mới nhất từ ​​thị trường Azure Stack Hub
• Loại xác thực: Khóa công khai SSH
• Đã chỉ định một địa chỉ IP công cộng để chúng tôi có thể dễ dàng SSH vào nó từ máy trạm quản lý
• Vì VM này cần thiết cho việc quản lý và bảo trì liên tục cụm K8s, chúng tôi đã thực hiện các biện pháp phòng ngừa thích hợp để đảm bảo rằng chúng tôi có thể khôi phục VM này trong trường hợp xảy ra thảm họa. Một tệp quan trọng cần được bảo vệ trên VM này sau khi cụm được tạo là tệp apimodel.json . Điều này sẽ được thảo luận sau trong loạt bài viết trên blog này.

Azure Stack Hub của chúng tôi chạy với các chứng chỉ được tạo từ một CA độc lập nội bộ trong phòng thí nghiệm. Điều này có nghĩa là chúng tôi cần nhập chứng chỉ gốc của CA vào kho chứng chỉ hệ điều hành của máy ảo khách hàng để nó có thể kết nối đúng với các điểm cuối quản lý Azure Stack Hub trước khi tiến hành thêm. Chúng tôi nghĩ rằng chúng tôi sẽ chia sẻ các bước để nhập chứng chỉ: 

1. CA độc lập cung cấp một tệp có phần mở rộng .cer khi yêu cầu chứng chỉ gốc. Để làm việc với kho lưu trữ chứng chỉ Ubuntu, chúng tôi phải chuyển đổi tệp này thành tệp .crt bằng cách đưa ra lệnh sau từ Git Bash trên máy trạm quản lý:

   openssl x509 -inform DER -in certnew.cer -out certnew.crt

2. Tạo một thư mục trên máy khách Ubuntu VM cho chứng chỉ CA bổ sung trong /usr/share/ca-certificates:

   sudo mkdir /usr/share/ca-certificates/extra

3. Đã chuyển tệp certnew.crt sang Ubuntu VM bằng WinSCP vào thư mục /home/azureuser. Sau đó, chúng tôi sao chép tệp từ thư mục home vào thư mục /usr/share/ca-certificates/extra.

   sudo cp certnew.crt /usr/share/ca-certificates/extra/certnew.crt

4. Thêm một dòng vào /etc/ca-certificates.conf.

   sudo nano /etc/ca-certificates.conf

   Thêm dòng sau vào cuối tệp:

   extra/certnew.crt

5. Đã cập nhật chứng chỉ không tương tác

   sudo update-ca-certificates

   Lệnh này tạo ra kết quả đầu ra sau để xác minh rằng chứng chỉ CA của phòng thí nghiệm đã được thêm thành công:

Lưu ý:   Chúng tôi đã biết rằng nếu quy trình nhập chứng chỉ gốc của CA này được thực hiện trên máy chủ đang chạy Docker, bạn phải dừng và khởi động lại Docker tại thời điểm này. Điều này được thực hiện trên Ubuntu thông qua các lệnh sau:  

sudo systemctl dừng docker
sudo systemctl khởi động docker

Sau đó, chúng tôi SSH vào máy ảo của khách hàng. Trong khi ở thư mục gốc, chúng tôi thực hiện lệnh được quy định trong tài liệu để tải xuống tập lệnh cài đặt công cụ AKS get-akse.sh .

curl -o get-akse.sh https://raw.githubusercontent.com/Azure/aks-engine/master/scripts/get-akse.sh
chmod 700 get-akse.sh
./get-akse.sh –version v0.43.0 

Sau khi cài đặt, chúng tôi đã ban hành lệnh aks-engine version để xác minh cài đặt thành công AKS engine.

Triển khai cụm K8s

Có một bước nữa cần thực hiện trước khi phát lệnh triển khai cụm K8s. Chúng tôi cần tùy chỉnh thông số kỹ thuật cụm bằng tệp API Model mẫu. Vì chúng tôi đang triển khai cụm Kubernetes dựa trên Linux, nên chúng tôi đã tải tệp kubernetes-azurestack.json vào thư mục gốc của VM máy khách. Mặc dù chúng tôi có thể sử dụng nano trên VM Linux để tùy chỉnh tệp, nhưng chúng tôi quyết định sử dụng WinSCP để sao chép tệp này sang máy trạm quản lý để chúng tôi có thể sử dụng VS Code để sửa đổi tệp. Sau đây là một số lưu ý về vấn đề này: 

• Bằng cách phát lệnh aks-engine get-versions , chúng tôi nhận thấy các phiên bản cụm lên đến 1.17 được hỗ trợ bởi AKS engine v0.43.0. Tuy nhiên, giải pháp Azure Monitor for Container chỉ hỗ trợ các phiên bản 1.15 trở về trước. Chúng tôi quyết định để giá trị khóa orchestratorRelease trong tệp kubernetes-azurestack.json ở giá trị mặc định là 1.14.
• Đã chèn https://portal.rack04.azs.mhclabs.com làm portalURL . 
• Đã sử dụng labcluster làm dnsPrefix . Đây là tên DNS cho cụm thực tế. Chúng tôi đã xác nhận rằng tên máy chủ này là duy nhất trong môi trường phòng thí nghiệm. 
• Để lại adminUsername tại azureuser . Sau đó, chúng tôi sao chép và dán khóa công khai từ PUTTYGEN vào trường keyData . Ảnh chụp màn hình sau đây cho thấy những gì đã được dán.

• Sao chép tệp đã sửa đổi trở lại thư mục gốc của máy ảo khách hàng.

Trong khi vẫn ở thư mục gốc của máy khách VM, chúng tôi đã ban hành lệnh triển khai cụm K8s. Đây là lệnh đã được thực thi. Hãy nhớ rằng ID máy khách và bí mật máy khách được liên kết với SPN và ID đăng ký là ID của đăng ký người dùng Azure Stack Hub.

 aks-engine triển khai \
–azure-env AzureStackCloud \
–location Rack04 \
–resource-group demoK8scluster-rg \
–api-model ./kubernetes-azurestack.json \
–output-directory demoK8scluster-rg \
–client-id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx \
–client-secret xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx \
–subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 

Sau khi triển khai hoàn tất và được xác minh bằng cách triển khai mysql với Helm , chúng tôi đã sao chép tệp apimodel.json được tìm thấy trong thư mục gốc của VM máy khách trong một thư mục con có tên nhóm tài nguyên của cụm – trong trường hợp này là demoK8scluster-rg – đến một vị trí an toàn bên ngoài đơn vị quy mô Azure Stack Hub. Tệp này được sử dụng làm đầu vào trong tất cả các hoạt động khác của công cụ AKS. Tệp apimodel.json được tạo chứa nguyên tắc dịch vụ, bí mật và khóa công khai SSH được sử dụng trong Mô hình API đầu vào. Nó cũng có tất cả các siêu dữ liệu khác mà công cụ AKS cần để thực hiện tất cả các hoạt động khác. Nếu những thông tin này bị mất, công cụ AKS sẽ không thể định cấu hình cụm sau này.

Đưa cụm K8s mới lên Azure Monitor cho các vùng chứa

Trước khi giới thiệu ứng dụng dựa trên dịch vụ vi mô đầu tiên của chúng tôi vào cụm K8s, chúng tôi muốn đưa cụm lên Azure Monitor cho các vùng chứa . Azure Monitor cho các vùng chứa không chỉ cung cấp trải nghiệm giám sát phong phú cho AKS trong Public Azure mà còn cho các cụm K8s được triển khai trong Azure Stack bằng công cụ AKS . Chúng tôi muốn xem những tài nguyên nào chỉ được sử dụng bởi các chức năng hệ thống Kubernetes trước khi triển khai bất kỳ ứng dụng nào. Các bước chúng tôi thực hiện trong phần này được thực hiện trên một trong các nút chính của K8 bằng kết nối SSH.  

Các điều kiện tiên quyết khá đơn giản, nhưng chúng tôi có một vài nhận xét khi thực hiện chúng: 

• Chúng tôi quyết định thực hiện onboarding bằng biểu đồ HELM. Đối với tùy chọn này, cần có phiên bản mới nhất của máy khách HELM. Chúng tôi thấy rằng miễn là chúng tôi thực hiện các bước trong Xác minh cụm của bạn trong tài liệu, chúng tôi không gặp bất kỳ sự cố nào.
• Vì chúng tôi chỉ chạy một cụm duy nhất trong môi trường của mình nên chúng tôi thấy rằng không cần phải làm bất cứ điều gì liên quan đến việc cấu hình kubectl hoặc máy khách HELM để sử dụng ngữ cảnh cụm K8s.   
• Chúng tôi không cần phải thực hiện bất kỳ thay đổi nào trong môi trường để cho phép các cổng khác nhau giao tiếp bình thường trong cụm hoặc bên ngoài với Public Azure.

Lưu ý:  Microsoft cũng hỗ trợ bật chức năng giám sát trên cụm K8s này trên Azure Stack Hub được triển khai với công cụ AKS bằng cách sử dụng định nghĩa API thay cho việc sử dụng biểu đồ HELM. Tùy chọn định nghĩa API không phụ thuộc vào Tiller hoặc bất kỳ thành phần nào khác. Sử dụng tùy chọn này, có thể bật chức năng giám sát trong quá trình tạo cụm. Bước thủ công duy nhất cho tùy chọn này là thêm giải pháp Container Insights vào không gian làm việc Log Analytics được chỉ định trong định nghĩa API.

Chúng tôi đã có Log Analytics Workspace để sử dụng cho thử nghiệm này. Tuy nhiên, chúng tôi đã mắc một lỗi trong quá trình chuẩn bị tích hợp. Chúng tôi dự định thêm thủ công giải pháp Container Insights vào không gian làm việc nhưng đã cài đặt giải pháp Container Monitoring cũ thay vì Container Insights . Để an toàn, chúng tôi đã chạy tập lệnh PowerShell onboarding_azuremonitor_for_containers.ps1 và cung cấp các giá trị cho tài nguyên của chúng tôi dưới dạng tham số. Tập lệnh đã bỏ qua việc tạo không gian làm việc vì chúng tôi đã có một không gian làm việc và chỉ cài đặt giải pháp Container Insights thông qua mẫu ARM trong GitHub được xác định trong tập lệnh.

Tại thời điểm này, chúng tôi có thể chỉ cần đưa ra các lệnh HELM trong phần Cài đặt biểu đồ của tài liệu. Bên cạnh việc chèn ID không gian làm việc và khóa không gian làm việc, chúng tôi cũng thay thế giá trị tham số –name bằng azuremonitor-containers . Chúng tôi không quan sát thấy bất kỳ điều gì bất thường trong quá trình tích hợp. Sau khi hoàn tất, chúng tôi phải đợi khoảng 10 phút trước khi có thể vào cổng thông tin Azure công cộng và xem cụm của mình xuất hiện. Chúng tôi phải nhớ nhấp vào menu thả xuống cho Môi trường trong phần Thông tin chi tiết về vùng chứa trong Azure Monitor và chọn “Azure Stack (Xem trước)” để cụm xuất hiện.

Chúng tôi hy vọng bài đăng trên blog này sẽ hữu ích cho bất kỳ ai triển khai cụm K8s trên Azure Stack Hub bằng công cụ AKS. Chúng tôi cũng tin rằng thông tin được cung cấp sẽ hỗ trợ việc đưa cụm mới đó vào Azure Monitor cho các container. Trong Phần 3, chúng tôi sẽ hướng dẫn từng bước trải nghiệm triển khai Docker Container Registry tự lưu trữ vào Azure Stack Hub.