Menyebarkan kluster Kubernetes ketersediaan tinggi di Azure Stack Hub
Artikel ini akan menunjukkan kepada Anda cara membangun lingkungan kluster Kubernetes yang sangat tersedia, yang disebarkan pada beberapa instans Azure Stack Hub, di lokasi fisik yang berbeda.
Dalam panduan penyebaran solusi ini, Anda mempelajari cara:
- Mengunduh dan menyiapkan Mesin AKS
- Menyambungkan ke VM Pembantu Mesin AKS
- Menyebarkan kluster Kubernetes
- Sambungkan ke kluster Kube
- Menyambungkan Azure Pipelines ke kluster Kubernetes
- Mengonfigurasi pemantauan
- Menyebarkan aplikasi
- Menskalakan otomatis aplikasi
- Mengonfigurasi Traffic Manager
- Tingkatkan Kubernetes
- Menskalakan Kubernetes
Tip
Microsoft Azure Stack Hub adalah perpanjangan dari Azure. Azure Stack Hub menghadirkan kelincahan dan inovasi komputasi awan ke lingkungan lokal Anda, memungkinkan satu-satunya cloud hybrid yang memungkinkan Anda membangun dan menerapkan aplikasi hybrid di mana saja.
Artikel Perspektif desain aplikasi hibrid mengulas pilar kualitas perangkat lunak (penempatan, skalabilitas, ketersediaan, ketahanan, kemampuan manajemen, dan keamanan) untuk merancang, menyebarkan, dan mengoperasikan aplikasi hibrid. Pertimbangan desain membantu dalam mengoptimalkan desain aplikasi hibrid, meminimalkan tantangan dalam lingkungan produksi.
Prasyarat
Sebelum memulai panduan penyebaran ini, pastikan Anda:
- Meninjau artikel Pola kluster Kubernetes ketersediaan tinggi.
- Meninjau isi repositori GitHub pendamping, yang berisi aset tambahan yang dirujuk dalam artikel ini.
- Memiliki akun yang dapat mengakses portal pengguna Azure Stack Hub, dengan setidaknya izin "kontributor".
Mengunduh dan menyiapkan Mesin AKS
Mesin AKS adalah biner yang dapat digunakan dari host Windows atau Linux apa pun yang dapat mencapai titik akhir Azure Stack Hub Azure Resource Manager. Panduan ini menjelaskan penyebaran VM Linux (atau Windows) baru di Azure Stack Hub. Ini akan digunakan nanti saat Mesin AKS menyebarkan kluster Kubernetes.
Catatan
Anda juga dapat menggunakan VM Windows atau Linux yang sudah ada untuk menyebarkan kluster Kubernetes di Azure Stack Hub menggunakan Mesin AKS.
Proses langkah demi langkah dan persyaratan untuk Mesin AKS didokumentasikan di sini:
- Instal Mesin AKS di Linux di Azure Stack Hub (atau menggunakan Windows)
Mesin AKS adalah alat bantu untuk menyebarkan dan mengoperasikan (tidak terkelola) kluster Kubernetes (di Azure dan Azure Stack Hub).
Detail dan perbedaan Mesin AKS di Azure Stack Hub dijelaskan di sini:
Lingkungan sampel akan menggunakan Terraform untuk mengotomatiskan penyebaran VM Mesin AKS. Anda dapat menemukan detail dan kode di repo GitHub pendamping.
Hasil dari langkah ini adalah grup sumber daya baru di Azure Stack Hub yang berisi VM pembantu Mesin AKS dan sumber daya terkait:
Catatan
Jika Anda harus menyebarkan Mesin AKS di lingkungan dengan celah udara yang tidak terhubung, tinjau Instans Azure Stack Hub yang Terputus untuk mempelajari selengkapnya.
Pada langkah berikutnya, kita akan menggunakan VM Mesin AKS yang baru disebarkan untuk menyebarkan kluster Kubernetes.
Menyambungkan ke VM pembantu Mesin AKS
Pertama, Anda harus tersambung ke VM pembantu Mesin AKS yang dibuat sebelumnya.
VM harus memiliki Alamat IP Publik dan harus dapat diakses melalui SSH (Port 22/TCP).
Tip
Anda dapat menggunakan alat pilihan Anda seperti MobaXterm, puTTY atau PowerShell di Windows 10 untuk tersambung ke VM Linux menggunakan SSH.
ssh <username>@<ipaddress>
Setelah tersambung, jalankan perintah aks-engine. Buka Versi Mesin AKS yang Didukung untuk mempelajari selengkapnya tentang versi Mesin AKS dan Kubernetes.
Menyebarkan kluster Kubernetes
VM pembantu Mesin AKS sendiri belum membuat kluster Kubernetes di Azure Stack Hub kami. Membuat kluster adalah tindakan pertama yang harus dilakukan di VM pembantu Mesin AKS.
Proses langkah demi langkah didokumentasikan di sini:
Hasil akhir dari perintah aks-engine deploy dan persiapan di langkah sebelumnya adalah kluster Kubernetes berfitur lengkap yang disebarkan ke ruang penyewa instans Azure Stack Hub pertama. Kluster itu sendiri terdiri dari komponen Azure IaaS seperti VM, load balancer, VNet, disk, dan sebagainya.
- Load balancer Azure (Titik Akhir K8s API) 2) Node Worker (Kumpulan Agen) 3) Node Master
Kluster sekarang aktif dan berjalan dan pada langkah berikutnya kami akan menghubungkannya.
Sambungkan ke kluster Kube
Anda sekarang dapat tersambung ke kluster Kubernetes yang dibuat sebelumnya, baik melalui SSH (menggunakan kunci SSH yang ditentukan sebagai bagian dari penyebaran) atau melalui kubectl (direkomendasikan). Alat baris perintah Kubernetes kubectl tersedia untuk Windows, Linux, dan macOS di sini. Ini sudah diinstal sebelumnya dan dikonfigurasi pada node master kluster kami:
ssh azureuser@<k8s-master-lb-ip>
Sebaiknya tidak menggunakan node master sebagai jumpbox untuk tugas administratif. Konfigurasi kubectl disimpan di .kube/config pada node master serta pada VM Mesin AKS. Anda dapat menyalin konfigurasi ke mesin admin dengan konektivitas ke kluster Kubernetes dan menggunakan perintah kubectl di sana. File .kube/config juga digunakan nanti untuk mengonfigurasi koneksi layanan di Azure Pipelines.
Penting
Amankan file-file ini karena berisi info masuk untuk kluster Kubernetes Anda. Penyerang dengan akses ke file memiliki informasi yang cukup untuk mendapatkan akses administrator ke file tersebut. Semua tindakan yang dilakukan menggunakan file .kube/config awal dilakukan menggunakan akun admin kluster.
Anda sekarang dapat mencoba berbagai perintah menggunakan kubectl untuk memeriksa status kluster Anda. Berikut adalah contoh perintah:
kubectl get nodes
NAME STATUS ROLE VERSION
k8s-linuxpool-35064155-0 Ready agent v1.14.8
k8s-linuxpool-35064155-1 Ready agent v1.14.8
k8s-linuxpool-35064155-2 Ready agent v1.14.8
k8s-master-35064155-0 Ready master v1.14.8
kubectl cluster-info
Kubernetes master is running at https://aks.***
CoreDNS is running at https://aks.***/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://aks.***/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://aks.***/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
Penting
Kubernetes memiliki model Kontrol Akses Berbasis Peran (RBAC) sendiri yang memungkinkan Anda membuat definisi peran dan pengikatan data peran yang terperinci. Ini adalah cara yang lebih baik untuk mengontrol akses ke kluster daripada membagikan izin admin kluster.
Menyambungkan Azure Pipelines ke kluster Kubernetes
Untuk menyambungkan Azure Pipelines ke kluster Kubernetes yang baru digunakan, diperlukan file kubeconfig (.kube/config) seperti yang dijelaskan pada langkah sebelumnya.
- Hubungkan ke salah satu node master kluster Kubernetes Anda.
- Salin konten file
.kube/config. - Buka Azure DevOps > Pengaturan Proyek > Koneksi Layanan untuk membuat koneksi layanan "Kubernetes" baru (gunakan KubeConfig sebagai metode Autentikasi)
Penting
Azure Pipelines (atau agen build-nya) harus memiliki akses ke Kubernetes API. Jika ada koneksi Internet dari Azure Pipelines ke kluster Azure Stack Hub Kubernetes, Anda harus menyebarkan Agen Pembuatan Azure Pipelines yang dihosting sendiri.
Saat menyebarkan Agen yang dihosting sendiri untuk Azure Pipelines, Anda dapat menyebarkan baik di Azure Stack Hub, atau pada mesin dengan konektivitas jaringan ke semua titik akhir manajemen yang diperlukan. Lihat detailnya di sini:
- Agen Azure Pipelines di Windows atau Linux
Bagian Pertimbangan Penyebaran (CI/CD) pola berisi alur keputusan yang membantu Anda memahami apakah akan menggunakan agen yang dihosting Microsoft atau agen yang dihosting sendiri:
Unduh file Visio dari semua diagram dalam artikel ini.
Dalam solusi sampel ini, topologi menyertakan agen build yang dihosting sendiri di setiap instans Azure Stack Hub. Agen dapat mengakses Titik Akhir Manajemen Azure Stack Hub dan titik akhir API kluster Kubernetes.
Unduh file Visio dari semua diagram dalam artikel ini.
Desain ini memenuhi persyaratan peraturan umum, yaitu hanya memiliki koneksi keluar dari solusi aplikasi.
Mengonfigurasi pemantauan
Anda dapat menggunakan Azure Monitor untuk kontainer guna memantau kontainer dalam solusi. Ini mengarahkan Azure Monitor ke kluster Kubernetes yang disebarkan Mesin AKS di Azure Stack Hub.
Ada dua cara untuk mengaktifkan Azure Monitor di kluster Anda. Kedua cara tersebut mengharuskan Anda menyiapkan ruang kerja Log Analytics di Azure.
- Metode satu menggunakan Helm Chart
- Metode dua sebagai bagian dari spesifikasi kluster Mesin AKS
Dalam topologi sampel, "Metode satu" digunakan, yang memungkinkan otomatisasi proses dan pembaruan dapat diinstal dengan lebih mudah.
Untuk langkah selanjutnya, Anda memerlukan Ruang Kerja Azure LogAnalytics (ID dan Kunci), Helm (versi 3), dan kubectl di mesin Anda.
Helm adalah manajer paket Kubernetes, tersedia sebagai biner yang berjalan di macOS, Windows, dan Linux. Helm dapat diunduh di helm.sh. Helm bergantung pada file konfigurasi Kubernetes yang digunakan untuk perintah kubectl:
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo update
helm install incubator/azuremonitor-containers \
--set omsagent.secret.wsid=<your_workspace_id> \
--set omsagent.secret.key=<your_workspace_key> \
--set omsagent.env.clusterName=<my_prod_cluster> \
--generate-name
Perintah ini akan menginstal agen Azure Monitor pada kluster Kubernetes Anda:
kubectl get pods -n kube-system
NAME READY STATUS
omsagent-8qdm6 1/1 Running
omsagent-r6ppm 1/1 Running
omsagent-rs-76c45758f5-lmc4l 1/1 Running
Agen Operations Management Suite (OMS) di kluster Kubernetes Anda akan mengirimkan data pemantauan ke Ruang Kerja Azure Log Analytics Anda (menggunakan HTTPS keluar). Anda sekarang dapat menggunakan Azure Monitor untuk mendapatkan wawasan yang lebih mendalam tentang kluster Kubernetes Anda di Azure Stack Hub. Desain ini adalah cara yang ampuh untuk mendemonstrasikan kekuatan analitik yang dapat disebarkan secara otomatis dengan kluster aplikasi Anda.
Penting
Jika Azure Monitor tidak menampilkan data Azure Stack Hub apa pun, pastikan Anda telah mengikuti instruksi tentang cara menambahkan solusi AzureMonitor-Containers ke ruang kerja Azure Log Analytics dengan hati-hati.
Menyebarkan aplikasi
Sebelum menginstal aplikasi sampel kami, ada langkah lain untuk mengonfigurasi pengontrol Ingress berbasis nginx di kluster Kubernetes kami. Pengontrol Ingress digunakan sebagai load balancer lapisan 7 untuk merutekan lalu lintas di kluster kami berdasarkan host, jalur, atau protokol. Nginx-ingress tersedia sebagai Helm Chart. Untuk petunjuk terperinci, lihat repositori Helm Chart GitHub.
Aplikasi sampel kami juga dikemas sebagai Helm Chart, seperti Agen Pemantau Azure pada langkah sebelumnya. Dengan demikian, sangatlah mudah untuk menyebarkan aplikasi ke kluster Kubernetes kami. Anda dapat menemukan file Helm Chart di repo GitHub pendamping
Aplikasi sampel adalah aplikasi tiga tingkat, disebarkan ke kluster Kubernetes pada masing-masing dari dua instans Azure Stack Hub. Aplikasi ini menggunakan database MongoDB. Anda dapat mempelajari selengkapnya tentang cara membuat data direplikasi di beberapa instans dalam pola Pertimbangan Data dan Penyimpanan.
Setelah menyebarkan Helm Chart untuk aplikasi, Anda akan melihat ketiga tingkatan aplikasi Anda direpresentasikan sebagai penyebaran dan set berstatus (untuk database) dengan satu pod:
kubectl get pod,deployment,statefulset
NAME READY STATUS
pod/ratings-api-569d7f7b54-mrv5d 1/1 Running
pod/ratings-mongodb-0 1/1 Running
pod/ratings-web-85667bfb86-l6vxz 1/1 Running
NAME READY
deployment.extensions/ratings-api 1/1
deployment.extensions/ratings-web 1/1
NAME READY
statefulset.apps/ratings-mongodb 1/1
Di sisi layanan, Anda akan menemukan Pengontrol Ingress berbasis nginx dan alamat IP publiknya:
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP
nginx-ingress-1588931383-controller LoadBalancer 10.0.114.180 *public-ip* 443:30667/TCP
nginx-ingress-1588931383-default-backend ClusterIP 10.0.76.54 <none> 80/TCP
ratings-api ClusterIP 10.0.46.69 <none> 80/TCP
ratings-web ClusterIP 10.0.161.124 <none> 80/TCP
Alamat "IP Eksternal" adalah "titik akhir aplikasi" kami. Begitulah cara pengguna akan tersambung untuk membuka aplikasi dan juga akan digunakan sebagai titik akhir untuk langkah selanjutnya Mengonfigurasi Traffic Manager.
Melakukan skala otomatis aplikasi
Anda dapat secara opsional mengonfigurasi Penskala Otomatis Pod Horizontal untuk meningkatkan atau menurunkan skala berdasarkan metrik tertentu seperti penggunaan CPU. Perintah berikut akan membuat Penskala Otomatis Pod Horizontal yang memelihara 1 hingga 10 replika Pod yang dikendalikan oleh penyebaran rating-web. HPA akan menambah dan mengurangi jumlah replika (melalui penyebaran) untuk mempertahankan rata-rata pemanfaatan CPU di semua Pod sebesar 80%:
kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10
Anda dapat memeriksa status penskala saat ini dengan menjalankan perintah ini:
kubectl get hpa
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
ratings-web Deployment/ratings-web/scale 0% / 80% 1 10 1 18s
Mengonfigurasi Traffic Manager
Untuk mendistribusikan lalu lintas antara dua (atau lebih) penyebaran aplikasi, kami akan menggunakan Azure Traffic Manager. Azure Traffic Manager adalah load balancer lalu lintas berbasis DNS di Azure.
Catatan
Traffic Manager menggunakan DNS untuk mengarahkan permintaan klien ke titik akhir layanan yang paling tepat berdasarkan metode perutean lalu lintas dan kesehatan titik akhir.
Daripada menggunakan Azure Traffic Manager, Anda juga dapat menggunakan solusi load-balancing global lainnya yang dihosting di lingkungan lokal. Dalam skenario sampel, kami akan menggunakan Azure Traffic Manager untuk mendistribusikan lalu lintas antara dua instans aplikasi kami. Mereka dapat berjalan di instans Azure Stack Hub di lokasi yang sama atau berbeda:
Unduh file Visio dari semua diagram dalam artikel ini.
Di Azure, kami mengonfigurasi Traffic Manager untuk menunjuk ke dua instans berbeda dari aplikasi kami:
Seperti yang Anda lihat, kedua titik akhir menunjuk ke dua instans aplikasi yang disebarkan dari bagian sebelumnya.
Pada titik ini:
- Infrastruktur Kubernetes telah dibuat, termasuk pengontrol ingress.
- Kluster telah disebarkan di dua instans Azure Stack Hub.
- Pemantauan telah dikonfigurasi.
- Azure Traffic Manager akan memuat lalu lintas keseimbangan di dua instans Azure Stack Hub.
- Di atas infrastruktur ini, sampel aplikasi tiga tingkat telah disebarkan secara otomatis menggunakan Helm Chart.
Solusinya sekarang harus aktif dan dapat diakses oleh pengguna!
Ada juga beberapa pertimbangan operasional pasca penyebaran yang layak didiskusikan, yang dibahas dalam dua bagian berikutnya.
Tingkatkan Kubernetes
Pertimbangkan topik berikut saat meningkatkan kluster Kubernetes:
- Meningkatkan kluster Kubernetes adalah operasi Hari ke-2 yang kompleks yang dapat dilakukan menggunakan Mesin AKS. Untuk informasi selengkapnya, lihat Meningkatkan kluster Kubernetes di Azure Stack Hub.
- Mesin AKS memungkinkan Anda meningkatkan kluster ke Kubernetes yang lebih baru dan versi gambar OS dasar. Untuk informasi selengkapnya, lihat Langkah-langkah untuk meningkatkan ke versi Kubernetes yang lebih baru.
- Anda juga dapat meningkatkan hanya node yang mendasarinya ke versi gambar OS dasar yang lebih baru. Untuk informasi selengkapnya, lihat Langkah-langkah untuk hanya meningkatkan versi gambar OS.
Gambar OS dasar yang lebih baru berisi pembaruan keamanan dan kernel. Operator kluster bertanggung jawab untuk memantau ketersediaan Versi Kubernetes dan Gambar OS yang lebih baru. Operator harus merencanakan dan menjalankan peningkatan ini menggunakan Mesin AKS. Gambar OS dasar harus diunduh dari Marketplace Azure Stack Hub oleh Operator Azure Stack Hub.
Menskalakan Kubernetes
Skala adalah operasi Hari 2 lainnya yang dapat diatur menggunakan Mesin AKS.
Perintah skala menggunakan kembali file konfigurasi kluster Anda (apimodel.json) di direktori output, sebagai input untuk penyebaran Azure Resource Manager baru. Mesin AKS menjalankan operasi penskalaan terhadap kumpulan agen tertentu. Saat operasi penskalaan selesai, Mesin AKS memperbarui definisi kluster dalam file apimodel.json yang sama. Definisi kluster mencerminkan jumlah node baru untuk mencerminkan konfigurasi kluster saat ini yang diperbarui.
Langkah berikutnya
- Pelajari selengkapnya tentang Pertimbangan desain aplikasi hibrida.
- Tinjau dan usulkan peningkatan pada kode untuk sampel ini di GitHub.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk