Masalah umum Config Sync

Container rekonsiler OOMKilled di AutoPilot

Di cluster Autopilot, penampung komponen Config Sync memiliki batas resource yang ditetapkan untuk CPU dan memori. Saat dimuat, container ini dapat dimatikan oleh kubelet atau kernel karena menggunakan terlalu banyak memori.

Solusi:

Upgrade ke versi 1.17.0 atau yang lebih baru. Pada Config Sync versi 1.17.0, batas CPU dan memori default disesuaikan untuk membantu menghindari error kehabisan memori pada sebagian besar kasus penggunaan.

Jika tidak dapat melakukan upgrade, tentukan batas memori yang lebih tinggi menggunakan penggantian resource.

Rekonsiliasi tidak dapat dijadwalkan

Rekonsiler Config Sync memerlukan jumlah resource yang berbeda, bergantung pada konfigurasi RootSync atau RepoSync. Konfigurasi tertentu memerlukan lebih banyak resource daripada yang lain.

Jika rekonsiler tidak dapat dijadwalkan, hal ini mungkin karena Anda meminta lebih banyak resource daripada yang tersedia di node Anda.

Jika Anda menggunakan cluster GKE mode standar, permintaan resource rekonsiler akan ditetapkan sangat rendah. Setelan ini dipilih sebagai upaya untuk memungkinkan penjadwalan, meskipun akan menyebabkan throttling dan performa yang lambat, sehingga Config Sync berfungsi pada cluster kecil dan node kecil. Namun, pada GKE Autopilotclusters, permintaan rekonsiler ditetapkan lebih tinggi, untuk menunjukkan penggunaan secara lebih realistis saat sinkronisasi.

Solusi:

GKE Autopilot atau GKE Standard dengan penyediaan otomatis node diaktifkan akan dapat melihat jumlah resource yang diminta dan membuat node dengan ukuran yang tepat untuk memungkinkan penjadwalan. Namun, jika mengonfigurasi node atau ukuran instance node secara manual, Anda mungkin perlu menyesuaikan setelan tersebut untuk mengakomodasi persyaratan resource Pod rekonsiler.

Error KNV1067 meskipun konfigurasi berhasil diterapkan

Karena ada masalah dengan OpenAPI v2, Anda mungkin melihat error KNV1067 meskipun konfigurasi berhasil diterapkan.

Solusi:

Jika cluster Anda menjalankan versi Kubernetes yang lebih lama dari 1.27, pastikan kolom protocol ditetapkan secara eksplisit di bagian spec: containers: ports: meskipun Anda menggunakan TCP default.

Config Sync gagal direkonsiliasi dengan error KNV2002

Jika Config Sync tidak dapat melakukan rekonsiliasi dengan KNV2002 error, mungkin hal ini disebabkan oleh masalah umum yang disebabkan oleh masalah client-go. Masalah ini menyebabkan daftar resource kosong di grup API external.metrics.k8s.io/v1beta1 dengan pesan error dari objek RootSync atau RepoSync, atau log rekonsiler:

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1

Solusi:

Untuk mengatasi masalah ini, upgrade cluster GKE Anda ke GKE versi 1.28 atau yang lebih baru atau upgrade Config Sync ke versi 1.16.0 atau yang lebih baru. Kedua versi ini berisi perbaikan untuk masalah client-go.

Pengeksporan gagal: Label metrik tidak dikenal

Pada versi 1.15.0, Config Sync menambahkan label type dan commit ke banyak metrik. Label ini meningkatkan kardinalitas metrik, sehingga meningkatkan jumlah metrik yang diekspor. Pemrosesan atribut juga ditambahkan untuk memfilter label ini saat mengekspor ke Cloud Monarch, tetapi pemfilteran ini salah dikonfigurasi, sehingga menyebabkan error transformasi dalam log otel-collector.

Solusi:

Upgrade ke versi 1.17.2 atau yang lebih baru.

Error kardinalitas dan transformasi metrik tinggi

Pada versi 1.15.0, Config Sync menambahkan label type dan commit ke banyak metrik. Label ini meningkatkan kardinalitas metrik, sehingga meningkatkan jumlah metrik yang diekspor. Pemrosesan atribut juga ditambahkan untuk memfilter label ini saat mengekspor ke Cloud Monarch, tetapi pemfilteran ini salah dikonfigurasi, sehingga menyebabkan error transformasi dalam log otel-collector.

Solusi:

Upgrade ke versi 1.16.1 atau yang lebih baru. Pada versi 1.16.1, kolom jenis dihapus, pemfilteran diperbaiki, dan kolom commit juga difilter dari Cloud Monitoring. Tindakan ini memperbaiki error dan mengurangi kardinalitas metrik.

Ekspor gagal. Izin ditolak

Secara default, saat reconciler-manager mendeteksi Kredensial Default Aplikasi, otel-collector akan dikonfigurasi untuk mengekspor metrik ke Prometheus, Cloud Monitoring, dan Monarch.

Solusi:

otel-collector mencatat error jika Anda belum Mengonfigurasi Cloud Monitoring atau Menonaktifkan Cloud Monitoring dan Cloud Monarch.

otel-collector mengalami error dengan konfigurasi kustom

Jika Anda mencoba mengubah atau menghapus salah satu ConfigMaps default, otel-collector, atau otel-collector-google-cloud, penyedia telekomunikasi tersebut mungkin mengalami error atau error karena tidak dapat memuat ConfigMap yang diperlukan.

