Pola kluster Kubernetes high availability

Artikel ini menjelaskan cara merancang dan mengoperasikan infrastruktur berbasis Kubernetes yang sangat tersedia menggunakan Azure Kubernetes Service (AKS) Engine di Azure Stack Hub. Skenario ini umum untuk organisasi dengan beban kerja penting di lingkungan yang sangat terbatas dan diatur. Organisasi dalam domain seperti keuangan, pertahanan, dan pemerintah.

Konteks dan masalah

Banyak organisasi mengembangkan solusi native cloud yang memanfaatkan layanan dan teknologi canggih seperti Kubernetes. Meskipun Azure menyediakan pusat data di sebagian besar wilayah di dunia, terkadang ada kasus penggunaan tepi dan skenario saat aplikasi yang penting bagi bisnis harus berjalan di lokasi tertentu. Pertimbangannya meliputi:

• Sensitivitas lokasi
• Latensi antara aplikasi dan sistem lokal
• Konservasi bandwidth
• Konektivitas
• Persyaratan peraturan atau hukum

Azure, dalam kombinasi dengan Azure Stack Hub, mengatasi sebagian besar masalah ini. Serangkaian opsi, keputusan, dan pertimbangan yang luas untuk keberhasilan implementasi Kubernetes yang berjalan di Azure Stack Hub dijelaskan di bawah ini.

Solusi

Pola ini mengasumsikan bahwa kita harus menghadapi seperangkat kendala yang ketat. Aplikasi harus berjalan di tempat dan semua data pribadi tidak boleh menjangkau layanan cloud publik. Pemantauan dan data non-PII lainnya dapat dikirim ke Azure dan diproses di sana. Layanan eksternal seperti Container Registry publik atau lainnya dapat diakses tetapi dapat disaring melalui firewall atau server proksi.

Aplikasi sampel yang ditampilkan di sini dirancang untuk menggunakan solusi asli Kubernetes jika memungkinkan. Desain ini menghindari penguncian vendor, alih-alih menggunakan layanan native platform. Sebagai contoh, aplikasi menggunakan ujung belakang database MongoDB yang dihosting sendiri alih-alih layanan PaaS atau layanan database eksternal. Untuk informasi selengkapnya, lihat Pengantar Kubernetes di jalur pembelajaran Azure.

Diagram sebelumnya menggambarkan arsitektur aplikasi dari aplikasi sampel yang berjalan di Kubernetes di Azure Stack Hub. Aplikasi ini terdiri dari beberapa komponen, termasuk:

1. Kluster Kubernetes berbasis AKS Engine di Azure Stack Hub.
2. cert-manager, yang menyediakan seperangkat alat untuk manajemen sertifikat di Kubernetes, digunakan untuk secara otomatis meminta sertifikat dari Let's Encrypt.
3. Namespace Kubernetes yang berisi komponen aplikasi untuk ujung depan (ratings-web), api (ratings-api), dan database (ratings-mongodb).
4. Pengontrol Ingress yang merutekan lalu lintas HTTP/HTTPS ke titik akhir dalam kluster Kubernetes.

Aplikasi sampel digunakan untuk menggambarkan arsitektur aplikasi. Semua komponen adalah contoh. Arsitektur hanya berisi satu penyebaran aplikasi. Untuk mencapai ketersediaan tinggi (HA), kami akan menjalankan penyebaran setidaknya dua kali pada dua instans Azure Stack Hub yang berbeda - dapat berjalan baik di lokasi yang sama atau di dua (atau lebih) situs yang berbeda:

Layanan seperti Azure Container Registry, Azure Monitor, dan lainnya, dihosting di luar Azure Stack Hub di Azure atau lokal. Desain hibrid ini melindungi solusi terhadap pemadaman satu instans Azure Stack Hub.

Komponen

Keseluruhan arsitektur terdiri dari komponen-komponen berikut:

Azure Stack Hub adalah ekstensi Azure yang menyediakan cara untuk menjalankan aplikasi di lingkungan lokal dan memberikan layanan Azure di pusat data Anda. Buka Gambaran umum Azure Stack Hub untuk mempelajari lebih lanjut.

Azure Kubernetes Service Engine (AKS Engine) adalah mesin di balik penawaran layanan Kubernetes terkelola, Azure Kubernetes Service (AKS), yang tersedia di Azure saat ini. Untuk Azure Stack Hub, AKS Engine memungkinkan kami menyebarkan, menskalakan, dan meningkatkan kluster Kubernetes berfitur lengkap yang dikelola sendiri menggunakan kemampuan IaaS Azure Stack Hub. Buka Gambaran umum AKS Engine untuk mempelajari lebih lanjut.

Buka Masalah dan Batasan Umum untuk mempelajari lebih lanjut tentang perbedaan antara AKS Engine di Azure dan AKS Engine di Azure Stack Hub.

Azure Virtual Network (VNet) digunakan untuk menyediakan infrastruktur jaringan di setiap Azure Stack Hub untuk Virtual Machines (VM) yang menghosting infrastruktur kluster Kubernetes.

