Memecahkan masalah Config Connector

---

Halaman ini menjelaskan teknik pemecahan masalah yang dapat Anda gunakan untuk memecahkan masalah Config Connector dan masalah umum yang mungkin Anda alami saat menggunakan produk.

Teknik pemecahan masalah dasar

Memeriksa versi Config Connector

Jalankan perintah berikut untuk mendapatkan versi Config Connector yang terinstal dan melakukan referensi silang catatan rilis untuk memverifikasi bahwa versi yang berjalan mendukung fitur dan resource yang ingin Anda gunakan:

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

Memeriksa status dan peristiwa resource

Biasanya, Anda dapat menentukan masalah pada resource Config Connector dengan memeriksa status resource Kubernetes. Diperiksa status dan peristiwa sumber daya sangat membantu untuk menentukan apakah Config Connector gagal merekonsiliasi resource dan alasan rekonsiliasi gagal.

Memastikan Config Connector sedang berjalan

Untuk memastikan bahwa Config Connector berjalan, pastikan semua Pod-nya telah READY:

kubectl get pod -n cnrm-system

Contoh output:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Jika Anda menginstal Config Connector di namespaced-mode, maka Anda akan memiliki satu Pod pengontrol (cnrm-controller-manager) untuk masing-masing yang bertanggung jawab untuk mengelola resource Config Connector dalam namespace itu.

Anda dapat memeriksa status Pod pengontrol yang bertanggung jawab untuk namespace dengan menjalankan:

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

Ganti NAMESPACE dengan nama namespace.

Memeriksa log pengontrol

Pod pengontrol akan mencatat informasi dan error yang terkait dengan rekonsiliasi untuk resource Config Connector.

Anda dapat memeriksa log Pod pengontrol dengan menjalankan:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Jika Anda menginstal Config Connector di namespaced-mode, perintah sebelumnya akan menunjukkan log dari semua Pod pengontrol yang digabungkan. Anda dapat memeriksa log Pod pengontrol untuk namespace tertentu dengan menjalankan:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Ganti NAMESPACE dengan nama namespace.

Baca selengkapnya tentang cara memeriksa dan membuat kueri log Config Connector.

Mengabaikan dan mendapatkan resource

Dalam beberapa kasus, Anda mungkin perlu memperbarui kolom yang tidak dapat diubah di resource. Sejak Anda tidak dapat mengedit kolom yang tidak dapat diubah, Anda harus mengabaikannya lalu mendapatkan resource:

1. Memperbarui konfigurasi YAML dari resource Config Connector dan menetapkan anotasi cnrm.cloud.google.com/deletion-policy ke abandon.
2. Menerapkan konfigurasi YAML yang diperbarui untuk mengupdate Config Connector kebijakan penghapusan resource.
3. Mengabaikan Config Connector resource.
4. Memperbarui kolom yang tidak dapat diubah yang perlu diubah di YAML konfigurasi Anda.
5. Terapkan konfigurasi YAML yang telah diperbarui ke mengakuisisi resource.

Masalah umum

Referensi terus diperbarui setiap 5-15 menit

Jika resource Config Connector Anda terus beralih dari status UpToDate menjadi status Updating setiap 5-10 menit, ada kemungkinan Config Connector mendeteksi perbedaan yang tidak disengaja antara resource status yang diinginkan dan status sebenarnya, sehingga menyebabkan Config Connector terus-menerus memperbarui sumber daya.

Pertama, pastikan bahwa Anda tidak memiliki sistem eksternal yang terus-menerus mengubah resource Config Connector atau Google Cloud (untuk misalnya, pipeline CI/CD, pengontrol kustom, cron job, dll.).

Jika perilaku tersebut bukan disebabkan oleh sistem eksternal, lihat apakah Google Cloud mengubah salah satu nilai yang ditentukan dalam resource Config Connector Anda. Sebagai misalnya, dalam beberapa kasus, Google Cloud mengubah format (misalnya, kapitalisasi) dari nilai bidang yang menyebabkan perbedaan antara nilai sumber daya Anda kondisi yang diinginkan dan kondisi aktual.

Dapatkan status resource Google Cloud menggunakan REST API (untuk misalnya, untuk ContainerCluster) atau Google Cloud CLI. Kemudian, bandingkan status tersebut dengan Config Connector Anda resource Anda Cari bidang yang nilainya tidak cocok, lalu perbarui Resource Config Connector yang akan dicocokkan. Secara khusus, cari nilai-nilai telah diformat ulang oleh Google Cloud. Misalnya, lihat masalah GitHub #578 dan #294.

Perhatikan bahwa ini bukan metode yang sempurna karena Config Connector dan Model resource Google Cloud berbeda, tetapi model ini harus memungkinkan Anda sebagian besar kasus perbedaan yang tidak diinginkan.

Jika Anda tidak dapat menyelesaikan masalah, lihat Tambahan bantuan.

Penghapusan namespace macet di "Menghentikan"

Penghapusan namespace mungkin terhenti di Terminating jika Anda harus Config Connector diinstal di mode dengan namespace dan jika ConfigConnectorContext namespace telah dihapus sebelum Resource Config Connector di namespace tersebut dihapus. Ketika sebuah ConfigConnectorContext dihapus, Config Connector dinonaktifkan untuknya namespace, yang mencegah sisa resource Config Connector di dalamnya namespace agar tidak dihapus.

Untuk memperbaiki masalah ini, Anda harus melakukan pembersihan paksa, lalu menghapus resource Google Cloud yang mendasarinya secara manual setelahnya.

Untuk mengurangi masalah ini pada masa mendatang, hanya hapus ConfigConnectorContext setelah semua resource Config Connector dalam namespace dihapus dari Kubernetes. Hindari menghapus seluruh namespace sebelum semua Config Connector resource dalam namespace tersebut telah dihapus sejak ConfigConnectorContext mungkin akan dihapus terlebih dahulu.

Lihat juga cara menghapus namespace yang berisi Project dan turunan atau Folder dan anak-anak mereka bisa merasa terhambat.

Penghapusan resource macet di "DeleteFailed" setelah project dihapus

Penghapusan resource Config Connector mungkin macet di DeleteFailed jika project Google Cloud mereka telah dihapus sebelumnya.

Untuk memperbaiki masalah ini, pulihkan proyek di Google Cloud untuk mengizinkan Config Connector menghapus resource turunan yang tersisa dari Kubernetes. Atau, Anda dapat melakukan pembersihan paksa.

Untuk mengurangi masalah ini pada masa mendatang, hanya hapus project Google Cloud setelah semua resource Config Connector turunannya dihapus dari Kubernetes. Hindari menghapus seluruh namespace yang mungkin berisi Resource Project dan resource Config Connector turunannya sejak Project mungkin akan dihapus terlebih dahulu.

Metadata Compute Engine tidak ditentukan

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menyatakan bahwa metadata Compute Engine tidak ditentukan, kemungkinan besar Akun layanan IAM yang digunakan oleh Config Connector tidak ada.

Contoh pesan UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

Untuk memperbaiki masalah ini, pastikan bahwa akun layanan IAM yang digunakan oleh Config Connector ada.

Untuk mengurangi masalah ini di masa mendatang, pastikan Anda mengikuti Penginstalan Config Connector petunjuk khusus.

Error 403: Permintaan memiliki cakupan autentikasi yang tidak memadai

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan menunjukkan {i>error <i}403 karena cakupan otentikasi yang tidak memadai, maka hal itu kemungkinan berarti Beban kerja Identity tidak diaktifkan di ke cluster GKE Anda.

Contoh pesan UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

Untuk melakukan penyelidikan, selesaikan langkah-langkah berikut:

1. Simpan konfigurasi Pod berikut sebagai wi-test.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: cnrm-system
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: cnrm-controller-manager
   

   Jika Anda menginstal Config Connector menggunakan mode namespace, serviceAccountName harus cnrm-controller-manager-NAMESPACE. Ganti NAMESPACE dengan namespace yang Anda gunakan selama penginstalan.

2. Buat Pod di cluster GKE Anda:

   kubectl apply -f wi-test.yaml
   

3. Buka sesi interaktif di Pod:

   kubectl exec -it workload-identity-test \
       --namespace cnrm-system \
       -- /bin/bash
   

4. Cantumkan identitas Anda:

   gcloud auth list
   

5. Pastikan identitas yang tercantum cocok dengan akun layanan Google yang terikat pada resource Anda.

   Jika Anda melihat akun layanan default Compute Engine sebagai gantinya, itu berarti Workload Identity Federation untuk GKE tidak diaktifkan di cluster GKE dan/atau kumpulan node.

6. Keluar dari sesi interaktif, lalu hapus Pod dari Cluster GKE:

   kubectl delete pod workload-identity-test \
       --namespace cnrm-system
   

Untuk memperbaiki masalah ini, gunakan cluster GKE dengan Workload Identity Federation for GKE mengaktifkan pembuatan versi.

Jika Anda masih melihat error yang sama pada cluster GKE dengan Workload Identity Federation for GKE diaktifkan, pastikan Anda tidak lupa untuk mengaktifkan Workload Identity Federation for GKE pada kumpulan node cluster. Baca selengkapnya tentang mengaktifkan Workload Identity Federation untuk GKE pada node yang ada Google Cloud Platform. Sebaiknya aktifkan Workload Identity Federation for GKE pada semua node pool cluster Anda sejak Config Connector dapat dijalankan di salah satunya.

403 Dilarang: Pemanggil tidak memiliki izin; lihat dokumentasi Workload Identity Federation untuk GKE

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan menunjukkan error 403 karena Workload Identity Federation for GKE, kemungkinan besar Akun layanan Kubernetes Config Connector tidak memiliki akun layanan yang sesuai Izin IAM untuk meniru identitas layanan IAM Anda Anda sebagai Workload Identity Federation untuk pengguna GKE.

Contoh pesan UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity Federation for GKE documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

Untuk memperbaiki dan mengurangi masalah pada masa mendatang, lihat Config Connector petunjuk penginstalan.

Error 403: Pemanggil tidak memiliki izin IAM

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menyatakan bahwa pemanggil tidak memiliki izin IAM, kemungkinan itu berarti akun layanan IAM yang digunakan oleh Config Connector tidak memiliki Izin IAM yang dinyatakan dalam pesan yang diperlukan untuk mengelola resource Google Cloud.

Contoh pesan UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

Jika Anda masih melihat error yang sama setelah memberikan IAM akun layanan izin IAM yang sesuai, lalu periksa apakah sumber daya Anda dibuat dalam project yang tepat. Periksa Kolom spec.projectRef resource Config Connector (atau kolomnya anotasi cnrm.cloud.google.com/project-id jika resource tidak mendukung spec.projectRef) dan pastikan bahwa resource tersebut merujuk ke proyek yang benar. Perhatikan bahwa Config Connector menggunakan nama namespace sebagai project ID jika resource atau namespace tidak menentukan project target. Baca selengkapnya tentang cara mengonfigurasi project target untuk cakupan project resource.

Jika Anda masih melihat error yang sama, periksa apakah Workload Identity Federation for GKE di cluster GKE Anda.

Untuk mengurangi masalah ini di masa mendatang, pastikan Anda mengikuti Penginstalan Config Connector petunjuk khusus.

Versi tidak didukung di penginstalan add-on Config Connector

Jika Anda tidak berhasil mengaktifkan add-on Config Connector, hal berikut pesan error muncul: Node version 1.15.x-gke.x s unsupported. Untuk mengatasi hal ini, error, pastikan versi cluster GKE memenuhi persyaratan versi dan fitur.

