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.