Azure Load Balancer digunakan untuk Kubernetes API Endpoint dan Nginx Ingress Controller. Penyeimbang beban merutekan lalu lintas eksternal (misalnya, Internet) ke node dan VM yang menawarkan layanan tertentu.

Azure Container Registry (ACR) digunakan untuk menyimpan gambar Docker privat dan bagan Helm, yang disebarkan ke kluster. AKS dapat mengautentikasi dengan Container Registry menggunakan identitas Azure AD-nya. Kubernetes tidak memerlukan ACR. Anda dapat menggunakan registri kontainer lainnya, seperti Docker Hub.

Azure Repos adalah seperangkat alat kontrol versi yang dapat Anda gunakan untuk mengelola kode. Anda juga dapat menggunakan GitHub atau repositori berbasis git lainnya. Buka Gambaran umum Azure Repos untuk mempelajari lebih lanjut.

Azure Pipelines adalah bagian dari Azure DevOps Services dan menjalankan pembangunan, pengujian, dan penyebaran otomatis. Anda juga dapat menggunakan solusi CI/CD pihak ketiga seperti Jenkins. Buka Gambaran umum Azure Pipelines untuk mempelajari lebih lanjut.

Azure Monitormengumpulkan dan menyimpan metrik dan log, telemetri aplikasi, dan metrik platform untuk layanan Azure. Anda dapat menggunakan data ini untuk memantau aplikasi, menyiapkan peringatan dan dasbor, serta melakukan analisis akar penyebab kegagalan. Azure Monitor terintegrasi dengan Kubernetes untuk mengumpulkan metrik dari pengontrol, node, dan kontainer, serta log kontainer dan log node master. Buka Gambaran umum Azure Monitor untuk mempelajari lebih lanjut.

Azure Traffic Manager adalah penyeimbang beban lalu lintas berbasis DNS yang memungkinkan Anda mendistribusikan lalu lintas secara optimal ke layanan di seluruh wilayah Azure yang berbeda atau penyebaran Azure Stack Hub. Traffic Manager juga menyediakan high availability dan respons yang cepat. Titik akhir aplikasi harus dapat diakses dari luar. Ada solusi lokal lain yang tersedia juga.

Kubernetes Ingress Controller mengekspos rute HTTP ke layanan dalam kluster Kubernetes. Nginx atau pengontrol masuk yang sesuai dapat digunakan untuk tujuan ini.

Helm adalah manajer paket untuk penyebaran Kubernetes, menyediakan cara untuk menggabungkan objek Kubernetes yang berbeda seperti Deployments, Services, Secrets, menjadi satu "bagan". Anda dapat memublikasikan, menyebarkan, mengontrol manajemen versi, dan memperbarui objek bagan. Azure Container Registry dapat digunakan sebagai repositori untuk menyimpan Bagan Helm dalam paket.

Pertimbangan rancangan

Pola ini mengikuti beberapa pertimbangan tingkat tinggi yang dijelaskan secara lebih terperinci di bagian selanjutnya dari artikel ini:

• Aplikasi ini menggunakan solusi native Kubernetes, untuk menghindari penguncian vendor.
• Aplikasi ini menggunakan arsitektur layanan mikro.
• Azure Stack Hub tidak memerlukan masuk tetapi memungkinkan konektivitas Internet keluar.

Praktik yang direkomendasikan ini juga akan berlaku untuk beban kerja dan skenario dunia nyata.

Pertimbangan skalabilitas

Skalabilitas penting untuk memberikan pengguna akses yang konsisten, andal, dan dengan performa baik ke aplikasi.

Skenario sampel mencakup skalabilitas pada beberapa lapisan tumpukan aplikasi. Berikut adalah gambaran umum tingkat tinggi dari berbagai lapisan:

Tingkat arsitektur	Mempengaruhi	Bagaimana?
Aplikasi	Aplikasi	Penskalaan horizontal berdasarkan jumlah Pod/Replika/Container Instances*
Kluster	Kluster Kube	Jumlah Node (antara 1 dan 50), ukuran VM-SKU, dan Kumpulan Node (AKS Engine di Azure Stack Hub saat ini hanya mendukung satu kumpulan node); menggunakan perintah skala AKS Engine (manual)
Infrastruktur	Azure Stack Hub	Jumlah node, kapasitas, dan unit skala dalam penyebaran Azure Stack Hub

* Menggunakan Horizontal Pod Autoscaler (HPA) Kubernetes; penskalaan berbasis metrik otomatis atau penskalaan vertikal dengan mengukur instans kontainer (cpu/memori).

Azure Stack Hub (tingkat infrastruktur)

Infrastruktur Azure Stack Hub adalah dasar dari penerapan ini, karena Azure Stack Hub berjalan pada perangkat keras fisik di pusat data. Saat memilih perangkat keras Hub Anda, Anda perlu membuat pilihan untuk CPU, kepadatan memori, konfigurasi penyimpanan, dan jumlah server. Untuk mempelajari lebih lanjut tentang skalabilitas Azure Stack Hub, lihat sumber daya berikut:

• Perencanaan kapasitas untuk ringkasan Azure Stack Hub
• Menambahkan node unit skala tambahan di Azure Stack Hub

Kluster Kubernetes (level kluster)

