Memecahkan masalah pertarungan pengontrol

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

Config Sync mengamati objek yang diterapkannya di cluster dan mengembalikan perubahan yang dibuat pada nilai yang dideklarasikan dalam sumber tepercaya. Jika perubahan ini dibuat oleh pengontrol lain, resource dapat beralih bolak-balik di antara status yang diinginkan oleh pengontrol yang bersaing. Salah satu gejala 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 akan mendeteksi lawan tersebut, mencatat penyimpangan, dan melaporkan error dalam status objek RootSync atau RepoSync.

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

Mengidentifikasi pertarungan pengontrol

Jika menggunakan Config Sync versi 1.15.0 atau yang lebih baru, Anda dapat meninjau error penanganan menggunakan perintah nomos status atau dengan memeriksa kolom status di objek RootSync atau RepoSync.

Jika belum menginstal alat command line nomos, Anda dapat meninjau log untuk rekonsiler 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 rekonsiler 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 tempat Anda membuat sumber kebenaran cakupan namespace.

Jika Anda melihat KNV2005 dalam hasil, berarti ada pertarungan pengontrol.

Pesan error berikut adalah contoh jenis error yang mungkin Anda lihat di log:

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

Selidiki pertarungan pengontrol

Untuk mengetahui informasi lebih lanjut tentang pertarungan pengontrol apa pun, perhatikan update pada file YAML resource dengan menjalankan perintah berikut:

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

Ganti kode berikut:

  • RESOURCE: jenis resource yang sedang diperebutkan.
  • OBJECT_NAME: nama objek yang sedang diperjuangkan.
  • NAMESPACE: namespace tempat resource yang sedang diperebutkan berada.

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

Perintah ini menampilkan aliran status resource setelah update diterapkan ke server API. Gunakan alat perbandingan file untuk membandingkan output.

Selesaikan pertarungan pengontrol

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

  • Perbarui manifes resource di sumber agar sesuai dengan nilai yang diinginkan pengontrol lain.
  • Hapus kolom yang dimaksud dari sumber agar pengontrol lain dapat mengelolanya.
  • Menonaktifkan atau uninstal pengontrol lainnya.
  • Hapus resource dari sumber dan kelola secara manual atau dengan pengontrol kustom yang menoleransi perubahan atau pengelolaan bersama tertentu.
  • Jika Anda memiliki pengontrol yang menyebabkan pertentangan resource, dan kolom yang diubah tidak ada dalam sumber tepercaya, update pengontrol Anda untuk melakukan patching, bukan mengupdate. Dengan begitu, perubahan akan diizinkan oleh Config Sync dan tidak dikembalikan.

Ada juga beberapa resource yang seharusnya dimiliki pengontrol lain (misalnya, beberapa operator menginstal atau mengelola CRD). Pengontrol lain ini akan otomatis menghapus metadata khusus untuk Config Sync. Jika komponen lain dalam cluster Kubernetes Anda menghapus metadata Config Sync, hentikan pengelolaan resource dengan Config Sync. Untuk mengetahui informasi cara melakukannya, lihat Berhenti mengelola objek terkelola.

Atau, jika tidak ingin Config Sync mengembalikan perubahan pada objek terkelola di cluster, Anda dapat menambahkan anotasi client.lifecycle.config.k8s.io/mutation: ignore ke objek yang mutasinya ingin diabaikan oleh Config Sync. Untuk mengetahui informasi tentang cara melakukannya, lihat Mengabaikan mutasi objek.

Langkah selanjutnya

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