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 lakukan referensi silang pada catatan rilis untuk memastikan 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 mengetahui masalah pada resource Config Connector dengan memeriksa status resource di Kubernetes. Memeriksa status dan peristiwa resource sangat berguna untuk menentukan apakah Config Connector gagal merekonsiliasi resource dan penyebab rekonsiliasi gagal.

Memastikan Config Connector berjalan

Untuk memastikan bahwa Config Connector berjalan, pastikan semua Pod-nya adalah 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 telah menginstal Config Connector dalam mode namespace, Anda akan memiliki satu Pod pengontrol (cnrm-controller-manager) untuk setiap namespace yang bertanggung jawab mengelola resource Config Connector dalam 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 namespaced-mode, perintah sebelumnya akan menampilkan log gabungan dari semua Pod pengontrol. 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.

Masalah umum

Referensi 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 resource, sehingga menyebabkan Config Connector terus memperbarui resource.

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

Jika perilaku bukan disebabkan oleh sistem eksternal, periksa apakah Google Cloud mengubah nilai apa pun yang ditentukan dalam resource Config Connector Anda. Misalnya, dalam beberapa kasus, Google Cloud mengubah format (misalnya, kapitalisasi) nilai kolom yang menyebabkan perbedaan antara status yang diinginkan resource dan status sebenarnya.

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 Config Connector Anda agar cocok. Khususnya, cari nilai yang diformat ulang oleh Google Cloud. Misalnya, lihat masalah GitHub #578 dan #294.

Perlu diperhatikan bahwa ini bukan metode yang sempurna karena model resource Config Connector dan Google Cloud berbeda, tetapi metode ini dapat membantu Anda menangkap sebagian besar kasus perbedaan yang tidak diinginkan.

Jika Anda tidak dapat menyelesaikan masalah, lihat Bantuan tambahan.

Penghapusan namespace yang macet saat "Menghentikan"

Penghapusan namespace mungkin macet di Terminating jika Anda menginstal Config Connector di namespaced-mode dan jika ConfigConnectorContext namespace dihapus sebelum semua resource Config Connector dalam namespace tersebut dihapus. Saat ConfigConnectorContext namespace dihapus, Config Connector akan dinonaktifkan untuk namespace tersebut, sehingga semua 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 dasar secara manual setelahnya.

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

Lihat juga bagaimana menghapus namespace yang berisi Project dan turunannya atau Folder dan turunannya dapat terhenti.

Penghapusan resource yang terhenti 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 dihapus dari Kubernetes. Jangan menghapus seluruh namespace yang mungkin berisi resource Project dan resource Config Connector turunannya karena resource 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 itu 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 sudah ada.

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

Error 403: Permintaan tidak memiliki cakupan autentikasi yang memadai

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menunjukkan error 403 karena cakupan autentikasi yang tidak memadai, kemungkinan itu 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 namespace, serviceAccountName harusnya 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 ke resource Anda.

    Jika Anda melihat akun layanan default Compute Engine, berarti Workload Identity tidak diaktifkan di cluster GKE dan/atau node pool 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 yang diaktifkan.

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

403 Terlarang: Pemanggil tidak memiliki izin; lihat dokumentasi Workload Identity

Jika resource Config Connector Anda memiliki status UpdateFailed dengan pesan yang menunjukkan error 403 karena Workload Identity, kemungkinan itu berarti akun layanan Kubernetes Config Connector tidak memiliki izin IAM yang sesuai untuk meniru identitas akun layanan IAM Anda sebagai pengguna Workload Identity.

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 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 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, ada kemungkinan akun layanan IAM yang digunakan oleh Config Connector tidak memiliki izin IAM yang disebutkan 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 masih melihat error yang sama setelah memberikan izin IAM yang sesuai kepada akun layanan IAM Anda, pastikan bahwa resource Anda dibuat di project yang tepat. 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 merujuk ke 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 diaktifkan di cluster GKE Anda atau tidak.

Untuk mengurangi masalah ini pada 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 cluster yang valid, 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 atau GKE Monitoring 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 saat penerimaan.

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

Artinya, alat yang terus-menerus menerapkan ulang resource (misalnya, GitOps) mungkin akan terhenti saat mengupdate resource jika tidak menangani error penerimaan.

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

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

Anda mungkin melihat error berikut pada status resource Config Connector segera setelah membuat atau mendapatkan 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)

Ini mungkin bukan berarti Anda telah memperbarui resource, tetapi alasannya mungkin karena Google Cloud API telah membuat perubahan pada kolom yang tidak dapat diubah yang Anda kelola 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 langsung. Untuk mencapainya, Anda harus menyelesaikan langkah-langkah berikut:

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

Resource tidak memiliki status

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

Tidak ada kecocokan untuk jenis "Foo"

Jika error ini terjadi, artinya cluster Kubernetes Anda tidak memiliki CRD untuk jenis resource Foo yang terinstal.

Pastikan jenisnya adalah jenis resource yang didukung oleh Config Connector.

Jika jenisnya didukung, berarti penginstalan Config Connector Anda sudah usang 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 mengetahui jenis resource yang didukung oleh versi Config Connector mana (misalnya, berikut 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 keduanya mendukung label.

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

Jika 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

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, berarti 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 dalam metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: [email protected]
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 "[email protected]" is invalid: metadata.name: Invalid value: "[email protected]": 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 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: [email protected]

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 mengupdate file .yaml resource dan menerapkannya kembali, atau menggunakan kubectl edit untuk mengedit spesifikasi resource) tidak akan 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.