Kluster Kubernetes sendiri terdiri dari, dan dibuat di atas komponen IaaS Azure (Stack) termasuk komputasi, penyimpanan, dan sumber daya jaringan. Solusi Kubernetes melibatkan node master dan pekerja, yang disebarkan sebagai VM di Azure (dan Azure Stack Hub).

• Node sarana kontrol menyediakan layanan Kubernetes inti dan pengaturan beban kerja aplikasi.
• Node pekerja (pekerja) menjalankan beban kerja aplikasi Anda.

Saat memilih ukuran VM untuk penyebaran awal, ada beberapa pertimbangan:

• Biaya - Saat merencanakan node pekerja Anda, ingatlah keseluruhan biaya per VM yang akan Anda keluarkan. Misalnya, jika beban kerja aplikasi Anda memerlukan sumber daya yang terbatas, Anda harus berencana untuk menyebarkan VM yang lebih kecil. Azure Stack Hub, seperti Azure, biasanya ditagih berdasarkan penggunaan, jadi ukuran peran VM untuk Kubernetes secara tepat sangat penting untuk mengoptimalkan biaya penggunaan.

• Skalabilitas - Skalabilitas kluster dicapai dengan menskalakan masuk dan keluar jumlah node master dan pekerja, atau dengan menambahkan kumpulan simpul tambahan (tidak tersedia di Azure Stack Hub hari ini). Penskalaan kluster dapat dilakukan berdasarkan data performa, dikumpulkan menggunakan Container Insights (Azure Monitor + Log Analytics).

  Jika aplikasi Anda membutuhkan lebih banyak (atau lebih sedikit) sumber daya, Anda dapat meluaskan skala (atau menciutkan skala) node Anda saat ini secara horizontal (antara 1 dan 50 node). Jika membutuhkan lebih dari 50 node, Anda dapat membuat kluster tambahan dalam langganan terpisah. Anda tidak dapat meningkatkan VM yang sebenarnya secara vertikal ke ukuran VM lain tanpa memindahkan kluster.

  Penskalaan dilakukan secara manual menggunakan VM pembantu AKS Engine yang digunakan untuk menyebarkan kluster Kubernetes pada awalnya. Untuk informasi selengkapnya, lihat Kluster Penskalaan Kubernetes

• Kuota - Pertimbangkan kuota yang telah Anda konfigurasikan saat merencanakan penyebaran AKS di Azure Stack Hub Anda. Pastikan setiap langganan memiliki paket yang tepat dan kuota dikonfigurasi. Langganan perlu mengakomodasi jumlah komputasi, penyimpanan, dan layanan lain yang diperlukan untuk kluster Anda saat menskalakan.

• Beban kerja aplikasi - Lihat Konsep kluster dan beban kerja dalam konsep inti Kubernetes untuk dokumen Azure Kubernetes Service. Artikel ini akan membantu Anda cakupan ukuran VM yang tepat berdasarkan kebutuhan komputasi dan memori aplikasi Anda.

Aplikasi (tingkat aplikasi)

Pada lapisan aplikasi, kami menggunakan Kubernetes Horizontal Pod Autoscaler (HPA). HPA dapat menambah atau mengurangi jumlah Replika (Pod/Container Instances) dalam penyebaran kami berdasarkan metrik yang berbeda (seperti pemanfaatan CPU).

Opsi lain adalah menskalakan instans kontainer secara vertikal. Hal ini dapat dicapai dengan mengubah jumlah CPU dan Memori yang diminta dan tersedia untuk penyebaran tertentu. Lihat Mengelola Sumber Daya untuk Kontainer di kubernetes.io untuk mempelajari lebih lanjut.

Pertimbangan jaringan dan konektivitas

Jaringan dan konektivitas juga memengaruhi tiga lapisan yang disebutkan sebelumnya untuk Kubernetes di Azure Stack Hub. Tabel berikut menunjukkan lapisan dan layanan mana yang dikandungnya:

Lapisan	Mempengaruhi	Apa?
Aplikasi	Aplikasi	Bagaimana aplikasi dapat diakses? Apakah akan diekspos ke Internet?
Kluster	Kluster Kube	Kubernetes API, VM AKS Engine, Menarik gambar kontainer (keluar), Mengirim data pemantauan dan telemetri (keluar)
Infrastruktur	Azure Stack Hub	Aksesibilitas titik akhir manajemen Azure Stack Hub seperti titik akhir portal dan Azure Resource Manager.

Aplikasi

Untuk lapisan aplikasi, pertimbangan yang paling penting adalah apakah aplikasi diekspos dan dapat diakses dari Internet. Dari perspektif Kubernetes, aksesibilitas Internet berarti mengekspos penyebaran atau pod menggunakan Layanan Kubernetes atau Pengontrol Masuk.

Mengekspos aplikasi menggunakan IP publik melalui Load Balancer atau Pengontrol Masuk tidak berarti bahwa aplikasi sekarang dapat diakses melalui Internet. Azure Stack Hub mungkin memiliki alamat IP publik yang hanya terlihat di intranet lokal - tidak semua IP publik benar-benar menghadap ke Internet.