Untuk mendapatkan semua versi yang valid untuk cluster Anda, jalankan perintah berikut:

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

Ganti ZONE dengan zona Compute Engine.

Pilih versi dari daftar yang memenuhi persyaratan.

Pesan {i>error<i} juga muncul jika Workload Identity Federation untuk GKE atau Pemantauan GKE dinonaktifkan. Pastikan fitur ini diaktifkan untuk memperbaiki error.

Tidak dapat membuat perubahan pada kolom yang tidak dapat diubah

Config Connector menolak update pada kolom yang tidak dapat diubah di .

Misalnya, memperbarui kolom yang tidak dapat diubah dengan kubectl apply akan menyebabkan yang gagal.

Artinya, alat yang terus-menerus menerapkan ulang resource (misalnya, GitOps) mungkin terjebak saat mengupdate resource jika mereka tidak menangani kesalahan penerimaan.

Karena Config Connector tidak mengizinkan pembaruan pada kolom yang tidak dapat diubah, satu-satunya cara untuk melakukan pembaruan semacam itu adalah menghapus dan membuat ulang sumber daya.

Terjadi error saat memperbarui kolom yang tidak dapat diubah jika tidak ada pembaruan

Anda mungkin melihat error berikut pada status Config Connector resource segera setelah Anda membuat atau memperoleh resource Google Cloud menggunakan Konektor Konfigurasi:

• Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (contoh)

• Update call failed: cannot make changes to immutable field(s) (contoh)

Hal ini mungkin tidak berarti bahwa Anda telah memperbarui sumber daya, tetapi alasannya mungkin Google Cloud API telah membuat perubahan pada kolom yang tidak dapat diubah yang dikelola oleh Anda di resource Config Connector. Hal ini menyebabkan ketidakcocokan antara status yang diinginkan dan status aktif kolom yang tidak dapat diubah.

Anda dapat mengatasi masalah ini dengan memperbarui nilai kolom yang tidak dapat diubah tersebut di resource Config Connector agar sesuai dengan status aktif. Untuk mencapainya, Anda harus selesaikan langkah-langkah berikut:

1. Memperbarui konfigurasi YAML dari resource Config Connector dan menetapkan anotasi cnrm.cloud.google.com/deletion-policy menjadi abandon.
2. Menerapkan konfigurasi YAML yang diperbarui untuk mengupdate Config Connector kebijakan penghapusan resource.
3. Abaikan resource Config Connector.
4. Mencetak status aktif resource Google Cloud yang sesuai menggunakan gcloud CLI.
5. Menemukan ketidakcocokan antara output gcloud CLI dan YAML konfigurasi resource Config Connector, dan memperbarui kolom tersebut konfigurasi YAML.
6. Terapkan konfigurasi YAML yang diperbarui ke mengakuisisi resource yang ditinggalkan.

Resource tidak memiliki status

Jika resource Anda tidak memiliki kolom status, ada kemungkinan Config Connector tidak berjalan dengan benar. Periksa apakah Config Connector sudah sedang berjalan.

Tidak ada kecocokan untuk jenis "Foo"

Saat error ini ditemukan, berarti cluster Kubernetes Anda tidak menginstal CRD untuk jenis resource Foo.

Verifikasi bahwa jenisnya adalah jenis resource yang didukung oleh Config Connector.

Jika jenisnya didukung, berarti instalasi Config Connector Anda adalah usang atau tidak valid.

Jika Anda menginstal Config Connector menggunakan add-on GKE, instalasi Anda akan ditingkatkan secara otomatis. Jika Anda menginstal secara manual Config Connector, maka Anda harus melakukan pemeriksaan upgrade.

Periksa repositori GitHub untuk menentukan jenis resource yang didukung oleh versi Config Connector mana (misalnya, berikut adalah jenis yang didukung oleh Config Connector v1.44.0).

