Menetapkan cluster database ke node menggunakan penjadwalan

Pilih versi dokumentasi:

Di operator AlloyDB Omni Kubernetes, penjadwalan adalah proses untuk mencocokkan Pod database baru dengan node untuk menyeimbangkan distribusi node di seluruh cluster dan membantu mengoptimalkan performa. Pod dan node dicocokkan berdasarkan beberapa kriteria dan resource yang tersedia, seperti CPU dan memori.

Untuk mengetahui informasi selengkapnya tentang penjadwalan, lihat Penjadwalan, Penghentian Sementara, dan Pengusiran dalam dokumentasi Kubernetes.

Halaman ini menunjukkan cara menentukan konfigurasi penjadwalan toleransi, afinitas node, dan batasan penyebaran topologi untuk instance pool baca dan primer dalam manifes Kubernetes Anda.

Untuk mengetahui informasi tentang cara menentukan taint pada node, lihat Taint dan Toleransi dalam dokumentasi Kubernetes.

Menentukan toleransi

Untuk menjadwalkan Pod AlloyDB Omni ke node yang tidak memiliki Pod aplikasi lain atau mencocokkan taint tertentu yang ditentukan pada node tersebut, terapkan satu atau beberapa toleransi ke node sebagai berikut:

  1. Ubah manifes cluster operator Kubernetes AlloyDB Omni untuk menyertakan bagian tolerations di bagian schedulingConfig dari salah satu bagian berikut:
    • primarySpec untuk instance utama
    • spec untuk instance kumpulan baca
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Ganti kode berikut:

    • TAINT_KEY: Nama unik yang ada dari kunci taint seperti nama host node atau nilai lain yang disimpulkan secara lokal yang berlaku untuk toleransi. Kunci taint sudah ditentukan di node. Kolom kosong dan OPERATOR_VALUE yang ditetapkan ke exists menandakan bahwa toleransi harus cocok dengan semua nilai dan semua kunci.
    • OPERATOR_VALUE: Merepresentasikan hubungan kunci dengan sekumpulan nilai. Tetapkan parameter ke salah satu opsi berikut:
      • exists: Kubernetes mencocokkan nilai apa pun jika taint ditentukan terlepas dari nilai taint.
      • equal: Kubernetes tidak menjadwalkan Pod ke node jika nilainya berbeda. Operator memerlukan nilai taint true.
    • VALUE: Nilai taint yang cocok dengan toleransi. Jika operatornya adalah Ada, nilainya kosong, jika tidak, nilainya adalah string biasa. Contoh, true.
    • TAINT_EFFECT: Menunjukkan efek pencemaran yang akan dicocokkan. Kolom kosong menandakan bahwa semua efek pencemaran harus cocok. Tetapkan parameter ke salah satu opsi berikut:
      • NoSchedule: Kubernetes tidak menjadwalkan Pod baru di node yang terkena taint.
      • PreferNoSchedule: Kubernetes menghindari penempatan Pod baru di node yang terkena taint kecuali jika diperlukan.
      • NoExecute: Kubernetes mengeluarkan Pod yang ada yang tidak menoleransi taint.
  2. Terapkan kembali manifes.

Menentukan afinitas node

Penjadwal Kubernetes menggunakan afinitas node sebagai serangkaian aturan untuk menentukan tempat menempatkan Pod. Afinitas node adalah versi pemilih node yang lebih fleksibel dan ekspresif.