Blok sebelumnya mempertimbangkan lalu lintas masuk ke aplikasi. Topik lain yang harus dipertimbangkan untuk penyebaran Kubernetes yang sukses adalah lalu lintas outbound/keluar. Berikut adalah beberapa kasus penggunaan yang memerlukan lalu lintas keluar:

• Menarik Gambar Kontainer yang disimpan di DockerHub atau Azure Container Registry
• Mengambil Bagan Helm
• Memancarkan data Application Insights (atau data pemantauan lainnya)

Beberapa lingkungan perusahaan mungkin memerlukan penggunaan server proksi transparan atau tidak transparan. Server ini memerlukan konfigurasi khusus pada berbagai komponen kluster kami. Dokumentasi AKS Engine berisi berbagai detail tentang cara mengakomodasi proksi jaringan. Untuk detail selengkapnya, lihat Server proksi dan AKS Engine

Terakhir, lalu lintas kluster harus mengalir di antara instans Azure Stack Hub. Penyebaran sampel terdiri dari kluster Kubernetes individual yang berjalan pada instans Azure Stack Hub individual. Lalu lintas di antara mereka, seperti lalu lintas replikasi antara dua database, adalah "lalu lintas eksternal". Lalu lintas eksternal harus dialihkan melalui alamat IP Publik Azure Stack Hub atau VPN Situs ke Situs untuk menghubungkan Kubernetes pada dua instans Azure Stack Hub:

Kluster

Kluster Kubernetes tidak perlu dapat diakses melalui Internet. Bagian yang relevan adalah API Kubernetes yang digunakan untuk mengoperasikan kluster, misalnya, menggunakan kubectl. Titik akhir API Kubernetes harus dapat diakses oleh semua orang yang mengoperasikan kluster atau menyebarkan aplikasi dan layanan di atasnya. Topik ini dibahas secara lebih terperinci dari perspektif DevOps di bagian Pertimbangan Penyebaran (CI/CD) di bawah ini.

Pada tingkat kluster, ada juga beberapa pertimbangan seputar lalu lintas keluar:

• Pembaruan node (untuk Ubuntu)
• Data pemantauan (dikirim ke Azure LogAnalytics)
• Agen lain yang membutuhkan lalu lintas keluar (khusus untuk lingkungan masing-masing penyebar)

Sebelum Anda menyebarkan kluster Kubernetes menggunakan AKS Engine, rencanakan desain jaringan akhir. Alih-alih membuat Jaringan Virtual khusus, mungkin lebih efisien untuk menyebarkan kluster ke dalam jaringan yang ada. Misalnya, Anda dapat memanfaatkan koneksi VPN Situs ke Situs yang sudah ada yang sudah dikonfigurasi di lingkungan Azure Stack Hub Anda.

Infrastruktur

Infrastruktur mengacu pada mengakses titik akhir manajemen Azure Stack Hub. Titik akhir mencakup portal penyewa dan admin, serta titik akhir admin dan penyewa Azure Resource Manager. Titik akhir ini diperlukan untuk mengoperasikan Azure Stack Hub dan layanan intinya.

Pertimbangan data dan penyimpanan

Dua instans aplikasi kami akan disebarkan, pada dua kluster Kubernetes individual, di dua instans Azure Stack Hub. Desain ini akan mengharuskan kita untuk mempertimbangkan cara mereplikasi dan menyinkronkan data di antaranya.

Dengan Azure, kami memiliki kemampuan bawaan untuk mereplikasi penyimpanan di beberapa wilayah dan zona di dalam cloud. Saat ini dengan Azure Stack Hub tidak ada cara asli untuk mereplikasi penyimpanan di dua instans Azure Stack Hub yang berbeda - mereka membentuk dua cloud independen tanpa cara menyeluruh untuk mengelolanya sebagai satu rangkaian. Merencanakan ketahanan aplikasi yang berjalan di Azure Stack Hub memaksa Anda untuk mempertimbangkan independensi ini dalam desain dan penyebaran aplikasi Anda.

Dalam kebanyakan kasus, replikasi penyimpanan tidak akan diperlukan untuk aplikasi yang tangguh dan sangat tersedia yang digunakan pada AKS. Tetapi Anda harus mempertimbangkan penyimpanan independen per instans Azure Stack Hub dalam desain aplikasi Anda. Jika desain ini menjadi perhatian atau pemblokiran jalan untuk menyebarkan solusi di Azure Stack Hub, ada kemungkinan solusi dari Mitra Microsoft yang menyediakan lampiran penyimpanan. Lampiran penyimpanan menyediakan solusi replikasi penyimpanan di beberapa Azure Stack Hubs dan Azure. Untuk informasi selengkapnya, lihat Solusi mitra.

Dalam arsitektur kami, lapisan ini dianggap:

Konfigurasi

Konfigurasi mencakup konfigurasi Azure Stack Hub, AKS Engine, dan kluster Kubernetes itu sendiri. Konfigurasi harus diotomatisasi sebanyak mungkin, dan disimpan sebagai Infrastructure-as-Code dalam sistem kontrol versi berbasis Git seperti Azure DevOps atau GitHub. Pengaturan ini tidak dapat dengan mudah disinkronkan di beberapa penyebaran. Oleh karena itu, sebaiknya simpan dan terapkan konfigurasi dari luar, dan menggunakan alur DevOps.

