Triển khai các cụm K8 vào đăng ký người dùng Azure Stack Hub

Chào mừng bạn đến với Phần 2 của loạt blog gồm ba phần về việc chạy các ứng dụng được chứa trong bộ chứa trên hệ sinh thái kết hợp 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 những nỗ lực thực hành được ghi lại trong phần 2 và 3. Bài viết này mô tả chi tiết quá trình thử nghiệm mà chúng tôi đã thực hiện với công cụ AKS và Azure Monitor cho các thùng chứa trong phòng thí nghiệm của Dell Technologies.

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

Trước khi tiếp tục với kết quả thử nghiệm với công cụ AKS và Azure Monitor dành cho bộ chứa, chúng tôi muốn bắt đầu bằng cách cung cấp chuyến tham quan phòng thí nghiệm mà chúng tôi đã sử dụng để kiểm tra tất cả các khả năng liên quan đến bộ chứa 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 dành cho Microsoft Azure Stack. Bảng thứ hai nêu chi tiết các nhóm tài nguyên khác nhau mà chúng tôi đã tạo để tổ chức một cách 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 cho một thuê bao người dùng duy nhất. 

Vui lòng tham khảo hình ảnh sau để có cái nhìn tổng quan ở cấp độ cao về kiến ​​trúc.

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

Bạn có thể tìm thấy tất cả các hướng dẫn từng bước và các tạo phẩm mẫu được sử dụng để triển khai công cụ AKS 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ì đã được viết – trừ khi chúng tôi muốn nêu bật một khái niệm quan trọng một cách cụ thể. Thay vào đó, chúng tôi sẽ chia sẻ những bài học chúng tôi đã học được khi làm theo tài liệu.   

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

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 rằng hệ thống Azure Stack Hub hoàn toàn hoạt động tốt bằng cách chạy Test-Azure Stack .
• Đã xác minh đủ bộ nhớ, dung lượng lưu trữ và dung lượng địa chỉ IP công cộng khả dụng trên hệ thống.   
• Đã xác minh rằng hạn ngạch được nhúng trong ưu đãi của đăng ký người dùng đã cung cấp đủ dung lượng cho tất cả các khả 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 thích 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 Hình ảnh cơ sở AKS. Trong thử nghiệm, chúng tôi đã sử dụng công cụ AKS v0.43.0, tùy thuộc vào phiên bản 2019.10.24 cho Hình ảnh cơ sở AKS.
• Đã 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 của Azure AD (SPN) thông qua Cổng Azure công cộng, nhưng một liên kết cũng được cung cấp để sử dụng các phương tiện có lập trình nhằm tạo SPN.  
• Đã chỉ định SPN cho vai trò Cộng tác viên của đăng ký người dùng.
• Đã tạo khóa SSH và tệp khóa riêng bằng Trình tạo khóa PuTTY (PUTTYGEN) cho từng 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 ảo máy khách Linux để chạy công cụ dòng lệnh của công cụ AKS dùng để triển khai và quản lý cụm K8. Dưới đây là thông số kỹ thuật của VM được cung cấp: 

• Nhóm tài nguyên: demoaksengine-rg
• Kích thước VM: DS1v2 tiêu 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 tới địa chỉ đó từ máy trạm quản lý
• Vì VM này cần thiết để quản lý và bảo trì liên tục cụm K8 nên 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 máy ảo 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 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ừ 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 để nó có thể kết nối đúng cách với các điểm cuối quản lý Azure Stack Hub trước khi tiến xa hơn. 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 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 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 để có 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 máy ảo Ubuntu bằng WinSCP sang thư mục /home/azureuser. Sau đó, chúng tôi sao chép tệp từ thư mục chính sang 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 từng được thực hiện trên máy chủ đã chạy Docker thì 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 bắt đầu docker

Sau đó chúng tôi sẽ SSH vào máy khách VM. Khi ở trong thư mục chính, chúng tôi đã thực thi lệnh quy định trong tài liệu để tải xuống tập lệnh cài đặt công cụ get-akse.sh AKS.

