Memecahkan masalah pertarungan pengontrol

Halaman ini menunjukkan cara menyelesaikan masalah terkait pertarungan pengontrol. Pertarungan seperti itu menghabiskan banyak resource dan dapat menurunkan performa Anda. Pertarungan pengontrol juga disebut pertentangan resource.

Config Sync memantau objek yang diterapkan pada cluster dan mengembalikannya perubahan yang dibuat pada nilai yang dideklarasikan dalam sumber kebenaran. Jika perubahan ini dibuat oleh pengontrol lain, sumber daya mungkin beralih bolak-balik di antara kondisi yang diinginkan oleh {i>controller<i} yang bersaing. Salah satu gejala dari perilaku ini adalah kolom metadata.generation dan metadata.resourceVersion meningkat dengan cepat. Oleh karena itu, jika objek terkelola diperbarui lebih dari lima kali per menit, Config Sync mendeteksi pertarungan, mencatat penyimpangan, dan melaporkan error dalam status objek RootSync atau RepoSync.

Config Sync memiliki logika khusus untuk mendeteksi pertarungan antara beberapa RootSync dan RepoSync. Untuk objek RepoSync, jika rekonsiliasi melihat bahwa sudah dikelola oleh rekonsiliasi lain, pembaruan lebih lanjut akan dilewati. Untuk objek RootSync, rekonsiliasi akan mencoba mengadopsi objek apa pun yang dikonfigurasi untuk dikelola, kecuali jika dikelola oleh objek RootSync lain. Ini mencegah rekonsiliasi Config Sync berkelahi satu sama lain dan melaporkan error dalam status semua objek RootSync dan RepoSync yang terlibat.

Mengidentifikasi pertarungan pengontrol

Anda dapat meninjau error pertarungan dengan menggunakan Perintah nomos status atau dengan memeriksa kolom status di objek RootSync atau RepoSync.

Jika alat command line nomos belum terinstal, Anda dapat meninjau log untuk rekonsiliasi RootSync dengan menjalankan perintah berikut:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

Untuk memfilter rekonsiliasi RepoSync tertentu, jalankan perintah berikut:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
    --container reconciler

Ganti NAMESPACE dengan namespace yang Anda buat sumber tepercaya cakupan namespace Anda.

Jika Anda melihat KNV2005 dalam hasil tersebut, berarti terjadi pertarungan pengontrol.

Pesan {i>error<i} berikut adalah contoh jenis {i>error<i} yang mungkin Anda lihat log Anda:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Menyelidiki pertarungan pengontrol

Untuk mengetahui informasi selengkapnya tentang pertarungan pengontrol, tonton info terbaru file YAML resource dengan menjalankan perintah berikut:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

Ganti kode berikut:

  • RESOURCE: jenis resource yang yang diperebutkan.
  • OBJECT_NAME: nama objek yang sedang diperebutkan.
  • NAMESPACE: namespace tempat resource sedang memperebutkan selesai sudah masuk.

Hasil log menentukan resource, nama objek, dan namespace yang harus Anda tambahkan.

Perintah ini mengembalikan aliran status resource setelah pembaruan yang diterapkan ke server API. Gunakan alat perbandingan file untuk membandingkan {i>output<i} tersebut.

Selesaikan pertarungan pengontrol

Ada beberapa cara untuk menyelesaikan pertarungan pengontrol. Pilih opsi yang sesuai yang terbaik untuk penyiapan Config Sync Anda:

  • Perbarui manifes resource di sumber agar cocok dengan nilai yang yang diinginkan oleh pengontrol.
  • Hapus kolom yang dimaksud dari sumber agar yang lain {i>controller<i} untuk mengelolanya.
  • Nonaktifkan atau uninstal pengontrol lainnya.
  • Menghapus resource dari sumber dan mengelolanya secara manual atau dengan pengontrol khusus yang menoleransi perubahan atau pengelolaan bersama tertentu.
  • Jika Anda memiliki pengontrol yang menyebabkan pertentangan resource, dan kolom yang diubah tidak ada di sumber kebenaran, perbarui {i>controller<i} Anda untuk melakukan patching alih-alih mengupdate. Dengan begitu, perubahan itu akan diizinkan oleh Config Sync dan tidak dikembalikan.

Ada juga beberapa sumber daya yang harus dimiliki {i>controller<i} lain (misalnya, beberapa operator menginstal atau mempertahankan CRD). Pengontrol lain ini secara otomatis menghapus metadata khusus untuk Config Sync. Jika komponen lain di Kubernetes Anda menghapus metadata Config Sync, menghentikan pengelolaan resource dengan Config Sync. Sebagai informasi tentang cara melakukannya, lihat Berhenti mengelola objek terkelola.

Atau, jika Anda tidak ingin Config Sync mengembalikan perubahan pada setelan dalam cluster, Anda dapat menambahkan anotasi client.lifecycle.config.k8s.io/mutation: ignore ke objek yang Anda ingin Config Sync mengabaikan mutasi. Untuk informasi tentang cara melakukan ini, lihat Mengabaikan mutasi objek.

Langkah selanjutnya

  • Jika Anda masih mengalami masalah, periksa apakah adalah masalah umum.