Mendeklarasikan dependensi antar-objek resource

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

Config Sync secara otomatis mendeteksi dependensi implisit antara objek tertentu saat menyinkronkannya ke cluster. Misalnya, objek Namespace selalu diterapkan sebelum objek apa pun di Namespace tersebut, dan objek CustomResourceDefinition (CRD) selalu diterapkan sebelum resource kustom jenis ini diterapkan. Demikian pula, urutan penghapusan dibalik untuk dependensi implisit ini: Namespace dihapus setelah objek di namespace tersebut, dan CRD dihapus setelah Resource Kustom dari jenis tersebut.

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

Persyaratan

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

• Batasan: Dependensi harus berada di sumber tepercaya yang sama dengan dependensinya. Dependensi harus dikelola oleh objek RootSync atau RepoSync yang sama dengan dependensinya, yang memastikan semua resource berada dalam ResourceGroup yang sama.

Menerapkan 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 penerapan hanya terdiri dari resource tanpa dependensi langsung atau tidak langsung satu sama lain. Grup penerapan tempat resource tidak memiliki dependensi apa pun akan diterapkan terlebih dahulu.

Pengaktifan dan rekonsiliasi

Saat objek diaktifkan (diterapkan atau dipangkas), objek tersebut mungkin memerlukan waktu beberapa saat untuk disesuaikan oleh pengontrolnya. Misalnya, saat Deployment diterapkan, Pod yang mendasarinya mungkin tidak langsung siap. Setelah Pod yang mendasarinya sudah siap, Deployment akan direkonsiliasi. Untuk berbagai jenis objek, Config Sync memeriksa berbagai jenis kondisi untuk memverifikasi apakah objek telah direkonsiliasi. Detail selengkapnya dapat ditemukan di sigs.k8s.io/cli-utils

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

Jika objek dependensi tidak direkonsiliasi dalam waktu tunggu rekonsiliasi default 5 menit, Config Sync tidak akan menerapkan objek dependensi 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 objek dependensi.

Untuk contoh WordPress, anotasi dalam Deployment WordPress menyerupai hal 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

Saat menerapkan objek, Config Sync akan menerapkan dependensi terlebih dahulu, yaitu StatefulSet wordpress-mysql objek. Setelah dependensi direkonsiliasi, Config Sync akan menerapkan Deployment wordpress dependen.

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 objek dependensi cakupan namespace.
  • KIND: Jenis objek dependensi. Kolom ini peka huruf besar/kecil. Misalnya, gunakan "Pod", bukan "pod".
  • NAME: Nama objek dependensi.

Untuk objek dalam grup inti, string kosong akan digunakan, misalnya /namespaces/test/Pod/pod-a.

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