Masalah umum Config Sync

Halaman ini mencantumkan masalah umum untuk versi Config Sync yang didukung.

Banyak masalah yang tercantum di sini telah diperbaiki. Versi tetap menunjukkan versi tempat perbaikan diperkenalkan. Untuk menerima perbaikan ini, upgrade ke versi yang tercantum atau lebih baru.

Untuk memfilter masalah umum menurut versi produk atau kategori masalah, pilih filter dari menu drop-down berikut.

Pilih versi Config Sync Anda:

Pilih kategori masalah Anda:

Atau, filter masalah umum:

Kategori Versi yang diidentifikasi Versi tetap Masalah dan solusi
Kesehatan komponen 1.15.0 1.17.0

Memperbaiki: Penampung rekonsiliasi OOMKilled di AutoPilot

Di cluster Autopilot, container komponen Config Sync memiliki batas resource yang ditetapkan untuk CPU dan memori. Saat beban, container ini dapat dimatikan oleh {i>kubelet<i} atau {i>kernel<i} karena menggunakan terlalu banyak memori.

Solusi:

Jika tidak dapat mengupgrade ke versi 1.17.0 atau yang lebih baru, tentukan batas memori yang lebih tinggi menggunakan penggantian resource.

Di versi 1.17.0, batas {i>default<i} CPU dan memori disesuaikan menjadi membantu menghindari {i>error<i} memori untuk sebagian besar kasus penggunaan.
Kesehatan komponen 1.15.0

Rekonsiliasi tidak dapat dijadwalkan

Rekonsiliasi Config Sync memerlukan jumlah resource yang bervariasi, bergantung pada konfigurasi RootSync atau RepoSync. Tertentu membutuhkan lebih banyak resource daripada yang lain.

Jika rekonsiliasi tidak dapat dijadwalkan, itu mungkin karena rekonsiliasi permintaan daripada yang tersedia di node Anda.

Jika Anda menggunakan cluster GKE mode standar, resource rekonsiliasi ditetapkan sangat rendah. Setelan ini dipilih sebagai upaya untuk izinkan penjadwalan, meskipun akan menyebabkan throttling dan keterlambatan performa, sehingga Config Sync dapat berfungsi pada cluster kecil dan node. Namun, pada GKE Autopilotcluster, permintaan rekonsiliasi ditetapkan lebih tinggi, untuk mewakili secara lebih realistis penggunaan saat menyinkronkan.

Solusi:

Autopilot GKE atau GKE Standard dengan penyediaan otomatis node harus dapat melihat berapa banyak sumber daya yang diminta dan membuat {i>node<i} yang berukuran tepat untuk memungkinkan penjadwalan. Namun, jika Anda secara manual mengonfigurasi node atau ukuran instance node, Anda mungkin perlu menyesuaikan setelan tersebut untuk mengakomodasi kebutuhan resource Pod yang melakukan rekonsiliasi.
Error KNV 1.15.0 Kubernetes versi 1.27

Perbaikan: Error KNV1067 meskipun konfigurasi berhasil diterapkan

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

Solusi:

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

Error KNV 1.15.0 1.16.0, Kubernetes versi 1.28

Perbaikan: Config Sync gagal direkonsiliasi dengan error KNV2002

Jika Config Sync tidak dapat merekonsiliasi dengan KNV2002 error, hal itu mungkin disebabkan oleh masalah yang telah diketahui 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 rekonsiliasi:

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
Metrik 1.15.0 1.17.2

Diperbaiki: Ekspor gagal: Label metrik tidak dikenal

Pada versi 1.15.0, Config Sync menambahkan type dan commit label 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, menyebabkan error transformasi di log otel-collector.
Metrik 1.15.0 1.16.1

Perbaikan: Error kardinalitas dan transformasi metrik tinggi

Pada versi 1.15.0, Config Sync menambahkan type dan commit label 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, menyebabkan error transformasi di log otel-collector.

Dalam versi 1.16.1, isian tipe telah dihapus, penyaringan diperbaiki, dan kolom commit juga difilter dari Cloud Monitoring. Tindakan ini telah memperbaiki error dan mengurangi kardinalitas metrik.
Metrik 1.15.0

Proses ekspor gagal. Izin ditolak

Secara default, saat pengelola rekonsiliasi mendeteksi Kredensial Default Aplikasi, kolektor otel dikonfigurasi untuk mengekspor metrik ke Prometheus, Cloud Monitoring, dan Monarch.

Solusi:

otel-collector mencatat error jika Anda belum Cloud Monitoring yang Dikonfigurasi atau Cloud Monitoring dinonaktifkan dan Cloud Monarch.
Metrik 1.15.0

otel-collector mengalami error dengan konfigurasi kustom

Jika Anda mencoba mengubah atau menghapus salah satu ConfigMaps default, otel-collector atau otel-collector-google-cloud, {i>otel-collector<i} mungkin {i>error<i} atau rusak karena tidak dapat memuat ConfigMap yang diperlukan.

Solusi:

Untuk menyesuaikan konfigurasi ekspor metrik, buat ConfigMap bernama otel-collector-custom dalam Namespace config-management-monitoring.
Nomos CLI 1.15.0 1.17.2

Perbaikan: 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 jika dijalankan di dalam Pod Kubernetes. Di nomos versi 1.17.2, otorisasi telah diubah agar berfungsi seperti kubectl. Karena ini berubah, cluster lokal ditarget secara default. Anda dapat mengganti dengan menentukan variabel lingkungan KUBECONFIG.
Pemulihan