Jika Anda ingin mengubah nilai kolom menjadi kosong atau default di resource Google Cloud yang mendasarinya, Anda harus meniadakan kolom tersebut dalam 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: "[email protected]"
        - external: "[email protected]"
    

    Untuk menghapus kolom ini, setel nilai ke kosong:

    spec:
      targetServiceAccounts: []
    
  • Untuk kolom jenis primitif, setel kolom ke kosong menggunakan salah satu opsi 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, setel 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: syncer memperbarui resource secara berlebihan

Jika Anda menggunakan Config Sync dan melihat error KNV2005 untuk resource Config Connector, ada 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 disebut sebagai "bertentangan" atas suatu resource jika keduanya terus memperbarui kolom yang sama dengan nilai yang berbeda. Update salah satunya memicu yang lain untuk bertindak dan mengupdate resource, yang menyebabkan resource satunya bertindak dan mengupdate resource, dan seterusnya.

Perkelahian tidak menjadi masalah di sebagian besar bidang. Kolom yang ditentukan dalam Config Sync tidak diubah oleh Config Connector, sedangkan kolom yang tidak ditentukan dalam 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 default subkolom dalam kolom objek, Config Connector juga dapat menjadi subkolom default dalam objek di dalam daftar. Namun, karena kolom daftar di resource Config Connector bersifat atomik, penetapan default subkolom dianggap mengubah nilai daftar sepenuhnya.

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

Untuk mengatasi masalah ini, Anda memiliki opsi berikut:

  1. Perbarui manifes resource di repositori Config Sync agar sesuai dengan konfigurasi resource yang ingin ditetapkan ke resource tersebut.

    Salah satu cara untuk melakukannya adalah dengan menghentikan sinkronisasi konfigurasi untuk sementara, menunggu Config Connector menyelesaikan rekonsiliasi resource, lalu memperbarui manifes resource agar sesuai dengan resource di Server Kubernetes API.

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

  3. Hentikan Config Connector 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 mendukung anotasi, periksa halaman referensi resource yang sesuai. Baca selengkapnya tentang anotasi.

failed calling webhook

Mungkin saja Config Connector berada dalam status sehingga Anda tidak dapat 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 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

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

Memperbarui error 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. Hal 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 yang terkait. Untuk IAMPolicyMember, hapus seluruh resource. Untuk IAMPolicy dan IAMParitialPolicy, hanya hapus binding yang melibatkan akun layanan yang dihapus. Namun, pembersihan tersebut tidak akan langsung menghapus binding peran Google Cloud. Binding peran Google Cloud dipertahankan selama 60 hari karena retensi pada akun layanan yang dihapus. Untuk informasi selengkapnya, lihat dokumentasi Google Cloud IAM tentang Menghapus akun layanan.

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

Resource dihapus oleh Config Connector

Config Connector tidak pernah menghapus resource 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 yang umum terjadi 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 container atau log audit cluster Kubernetes. Permintaan penghapusan ini adalah hasil dari pemicu eksternal dan Config Connector mencoba merekonsiliasi permintaan penghapusan.

Untuk mengetahui alasan penghapusan resource, Anda harus melihat permintaan penghapusan pertama yang dikirim ke resource terkait. Cara terbaik untuk memeriksanya adalah dengan memeriksa log audit cluster Kubernetes.

Misalnya, jika menggunakan GKE, Anda dapat menggunakan Cloud Logging untuk membuat kueri untuk log audit cluster GKE. Misalnya, jika Anda ingin mencari permintaan penghapusan awal untuk resource BigQueryDataset yang bernama foo di namespace bar, Anda perlu 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 menggunakan kueri ini, Anda akan mencari permintaan penghapusan pertama, lalu memeriksa authenticationInfo.principalEmail dari pesan log penghapusan tersebut untuk menentukan penyebab penghapusan.

Pod Pengontrol OOMKilled

Jika Anda melihat error OOMKilled pada Pod pengontrol Config Connector, ini menunjukkan bahwa container atau seluruh Pod telah dihentikan karena menggunakan memori lebih banyak daripada yang diizinkan. Hal ini dapat diverifikasi dengan menjalankan perintah kubectldescribe. Status Pod dapat muncul sebagai OOMKilled atau Terminating. Selain itu, meneliti log peristiwa Pod dapat mengungkapkan setiap kejadian 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 membuat Pod cnrm tidak bisa diupdate.

Untuk mengonfirmasi bahwa PodSecurityPolicies mencegah upgrade Anda, periksa peristiwa config-connector-operator dan 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 di PodSecurityPolicy yang sesuai dengan anotasi yang disebutkan dalam error. Pada contoh sebelumnya, anotasinya adalah seccomp.security.alpha.kubernetes.io.

Pembersihan paksa

Jika resource Config Connector Anda terhenti saat dihapus dan Anda hanya ingin mengeluarkannya dari cluster Kubernetes, Anda dapat memaksa penghapusan tersebut dengan menghapus finalizer.

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

Karena dengan menghapus finalr resource, resource dapat langsung dihapus dari cluster Kubernetes, sehingga Config Connector mungkin (tetapi tidak harus) tidak memiliki kesempatan untuk menyelesaikan penghapusan resource Google Cloud yang mendasarinya. Artinya, setelah itu Anda mungkin ingin menghapus resource Google Cloud secara manual.

Pemantauan

Regresi

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

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 bernilai pubsubtopic-controller.
  • resource.namespace: berisi namespace resource.
  • resource.name: berisi nama resource.

Menggunakan Cloud Logging untuk pembuatan kueri log lanjutan

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

# 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 menghubungi Dukungan Google Cloud.