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, Preemption, dan Eviction dalam dokumentasi Kubernetes.

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

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 bebas dari 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 AlloyDB Omni Kubernetes 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 diterapkan toleransi. Kunci taint sudah ditentukan pada node. Kolom kosong dan OPERATOR_VALUE yang ditetapkan ke exists menandakan bahwa toleransi harus cocok dengan semua nilai dan semua kunci.
    • OPERATOR_VALUE: Mewakili 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 Exists, nilainya kosong, jika tidak, nilainya adalah string reguler. Contohnya, true.
    • TAINT_EFFECT: Menunjukkan efek taint yang akan dicocokkan. Kolom kosong menandakan bahwa semua efek taint harus dicocokkan. 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 mentoleransi taint.
  2. Terapkan kembali manifes.

Menentukan afinitas node

Penjadwal Kubernetes menggunakan afinitas node sebagai sekumpulan 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, 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. Contohnya, disktype=ssd.
    • OPERATOR_VALUE: Mewakili 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 anti-afinitas pod

Anti-afinitas pod mencegah penjadwal Kubernetes menjadwalkan pod di node yang sama atau dalam domain topologi yang sama, seperti zona atau region. Hal ini memastikan bahwa replika layanan didistribusikan untuk menghindari satu titik kegagalan.

Untuk lingkungan produksi, sebaiknya gunakan aturan anti-afinitas ini untuk menjadwalkan pod database di node yang berbeda dari pod operator menggunakan label berikut:

schedulingconfig:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: alloydb-omni-operator
      namespaces:
      - alloydb-omni-system
      topologyKey: kubernetes.io/hostname

Untuk menambahkan aturan anti-afinitas pod ke database, ikuti langkah-langkah berikut:

  1. Ubah file manifes cluster database untuk menyertakan kolom podAntiAffinity. Anda harus menambahkan podAntiAffinity ke kolom schedulingConfig di kolom primarySpec untuk instance utama, atau di kolom spec untuk instance kumpulan baca.

    podAntiAffinity:
  POD_ANTI_AFFINITY_TYPE:
  - weight: WEIGHT_VALUE
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: LABEL_KEY
          operator: OPERATOR_VALUE
          values:
          - LABEL_VALUE
      topologyKey: "TOPOLOGY_KEY"

    Ganti variabel berikut:

    • POD_ANTI_AFFINITY_TYPE: gunakan salah satu nilai berikut:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes hanya menjadwalkan pod pada aturan yang ditentukan.
      • preferredDuringSchedulingIgnoredDuringExecution: penjadwal Kubernetes mencoba menemukan node yang memenuhi aturan yang ditentukan. Jika tidak ada node seperti itu, Kubernetes akan menjadwalkan pod ke node lain dalam cluster.
    • WEIGHT_VALUE: digunakan saat POD_ANTI_AFFINITY_TYPE ditetapkan ke preferredDuringSchedulingIgnoredDuringExecution. Menunjukkan seberapa kuat preferensi node yang ditentukan. Nilai berkisar dari 1 hingga 100.
    • LABEL_KEY: berfungsi sebagai indikator lokasi dan memfasilitasi distribusi pod yang merata di seluruh cluster.
    • OPERATOR_VALUE: operator yang digunakan untuk mencocokkan dengan pod yang ditentukan. Gunakan salah satu nilai berikut:
      • In: array values tidak boleh kosong.
      • NotIn: array values tidak boleh kosong.
      • Exists: array values harus kosong.
      • DoesNotExist: array values harus kosong.
    • LABEL_VALUE: nol, satu, atau beberapa nilai pod yang akan dicocokkan dengan LABEL_KEY.
    • TOPOLOGY_KEY: menentukan domain topologi. Misalnya, kubernetes.io/hostname untuk mencegah pod di node yang sama, atau topology.kubernetes.io/zone untuk menyebarkan pod di seluruh zona.

  2. Terapkan kembali file 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 penggunaan resource yang seimbang dengan mencegah terlalu banyak Pod cluster database AlloyDB Omni mendarat di satu titik kegagalan.

Untuk menentukan cara cluster database AlloyDB Omni Anda menyebar di seluruh topologi cluster, 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 masih menjadwalkan Pod, tetapi memprioritaskan node yang meminimalkan kemiringan.

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

Contoh

Contoh berikut mengilustrasikan penjadwalan Pod di instance utama dan kumpulan baca 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
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app
          topologyKey: "kubernetes.io/hostname"
      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 toleransi cocok dengan taint apa pun dengan kunci taint yang ditentukan, terlepas dari nilainya.
  • Efek NoSchedule berarti Pod tidak akan dijadwalkan di node bidang 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.

Aturan afinitas node contoh menunjukkan preferensi untuk menjadwalkan Pod di node yang memiliki label another-node-label-key dengan nilai another-node-label-value. Preferensinya lemah sehingga bukan persyaratan yang kuat.

Aturan podAntiAffinity dalam contoh ini mencegah pod dengan label app: my-app dijadwalkan di nama host yang sama. Hal ini memastikan bahwa replika my-app tersebar di berbagai node, sehingga meningkatkan toleransi fault.

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

Contoh ini menggabungkan hal berikut:

  • Toleransi yang memungkinkan Pod dijadwalkan di node panel kontrol dengan mentoleransi taint NoSchedule.
  • Afinitas node yang lebih memilih node dengan label tertentu, tetapi tidak secara ketat memerlukannya; oleh karena itu, afinitas node menawarkan fleksibilitas dalam penjadwalan.
  • Aturan anti-afinitas pod yang mencegah pod dengan label app: my-app dijadwalkan di nama host yang sama.
  • Batasan penyebaran topologi yang menerapkan distribusi Pod yang seimbang di seluruh zona ketersediaan, sehingga meningkatkan ketahanan dan meningkatkan penggunaan resource.

Langkah berikutnya