Aplikasi

Aplikasi harus disimpan dalam repositori berbasis Git. Setiap kali ada penyebaran baru, perubahan pada aplikasi, atau pemulihan bencana, dapat dengan mudah disebarkan menggunakan Azure Pipelines.

Data

Data adalah pertimbangan paling penting dalam sebagian besar desain aplikasi. Data aplikasi harus tetap sinkron antara berbagai instans aplikasi. Data juga membutuhkan strategi pencadangan dan pemulihan bencana jika terjadi pemadaman.

Mencapai desain ini sangat tergantung pada pilihan teknologi. Berikut adalah beberapa contoh solusi untuk mengimplementasikan database dengan cara yang sangat tersedia di Azure Stack Hub:

• Pelajari cara menyebarkan grup ketersediaan SQL Server 2016 ke Azure dan Azure Stack Hub
• Menerapkan solusi MongoDB yang sangat tersedia ke Azure dan Azure Stack Hub

Pertimbangan saat bekerja dengan data di beberapa lokasi adalah pertimbangan yang lebih kompleks untuk solusi yang sangat tersedia dan tangguh. Pertimbangkan:

• Latensi dan konektivitas jaringan antara Azure Stack Hubs.
• Ketersediaan identitas untuk layanan dan izin. Setiap instans Azure Stack Hub terintegrasi dengan direktori eksternal. Selama penyebaran, Anda memilih untuk menggunakan Azure Active Directory (Azure AD) atau Active Directory Federation Services (ADFS). Dengan demikian, ada potensi untuk menggunakan satu identitas yang dapat berinteraksi dengan beberapa instans Azure Stack Hub independen.

Keberlangsungan bisnis dan pemulihan bencana

Kelangsungan bisnis dan pemulihan bencana (BCDR) adalah topik penting di Azure Stack Hub dan Azure. Perbedaan utama adalah bahwa di Azure Stack Hub, operator harus mengelola seluruh proses BCDR. Di Azure, bagian BCDR dikelola otomatis oleh Microsoft.

BCDR memengaruhi area yang sama yang disebutkan di bagian sebelumnya Pertimbangan data dan penyimpanan:

• Infrastruktur/Konfigurasi
• Ketersediaan Aplikasi
• Data Aplikasi

Dan seperti yang disebutkan di bagian sebelumnya, area ini adalah tanggung jawab operator Azure Stack Hub dan dapat bervariasi antarorganisasi. Rencanakan BCDR sesuai dengan alat dan proses yang tersedia.

Infrastruktur dan konfigurasi

Bagian ini mencakup infrastruktur fisik dan logis serta konfigurasi Azure Stack Hub. Ini mencakup tindakan di admin dan ruang penyewa.

Operator Azure Stack Hub (atau administrator) bertanggung jawab untuk pemeliharaan instans Azure Stack Hub. Termasuk komponen seperti jaringan, penyimpanan, identitas, dan topik lain yang berada di luar cakupan artikel ini. Untuk mempelajari lebih lanjut tentang spesifikasi operasi Azure Stack Hub, lihat sumber daya berikut:

• Memulihkan data di Azure Stack Hub dengan Layanan Pencadangan Infrastruktur
• Mengaktifkan pencadangan untuk Azure Stack Hub dari portal administrator
• Memulihkan data dari kehilangan data masif
• Praktik terbaik Layanan Pencadangan Infrastruktur

Azure Stack Hub adalah platform dan fabric tempat aplikasi Kubernetes akan disebarkan. Pemilik aplikasi untuk aplikasi Kubernetes akan menjadi pengguna Azure Stack Hub, dengan akses yang diberikan untuk menyebarkan infrastruktur aplikasi yang diperlukan untuk solusi. Infrastruktur aplikasi dalam hal ini berarti kluster Kubernetes, disebarkan menggunakan AKS Engine, dan layanan di sekitarnya. Komponen-komponen ini akan disebarkan ke Azure Stack Hub, dibatasi oleh penawaran Azure Stack Hub. Pastikan penawaran yang diterima oleh pemilik aplikasi Kubernetes memiliki kapasitas yang cukup (dinyatakan dalam kuota Azure Stack Hub) untuk menyebarkan seluruh solusi. Seperti yang direkomendasikan di bagian sebelumnya, penyebaran aplikasi harus diotomatisasi menggunakan Infrastructure-as-Code dan alur penyebaran seperti Azure DevOps Azure Pipelines.

Untuk informasi selengkapnya tentang penawaran dan kuota Azure Stack Hub, lihat Gambaran umum layanan, paket, penawaran, dan langganan Azure Stack Hub

Penting untuk menyimpan dan menyimpan konfigurasi AKS Engine dengan aman termasuk output-nya. File ini berisi informasi rahasia yang digunakan untuk mengakses kluster Kubernetes, sehingga harus dilindungi agar tidak terpapar ke non-administrator.

Ketersediaan aplikasi