Untuk menentukan node mana yang harus dijadwalkan untuk menjalankan database Anda, ikuti langkah-langkah berikut:

  1. Ubah manifes cluster database untuk menyertakan bagian nodeaffinity setelah bagian tolerations di bagian schedulingConfig dari primarySpec untuk instance utama atau spec untuk instance kumpulan baca: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Ganti kode berikut:

    • NODE_AFFINITY_TYPE: Tetapkan parameter ke salah satu opsi berikut:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes menjadwalkan Pod berdasarkan aturan yang ditentukan.
      • preferredDuringSchedulingIgnoredDuringExecution: Penjadwal Kubernetes mencoba menemukan node yang memenuhi aturan yang ditentukan untuk penjadwalan. Namun, jika tidak ada node seperti itu, Kubernetes akan menjadwalkan ke node lain dalam cluster.
    • WAIT_VALUE: Menunjukkan bobot preferensi untuk node yang ditentukan. Nilai yang lebih tinggi menunjukkan preferensi yang lebih kuat. Nilai yang valid adalah dari 1 hingga 100.
    • LABEL_KEY: Label node untuk kunci yang berfungsi sebagai indikator lokasi dan memfasilitasi distribusi Pod yang merata di seluruh cluster. Contoh, disktype=ssd.
    • OPERATOR_VALUE: Merepresentasikan hubungan kunci dengan sekumpulan nilai. Tetapkan parameter ke salah satu opsi berikut:
      • In: Array nilai tidak boleh kosong.
      • NotIn: Array nilai tidak boleh kosong.
      • Exists: Array nilai harus kosong.
      • DoesNotExist: Array nilai harus kosong.
      • Gt: Array nilai harus memiliki satu elemen, yang ditafsirkan sebagai bilangan bulat.
      • Lt: Array nilai harus memiliki satu elemen, yang ditafsirkan sebagai bilangan bulat.
    • LABEL_KEY_VALUE: Nilai untuk kunci label Anda. Tetapkan parameter ke array nilai string sebagai berikut:
      • Jika operatornya adalah In atau NotIn, array nilai tidak boleh kosong.
      • Jika operatornya adalah Exists atau DoesNotExist, array nilai harus kosong.
      • Jika operatornya adalah Gt atau Lt, array nilai harus memiliki satu elemen, yang ditafsirkan sebagai bilangan bulat.
  2. Terapkan kembali manifes.

Menentukan batasan penyebaran topologi

Kolom topologySpreadConstraints, yang terletak di spec Kubernetes Pod API dan akibatnya di schedulingConfig manifes cluster database AlloyDB Omni, mengontrol cara Pod didistribusikan di berbagai domain topologi seperti zona, node, atau region di cluster Anda. Hal ini membantu meningkatkan ketersediaan tinggi dan pemanfaatan resource yang seimbang dengan mencegah terlalu banyak Pod cluster database AlloyDB Omni ditempatkan pada satu titik kegagalan.

Untuk menentukan cara penyebaran cluster database AlloyDB Omni di seluruh topologi cluster Anda, sertakan bagian topologySpreadConstraints di schedulingConfig dari primarySpec untuk instance utama atau spec untuk instance kumpulan baca:

schedulingconfig:
      # Other scheduling configs like tolerations, nodeaffinity
      topologySpreadConstraints:
        - maxSkew: MAXSKEW_VALUE
          topologyKey: "TOPOLOGY_KEY"
          whenUnsatisfiable: WHEN_UNSATISFIABLE_VALUE
          # labelSelector: <object> # optional
          # minDomains: <integer> # optional
          # matchLabelKeys: <list> # optional
          # nodeAffinityPolicy: [Honor|Ignore] # optional
          # nodeTaintsPolicy: [Honor|Ignore] # optional

Ganti kode berikut:

  • MAXSKEW_VALUE: menentukan perbedaan maksimum yang diizinkan dalam jumlah Pod yang cocok antara dua domain topologi. Parameter ini harus lebih besar dari 0.
  • TOPOLOGY_KEY: kunci label node yang menentukan domain topologi, misalnya, topology.kubernetes.io/zone untuk zona. Penjadwal mencoba menyeimbangkan Pod di seluruh domain ini.
  • WHEN_UNSATISFIABLE_VALUE: menunjukkan cara penjadwal menangani Pod jika Pod tidak memenuhi batasan penyebaran. Tetapkan parameter ke salah satu opsi berikut:
    • DoNotSchedule: penjadwal tidak menjadwalkan Pod ke node jika batasan penyebaran tidak terpenuhi. Ini adalah nilai defaultnya.
    • ScheduleAnyway: penjadwal tetap menjadwalkan Pod, tetapi memprioritaskan node yang meminimalkan kemiringan.