Label tidak disebarkan ke resource Google Cloud

Config Connector menyebarkan label yang ditemukan di metadata.labels ke lapisan dasar resource Google Cloud tertentu. Namun, perhatikan bahwa tidak semua data label dukungan resource. Periksa dokumentasi REST API resource (untuk berikut ini adalah dokumentasi API untuk PubSubTopic) untuk melihat apakah PubSubTopic label dukungan.

Gagal memanggil webhook x509: sertifikat bergantung pada kolom Nama Umum yang lama

Jika melihat pesan {i>error<i} yang mirip dengan contoh berikut, Anda mungkin mengalami masalah terkait sertifikat:

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Catatan: Masalah ini hanya terjadi pada Kubernetes versi 1.19 atau yang lebih baru dan Config Connector versi 1.43 dan yang lebih baru mendukung pembuatan otomatis sertifikat, sehingga Anda tidak akan mengalami masalah ini.

Untuk mengatasi masalah ini, hapus sertifikat dan Pod yang relevan:

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

Setelah Anda menghapus resource ini, sertifikat yang benar akan dibuat kembali.

Untuk informasi selengkapnya tentang error ini, lihat Masalah GitHub.

Error karena karakter khusus dalam nama resource

Karakter khusus tidak valid di kolom metadata.name Kubernetes. Jika Anda melihat pesan {i>error<i} yang mirip dengan contoh berikut, maka metadata.name resource kemungkinan memiliki nilai dengan karakter khusus:

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Misalnya, SQLUser resource berisi karakter yang tidak valid di metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: [e-mail]
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Jika Anda mencoba membuat resource ini, Anda akan mendapatkan error berikut:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "[e-mail]" is invalid: metadata.name: Invalid value: "[e-mail]": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Jika ingin memberi nama resource yang bukan nama Kubernetes yang valid, tetapi merupakan nama resource Google Cloud yang valid, Anda dapat menggunakan resourceID, seperti yang ditunjukkan pada contoh berikut:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: [e-mail]

Konfigurasi ini menyebabkan Config Connector menggunakan resourceID, bukan metadata.name sebagai nama resource.

Tidak dapat menghapus kolom dari spesifikasi resource

Menghapus kolom dari spesifikasi resource Config Connector (dengan memperbarui file .yaml resource dan mengajukan permohonan ulang, atau dengan menggunakan kubectl edit untuk mengedit spesifikasi resource) sebenarnya tidak menghapus kolom tersebut dari spesifikasi resource Config Connector atau resource Google Cloud yang mendasarinya. Sebaliknya, menghapus kolom dari spesifikasi hanya akan membuat kolom itu dikelola secara eksternal.

Catatan: Ada satu pengecualian: kolom dalam daftar. Daftar bersifat atomik, yang berarti Config Connector akan mencoba menetapkan daftar dalam layanan Google Cloud agar setara dengan yang ditentukan dalam spesifikasi.

Jika Anda ingin mengubah nilai {i>field<i} menjadi kosong atau {i>default<i} di Google Cloud, Anda harus mengosongkan kolom di Spesifikasi resource Config Connector:

• Untuk kolom jenis daftar, tetapkan kolom ke daftar kosong menggunakan [].

  Contoh berikut menunjukkan kolom targetServiceAccounts yang ingin kita hapus:

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

  Untuk menghapus kolom ini, tetapkan nilai ke kosong:

  spec:
    targetServiceAccounts: []
  

• Untuk kolom jenis primitif, tetapkan kolom ke kosong menggunakan salah satu hal berikut:

  Jenis	Nilai kosong
  string	""
  bool	"salah"
  bilangan bulat	0

  Contoh berikut menunjukkan kolom identityNamespace yang ingin kita hapus:

  spec:
    workloadIdentityConfig:
      identityNamespace: "foo-project.svc.id.goog"
  

  Untuk menghapus kolom ini, tetapkan nilai ke kosong:

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• Untuk kolom jenis objek, saat ini di Config Connector, tidak ada cara mudah untuk mengatur seluruh isian tipe objek sebagai "NULL". Anda dapat mencoba untuk menyetel sub-isian dari sebagai default atau kosong dengan mengikuti panduan di atas dan verifikasi apakah berfungsi.