cuộn tròn -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 đã đưa ra lệnh phiên bản aks-engine để xác minh quá trình cài đặt thành công công cụ AKS.

Triển khai cụm K8

Còn một bước nữa cần được thực hiện trước khi ra lệnh triển khai cụm K8. Chúng tôi cần tùy chỉnh đặc tả cụm bằng cách sử dụng tệp Mô hình API mẫu. Vì đ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 chính của máy khách VM. Mặc dù lẽ ra chúng tôi có thể sử dụng nano trên máy ảo 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ý để thay vào đó, chúng tôi có thể sử dụng VS Code để sửa đổi tệp. Dưới đây là một số lưu ý về điều này: 

• Thông qua việc ban hành lệnh aks-engine get-versions , chúng tôi nhận thấy rằng các phiên bản cụm lên đến 1.17 đã được AKS engine v0.43.0 hỗ trợ. 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 để lại 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 cổngURL . 
• Đã 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 tên người dùng quản trị viên tại azureuser . Sau đó, chúng tôi đã sao chép và dán khóa chung 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 chính của máy khách VM.

Khi vẫn còn trong thư mục chính 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 khách hàng và bí mật khách hàng được liên kết với SPN và ID đăng ký là 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 \
— id khách hàng xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
–client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
–subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 

Sau khi quá trình 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 chính của máy khách VM trong 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 – sang một vị trí an toàn bên ngoài đơn vị cân 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. Apimodel.json được tạo chứa khóa chính, khóa 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 điều này bị mất, động cơ AKS sẽ không thể định cấu hình cụm sau này.

Đưa cụm K8 mới vào Azure Monitor cho bộ chứa

Trước khi giới thiệu ứng dụng dựa trên vi dịch vụ đầu tiên của chúng tôi cho cụm K8, chúng tôi ưu tiên tích hợp cụm vào Azure Monitor cho bộ chứa . Azure Monitor dành cho 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 K8 đượ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 của 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 đã thực hiện một số quan sát khi xem xét chúng: 

• Chúng tôi quyết định thực hiện quá trình giới thiệu 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 ứng dụng khách HELM. Chúng tôi nhận 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 thì chúng tôi không gặp phải bất kỳ vấn đề 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 mình không phải làm bất cứ điều gì liên quan đến việc định cấu hình máy khách kubectl hoặc máy khách HELM để sử dụng ngữ cảnh cụm K8s.   
• Chúng tôi không 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 chính xác trong cụm hoặc bên ngoài với Public Azure.

Lưu ý:  Microsoft cũng hỗ trợ kích hoạt tính 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 thế 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, việc giám sát có thể được kích hoạ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 Thông tin chi tiết về vùng chứa vào không gian làm việc Phân tích nhật ký được chỉ định trong định nghĩa API.

Chúng tôi đã có sẵn Không gian làm việc Phân tích nhật ký cho thử nghiệm này. Tuy nhiên, chúng tôi đã mắc một sai lầm trong quá trình chuẩn bị làm quen. Chúng tôi dự định thêm giải pháp Thông tin chi tiết về vùng chứa theo cách thủ công vào không gian làm việc nhưng đã cài đặt giải pháp Giám sát vùng chứa cũ thay vì Thông tin chi tiết về vùng chứa . Để đảm bảo 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ó 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 ta 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 điều gì bất thường trong quá trình giới thiệu. Sau khi hoàn tất, chúng tôi phải đợi khoảng 10 phút trước khi có thể truy cập cổng Public Azure và thấy cụm của chúng tôi 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 (Bản xem trước)” để cụm xuất hiện.

Chúng tôi hy vọng bài đăng trên blog này cung cấp thông tin chi tiết cho bất kỳ ai triển khai cụm K8 trên Azure Stack Hub bằng công cụ AKS. Chúng tôi cũng tin tưởng rằng thông tin được cung cấp sẽ hỗ trợ quá trình triển khai cụm mới đó lên Azure Monitor cho bộ chứa. Trong Phần 3, chúng ta sẽ trình bày trải nghiệm của mình khi triển khai Sổ đăng ký vùng chứa Docker tự lưu trữ vào Azure Stack Hub.