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 ini.

Teknik pemecahan masalah dasar

Memeriksa versi Config Connector

Jalankan perintah berikut untuk mendapatkan versi Config Connector yang diinstal, dan lakukan 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 di Kubernetes. Memeriksa status dan peristiwa resource sangat membantu untuk menentukan apakah Config Connector gagal merekonsiliasi resource dan alasan merekonsiliasi gagal.

Pastikan Konektor Konfigurasi sedang berjalan

Untuk memeriksa apakah Config Connector sedang berjalan, pastikan semua Pod-nya 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 Config Connector diinstal dalam mode namespace, Anda akan memiliki satu Pod pengontrol (cnrm-controller-manager) untuk setiap namespace yang bertanggung jawab mengelola resource Config Connector di namespace tersebut.

Anda dapat memeriksa status Pod pengontrol yang bertanggung jawab atas namespace tertentu 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 mencatat informasi dan error yang terkait dengan rekonsiliasi 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 telah menginstal Config Connector dalam mode namespace, perintah sebelumnya akan menampilkan 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 memperoleh resource

Dalam beberapa kasus, Anda mungkin perlu memperbarui kolom yang tidak dapat diubah dalam resource. Karena Anda tidak dapat mengedit kolom yang tidak dapat diubah, Anda harus melepaskan lalu memperoleh resource:

1. Update konfigurasi YAML resource Config Connector dan tetapkan anotasi cnrm.cloud.google.com/deletion-policy ke abandon.
2. Terapkan konfigurasi YAML yang diperbarui untuk memperbarui kebijakan penghapusan resource Config Connector.
3. Menghentikan resource Config Connector.
4. Perbarui kolom immutable yang perlu diubah dalam konfigurasi YAML.
5. Terapkan konfigurasi YAML yang telah diperbarui untuk mendapatkan resource yang ditinggalkan.

Masalah umum

Resource terus diperbarui setiap 5-15 menit

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

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

Jika perilaku tersebut bukan karena sistem eksternal, lihat apakah Google Cloud mengubah nilai apa pun yang ditentukan dalam resource Config Connector Anda. Misalnya, dalam beberapa kasus, Google Cloud mengubah format (misalnya, huruf besar) nilai kolom yang menyebabkan perbedaan antara status yang diinginkan dan status aktual resource Anda.

Dapatkan status resource Google Cloud menggunakan REST API (misalnya, untuk ContainerCluster) atau Google Cloud CLI. Kemudian, bandingkan status tersebut dengan resource Config Connector Anda. Cari kolom yang nilainya tidak cocok, lalu perbarui resource Konektor Konfigurasi agar cocok. Secara khusus, cari nilai apa pun yang diformat ulang oleh Google Cloud. Misalnya, lihat masalah GitHub #578 dan #294.

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

Jika Anda tidak dapat menyelesaikan masalah, lihat Bantuan tambahan.

Penghapusan namespace macet di "Terminating"

Penghapusan namespace mungkin macet di Terminating jika Anda telah menginstal Config Connector dalam mode namespace dan jika ConfigConnectorContext namespace dihapus sebelum semua resource Config Connector di namespace tersebut dihapus. Saat ConfigConnectorContext namespace dihapus, Config Connector akan dinonaktifkan untuk namespace tersebut, sehingga resource Config Connector yang tersisa di namespace tersebut tidak akan dihapus.

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

Untuk mengurangi masalah ini di masa mendatang, hanya hapus ConfigConnectorContext setelah semua resource Config Connector di namespace-nya telah dihapus dari Kubernetes. Hindari menghapus seluruh namespace sebelum semua resource Config Connector di namespace tersebut dihapus karena ConfigConnectorContext mungkin dihapus terlebih dahulu.

Lihat juga cara menghapus namespace yang berisi Project dan turunan-turunannya atau Folder dan turunan-turunannya dapat macet.

Penghapusan resource macet di "DeleteFailed" setelah project dihapus

Penghapusan resource Config Connector mungkin terhenti di DeleteFailed jika project Google Cloud-nya telah dihapus sebelumnya.

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

Untuk mengurangi masalah ini di masa mendatang, hanya hapus project Google Cloud setelah semua resource Config Connector turunannya telah dihapus dari Kubernetes. Hindari menghapus seluruh namespace yang mungkin berisi resource Project dan resource Config Connector turunannya karena resource Project mungkin 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, hal ini mungkin berarti 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 akun layanan IAM yang digunakan oleh Config Connector ada.

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

Error 403: Permintaan memiliki cakupan autentikasi yang tidak memadai

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menunjukkan error 403 karena cakupan autentikasi tidak memadai, hal itu mungkin berarti Workload Identity tidak diaktifkan di 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 menyelidikinya, 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 dengan namespace, serviceAccountName harus berupa 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 dengan resource Anda.

   Jika Anda melihat akun layanan default Compute Engine, artinya Workload Identity Federation untuk GKE tidak diaktifkan di cluster dan/atau node pool GKE Anda.

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

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

Untuk memperbaiki masalah ini, gunakan cluster GKE dengan Workload Identity Federation untuk GKE diaktifkan.

Jika Anda masih melihat error yang sama di cluster GKE dengan Workload Identity Federation untuk GKE diaktifkan, pastikan Anda tidak lupa untuk mengaktifkan Workload Identity Federation untuk GKE di node pool cluster. Baca selengkapnya tentang mengaktifkan Workload Identity Federation untuk GKE di node pool yang ada. Sebaiknya aktifkan Workload Identity Federation untuk GKE di semua kumpulan node cluster Anda karena Config Connector dapat berjalan di salah satu kumpulan node tersebut.

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

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menunjukkan error 403 karena Workload Identity Federation untuk GKE, hal ini mungkin berarti akun layanan Kubernetes Config Connector tidak memiliki izin IAM yang sesuai untuk meniru akun layanan IAM Anda sebagai pengguna Workload Identity Federation untuk 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 ini di masa mendatang, lihat petunjuk penginstalan Config Connector.

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, hal ini mungkin berarti bahwa 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 izin IAM yang sesuai kepada akun layanan IAM, periksa apakah resource Anda dibuat di project yang benar. Periksa kolom spec.projectRef resource Config Connector (atau anotasi cnrm.cloud.google.com/project-id-nya jika resource tidak mendukung kolom spec.projectRef) dan pastikan resource mereferensikan project 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 resource cakupan project.

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

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

Versi tidak didukung dalam penginstalan add-on Config Connector

Jika Anda tidak berhasil mengaktifkan add-on Config Connector, pesan error berikut akan muncul: Node version 1.15.x-gke.x s unsupported. Untuk mengatasi error ini, 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 error juga muncul jika Workload Identity Federation for GKE atau GKE Monitoring dinonaktifkan. Pastikan fitur ini diaktifkan untuk memperbaiki error.

Tidak dapat membuat perubahan pada kolom yang tidak dapat diubah

Config Connector menolak pembaruan pada kolom yang tidak dapat diubah saat diizinkan.

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

Artinya, alat yang terus-menerus menerapkan ulang resource (misalnya, GitOps) mungkin mengalami macet saat mengupdate resource jika tidak menangani error izin.

Karena Config Connector tidak mengizinkan pembaruan pada kolom yang tidak dapat diubah, satu-satunya cara untuk melakukan pembaruan tersebut adalah dengan menghapus dan membuat ulang resource.

Error saat memperbarui kolom yang tidak dapat diubah jika tidak ada pembaruan

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

• 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 benar-benar telah memperbarui resource, tetapi alasannya mungkin karena 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 cocok dengan status live. Untuk melakukannya, Anda harus menyelesaikan langkah-langkah berikut:

1. Perbarui konfigurasi YAML resource Config Connector dan tetapkan anotasi cnrm.cloud.google.com/deletion-policy ke abandon.
2. Terapkan konfigurasi YAML yang diperbarui untuk memperbarui kebijakan penghapusan resource Config Connector.
3. Menghapus resource Config Connector.
4. Cetak status aktif resource Google Cloud yang sesuai menggunakan gcloud CLI.
5. Temukan ketidakcocokan antara output gcloud CLI dan konfigurasi YAML resource Config Connector, lalu perbarui kolom tersebut di konfigurasi YAML.
6. Terapkan konfigurasi YAML yang telah diperbarui untuk mendapatkan resource yang ditinggalkan.

Resource tidak memiliki status

Jika resource Anda tidak memiliki kolom status, kemungkinan Config Connector tidak berjalan dengan benar. Pastikan Config Connector berjalan.

Tidak ada kecocokan untuk jenis "Foo"

Jika error ini muncul, artinya cluster Kubernetes Anda tidak menginstal CRD untuk jenis resource Foo.

Pastikan jenisnya adalah jenis resource yang didukung oleh Konektor Konfigurasi.

Jika jenis tersebut didukung, berarti penginstalan Config Connector Anda sudah tidak berlaku atau tidak valid.

Jika Anda menginstal Config Connector menggunakan add-on GKE, penginstalan Anda akan otomatis diupgrade. Jika menginstal Config Connector secara manual, Anda harus melakukan upgrade manual.

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 diterapkan ke resource Google Cloud