Aplikasi tidak boleh bergantung pada cadangan instans yang disebarkan. Sebagai praktik standar, penyebaran ulang aplikasi sepenuhnya mengikuti pola Infrastructure-as-Code. Misalnya, pemindahan menggunakan Azure DevOps Azure Pipelines. Prosedur BCDR harus melibatkan pemindahan aplikasi ke kluster Kubernetes yang sama atau lainnya.

Data aplikasi

Data aplikasi adalah bagian penting untuk meminimalkan kehilangan data. Pada bagian sebelumnya, teknik untuk mereplikasi dan menyinkronkan data antara dua (atau lebih) contoh aplikasi dijelaskan. Bergantung pada infrastruktur database (MySQL, MongoDB, MSSQL atau lainnya) yang digunakan untuk menyimpan data, akan ada berbagai ketersediaan database dan teknik cadangan yang tersedia untuk dipilih.

Cara yang disarankan untuk mencapai integritas adalah dengan menggunakan:

• Solusi pencadangan asli untuk database tertentu.
• Solusi cadangan yang secara resmi mendukung pencadangan dan pemulihan jenis database yang digunakan oleh aplikasi Anda.

Penting

Jangan menyimpan data cadangan Anda pada instans Azure Stack Hub yang sama tempat data aplikasi Anda berada. Pemadaman total instans Azure Stack Hub juga akan membahayakan cadangan Anda.

Pertimbangan ketersediaan

Kubernetes di Azure Stack Hub yang disebarkan melalui AKS Engine bukanlah layanan terkelola. Ini adalah penyebaran otomatis dan konfigurasi kluster Kubernetes menggunakan Azure Infrastructure-as-a-Service (IaaS). Dengan demikian, menyediakan ketersediaan yang sama dengan infrastruktur yang mendasarinya.

Infrastruktur Azure Stack Hub sudah tahan terhadap kegagalan, dan menyediakan kemampuan seperti Rangkaian Ketersediaan untuk mendistribusikan komponen di beberapa domain kesalahan dan pembaruan. Namun, teknologi yang mendasarinya (pengklusteran failover) masih menimbulkan beberapa waktu henti untuk mesin virtual pada server fisik yang terdampak jika ada kegagalan perangkat keras.

Ini adalah praktik yang baik untuk menyebarkan kluster Kubernetes produksi Anda serta beban kerja ke dua kluster (atau lebih). Kluster ini harus dihosting di lokasi atau pusat data yang berbeda, dan menggunakan teknologi seperti Azure Traffic Manager untuk merutekan pengguna berdasarkan waktu respons kluster atau berdasarkan geografi.

Pelanggan yang memiliki satu kluster Kubernetes biasanya terhubung ke IP layanan atau nama DNS aplikasi tertentu. Dalam penyebaran multikluster, pelanggan harus menyambungkan ke nama DNS Traffic Manager yang menunjuk ke layanan pada setiap kluster Kubernetes.

Catatan

Pola ini juga merupakan praktik terbaik untuk kluster AKS (terkelola) di Azure.

Kluster Kubernetes itu sendiri, yang disebarkan melalui AKS Engine, harus terdiri dari setidaknya tiga node master dan dua node pekerja.

Pertimbangan identitas dan keamanan

Identitas dan keamanan adalah topik penting. Terutama saat solusi mencakup instans Azure Stack Hub independen. Kubernetes dan Azure (termasuk Azure Stack Hub) memiliki mekanisme berbeda untuk kontrol akses berbasis peran (RBAC):

• Azure RBAC mengontrol akses ke sumber daya di Azure, termasuk kemampuan untuk membuat sumber daya Azure baru. Izin dapat ditetapkan untuk pengguna, grup, atau perwakilan layanan. (Perwakilan layanan adalah identitas keamanan yang digunakan oleh aplikasi.)
• Kubernetes RBAC mengontrol izin ke API Kubernetes. Misalnya, membuat pod dan daftar pod adalah tindakan yang dapat diotorisasi (atau ditolak) kepada pengguna melalui Kubernetes RBAC. Untuk menetapkan izin Kubernetes ke pengguna, Anda membuat peran dan pengikatan peran.

Identitas Azure Stack Hub dan RBAC

Azure Stack Hub menyediakan dua pilihan penyedia identitas. Penyedia yang Anda gunakan bergantung pada lingkungan dan apakah berjalan di lingkungan yang terhubung atau terputus:

• Azure AD - hanya dapat digunakan dalam lingkungan yang terhubung.
• ADFS ke forest Active Directory tradisional - dapat digunakan di lingkungan yang terhubung atau terputus.

Penyedia identitas mengelola pengguna dan grup, termasuk autentikasi dan otorisasi untuk mengakses sumber daya. Akses dapat diberikan ke sumber daya Azure Stack Hub seperti langganan, grup sumber daya, dan sumber daya individual seperti VM atau penyeimbang beban. Untuk memiliki model akses yang konsisten, Anda harus mempertimbangkan untuk menggunakan grup yang sama (baik langsung atau bersarang) untuk semua Azure Stack Hubs. Berikut adalah contoh konfigurasi:

Contoh berisi grup khusus (menggunakan AAD atau ADFS) untuk tujuan tertentu. Misalnya, untuk memberikan izin Kontributor untuk Grup Sumber Daya yang berisi infrastruktur kluster Kubernetes kami pada instans Azure Stack Hub tertentu (di sini "Kontributor Kluster Seattle K8s"). Grup ini kemudian disarangkan ke dalam grup keseluruhan yang berisi "subgrup" untuk setiap Azure Stack Hub.