KNV2005: sinkronisasi memperbarui resource secara berlebihan

Jika Anda menggunakan Sinkronisasi Konfigurasi dan Anda melihat KNV2005 error untuk resource Config Connector, maka kemungkinan Config Sync dan Config Connector berebut resource.

Contoh pesan log:

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

Config Sync dan Config Connector dikatakan "bermasalah" melalui resource jika kolom yang sama terus diperbarui ke nilai yang berbeda. Info terbaru memicu yang lain untuk bertindak dan memperbarui sumber daya, yang menyebabkan yang lain bertindak dan memperbarui sumber daya, dan sebagainya.

Bertarung bukanlah masalah untuk sebagian besar bidang. Kolom yang ditentukan dalam Config Sync tidak diubah oleh Config Connector, sedangkan kolom yang tidak yang ditentukan dalam Config Sync dan default oleh Config Connector diabaikan oleh Sinkronisasi Konfigurasi. Oleh karena itu, untuk sebagian besar {i>field<i}, {i> Config Sync<i} dan Config Connector tidak boleh memperbarui kolom yang sama ke kolom yang berbeda masing-masing.

Ada satu pengecualian: kolom daftar. Serupa dengan cara Config Connector mungkin subkolom default di kolom objek, Config Connector juga dapat default subkolom dalam objek di dalam daftar. Namun, karena kolom daftar di Config Connector resource bersifat atomik, {i>default<i} sub-kolom dianggap sebagai perubahan dari daftar secara keseluruhan.

Oleh karena itu, Config Sync dan Config Connector akan mengalami masalah jika Config Sync menetapkan kolom daftar dan setiap subkolom Config Connector menetapkan setiap subkolom secara default dalam daftar tersebut.

Untuk mengatasi masalah ini, Anda memiliki opsi berikut:

1. Update manifes resource di repositori Config Sync agar sesuai dengan Config Connector mencoba menetapkan resource.

   Salah satu cara untuk melakukannya adalah dengan menghentikan sinkronisasi untuk sementara konfigurasi, tunggu Config Connector selesai merekonsiliasi resource, lalu mengupdate manifes resource agar sesuai dengan resource di Kubernetes API Server.

2. Menghentikan Config Sync agar tidak bereaksi terhadap update pada resource di Server Kubernetes API dengan menyetel anotasi client.lifecycle.config.k8s.io/mutation hingga ignore. Baca selengkapnya tentang cara agar objek abaikan Config Sync mutasi.

3. Hentikan Config Connector agar tidak memperbarui spesifikasi resource sepenuhnya dengan menetapkan anotasi cnrm.cloud.google.com/state-into-spec menjadi absent di resource Anda Anotasi ini tidak didukung untuk semua resource. Untuk melihat apakah sumber daya yang mendukung anotasi, periksa halaman referensi resource. Baca selengkapnya tentang anotasi.

failed calling webhook

Config Connector mungkin akan berada dalam status yang tidak dapat di-uninstal Konektor Konfigurasi. Hal ini biasanya terjadi saat menggunakan add-on Config Connector dan menonaktifkan Config Connector sebelum menghapus CRD Config Connector. Saat mencoba meng-uninstal, Anda akan menerima pesan error seperti berikut:

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

Untuk mengatasi error ini, Anda harus menghapus webhook secara manual terlebih dahulu:

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

Anda kemudian dapat melanjutkan untuk meng-uninstal Config Connector.

Error pembaruan pada IAMPolicy, IAMPartialPolicy, dan IAMPolicyMember