Config Connector menyebarkan label yang ditemukan di metadata.labels ke resource Google Cloud yang mendasarinya. Namun, perlu diperhatikan bahwa tidak semua resource Google Cloud mendukung label. Periksa dokumentasi REST API resource (misalnya, berikut adalah dokumentasi API untuk PubSubTopic) untuk melihat apakah resource tersebut mendukung label.

Gagal memanggil webhook x509: sertifikat mengandalkan kolom Common Name lama

Jika Anda melihat error yang mirip dengan contoh berikut, Anda mungkin mengalami masalah dengan 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 dengan Kubernetes versi 1.19 atau yang lebih baru dan Config Connector versi 1.43 dan yang lebih baru mendukung pembuatan otomatis sertifikat, yang akan mencegah Anda 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 ulang.

Untuk mengetahui 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 error yang mirip dengan contoh berikut, 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, resource SQLUser berikut 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 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 resource nama yang bukan nama Kubernetes yang valid, tetapi merupakan nama resource Google Cloud yang valid, Anda dapat menggunakan kolom resourceID seperti yang ditunjukkan dalam 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 menerapkan ulang, atau dengan menggunakan kubectl edit untuk mengedit spesifikasi resource) tidak benar-benar menghapus kolom tersebut dari spesifikasi resource Config Connector atau resource Google Cloud yang mendasarinya. Sebaliknya, menghapus kolom dari spesifikasi hanya akan membuat kolom tersebut dikelola secara eksternal.

Catatan: Ada satu pengecualian: kolom di dalam daftar. Daftar bersifat atomik, yang berarti Konektor Konfigurasi akan mencoba menetapkan daftar di Google Cloud yang mendasarinya agar setara dengan daftar yang ditentukan dalam spesifikasi.

Jika ingin mengubah nilai kolom menjadi kosong atau default di resource Google Cloud yang mendasarinya, 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 dari berikut:

  Jenis	Nilai kosong
  string	""
  bool	"false"
  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 menetapkan seluruh kolom jenis objek sebagai "NULL". Anda dapat mencoba menetapkan subkolom jenis objek sebagai kosong atau default dengan mengikuti panduan di atas dan memverifikasi apakah subkolom tersebut berfungsi.

KNV2005: sinkronisasi memperbarui resource secara berlebihan

Jika Anda menggunakan Config Sync dan melihat error KNV2005 untuk resource Config Connector, kemungkinan Config Sync dan Config Connector saling 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 "bertarung" untuk resource jika keduanya terus memperbarui kolom yang sama ke nilai yang berbeda. Update satu memicu update lainnya untuk bertindak dan memperbarui resource, yang menyebabkan update lainnya bertindak dan memperbarui resource, dan seterusnya.

Pertarungan tidak menjadi masalah bagi sebagian besar kolom. Kolom yang ditentukan di Config Sync tidak diubah oleh Config Connector, sedangkan kolom yang tidak ditentukan di Config Sync dan ditetapkan secara default oleh Config Connector akan diabaikan oleh Config Sync. Oleh karena itu, untuk sebagian besar kolom, Config Sync dan Config Connector tidak boleh memperbarui kolom yang sama ke nilai yang berbeda.

Ada satu pengecualian: kolom daftar. Serupa dengan cara Config Connector dapat menetapkan subkolom default di kolom objek, Config Connector juga dapat menetapkan subkolom default dalam objek di dalam daftar. Namun, karena kolom daftar dalam resource Config Connector bersifat atomik, penetapan subkolom secara default dianggap sebagai perubahan nilai daftar sepenuhnya.

Oleh karena itu, Config Sync dan Config Connector akan saling bertentangan jika Config Sync menetapkan kolom daftar dan Config Connector menetapkan subkolom default dalam daftar tersebut.

Untuk mengatasi masalah ini, Anda memiliki opsi berikut:

1. Perbarui manifes resource di repositori Config Sync agar cocok dengan yang coba ditetapkan oleh Config Connector.

   Salah satu cara untuk melakukannya adalah dengan berhenti menyinkronkan konfigurasi sementara, menunggu Config Connector selesai merekonsiliasi resource, lalu memperbarui manifes resource agar cocok dengan resource di Server API Kubernetes.

2. Hentikan Config Sync agar tidak bereaksi terhadap update pada resource di Server API Kubernetes dengan menetapkan anotasi client.lifecycle.config.k8s.io/mutation ke ignore. Baca selengkapnya tentang cara membuat Config Sync mengabaikan mutasi objek.

