Penempatan sumber daya di Azure Operator Nexus Kubernetes
Instans Nexus operator disebarkan di tempat pelanggan. Setiap instans terdiri dari satu atau beberapa rak server bare metal.
Ketika pengguna membuat Kluster Kubernetes Nexus (NKS), mereka menentukan hitungan dan unit penyimpanan stok (SKU) untuk komputer virtual (VM) yang membentuk Sarana Kontrol Kubernetes dan satu atau beberapa Kumpulan Agen. Kumpulan Agen adalah sekumpulan Simpul Pekerja tempat fungsi jaringan kontainer pelanggan berjalan.
Platform Nexus bertanggung jawab untuk memutuskan server bare metal tempat setiap VM NKS diluncurkan.
Bagaimana platform Nexus menjadwalkan VM Kluster Nexus Kubernetes
Nexus pertama-tama mengidentifikasi kumpulan server bare metal potensial yang memenuhi semua persyaratan sumber daya SKU VM NKS. Misalnya, jika pengguna menentukan NC_G48_224_v1 SKU VM untuk kumpulan agen mereka, Nexus mengumpulkan server bare metal yang memiliki kapasitas yang tersedia untuk 48 vCPU, 224Gi RAM, dll.
Nexus kemudian memeriksa AvailabilityZones bidang untuk Kumpulan Agen atau Sarana Kontrol yang dijadwalkan. Jika bidang ini tidak kosong, Nexus memfilter daftar server bare metal potensial hanya ke server tersebut di zona ketersediaan (rak) yang ditentukan. Perilaku ini adalah batasan penjadwalan keras. Jika tidak ada server bare metal dalam daftar yang difilter, Nexus tidak menjadwalkan NKS VM dan kluster gagal disediakan.
Setelah Nexus mengidentifikasi daftar server bare metal potensial untuk menempatkan NKS VM, Nexus kemudian memilih salah satu server bare metal setelah menerapkan aturan pengurutan berikut:
Lebih suka server bare metal di zona ketersediaan (rak) yang tidak memiliki VM NKS dari Kluster NKS ini. Dengan kata lain, sebarkan VM NKS untuk Kluster NKS di seluruh zona ketersediaan.
Lebih suka server bare metal dalam satu zona ketersediaan (rak) yang tidak memiliki VM NKS lain dari Kluster NKS yang sama. Dengan kata lain, sebarkan VM NKS untuk Kluster NKS di seluruh server bare metal dalam zona ketersediaan.
Jika NKS VM SKU adalah
NC_G48_224_v1atauNC_P46_224_v1, lebih suka server bare metal yang sudah menampungNC_G48_224_v1atauNC_P46_224_v1NKS VM dari Kluster NKS lainnya. Dengan kata lain, kelompokkan VM ekstra besar dari Kluster NKS yang berbeda di server bare metal yang sama. Aturan ini "bin packs" VM ekstra besar untuk mengurangi fragmentasi sumber daya komputasi yang tersedia.
Contoh skenario penempatan
Bagian berikut menyoroti perilaku yang harus diharapkan pengguna Nexus saat membuat Kluster NKS terhadap lingkungan Operator Nexus.
Petunjuk: Anda dapat melihat server bare metal mana yang dijadwalkan oleh VM NKS Anda dengan memeriksa
nodes.bareMetalMachineIdproperti sumber daya NKS KubernetesCluster atau melihat kolom "Host" di tampilan Portal Microsoft Azure dari Node Kluster Kubernetes.
Contoh lingkungan Operator Nexus memiliki spesifikasi ini:
- Delapan rak dari 16 server bare metal
- Setiap server bare metal berisi dua sel Akses Memori Non-Seragam (NUMA)
- Setiap sel NUMA menyediakan 48 CPU dan RAM 224Gi
Lingkungan kosong
Mengingat lingkungan Operator Nexus kosong dengan kapasitas yang diberikan, kami membuat tiga Kluster Kubernetes Nexus berukuran berbeda.
Kluster NKS memiliki spesifikasi ini, dan kami berasumsi untuk tujuan latihan ini bahwa pengguna membuat tiga Kluster dalam urutan berikut:
Kluster A
- Sarana kontrol,
NC_G12_56_v1SKU, tiga hitungan - Kumpulan agen #1,
NC_P46_224_v1SKU, 24 hitungan - Kumpulan agen #2,
NC_G6_28_v1SKU, enam hitungan
Kluster B
- Sarana kontrol,
NC_G24_112_v1SKU, lima hitungan - Kumpulan agen #1,
NC_P46_224_v1SKU, 48 jumlah - Kumpulan agen #2,
NC_P22_112_v1SKU, 24 hitungan
Kluster C
- Sarana kontrol,
NC_G12_56_v1SKU, tiga hitungan - Kumpulan agen #1,
NC_P46_224_v1SKU, 12 hitungan,AvailabilityZones = [1,4]
Berikut adalah tabel yang meringkas apa yang akan dilihat pengguna setelah meluncurkan Kluster A, B, dan C pada lingkungan Nexus Operator kosong.
| Kluster | Kumpulan | SKU | Jumlah Total | Diharapkan # Rak | Aktual # Rak | Diharapkan # VM per Rak | Aktual # VM per Rak |
|---|---|---|---|---|---|---|---|
| A | Sarana kontrol | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | Kumpulan Agen #1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | Kumpulan Agen #2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | Sarana kontrol | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | Kumpulan Agen #1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | Kumpulan Agen #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | Sarana kontrol | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | Kumpulan Agen #1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Ada delapan rak sehingga VM untuk setiap kumpulan tersebar hingga delapan rak. Kumpulan dengan lebih dari delapan VM memerlukan beberapa VM per rak yang tersebar di berbagai server bare metal.
Cluster C Agent Pool #1 memiliki 12 VM yang dibatasi untuk AvailabilityZones [1, 4] sehingga memiliki 12 VM pada 12 server bare metal, enam di masing-masing rak 1 dan 4.
VM ekstra besar ( NC_P46_224_v1 SKU) dari kluster yang berbeda ditempatkan pada server bare metal yang sama (lihat aturan #3 di Bagaimana platform Nexus menjadwalkan VM Kluster Nexus Kubernetes).
Berikut adalah visualisasi tata letak yang mungkin dilihat pengguna setelah menyebarkan Kluster A, B, dan C ke lingkungan kosong.
Lingkungan setengah penuh
Kita sekarang menjalankan melalui contoh meluncurkan Kluster NKS lain ketika lingkungan target setengah penuh. Lingkungan target setengah penuh setelah Kluster A, B, dan C disebarkan ke lingkungan target.
Kluster D memiliki spesifikasi berikut:
- Sarana kontrol,
NC_G24_112_v1SKU, lima hitungan - Kumpulan agen #1,
NC_P46_224_v1SKU, 24 hitungan,AvailabilityZones = [7,8] - Kumpulan agen #2,
NC_P22_112_v1SKU, 24 hitungan
Berikut adalah tabel yang meringkas apa yang harus dilihat pengguna setelah meluncurkan Kluster D ke lingkungan Operator Nexus setengah penuh yang ada setelah meluncurkan Kluster A, B, dan C.
| Kluster | Kumpulan | SKU | Jumlah Total | Diharapkan # Rak | Aktual # Rak | Diharapkan # VM per Rak | Aktual # VM per Rak |
|---|---|---|---|---|---|---|---|
| D | Sarana kontrol | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Kumpulan Agen #1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Kumpulan Agen #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
Kumpulan Agen Kluster D #1 memiliki 12 VM yang dibatasi untuk AvailabilityZones [7, 8] sehingga memiliki 12 VM pada 12 server bare metal, enam di masing-masing rak 7 dan 8. VM tersebut mendarat di server bare metal juga menampung VM ekstra besar dari kluster lain karena aturan pengurutan yang mengelompokkan VM ekstra-besar dari kluster yang berbeda ke server bare metal yang sama.
Jika VM sarana kontrol Cluster D mendarat di rak 7 atau 8, kemungkinan satu Cluster D Agent Pool #1 VM mendarat di server bare metal yang sama dengan VM sarana kontrol Cluster D tersebut. Perilaku ini disebabkan oleh Kumpulan Agen #1 yang "disematkan" ke rak 7 dan 8. Batasan kapasitas di rak tersebut menyebabkan penjadwal mengalokasikan VM sarana kontrol dan Kumpulan Agen #1 VM dari Kluster NKS yang sama.
Kumpulan Agen Kluster D #2 memiliki tiga VM pada server bare metal yang berbeda di masing-masing dari delapan rak. Batasan kapasitas yang dihasilkan dari Kumpulan Agen Kluster D #1 disematkan ke rak 7 dan 8. Oleh karena itu, VM dari Cluster D's Agent Pool #1 dan Agent Pool #2 terletak di server bare metal yang sama di rak 7 dan 8.
Berikut adalah visualisasi tata letak yang mungkin dilihat pengguna setelah menyebarkan Kluster D ke lingkungan target.
Lingkungan hampir penuh
Dalam contoh lingkungan target kami, empat dari delapan rak mendekati kapasitas. Mari kita coba meluncurkan Kluster NKS lain.
Kluster E memiliki spesifikasi berikut:
- Sarana kontrol,
NC_G24_112_v1SKU, lima hitungan - Kumpulan agen #1,
NC_P46_224_v1SKU, 32 jumlah
Berikut adalah tabel yang meringkas apa yang akan dilihat pengguna setelah meluncurkan Kluster E ke lingkungan target.
| Kluster | Kumpulan | SKU | Jumlah Total | Diharapkan # Rak | Aktual # Rak | Diharapkan # VM per Rak | Aktual # VM per Rak |
|---|---|---|---|---|---|---|---|
| E | Sarana kontrol | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Kumpulan Agen #1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 atau 5 |
Kumpulan Agen Kluster E #1 akan menyebar secara tidak merata di semua delapan rak. Rak 7 dan 8 akan memiliki tiga VM NKS dari Kumpulan Agen #1 alih-alih empat VM NKS yang diharapkan karena tidak ada lagi kapasitas untuk VM SKU ekstra besar di rak tersebut setelah menjadwalkan Kluster A hingga D. Karena rak 7 dan 8 tidak memiliki kapasitas untuk SKU ekstra besar keempat di Agent Pool #1, lima VM NKS akan mendarat di dua rak yang paling sedikit digunakan. Dalam contoh kami, rak yang paling sedikit digunakan adalah rak 3 dan 6.
Berikut adalah visualisasi tata letak yang mungkin dilihat pengguna setelah menyebarkan Kluster E ke lingkungan target.
Penempatan selama peningkatan runtime
Mulai April 2024 (rilis Network Cloud 2304.1), peningkatan runtime dilakukan menggunakan strategi rak demi rak. Server bare metal di rak 1 digambarkan ulang sekaligus. Proses peningkatan dijeda hingga semua server bare metal berhasil memulai ulang dan memberi tahu Nexus bahwa mereka siap untuk menerima beban kerja.
Catatan
Dimungkinkan untuk menginstruksikan Operator Nexus untuk hanya menargetkan kembali sebagian server bare metal dalam rak sekaligus, namun defaultnya adalah menggambar ulang semua server bare metal dalam rak secara paralel.
Ketika server bare metal individu digambarkan ulang, semua beban kerja yang berjalan di server bare metal tersebut, termasuk semua VM NKS, kehilangan daya, dan konektivitas. Kontainer beban kerja yang berjalan pada NKS VM akan, pada gilirannya, kehilangan daya, dan konektivitas. Setelah satu menit tidak dapat mencapai kontainer beban kerja tersebut, Kubernetes Control Plane kluster NKS akan menandai Pod yang sesuai sebagai tidak sehat. Jika Pod adalah anggota Deployment atau StatefulSet, Kubernetes Control Plane kluster NKS mencoba meluncurkan Pod pengganti untuk membawa jumlah replika yang diamati dari Deployment atau StatefulSet kembali ke jumlah replika yang diinginkan.
Pod baru hanya diluncurkan jika ada kapasitas yang tersedia untuk Pod di NKS VM yang masih sehat. Pada April 2024 (rilis Network Cloud 2304.1), VM NKS baru tidak dibuat untuk menggantikan VM NKS yang berada di server bare metal yang dicitrakan ulang.
Setelah server bare metal berhasil dicitrakan ulang dan dapat menerima VM NKS baru, VM NKS yang awalnya berada di server bare metal yang sama di server bare metal yang baru dicitrakan kembali. Kontainer beban kerja kemudian dapat dijadwalkan ke VM NKS tersebut, berpotensi memulihkan Deployments atau StatefulSets yang memiliki Pod pada VM NKS yang berada di server bare metal.
Catatan
Perilaku ini mungkin tampak bagi pengguna seolah-olah VM NKS tidak "berpindah" dari server bare metal, padahal sebenarnya instans baru VM NKS yang identik diluncurkan pada server bare metal yang baru dicitrakan ulang yang mempertahankan nama server bare metal yang sama seperti sebelum dicitrakan ulang.
Praktik terbaik
Saat bekerja dengan Operator Nexus, ingatlah praktik terbaik berikut.
- Hindari menentukan
AvailabilityZonesuntuk Kumpulan Agen. - Luncurkan Kluster NKS yang lebih besar sebelum kluster yang lebih kecil.
- Kurangi Jumlah Kumpulan Agen sebelum mengurangi ukuran SKU VM.
Hindari menentukan AvailabilityZones untuk Kumpulan Agen
Seperti yang Anda tahu dari skenario penempatan di atas, menentukan AvailabilityZones untuk Kumpulan Agen adalah alasan utama bahwa VM NKS dari Kluster NKS yang sama akan berakhir di server bare metal yang sama. Dengan menentukan , Anda "menyematkan AvailabilityZones" Kumpulan Agen ke subset rak dan oleh karena itu membatasi jumlah server bare metal potensial di set rak tersebut untuk Kluster NKS lainnya dan VM Kumpulan Agen lainnya di Kluster NKS yang sama untuk mendarat.
Oleh karena itu, praktik terbaik pertama kami adalah menghindari menentukan AvailabilityZones untuk Kumpulan Agen. Jika Anda memerlukan penyematan Kumpulan Agen ke sekumpulan Zona Ketersediaan, buat yang diatur sebesar mungkin untuk meminimalkan ketidakseimbangan yang dapat terjadi.
Satu pengecualian untuk praktik terbaik ini adalah ketika Anda memiliki skenario dengan hanya dua atau tiga VM di kumpulan agen. Anda mungkin mempertimbangkan pengaturan AvailabilityZones untuk kumpulan agen tersebut ke [1,3,5,7] atau [0,2,4,6] untuk meningkatkan ketersediaan selama peningkatan runtime.
Luncurkan Kluster NKS yang lebih besar sebelum kluster yang lebih kecil
Mulai April 2024, dan rilis Network Cloud 2403.1, Kluster NKS dijadwalkan dalam urutan pembuatannya. Untuk mengemas lingkungan target Anda secara paling efisien, kami sarankan Anda membuat Kluster NKS yang lebih besar sebelum yang lebih kecil. Demikian juga, kami sarankan Anda menjadwalkan Kumpulan Agen yang lebih besar sebelum yang lebih kecil.
Rekomendasi ini penting untuk Kumpulan Agen menggunakan SKU atau NC_P46_224_v1 ekstra besarNC_G48_224_v1. Menjadwalkan Kumpulan Agen dengan jumlah terbesar dari VM SKU ekstra besar ini menciptakan serangkaian server bare metal yang lebih besar di mana VM SKU ekstra besar lainnya dari Kumpulan Agen di Kluster NKS lainnya dapat dikolokasikan.
Kurangi jumlah Kumpulan Agen sebelum mengurangi ukuran SKU VM
Jika Anda mengalami batasan kapasitas saat meluncurkan Kluster NKS atau Kumpulan Agen, kurangi Jumlah Kumpulan Agen sebelum menyesuaikan ukuran SKU VM. Misalnya, jika Anda mencoba membuat Kluster NKS dengan Kumpulan Agen dengan ukuran NC_P46_224_v1 SKU VM dan Hitungan 24 dan mendapatkan kembali kegagalan untuk menyediakan Kluster NKS karena sumber daya yang tidak mencukup, Anda mungkin tergoda untuk menggunakan Ukuran NC_P36_168_v1 SKU VM dan melanjutkan dengan Hitungan 24. Namun, karena persyaratan untuk VM beban kerja diselaraskan ke sel NUMA tunggal pada server bare metal, kemungkinan permintaan yang sama mengalihkan kegagalan sumber daya yang sama yang tidak mencukupi. Alih-alih mengurangi ukuran SKU VM, pertimbangkan untuk mengurangi Jumlah Kumpulan Agen menjadi 20. Ada kemungkinan yang lebih baik permintaan Anda sesuai dengan kapasitas sumber daya lingkungan target dan penyebaran Keseluruhan Anda memiliki lebih banyak inti CPU daripada jika Anda menurunkan ukuran SKU VM.
SKU VM yang dioptimalkan memori
NC_E94_448_v1 mengonsumsi semua sumber daya komputer fisik yang tersedia untuk pelanggan. NC_E70_336_v1 mengonsumsi 75% sumber daya yang tersedia untuk pelanggan, namun, tidak dinyatakan bahwa ini akan persis satu-penuh dan satu setengah sel NUMA. Ini berarti bahwa NC_G24_112_v1 mungkin atau mungkin tidak dapat menjadwalkan pada komputer yang menjalankan NC_E70_336_v1 tergantung pada bagaimana VM NC_E70_336_v1 dijadwalkan di seluruh sel NUMA.