Jika Anda menghapus resource IAMServiceAccount Config Connector sebelum membersihkan resource IAMPolicy,IAMPartialPolicy, dan IAMPolicyMember yang bergantung pada akun layanan tersebut, Config Connector tidak dapat menemukan akun layanan yang dirujuk dalam resource IAM tersebut selama rekonsiliasi. Ini menghasilkan status UpdateFailed dengan pesan error seperti berikut:

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

Untuk mengatasi masalah ini, periksa akun layanan Anda dan lihat apakah akun layanan yang diperlukan untuk resource IAM tersebut telah dihapus. Jika akun layanan dihapus, bersihkan juga resource IAM Config Connector terkait. Untuk IAMPolicyMember, hapus seluruh resource. Untuk IAMPolicy dan IAMParitialPolicy, hanya hapus binding yang melibatkan akun layanan yang dihapus. Namun, pembersihan tersebut tidak langsung menghapus binding peran Google Cloud. Binding peran Google Cloud dipertahankan selama 60 hari karena retensi pada akun layanan yang dihapus. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Google Cloud IAM tentang Menghapus akun layanan.

Catatan: Jika mengalami masalah selama penghapusan, Anda mungkin perlu melakukan pembersihan paksa. Jika ingin segera menghapus binding IAM Google Cloud, Anda harus menghapus resource Google Cloud yang mendasarinya secara manual menggunakan gcloud.

Untuk menghindari masalah ini, Anda harus selalu membersihkan resource Config Connector IAMPolicy, IAMPartialPolicy,IAMPolicyMember sebelum menghapus IAMServiceAccount yang direferensikan.

Resource dihapus oleh Config Connector

Config Connector tidak pernah menghapus resource Anda tanpa penyebab eksternal. Misalnya, menjalankan kubectl delete, menggunakan alat manajemen konfigurasi seperti Argo CD, atau menggunakan klien API yang disesuaikan dapat menyebabkan penghapusan resource.

Kesalahpahaman yang umum adalah bahwa Config Connector telah memulai dan menghapus beberapa resource dalam cluster Anda. Misalnya, jika Anda menggunakan Config Connector, Anda mungkin melihat permintaan hapus dari pengelola pengontrol Config Connector terhadap resource tertentu dari pesan log container atau cluster Kubernetes log audit. Permintaan penghapusan ini adalah hasil dari pemicu eksternal dan Config Connector mencoba merekonsiliasi permintaan penghapusan.

Untuk menentukan alasan penghapusan sumber daya, Anda perlu melihat permintaan penghapusan pertama yang dikirim ke resource yang sesuai. Tujuan cara terbaik untuk memeriksanya adalah dengan memeriksa log audit cluster Kubernetes.

Sebagai contoh, jika menggunakan GKE, Anda dapat menggunakan Cloud Logging untuk membuat kueri Log audit cluster GKE. Misalnya, jika Anda ingin melihat untuk permintaan penghapusan awal bagi resource BigQueryDataset bernama foo di namespace bar, Anda akan menjalankan kueri seperti berikut ini:

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

Dengan menggunakan kueri ini, Anda akan mencari permintaan penghapusan pertama dan kemudian memeriksa authenticationInfo.principalEmail pesan log hapus tersebut untuk menentukan penyebab penghapusan.

Pod Pengontrol OOMKilled

Jika Anda melihat error OOMKilled pada Pod pengontrol Config Connector, hal ini menunjukkan bahwa sebuah container atau seluruh Pod dihentikan karena menggunakan memori lebih dari yang diizinkan. Verifikasi ini dapat diverifikasi dengan menjalankan perintah kubectl explain. Status Pod dapat muncul sebagai OOMKilled atau Terminating. Selain itu, memeriksa log aktivitas Pod dapat mengungkapkan kejadian apa pun yang terkait dengan OOM.

kubectl describe pod POD_NAME -n cnrm-system

