Menyiapkan domain topologi

Halaman ini memberikan ringkasan tentang domain topologi dan panduan untuk menyiapkannya.

Untuk menyiapkan domain topologi, Anda harus mengaktifkan cluster lanjutan. Perhatikan batasan berikut pada pratinjau cluster lanjutan:

  • Anda dapat mengaktifkan cluster lanjutan pada waktu pembuatan cluster hanya untuk cluster 1.31 baru.
  • Setelah cluster lanjutan diaktifkan, Anda tidak akan dapat mengupgrade cluster ke versi 1.32. Hanya aktifkan cluster lanjutan di lingkungan pengujian.

Halaman ini ditujukan bagi Admin dan arsitek yang menentukan solusi IT dan arsitektur sistem sesuai dengan strategi perusahaan, serta membuat dan mengelola kebijakan terkait izin pengguna. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE Enterprise umum.

Ringkasan

Domain topologi adalah sekelompok node cluster yang dianggap sebagai bagian dari pengelompokan logis atau fisik yang sama seperti kampus atau pusat data. Domain topologi harus sesuai dengan beberapa hardware atau software yang mendasarinya yang memiliki kemungkinan kegagalan yang berkorelasi. Contoh:

  • Kegagalan software seperti Server vCenter yang berbeda
  • Kegagalan hardware seperti rak yang berbeda, sumber daya yang berbeda, dan gedung yang berbeda

Di Google Distributed Cloud (khusus software) untuk VMware, sebagai bagian dari penyiapan domain topologi saat membuat cluster, Anda menentukan label topologi. Setelah pembuatan cluster, label topologi diisi ke label node di domain topologi.

Untuk menggunakan domain topologi selama pratinjau, Anda memiliki opsi berikut:

  • Gunakan batasan default tingkat cluster Kubernetes, "topology.kubernetes.io/zone", sebagai kunci dalam label topologi. Untuk mengetahui informasi selengkapnya, lihat Batasan default bawaan.

  • Konfigurasikan PodTemplate di Deployment, StatefulSet, atau ReplicaSet, seperti yang berlaku dengan kunci label topologi. Dalam spesifikasi Pod, Anda menggunakan kunci dalam label topologi sebagai nilai untuk kolom topologySpreadConstraints.topologyKey. Kunci ini memungkinkan penjadwal Kubernetes mendistribusikan Pod di seluruh domain topologi untuk memastikan ketersediaan tinggi dan mencegah kelebihan konsentrasi di satu area jika terjadi kegagalan. Untuk informasi selengkapnya tentang cara mengonfigurasi topologySpreadConstraints dalam spec Pod, lihat Batasan Penyebaran Topologi Pod dalam dokumentasi Kubernetes.

Contoh label domain topologi

Misalnya, Anda membuat tiga domain topologi berikut saat membuat cluster pengguna:

...
topologyDomains:
- name: "topology-domain-1"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-1"
...

...
topologyDomains:
- name: "topology-domain-2"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-2"
...

...
topologyDomains:
- name: "topology-domain-3"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-3"
...

Setelah cluster dibuat, Anda memperbarui spesifikasi Pod, misalnya:

...
topologySpreadConstraints:
  topologyKey: "topology.examplepetstore.com/zone"
...

Pada tingkat tinggi, penjadwal Kubernetes menggunakan topology.examplepetstore.com/zone untuk memisahkan node cluster ke dalam grup yang berbeda, zone-1, zone-2, dan zone-3. Kemudian, penjadwal menyebarkan Pod di tiga grup node ini.

Panduan untuk Penyiapan Domain Topologi

Untuk memastikan penggunaan semua resource cluster yang efektif oleh penjadwal Kubernetes, kami merekomendasikan panduan berikut:

  • Domain topologi harus seimbang. Anda harus menyediakan kapasitas CPU dan RAM dalam jumlah yang hampir sama di setiap domain topologi.
  • Berikan setidaknya dua dan sebaiknya tiga domain topologi.
  • Jangan sebarkan menurut lebih dari satu kunci topologi.
  • Node harus memiliki ukuran yang serupa di setiap domain topologi.
  • Jika Anda menggunakan taint dan toleransi untuk pemisahan beban kerja dalam cluster, setiap grup node harus memenuhi persyaratan sebelumnya.

Jika pedoman ini tidak terpenuhi, penjadwal akan tetap mencoba menggunakan kapasitas penuh cluster, tetapi mungkin perlu waktu lebih lama untuk menjadwalkan Pod, dan tidak semua Pod akan mendapatkan perilaku penyebaran yang diharapkan.

Langkah selanjutnya