Mendeklarasikan dependensi antar-objek resource

Panduan ini menjelaskan cara kerja dependensi di Config Sync dan cara menentukan dependensi Anda sendiri.

Config Sync otomatis mendeteksi dependensi implisit antar-objek tertentu saat menyinkronkannya ke cluster. Misalnya, objek Namespace selalu diterapkan sebelum di Namespace tersebut, dan objek CustomResourceDefinition (CRD) selalu diterapkan sebelum resource kustom jenis ini diterapkan. Demikian juga, pengurutan penghapusan terbalik untuk dependensi implisit ini: Namespace dihapus setelah objek di namespace tersebut, dan CRD akan dihapus setelah Resource Kustom jenis tersebut.

Anda juga dapat menyetel dependensi eksplisit menggunakan anotasi depends-on. Misalnya, Anda mungkin ingin MySQL StatefulSet dimulai sebelum Deployment Wordpress, sehingga database Anda diterapkan dan siap sebelum Wordpress dimulai.

Persyaratan

  • RootSync API dan RepoSync harus diaktifkan. Jika Anda menginstal Config Sync secara manual menggunakan kubectl, dan tidak memiliki RootSync dan RepoSync API aktif, Anda harus memigrasikan objek ConfigManagement.

  • Batasan: Dependensi harus berada dalam sumber kebenaran yang sama dengan tanggungan mereka. Dependensi harus dikelola oleh RootSync atau RepoSync yang sama sebagai dependensinya, yang memastikan semua resource {i>ResourceGroup<i}.

Terapkan grup

Saat menyinkronkan resource ke cluster, Config Sync membagi resource yang memiliki dependensi langsung atau tidak langsung ke dalam grup penerapan yang berbeda. Satu grup berlaku hanya terdiri dari resource tanpa ketergantungan langsung atau tidak langsung terhadap satu sama lain. Grup penerapan tempat resource tidak memiliki dependensi akan diterapkan terlebih dahulu.

Aktuasi dan rekonsiliasi

Ketika objek digerakkan (baik diterapkan maupun dipangkas), objek itu butuh waktu beberapa saat untuk direkonsiliasi oleh {i>controller<i}-nya. Misalnya, saat Deployment diterapkan, Pod yang mendasarinya mungkin tidak akan segera siap. Setelah Pod yang mendasarinya sudah siap, Deployment direkonsiliasi. Untuk berbagai jenis objek, Config Sync memeriksa berbagai jenis kondisi untuk diverifikasi jika suatu objek direkonsiliasi. Detail selengkapnya dapat ditemukan di sigs.k8s.io/cli-utils

Dengan anotasi depends-on, Config Sync tidak hanya menerapkan objek dalam yang Anda inginkan, hal itu juga akan memverifikasi bahwa objek dependensi direkonsiliasi sebelum menerapkan objek dependen.

Jika objek dependensi tidak merekonsiliasi dalam waktu tunggu rekonsiliasi default 5 menit, Config Sync tidak akan menerapkan objek dependen hingga periode sinkronisasi berikutnya. Anda dapat mengganti waktu tunggu rekonsiliasi default dengan menetapkan spec.override.reconcileTimeout.

Menambahkan anotasi depends-on ke objek

Untuk menentukan dependensi, tambahkan anotasi config.kubernetes.io/depends-on pada objek dependen dengan nilai yang mereferensikan dependensi.

Untuk contoh Wordpress, anotasi di Wordpress Deployment terlihat seperti berikut:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  namespace: default
  labels:
    app: wordpress
  annotations:
    config.kubernetes.io/depends-on: apps/namespaces/default/StatefulSet/wordpress-mysql

Ketika Config Sync menerapkan objek, pertama-tama dependensi akan diterapkan, objek wordpress-mysql StatefulSet. Ketika dependensi direkonsiliasi, Config Sync menerapkan aturan Deployment wordpress.

Referensi objek

Referensi objek menggunakan sintaksis berikut:

  • Untuk objek dengan namespace:

    GROUP/namespaces/NAMESPACE/KIND/NAME
    
  • Untuk objek cakupan cluster:

    GROUP/KIND/NAME
    

    Ganti kode berikut:

    • GROUP: Grup objek dependensi.
    • NAMESPACE: Namespace ruang nama yang dicakup dependensi.
    • KIND: Jenis objek dependensi. Kolom ini peka huruf besar/kecil. Misalnya, gunakan "Pod" bukan "pod".
    • NAME: Nama objek dependensi.

Untuk objek dalam kelompok inti, yang digunakan adalah string kosong, misalnya /namespaces/test/Pod/pod-a.

Gunakan , untuk memisahkan beberapa referensi objek, misalnya /namespaces/test/Pod/pod-a,/namespaces/test/Pod/pod-b.