Pengguna sampel kami sekarang akan memiliki izin "Kontributor" ke kedua Grup Sumber Daya yang berisi seluruh rangkaian sumber daya infrastruktur Kubernetes. Pengguna akan memiliki akses ke sumber daya di kedua instans Azure Stack Hub, karena instans berbagi penyedia identitas yang sama.

Penting

Izin ini hanya memengaruhi Azure Stack Hub dan beberapa sumber daya yang disebarkan di atasnya. Pengguna yang memiliki tingkat akses ini dapat melakukan banyak kerusakan, tetapi tidak dapat mengakses VM Kubernetes IaaS atau API Kubernetes tanpa akses tambahan ke penyebaran Kubernetes.

Identitas dan RBAC Kubernetes

Kluster Kubernetes, secara default, tidak menggunakan Penyedia Identitas yang sama dengan Azure Stack Hub yang sedang digunakan. VM yang menghosting kluster Kubernetes, master, dan node pekerja, menggunakan Kunci SSH yang ditentukan selama penyebaran kluster. Kunci SSH ini diperlukan untuk terhubung ke node ini menggunakan SSH.

API Kubernetes (misalnya, diakses dengan menggunakan kubectl) juga dilindungi oleh akun layanan termasuk akun layanan "admin kluster" default. Info masuk untuk akun layanan ini awalnya disimpan dalam file .kube/config di node master Kubernetes Anda.

Manajemen rahasia dan kredensial aplikasi

Untuk menyimpan rahasia seperti string koneksi atau info masuk database ada beberapa pilihan, termasuk:

• Azure Key Vault
• Rahasia Kubernetes
• Solusi Pihak ke-3 seperti HashiCorp Vault (berjalan di Kubernetes)

Jangan menyimpan rahasia atau info masuk dalam teks biasa dalam file konfigurasi, kode aplikasi, atau dalam skrip Anda. Dan jangan menyimpannya dalam sistem kontrol versi. Sebaliknya, otomatisasi penyebaran harus mengambil rahasia sesuai kebutuhan.

Patch dan pembaruan

Proses Patch and Update (PNU) di Azure Kubernetes Service sebagian otomatis. Peningkatan versi Kubernetes dipicu secara manual, sementara pembaruan keamanan diterapkan secara otomatis. Pembaruan ini mencakup perbaikan keamanan OS atau pembaruan kernel. AKS tidak secara otomatis me-reboot simpul Linux ini untuk menyelesaikan proses pembaruan.

Proses PNU untuk kluster Kubernetes yang disebarkan menggunakan AKS Engine di Azure Stack Hub tidak dikelola, dan merupakan tanggung jawab operator kluster.

AKS Engine membantu dengan dua tugas yang paling penting:

• Meningkatkan ke Kubernetes yang lebih baru dan versi gambar OS dasar
• Hanya meningkatkan gambar OS dasar

Gambar OS dasar yang lebih baru berisi pembaruan kernel dan perbaikan keamanan OS terbaru.

Mekanisme Peningkatan Tanpa Pengawasan secara otomatis menginstal pembaruan keamanan yang dirilis sebelum versi gambar OS dasar baru tersedia di Marketplace Azure Stack Hub. Peningkatan tanpa pengawasan diaktifkan secara default dan menginstal pembaruan keamanan secara otomatis, tetapi tidak me-reboot node kluster Kubernetes. Me-reboot node dapat diotomatisasi menggunakan KUbernetes REbootDaemon (kured)) sumber terbuka. Kured mengawasi node Linux yang memerlukan reboot, kemudian secara otomatis menangani penjadwalan ulang pod yang sedang berjalan dan proses reboot node.

Pertimbangan penyebaran (CI/CD)

Azure dan Azure Stack Hub mengekspos REST API Azure Resource Manager yang sama. API ini ditujukan seperti cloud Azure lainnya (Azure, Azure China 21Vianet, Azure Government). Mungkin ada perbedaan dalam versi API antara cloud, dan Azure Stack Hub hanya menyediakan subset layanan. Titik akhir manajemen URI juga berbeda untuk setiap cloud, dan setiap instans Azure Stack Hub.

Selain perbedaan halus yang disebutkan, Rest API Azure Resource Manager menyediakan cara yang konsisten untuk berinteraksi dengan Azure dan Azure Stack Hub. Seperangkat alat yang sama dapat digunakan di sini seperti yang akan digunakan dengan cloud Azure lainnya. Anda dapat menggunakan Azure DevOps, alat seperti Jenkins, atau PowerShell, untuk menyebarkan dan mengatur layanan ke Azure Stack Hub.

Pertimbangan

Salah satu perbedaan utama dalam hal penyebaran Azure Stack Hub adalah pertanyaan tentang aksesibilitas Internet. Aksesibilitas internet menentukan apakah akan memilih agen build yang dihosting Microsoft atau yang dihosting sendiri untuk pekerjaan CI/CD Anda.