Solusi:

Untuk menyesuaikan konfigurasi ekspor metrik, buat ConfigMap bernama otel-collector-custom di namespace config-management-monitoring.

nomos status dan nomos bugreport tidak berfungsi di Pod

Sebelum nomos versi 1.17.2, nomos bugreport dan nomos status hanya dapat terhubung ke cluster lokal saat dijalankan di dalam Pod Kubernetes. Pada nomos versi 1.17.2, metode otorisasi diubah agar berfungsi lebih seperti kubectl. Karena perubahan ini, cluster lokal ditarget secara default. Anda dapat mengganti konfigurasi dengan menentukan variabel lingkungan KUBECONFIG.

Solusi:

Upgrade ke nomos versi 1.17.2.

Sinkronisasi Konfigurasi Bertarung dengan dirinya sendiri

Config Sync mungkin tampak berada dalam perkelahian pengontrol. dengan dirinya sendiri. Masalah ini terjadi jika Anda menetapkan nilai default untuk kolom opsional resource di repositori Git. Misalnya, menetapkan apiGroup: "" untuk subjek RoleBinding akan memicu hal ini karena kolom apiGroup bersifat opsional dan string kosong adalah nilai defaultnya. Nilai default kolom string, boolean, dan bilangan bulat adalah "", false, dan 0 (masing-masing).

Solusi:

Hapus kolom dari deklarasi resource.

Pertempuran Config Sync dengan resource Config Connector

Config Sync mungkin tampak memperjuangkan Config Connector atas sebuah resource, misalnya StorageBucket. Masalah ini terjadi jika Anda tidak menetapkan nilai kolom opsional dari spec.lifecycleRule.condition.withState resource dalam sumber tepercaya.

Solusi:

Anda dapat menghindari masalah ini dengan menambahkan kolom withState=ANY pada deklarasi resource. Atau, Anda dapat mengabaikan lalu mendapatkan kembali resource dengan anotasi cnrm.cloud.google.com/state-into-spec: absent.

Tidak dapat mengevaluasi link sumber secara berkala

Config Sync dapat mengalami masalah saat rekonsiler dimulai, ketika secara berkala tidak dapat mengevaluasi link sumber. Masalah ini terjadi karena git-sync belum meng-clone repositori sumber.

Solusi:

Update Config Sync ke versi 1.16.2 atau yang lebih baru. Dalam versi ini, ini adalah error sementara, sehingga dicatat ke dalam log, tetapi tidak dilaporkan sebagai error.

Kredensial autentikasi yang tidak valid secara berkala untuk Cloud Source Repositories

Config Sync dapat mengalami error secara berkala saat masa berlaku token autentikasi untuk Cloud Source Repositories berakhir. Masalah ini disebabkan oleh refresh token yang menunggu hingga masa berlakunya habis sebelum memuat ulang token.

Solusi:

Update Config Sync ke versi 1.18.0 atau yang lebih baru. Dalam versi ini, token diperbarui pada permintaan pertama dalam waktu lima menit setelah masa berlaku token habis. Hal ini untuk mencegah error kredensial autentikasi yang tidak valid kecuali jika kredensial tersebut benar-benar tidak valid.

Terjadi error saat menyinkronkan repositori: batas waktu konteks terlampaui

Pada versi sebelum 1.17.0, Config Sync memeriksa histori repositori Git lengkap secara default. Hal ini dapat menyebabkan waktu permintaan pengambilan habis pada repositori besar dengan banyak commit.

Solusi:

Upgrade ke versi 1.17.0 atau yang lebih baru. Pada versi 1.17.0 dan yang lebih baru, pengambilan Git dilakukan dengan --depth=1, yang hanya mengambil commit terbaru. Hal ini akan mempercepat pengambilan sumber, menghindari sebagian besar waktu tunggu, dan mengurangi beban server Git.

Jika masih mengalami masalah ini setelah melakukan upgrade, kemungkinan Sumber tepercaya Anda memiliki banyak file, server Git merespons dengan lambat, atau ada masalah jaringan lainnya.

Jumlah permintaan PATCH yang tidak efektif di log audit tinggi

Perbaikan Config Sync menggunakan Dry-run untuk mendeteksi penyimpangan. Hal ini dapat menyebabkan permintaan PATCH muncul di log audit, meskipun PATCH tidak dipertahankan, karena log audit tidak membedakan antara uji coba dan permintaan normal.

Solusi:

Config Sync gagal mengambil commit terbaru dari cabang

Di Config Sync versi 1.17.0 dan yang lebih baru, Anda mungkin mengalami masalah saat Config Sync gagal menarik commit terbaru dari HEAD cabang tertentu ketika cabang yang sama direferensikan di beberapa remote dan tidak sinkron. Misalnya, cabang main dari repositori jarak jauh origin mungkin berada di depan cabang yang sama dalam repositori jarak jauh upstream, tetapi Config Sync hanya mengambil SHA commit dari baris terakhir, yang mungkin bukan merupakan commit terbaru.

Contoh berikut menunjukkan seperti apa masalah ini mungkin terlihat:

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

Solusi:

Untuk mengurangi masalah ini, Anda dapat menetapkan revisi Git (spec.git.revision) ke SHA commit terbaru, terlepas dari nilai yang ditetapkan untuk cabang Git (spec.git.branch). Untuk mengetahui informasi selengkapnya tentang konfigurasi Git, lihat Konfigurasi untuk repositori Git.