Ganti POD_NAME dengan Pod yang sedang dipecahkan masalahnya.

Untuk mengatasi masalah ini, Anda dapat menggunakan resource kustom ControllerResource untuk meningkatkan permintaan memori dan memori untuk Pod.

PodSecurityPolicy mencegah upgrade

Sesudah beralih dari add-on Config Connector ke penginstalan manual dan mengupgrade Config Connector ke versi baru, penggunaan PodSecurityPolicies dapat mencegah Pod cnrm diupdate.

Untuk mengonfirmasi bahwa PodSecurityPolicies mencegah upgrade Anda, memeriksa peristiwa config-connector-operator lalu cari error yang mirip dengan yang berikut ini:

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

Untuk mengatasi masalah ini, Anda harus menentukan anotasi pada PodSecurityPolicy sesuai dengan anotasi yang disebutkan dalam error. Di kolom contoh sebelumnya, anotasinya adalah seccomp.security.alpha.kubernetes.io.

Pembersihan paksa

Jika resource Config Connector macet saat penghapusan dan Anda hanya ingin menghapusnya dari cluster Kubernetes, Anda dapat memaksa penghapusannya dengan menghapus finalizer.

Peringatan: Operasi ini harus dilakukan sebagai upaya terakhir karena penghapusan finaler berada di luar batas penggunaan normal untuk Config Connector dan dapat memiliki konsekuensi yang tidak diharapkan. Khususnya, tidak ada jaminan mengenai terjadi pada resource Google Cloud yang mendasarinya.

Anda dapat menghapus finaler resource dengan mengedit resource menggunakan kubectl edit, menghapus kolom metadata.finalizers, lalu menyimpan file ke menyimpan perubahan pada Server Kubernetes API.

Karena menghapus finaler resource memungkinkan resource segera dihapus dari cluster Kubernetes, Config Connector mungkin (tetapi tidak tidak mendapatkan kesempatan untuk menyelesaikan penghapusan resource Google Cloud tertentu. Ini berarti bahwa Anda mungkin ingin menghapus secara manual resource Google Cloud Anda setelahnya.

Pemantauan

Metrik

Anda dapat menggunakan Prometheus untuk mengumpulkan dan menampilkan metrik dari Config Connector.

Logging

Semua output log terstruktur Pod Config Connector dalam format JSON.

Log Pod pengontrol terutama berguna untuk {i>debugging<i} masalah dengan rekonsiliasi sumber daya.

Anda dapat meminta log untuk resource tertentu dengan memfilter hal berikut dalam pesan log:

• logger: berisi jenis resource dalam huruf kecil. Misalnya, resource PubSubTopic memiliki logger dari pubsubtopic-controller.
• resource.namespace: berisi namespace resource.
• resource.name: berisi nama resource.

Menggunakan Cloud Logging untuk kueri log tingkat lanjut

Jika menggunakan GKE, Anda dapat menggunakan Cloud Logging untuk mengkueri log untuk resource tertentu dengan kueri berikut:

Catatan: Sintaksis kueri tidak mendukung komentar. Kueri berikut menggunakan sebuah konvensi pemberian komentar, # komentar, untuk memberikan teks penjelasan, tetapi komentar tidak dapat disertakan dalam kueri.

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

Ganti kode berikut:

• GKE_CLUSTER_NAME dengan nama cluster GKE yang menjalankan Config Connector
• GKE_CLUSTER_LOCATION dengan lokasi cluster GKE yang menjalankan Config Connector. Contoh, us-central1.
• RESOURCE_KIND dengan jenis resource dalam huruf kecil. Misalnya, pubsubtopic.
• RESOURCE_NAMESPACE dengan namespace resource.
• RESOURCE_NAME dengan nama resource.

Bantuan tambahan

Untuk mendapatkan bantuan tambahan, Anda dapat mengajukan masalah di GitHub atau hubungi Dukungan Google Cloud.