Agen yang dihost sendiri dapat berjalan di atas Azure Stack Hub (sebagai VM IaaS) atau di subnet jaringan yang dapat mengakses Azure Stack Hub. Buka Agen Azure Pipelines untuk mempelajari perbedaannya lebih lanjut.

Gambar berikut membantu Anda memutuskan apakah Anda memerlukan agen build yang dihosting sendiri atau yang dihosting Microsoft:

• Apakah titik akhir manajemen Azure Stack Hub dapat diakses melalui Internet?
  • Ya: Kita dapat menggunakan Azure Pipelines dengan agen yang dihosting Microsoft untuk terhubung ke Azure Stack Hub.
  • Tidak: Kita memerlukan agen yang dihosting sendiri yang dapat terhubung ke titik akhir manajemen Azure Stack Hub.
• Apakah kluster Kubernetes kami dapat diakses melalui Internet?
  • Ya: Kita dapat menggunakan Azure Pipelines dengan agen yang dihosting Microsoft untuk berinteraksi langsung dengan titik akhir API Kubernetes.
  • Tidak: Kita memerlukan Agen yang dihosting sendiri yang dapat terhubung ke titik akhir API kluster Kubernetes.

Dalam skenario saat titik akhir manajemen Azure Stack Hub dan API Kubernetes dapat diakses melalui internet, penyebaran dapat menggunakan agen yang dihosting Microsoft. Penyebaran ini akan menghasilkan arsitektur aplikasi sebagai berikut:

Jika titik akhir Azure Resource Manager, API Kubernetes, atau keduanya tidak dapat diakses secara langsung melalui Internet, kita dapat memanfaatkan agen build yang dihosting sendiri untuk menjalankan langkah-langkah alur. Desain ini membutuhkan lebih sedikit konektivitas, dan hanya dapat disebarkan dengan konektivitas jaringan lokal ke titik akhir Azure Resource Manager dan API Kubernetes:

Catatan

Bagaimana dengan skenario yang terputus? Dalam skenario saat Azure Stack Hub atau Kubernetes atau keduanya tidak memiliki titik akhir manajemen yang menghadap ke internet, masih mungkin untuk menggunakan Azure DevOps untuk penyebaran Anda. Anda dapat menggunakan Kumpulan Agen yang dihosting sendiri (yang merupakan Agen DevOps yang berjalan di tempat atau di Azure Stack Hub itu sendiri) atau Azure DevOps Server yang sepenuhnya dihost sendiri secara lokal. Agen yang dihost sendiri hanya membutuhkan konektivitas Internet HTTPS (TCP/443) keluar.

Pola dapat menggunakan kluster Kubernetes (disebarkan dan diatur dengan mesin AKS) pada setiap instans Azure Stack Hub. Ini termasuk aplikasi yang terdiri dari ujung depan, tingkat menengah, layanan ujung belakang (misalnya MongoDB), dan Pengontrol Masuk berbasis nginx. Alih-alih menggunakan database yang dihosting di kluster K8s, Anda dapat memanfaatkan "penyimpanan data eksternal". Opsi database termasuk MySQL, SQL Server, atau database apa pun yang dihosting di luar Azure Stack Hub atau di IaaS. Konfigurasi seperti ini tidak ada dalam cakupan di sini.

Solusi mitra

Ada solusi Mitra Microsoft yang dapat memperluas kemampuan Azure Stack Hub. Solusi ini telah ditemukan berguna dalam penyebaran aplikasi yang berjalan pada kluster Kubernetes.

Penyimpanan dan solusi data

Seperti yang dijelaskan dalam Pertimbangan data dan penyimpanan, Azure Stack Hub saat ini tidak memiliki solusi asli untuk mereplikasi penyimpanan di beberapa instans. Tidak seperti Azure, kemampuan mereplikasi penyimpanan di beberapa wilayah tidak ada. Di Azure Stack Hub, setiap instans adalah cloudnya sendiri yang berbeda. Namun, solusi tersedia dari Mitra Microsoft yang memungkinkan replikasi penyimpanan di seluruh Azure Stack Hubs dan Azure.

SCALITY

Scality memberikan penyimpanan skala web yang telah mendukung bisnis digital sejak 2009. Scality RING, penyimpanan yang ditentukan perangkat lunak kami, mengubah server x86 komoditas menjadi kumpulan penyimpanan tak terbatas untuk semua jenis data - file dan objek - pada skala petabyte.

CLOUDIAN

Cloudian menyederhanakan penyimpanan perusahaan dengan penyimpanan terukur tanpa batas yang mengonsolidasikan himpunan data besar ke satu lingkungan yang mudah dikelola.

Langkah berikutnya

Untuk mempelajari lebih lanjut tentang konsep yang diperkenalkan dalam artikel ini:

• Penskalaan lintas cloud dan Pola aplikasi terdistribusi geografis di Azure Stack Hub.
• Arsitektur layanan mikro pada Azure Kubernetes Service (AKS).

Saat Anda siap menguji contoh solusi, lanjutkan dengan Panduan penyebaran kluster Kubernetes high availability . Panduan penyebaran memberikan petunjuk langkah demi langkah untuk menyebarkan dan menguji komponennya.