3. Hentikan Konektor Konfigurasi agar tidak memperbarui spesifikasi resource sepenuhnya dengan menetapkan anotasi cnrm.cloud.google.com/state-into-spec ke absent pada resource. Anotasi ini tidak didukung untuk semua resource. Untuk melihat apakah resource Anda mendukung anotasi, periksa halaman referensi resource yang sesuai. Baca selengkapnya tentang anotasi.

failed calling webhook

Config Connector mungkin berada dalam status yang tidak memungkinkan Anda meng-uninstal Config Connector. Hal ini biasanya terjadi saat menggunakan add-on Config Connector dan menonaktifkan Config Connector sebelum menghapus CRD Config Connector. Saat mencoba meng-uninstal, Anda menerima error yang mirip dengan berikut ini:

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

Kemudian, Anda dapat melanjutkan untuk meng-uninstal Config Connector.

Error update dengan IAMPolicy, IAMPartialPolicy, dan IAMPolicyMember

Jika Anda menghapus resource Config Connector IAMServiceAccount 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. Tindakan ini akan 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 dihapus. Jika akun layanan dihapus, bersihkan juga resource Config Connector IAM 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 langsung 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 pengelolaan konfigurasi seperti Argo CD, atau menggunakan klien API yang disesuaikan dapat menyebabkan penghapusan resource.

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

Untuk menentukan alasan resource dihapus, Anda perlu memeriksa permintaan penghapusan pertama yang dikirim ke resource yang sesuai. Cara terbaik untuk memeriksanya adalah dengan memeriksa log audit cluster Kubernetes.

Misalnya, jika menggunakan GKE, Anda dapat menggunakan Cloud Logging untuk membuat kueri terhadap log audit cluster GKE. Misalnya, jika ingin mencari permintaan penghapusan awal untuk resource BigQueryDataset bernama foo di namespace bar, Anda akan menjalankan kueri seperti berikut:

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 kueri ini, Anda akan mencari permintaan penghapusan pertama, lalu memeriksa authenticationInfo.principalEmail pesan log penghapusan tersebut untuk menentukan penyebab penghapusan.

Pod Pengontrol OOMKilled

Jika Anda melihat error OOMKilled di Pod pengontrol Config Connector, hal ini menunjukkan bahwa container atau seluruh Pod dihentikan karena menggunakan lebih banyak memori daripada yang diizinkan. Hal ini dapat diverifikasi dengan menjalankan perintah kubectl describe. Status Pod dapat muncul sebagai OOMKilled atau Terminating. Selain itu, memeriksa log aktivitas Pod dapat mengungkapkan terjadinya peristiwa terkait OOM.

kubectl describe pod POD_NAME -n cnrm-system

Ganti POD_NAME dengan Pod yang sedang Anda pecahkan masalahnya.

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

PodSecurityPolicy mencegah upgrade

Setelah 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, periksa peristiwa config-connector-operator dan cari error yang mirip dengan berikut:

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 yang sesuai dengan anotasi yang disebutkan dalam error. Pada contoh sebelumnya, anotasi adalah seccomp.security.alpha.kubernetes.io.

Pembersihan paksa

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

Peringatan: Operasi ini harus dilakukan sebagai upaya terakhir karena penghapusan finalizer berada di luar batas penggunaan normal untuk Config Connector dan dapat memiliki konsekuensi yang tidak diinginkan. Secara khusus, tidak ada jaminan terkait hal yang terjadi pada resource Google Cloud yang mendasarinya.

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

Karena menghapus finalizer resource memungkinkan resource segera dihapus dari cluster Kubernetes, Config Connector mungkin (tetapi tidak harus) tidak mendapatkan kesempatan untuk menyelesaikan penghapusan resource Google Cloud yang mendasarinya. Artinya, Anda mungkin ingin menghapus resource Google Cloud secara manual setelahnya.

Pemantauan

Metrik

Anda dapat menggunakan Prometheus untuk mengumpulkan dan menampilkan metrik dari Konektor Konfigurasi.

Logging

Semua Pod Config Connector menghasilkan log terstruktur dalam format JSON.

Log Pod pengontrol sangat berguna untuk men-debug masalah terkait rekonsiliasi resource.

Anda dapat membuat kueri log untuk resource tertentu dengan memfilter kolom berikut dalam pesan log:

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

Menggunakan Cloud Logging untuk kueri log lanjutan

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

Catatan: Sintaksis kueri tidak mendukung komentar. Kueri berikut menggunakan konvensi komentar, # comment, untuk memberikan teks penjelasan, tetapi komentar ini 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 melaporkan masalah di GitHub atau menghubungi Dukungan Google Cloud.