Untuk mengetahui informasi selengkapnya tentang batasan penyebaran topologi Pod, lihat dokumentasi Kubernetes resmi.

Contoh

Contoh berikut mengilustrasikan penjadwalan Pod di instance kumpulan baca dan primer operator AlloyDB Omni Kubernetes. Penyiapan penjadwalan tersebut membantu memastikan bahwa instance utama cluster database dijadwalkan di node yang sesuai sekaligus memungkinkan fleksibilitas dalam pemilihan node. Fleksibilitas ini dapat berguna untuk menyeimbangkan beban, mengoptimalkan penggunaan resource, atau mematuhi peran dan karakteristik node tertentu.

    schedulingconfig:
      tolerations:
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Exists"
        effect: "NoSchedule"
      nodeaffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
            - key: another-node-label-key
              operator: In
              values:
              - another-node-label-value
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

Toleransi contoh memungkinkan Pod dijadwalkan di node yang ditandai sebagai node bidang kontrol karena detail berikut:

  • Kunci taint node-role.kubernetes.io/control-plane menunjukkan bahwa node memiliki node bidang kontrol.
  • Operator Exists berarti bahwa toleransi cocok dengan taint apa pun dengan kunci taint yang ditentukan, terlepas dari nilainya.
  • Efek NoSchedule berarti Pod tidak akan dijadwalkan di node panel kontrol kecuali jika memiliki toleransi yang cocok.

Jenis afinitas node preferredDuringSchedulingIgnoredDuringExecution menentukan bahwa aturan yang ditentukan untuk afinitas node lebih disukai, tetapi tidak diperlukan selama penjadwalan. Jika node pilihan tidak tersedia, Pod mungkin masih dijadwalkan di node lain. Nilai bobot 1 menunjukkan preferensi yang lemah. Kriteria pemilihan node ditentukan di bagian preference. Bagian matchExpressions berisi array ekspresi yang digunakan untuk mencocokkan node. Kunci another-node-label-key mewakili kunci label node yang akan dicocokkan. Operator In berarti node harus memiliki kunci dengan salah satu nilai yang ditentukan. Kunci another-node-label-key harus memiliki nilai another-node-label-value.

Contoh aturan afinitas node menunjukkan preferensi untuk menjadwalkan Pod di node yang memiliki label another-node-label-key dengan nilai another-node-label-value. Preferensi ini lemah sehingga bukan persyaratan yang kuat.

topologySpreadConstraints dalam contoh ini mendistribusikan Pod di berbagai zona Kubernetes. Nilai maxSkew dari 1 menunjukkan bahwa paling banyak ada satu Pod lagi di zona tertentu dibandingkan dengan jumlah minimum Pod di zona lain. Setelan whenUnsatisfiable, dengan nilai DoNotSchedule, berarti jika batasan ini tidak dapat dipenuhi, Pod akan tetap tidak terjadwal.

Contoh ini menggabungkan hal berikut:

  • Toleransi yang memungkinkan Pod dijadwalkan di node bidang kontrol dengan menoleransi taint NoSchedule.
  • Afinitas node yang lebih memilih node dengan label tertentu, tetapi tidak secara ketat mewajibkannya; oleh karena itu, afinitas ini menawarkan fleksibilitas dalam penjadwalan.
  • Batasan penyebaran topologi yang menerapkan distribusi Pod yang seimbang di seluruh zona ketersediaan, sehingga meningkatkan ketahanan dan penggunaan resource yang lebih baik.

Langkah berikutnya