Sinkronisasi Konfigurasi berkonflik dengan dirinya sendiri

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

Solusi:

Hapus kolom dari deklarasi resource.
Pemulihan

Perlawanan Sinkronisasi Konfigurasi dengan resource Config Connector

Config Sync mungkin terlihat seperti perkelahian Config Connector melalui resource, misalnya StorageBucket. Masalah ini terjadi jika Anda tidak menetapkan nilai kolom opsional resource spec.lifecycleRule.condition.withState di sumber kebenaran.

Solusi:

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

Sumber kebenaran 1.17.3 1.18.3

Memperbaiki: Kegagalan Autentikasi SSH Git dengan GitHub

git-sync v4.2.1 memiliki bug yang menghapus nama pengguna dari URL repositori saat menggunakan SSH, yang menyebabkan otentikasi gagal saat menghubungkan ke GitHub, yang mengharuskan pengguna menjadi git.

Pesan error dari git adalah: git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Solusi:

Gunakan metode autentikasi lain.
Sumber kebenaran 1.16.1 1.16.2

Tetap: Tidak dapat mengevaluasi tautan sumber secara berkala

Config Sync dapat mengalami masalah saat rekonsiliasi dimulai dari tempatnya tidak dapat mengevaluasi tautan sumber secara berkala. Masalah ini terjadi karena git-sync belum meng-clone repositori sumber.

Pada versi 1.16.2 dan yang lebih baru, ini adalah {i>error<i} sementara, jadi dicatat tetapi tidak dilaporkan sebagai kesalahan.
Sumber kebenaran 1.15.0 1.18.0

Perbaikan: Kredensial autentikasi yang tidak valid secara berkala untuk Cloud Source Repositories

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

Pada versi 1.18.0 dan yang lebih baru, token diperbarui pada permintaan pertama dalam waktu lima menit setelah masa berlaku token habis. Hal ini mencegah permintaan tidak valid kredensial otentikasi, kecuali kredensial tersebut benar-benar tidak valid.
Sumber kebenaran 1.15.0 1.17.0

Perbaikan: Error dalam menyinkronkan repositori: batas waktu konteks terlampaui

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

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 Anda masih mengalami masalah ini setelah meningkatkan versi, kemungkinan bahwa {i>Source of truth<i} memiliki banyak file, server Git Anda merespons dengan lambat, atau ada beberapa masalah jaringan lainnya.
Menyinkronkan 1.15.0

Jumlah permintaan PATCH yang tidak efektif dalam log audit yang tinggi

Remediator Config Sync menggunakan Uji coba untuk mendeteksi penyimpangan. Ini dapat menyebabkan permintaan PATCH muncul di log audit, bahkan saat PATCH tidak disimpan, karena log audit tidak membedakan antara permintaan uji coba dan permintaan normal.

Solusi:

Karena log audit tidak dapat membedakan antara uji coba dan non-kering permintaan, Anda dapat mengabaikan permintaan PATCH.
Menyinkronkan 1.17.0 1.17.3

Perbaikan: Config Sync gagal mengambil commit terbaru dari cabang

Pada Config Sync versi 1.17.0, 1.17.1, dan 1.17.2, Anda mungkin mengalami masalah saat Config Sync gagal menarik commit terbaru dari {i>HEAD<i} cabang tertentu ketika cabang yang sama{i> <i}direferensikan pada beberapa remote dan mereka tidak sinkron. Misalnya, Cabang main dari repositori jarak jauh origin mungkin berada di depan cabang yang sama di repositori jarak jauh upstream, tetapi Config Sync hanya mengambil SHA commit dari baris terakhir, yang mungkin bukan commit terbaru.

Contoh berikut menunjukkan tampilan masalah ini:

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

Pada versi 1.17.3 dan yang lebih baru, dependensi git-sync telah diupdate dengan mekanisme pengambilan yang berbeda.

Jika tidak dapat melakukan upgrade, Anda dapat menyetel revisi Git (spec.git.revision) ke SHA commit terbaru, terlepas dari nilai yang ditetapkan untuk cabang Git (spec.git.branch). Untuk selengkapnya konfigurasi Git, lihat Konfigurasi untuk repositori Git.
Registry pribadi 1.19.0

Config Sync tidak menggunakan registry pribadi untuk Deployment rekonsiliasi

Config Sync akan menggantikan image untuk semua Deployment saat registry pribadi dikonfigurasi. Namun, Config Sync tidak dapat menggantikan registry image untuk image di Deployment rekonsiliasi.

Solusi:

Solusi untuk masalah ini adalah dengan mengonfigurasi mirror registry image di containerd.

Menyinkronkan 1.17.0 1.18.3

Perbaikan: Rekonsiliasi Config Sync mengalami errorlooping

Pada Config Sync versi 1.17.0 atau yang lebih baru, Anda mungkin mengalami masalah di mana rekonsiliasi gagal membuat {i>rest config<i} pada beberapa penyedia Kubernetes.

Contoh berikut menunjukkan tampilan masalah ini di log rekonsiliasi:

Error creating rest config: failed to build rest config: reading local kubeconfig: loading REST config from "/.kube/config": stat /.kube/config: no such file or directory

Kembali ke atas

Langkah selanjutnya