Halaman ini menunjukkan cara menyelesaikan masalah terkait pertentangan pengontrol. Pertarungan tersebut menghabiskan banyak resource dan dapat menurunkan performa Anda. Pertarungan pengontrol juga dikenal sebagai persaingan resource.
Config Sync memantau objek yang diterapkannya di cluster dan mengembalikan
perubahan yang dilakukan pada nilai yang dideklarasikan di sumber tepercaya. Jika perubahan ini
dibuat oleh pengontrol lain, resource mungkin beralih bolak-balik 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 konflik, mencatat drift, dan melaporkan
error dalam status objek RootSync atau RepoSync.
Config Sync memiliki logika khusus untuk mendeteksi konflik antara beberapa objek RootSync
dan RepoSync. Untuk objek RepoSync, jika rekonsiliator melihat bahwa
objek sudah dikelola oleh rekonsiliator lain, update lebih lanjut akan dilewati.
Untuk objek RootSync, rekonsiliator mencoba mengadopsi objek apa pun yang
dikonfigurasi untuk dikelola, kecuali jika dikelola oleh objek RootSync lain. Tindakan ini
mencegah rekonsiliator Config Sync saling bertentangan dan
melaporkan error dalam status semua objek RootSync dan RepoSync yang terlibat.
Mengidentifikasi pertentangan pengontrol
Anda dapat meninjau error pertentangan 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 rekonsiliator 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 rekonsiliator 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 tepercaya cakupan namespace.
Jika Anda melihat KNV2005 dalam hasil, berarti ada pertentangan 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.
Menginvestigasi pertentangan pengontrol
Untuk menemukan informasi selengkapnya tentang pertentangan pengontrol, lihat 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 diperebutkan.OBJECT_NAME: nama objek yang sedang diperebutkan.NAMESPACE: namespace tempat resource yang diperebutkan berada.
Hasil log menentukan resource, nama objek, dan namespace yang perlu Anda tambahkan.
Perintah ini menampilkan streaming status resource setelah update diterapkan ke server API. Gunakan alat perbandingan file untuk membandingkan output.
Menyelesaikan pertentangan pengontrol
Ada beberapa cara untuk menyelesaikan konflik pengontrol. Pilih opsi yang paling cocok untuk penyiapan Config Sync Anda:
- Perbarui manifes resource di sumber agar cocok dengan nilai yang diinginkan pengontrol lainnya.
- Hapus kolom yang dipermasalahkan dari sumber agar pengontrol lain dapat mengelolanya.
- Nonaktifkan atau uninstal pengontrol lainnya.
- Hapus resource dari sumber dan kelola secara manual atau dengan pengontrol kustom yang menerima perubahan atau pengelolaan bersama tertentu.
- Jika Anda memiliki pengontrol yang menyebabkan pertentangan resource, dan kolom yang diubah tidak ada di sumber tepercaya, perbarui pengontrol untuk melakukan patching, bukan mengupdate. Dengan begitu, perubahan akan diizinkan oleh Sinkronisasi Konfigurasi dan tidak akan dikembalikan.
Ada juga beberapa resource yang harus dimiliki oleh pengontrol lain (misalnya, beberapa operator menginstal atau mengelola CRD). Pengontrol lain ini akan otomatis menghapus metadata khusus untuk Config Sync. Jika komponen lain di cluster Kubernetes Anda menghapus metadata Config Sync, berhenti mengelola resource dengan Config Sync. Untuk mengetahui informasi tentang cara melakukannya, lihat Berhenti mengelola objek terkelola.
Atau, jika tidak ingin Config Sync mengembalikan perubahan ke objek
yang dikelola di cluster, Anda dapat menambahkan
anotasi client.lifecycle.config.k8s.io/mutation: ignore ke objek yang
ingin Anda abaikan mutasinya 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.