Ketersediaan aplikasi di AKS diaktifkan oleh Azure Arc

Berlaku untuk: AKS di Azure Stack HCI 22H2, AKS di Windows Server

Azure Kubernetes Service (AKS) yang diaktifkan oleh Azure Arc menawarkan platform kontainer yang didukung penuh yang dapat menjalankan aplikasi cloud-native pada platform orkestrasi kontainer Kube. Arsitektur ini mendukung menjalankan beban kerja Windows dan Linux virtual.

Arsitektur AKS dibangun dengan pengklusteran failover dan migrasi langsung yang secara otomatis diaktifkan untuk kluster target (beban kerja). Selama berbagai peristiwa gangguan, mesin virtual yang menjadi tuan rumah beban kerja pelanggan akan bebas bergerak tanpa waktu henti aplikasi. Arsitektur ini berarti bahwa pelanggan perusahaan tradisional, yang mengelola aplikasi warisan sebagai singleton untuk AKS di Azure Stack HCI atau Windows Server, mendapatkan waktu aktif yang serupa (atau lebih baik) daripada yang saat ini dialami pada aplikasi VM warisan.

Artikel ini menjelaskan beberapa konsep mendasar untuk pengguna yang ingin menjalankan aplikasi kontainer di AKS Arc dengan migrasi langsung diaktifkan untuk memastikan aplikasi tersedia selama gangguan. Terminologi Kubernetes, seperti gangguan sukarela dan gangguan tak disengaja, digunakan untuk merujuk pada waktu henti aplikasi yang berjalan dalam pod.

Apa itu migrasi langsung?

Migrasi langsung adalah fitur Hyper-V yang memungkinkan Anda memindahkan mesin virtual secara transparan dari satu host Hyper-V ke host lain tanpa waktu henti yang dirasakan. Manfaat utama migrasi langsung adalah fleksibilitas; komputer virtual yang berjalan tidak terikat dengan satu komputer host. Hal ini akan memungkinkan tindakan seperti menguras sejumlah mesin virtual tertentu sebelum menonaktifkan atau meningkatkan host. Ketika dipasangkan dengan Pengklusteran Failover Windows, migrasi langsung memungkinkan pembuatan sistem yang sangat tersedia dan toleran terhadap kesalahan.

Arsitektur AKS saat ini di Azure Stack HCI dan Windows Server mengasumsikan bahwa Anda mengaktifkan migrasi langsung di lingkungan terkluster Azure Stack HCI Anda. Oleh karena itu, semua VM simpul pekerja Kubernetes dibuat dengan migrasi langsung yang dikonfigurasi. Node ini dapat dipindahkan di sekitar host fisik jika terjadi gangguan untuk memastikan platform sangat tersedia.

Ketika Anda menjalankan aplikasi warisan sebagai singleton di atas Kubernetes, arsitektur ini memenuhi kebutuhan ketersediaan tinggi Anda. Kubernetes mengelola penjadwalan pod pada simpul pekerja yang tersedia saat migrasi langsung mengelola penjadwalan VM simpul pekerja pada host fisik yang tersedia.

Skenario gangguan aplikasi

Studi komparatif tentang waktu pemulihan untuk aplikasi yang berjalan di VM pada AKS di Azure Stack HCI dan Windows Server dengan jelas menunjukkan bahwa ada dampak minimal pada aplikasi ketika peristiwa gangguan umum terjadi. Tiga contoh skenario gangguan meliputi:

• Menerapkan pembaruan yang menghasilkan reboot mesin fisik.
• Menerapkan pembaruan yang melibatkan pembuatan ulang node pekerja.
• Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik.

Catatan

Skenario ini mengasumsikan bahwa pemilik aplikasi masih menggunakan pengaturan afinitas dan anti-afinitas Kubernetes untuk memastikan penjadwalan pod yang tepat di seluruh node pekerja.

Peristiwa gangguan	Menjalankan aplikasi di VM di Azure Stack HCI	Menjalankan aplikasi di VM di AKS di Azure Stack HCI atau Windows Server
Menerapkan pembaruan yang menghasilkan boot ulang komputer fisik	Tidak ada dampak	Tidak ada dampak
Menerapkan pembaruan yang melibatkan pembuatan ulang simpul pekerja (atau me-reboot VM)	Tidak ada dampak	Bervariasi
Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik	6-8 menit	6-8 menit

Menerapkan pembaruan yang menghasilkan boot ulang komputer fisik

Selama acara pemeliharaan host fisik, seperti menerapkan pembaruan yang menghasilkan reboot mesin host, tidak ada dampak yang diharapkan untuk aplikasi yang berjalan di kluster. Administrator kluster menguras host dan memastikan bahwa semua VM dimigrasikan secara langsung sebelum menerapkan pembaruan.

Menerapkan pembaruan yang melibatkan pembuatan ulang simpul pekerja

Skenario ini melibatkan menurunkan VM node pekerja untuk melakukan pemeliharaan rutin. Untuk mempersiapkan pembaruan, administrator kluster menguras dan mengisolasi simpul, sehingga semua pod dikeluarkan ke simpul pekerja yang tersedia sebelum menerapkan pembaruan. Setelah pembaruan selesai, simpul pekerja bergabung kembali dan tersedia untuk penjadwalan.

Catatan

Ketersediaan aplikasi bervariasi, karena mencakup waktu yang diperlukan untuk mengunduh gambar kontainer dasar, terutama untuk gambar yang lebih besar yang disimpan di cloud publik. Oleh karena itu, disarankan agar Anda menggunakan gambar kontainer dasar kecil, dan untuk kontainer Windows, disarankan agar Anda menggunakan nano server gambar dasar.

Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik

Dalam skenario ini, peristiwa gangguan tak disengaja terjadi pada mesin fisik yang menampung kontainer/pod aplikasi lama di salah satu VM node pekerja. Pengklusteran failover menempatkan host dalam keadaan terisolasi, dan kemudian setelah periode 6 hingga 8 menit, memulai proses migrasi langsung VM ini ke host yang bertahan. Dalam hal ini, waktu henti aplikasi setara dengan waktu yang diperlukan untuk memulai ulang VM node host dan pekerja.

Kesimpulan

Teknologi pengklusteran failover AKS dirancang untuk memastikan bahwa lingkungan komputasi di Azure Stack HCI dan Windows Server sangat tersedia dan toleran terhadap kesalahan. Namun, pemilik aplikasi masih harus mengkonfigurasi penyebaran untuk menggunakan fitur Kubernetes, seperti Deployments, Affinity Mapping, RelicaSets, untuk memastikan bahwa pod tangguh dalam skenario gangguan.

Langkah berikutnya

Gambaran umum AKS di Windows Server dan Azure Stack HCI