Pilih tipe instans ECS untuk node worker dan master ACK berdasarkan beban kerja, toleransi kesalahan, dan skala kluster.
Tipe instans yang tidak didukung oleh ACK
Tipe instans berikut tidak dapat digunakan sebagai node worker atau master ACK.
Batasan umum
| Keluarga instans yang tidak didukung | Contoh | Alasan |
|---|---|---|
| t5, burstable | ecs.t5-lc2m1.nano | Kinerja tidak stabil dapat menyebabkan ketidakstabilan kluster |
| t6, burstable | ecs.t6-c4m1.large | Kinerja tidak stabil dapat menyebabkan ketidakstabilan kluster |
| Tipe instans dengan kurang dari 4 core vCPU | ecs.g6.large | Spesifikasi terlalu rendah untuk operasi kluster yang stabil |
| c6t, komputasi-teroptimalkan yang ditingkatkan keamanannya | ecs.c6t.large | Tidak didukung |
| g6t, tujuan umum yang ditingkatkan keamanannya | ecs.g6t.large | Tidak didukung |
| Super Computing Cluster (SCC) | ecs.sccg7.32xlarge | Tidak didukung |
Untuk menggunakan tipe instans dengan spesifikasi rendah, ajukan permintaan di Quota Center.
Untuk beban kerja GPU, lihat Keluarga instans GPU-accelerated yang didukung oleh ACK.
Batasan plugin jaringan Terway
Dengan Terway, kapasitas Pod per node bergantung pada jumlah elastic network interfaces (ENIs) yang didukung oleh tipe instans tersebut. Tipe instans di bawah ambang batas minimum Pod tidak kompatibel.
-
Mode ENI inklusif atau Shared ENI + Trunk ENI mode: Batas Pod per node harus melebihi 11. Rumus:
(Jumlah ENI - 1) × Jumlah IP privat per ENI > 11. Contoh: ecs.g6.large mendukung 2 ENI dengan masing-masing 6 alamat IPv4 privat. Batas Pod =(2 - 1) × 6 = 6. Tipe ini tidak kompatibel. -
Exclusive ENI mode: Batas Pod per node harus melebihi 6. Rumus:
Jumlah ENI - 1 > 6. Contoh: ecs.g6.xlarge mendukung 3 ENI. Batas Pod =3 - 1 = 2. Tipe ini tidak kompatibel.
Untuk tipe instans yang kompatibel berdasarkan mode Terway, lihat Gunakan plugin jaringan Terway.
Mengapa lebih sedikit instans berukuran besar memberikan kinerja lebih baik
Setiap node menyisihkan CPU, memori, dan disk untuk manajemen kluster. Pada instans kecil, alokasi ini mengonsumsi bagian yang lebih besar dari total kapasitas, sehingga menyisakan ruang lebih sedikit untuk beban kerja.
Fragmentasi memperparah kondisi ini: setelah mengalokasikan sumber daya ke sebuah kontainer, sisa kapasitas pada instans kecil mungkin terlalu kecil untuk menampung kontainer lain dan menjadi menganggur.
Instans besar mengatasi kedua masalah tersebut:
-
Efisiensi jaringan lebih baik: Lebih banyak kontainer berbagi satu instans, mengurangi lalu lintas lintas-node. Instans besar juga menyediakan lebar pita jaringan yang lebih tinggi.
-
Penarikan gambar lebih cepat: Gambar kontainer hanya ditarik sekali per node dan dibagikan ke seluruh kontainer. Dengan banyak instans kecil, gambar yang sama ditarik di setiap instans, sehingga memperlambat proses scale-out.
Pilih spesifikasi node worker
Spesifikasi minimum
Gunakan tipe instans dengan minimal 4 core CPU dan memori 8 GB.
Penentuan ukuran untuk toleransi kesalahan
Hitung total core CPU yang dibutuhkan untuk beban kerja harian Anda, lalu tentukan ukuran node agar mampu menyerap kegagalan instans tanpa gangguan layanan.
Contoh:
| Target toleransi kesalahan | Jumlah node | Ukuran node | Beban operasi maksimum |
|---|---|---|---|
| 10% (satu node dapat gagal) | minimal 10 | 16 core CPU | 144 core (160 × 90%) |
| 20% (satu node dapat gagal) | minimal 5 | 32 core CPU | 128 core (160 × 80%) |
Jika satu instans gagal, instans yang tersisa tetap dapat menangani beban puncak.
Rasio CPU-memori
Pilih rasio yang sesuai dengan jenis beban kerja Anda:
-
1:2 atau 1:4: Beban kerja tujuan umum
-
1:8: Aplikasi intensif memori seperti layanan Java
Beban kerja GPU
Untuk penjadwalan yang stabil, jangan mencampur tipe instans GPU dan non-GPU dalam kelompok node yang sama.
Instans optimasi memori persisten
Keluarga instans seperti re6p menggunakan arsitektur hibrid yang menggabungkan memori reguler dan memori persisten. Untuk mengaktifkan penyimpanan persisten, lihat Volume memori non-volatile. Lihat Keluarga instans untuk tipe yang didukung.
Kluster berskala besar: ECS Bare Metal Instance
Pada skala harian sekitar 1.000 core CPU, gunakan ECS Bare Metal Instance. Satu instans menyediakan minimal 96 core CPU, sehingga kluster 1.000 core hanya memerlukan 10–11 node. Lihat ECS Bare Metal Instance.
Pilih spesifikasi node master
Node master menjalankan etcd, kube-apiserver, dan kube-controller. Pada kluster produksi khusus ACK, sesuaikan ukuran node master dengan skala kluster.
Ukuran kluster di sini diukur berdasarkan jumlah node. Dalam praktiknya, jumlah Pod, frekuensi penerapan, atau volume permintaan juga merupakan metrik penentuan ukuran yang valid.
Gunakan instans kecil hanya untuk pengujian. Untuk kluster produksi, pilih spesifikasi node master dari tabel berikut.
| Jumlah node | Spesifikasi node master yang direkomendasikan |
|---|---|
| 1–5 | 4 core CPU, memori 8 GB (2 core/4 GB atau lebih rendah tidak direkomendasikan) |
| 6–20 | 4 core CPU, memori 16 GB |
| 21–100 | 8 core CPU, memori 32 GB |
| 100–200 | 16 core CPU, memori 64 GB |
| 200–500 (evaluasi risiko blast radius) | 64 core CPU, memori 128 GB |
ECS Bare Metal Instances
Dibangun di atas virtualisasi 2.0 Alibaba Cloud, ECS Bare Metal Instance menggabungkan elastisitas VM dengan kinerja server fisik dan mendukung virtualisasi bersarang.
ECS Bare Metal Instance cocok untuk komputasi khusus, komputasi terenkripsi, dan penyebaran cloud hibrid. Lihat Ikhtisar ECS Bare Metal Instance untuk keluarga instans yang didukung.
Kapan menggunakan ECS Bare Metal Instance:
-
Skala kluster besar: Pada skala harian sekitar 1.000 core CPU, setiap instans menyediakan minimal 96 core, sehingga hanya memerlukan 10–11 node.
-
Lonjakan traffic yang memerlukan scale-out cepat: ECS Bare Metal Instance mengungguli server fisik dengan spesifikasi setara dan dapat diskalakan hingga jutaan vCPU untuk lonjakan traffic mendadak, seperti promosi e-commerce.