Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Jenis pengontrol Config Connector

Config Connector menggunakan arsitektur berlapis untuk merekonsiliasi resource di Google Cloud lingkungan Anda dengan spesifikasi Kubernetes Anda. Pengontrol induk tingkat atas merutekan rekonsiliasi setiap resource ke salah satu dari empat implementasi pengontrol yang mendasarinya.

Memahami setiap jenis pengontrol, perbedaan teknisnya, dan cara mengontrol perutean di seluruh namespace dapat membantu Anda mengoptimalkan performa dan memecahkan masalah konfigurasi.

Jenis pengontrol yang mendasarinya

Config Connector menggunakan jenis pengontrol berikut:

Pengontrol langsung: Pengontrol ini menggunakan library controller-runtime Kubernetes standar dan berkomunikasi dengan Google Cloud API secara langsung menggunakan Go SDK Google Cloud resmi. Sebaiknya gunakan pengontrol langsung jika memungkinkan. Tidak semua resource mendukung pengontrol langsung. Resource baru menggunakan pengontrol langsung secara default. Resource yang ada dimigrasikan secara berkala. Untuk mengetahui informasi selengkapnya, lihat catatan rilis.
Pengontrol berbasis Terraform (TF): Pengontrol ini bertindak sebagai "wrapper" untuk Terraform Google Provider. Pengontrol menerjemahkan spesifikasi Model Resource Kubernetes (KRM) ke dalam status yang kompatibel dengan Terraform dan mengimplementasikan operasi Terraform plan dan apply.
Pengontrol berbasis DCL: Jenis pengontrol ini bertindak sebagai "wrapper" untuk Google Cloud Declarative Client Library (DCL).
Pengontrol khusus IAM: Pengontrol ini adalah pengontrol khusus yang dirancang khusus untuk mengelola resource Identity and Access Management (IAM), termasuk IAMPolicy, IAMPartialPolicy, IAMPolicyMember, dan IAMAuditConfig. Beberapa resource IAM secara opsional mendukung pengontrol langsung.

Manfaat pengontrol langsung

Beberapa jenis resource mendukung beberapa jenis pengontrol. Jika resource mendukung pengontrol langsung, sebaiknya gunakan pengontrol langsung, bukan jenis pengontrol lain, karena alasan berikut:

Pengurangan konsumsi resource: Pengontrol langsung tidak memiliki overhead CPU dan memori yang terkait dengan menjalankan dan menerjemahkan status berbasis Terraform atau berbasis DCL.
Latensi rekonsiliasi yang ditingkatkan: Pengontrol langsung dapat melakukan operasi langsung terhadap endpoint, sehingga mengurangi waktu rata-rata yang diperlukan untuk mencapai konsistensi status resource. Google Cloud
Status terperinci dan perbedaan terstruktur: Pengontrol langsung menyediakan pelaporan perbedaan terstruktur dalam log cnrm-controller-manager. Log ini berisi perubahan kolom yang tepat yang memicu error seperti loop rekonsiliasi, yang dapat membantu mempermudah pemecahan masalah.
Status yang diamati secara native: Pengontrol langsung mengisi status.observedState dalam status resource, sehingga memberikan tampilan sisi server yang transparan dari kolom resource yang ditampilkan langsung oleh Google Cloud API.
Penanganan siklus proses yang ditingkatkan: Pengontrol langsung menyertakan fitur tambahan seperti penghapusan orphan yang lancar.

Pengontrol perutean induk

Terlepas dari jenis resource, Config Connector mencegat semua permintaan rekonsiliasi dalam pengontrol induk pusat. Pengontrol induk bertindak sebagai perute, yang mengevaluasi logika turunan mana yang menangani sinkronisasi aktif menggunakan aturan prioritas berikut:

Penggantian namespace: Pengontrol induk pertama-tama memeriksa konfigurasi resource ConfigConnectorContext di namespace resource target untuk penggantian pengontrol eksplisit.
Default statis: Jika tidak ada penggantian lokal yang ditentukan, pengontrol induk akan menggunakan rekonsiliasi waktu build yang ditentukan dalam konfigurasi pemetaan statis Config Connector.

Mengidentifikasi pengontrol untuk resource

Anda dapat menentukan jenis pengontrol yang dikonfigurasi atau aktif untuk Google Cloud resource tertentu menggunakan pemetaan kode aktif atau memeriksa struktur CustomResourceDefinition (CRD) di Google Kubernetes Engine (GKE).

Untuk mencari konfigurasi statis untuk resource, periksa resource di GitHub di pkg/controller/resourceconfig/static_config.go, dan cari blok konfigurasi untuk resource, seperti contoh berikut:

{Group: "alloydb.cnrm.cloud.google.com", Kind: "AlloyDBCluster"}: {
    DefaultController:    k8s.ReconcilerTypeTerraform,
    SupportedControllers: []k8s.ReconcilerType{k8s.ReconcilerTypeDirect, k8s.ReconcilerTypeTerraform},
}

DefaultController: Menunjukkan rekonsiliasi default yang digunakan jika tidak ada aturan penggantian konteks tingkat namespace yang ditentukan.
SupportedControllers: Mencantumkan semua rekonsiliasi yang diimplementasikan dan tersedia untuk resource ini. Penggantian beralih ke rekonsiliasi yang tercantum di sini.

Untuk memeriksa label CRD, gunakan perintah kubectl get crd:

kubectl get crd RESOURCE_NAME -o jsonpath='{.metadata.labels}'

Ganti RESOURCE_NAME dengan nama CRD Config Connector yang tepat, misalnya, bigquerydatasets.bigquery.cnrm.cloud.google.com.

Periksa hasil untuk mengetahui informasi berikut:

cnrm.cloud.google.com/tf2crd: "true": Pengontrol berbasis Terraform (TF) mengelola resource.
cnrm.cloud.google.com/dcl2crd: "true": Pengontrol berbasis DCL mengelola resource.
Tidak adanya label ini: Pengontrol langsung mengelola resource.

Mengganti pengontrol default

Ada dua metode utama untuk mengganti jenis pengontrol di Config Connector. Perbedaan di antara keduanya terutama melibatkan cakupan operasional, overhead pemeliharaan, dan prioritas yang mereka ambil selama rekonsiliasi.

Tabel berikut merangkum perbedaan antara kedua pendekatan tersebut:

Fitur	Anotasi resource	Penggantian ConfigConnectorContext
Cakupan	Instance resource tunggal	Semua resource dari jenis dalam namespace
Prioritas	Tertinggi (mengganti ConfigConnectorContext)	Sedang (mengganti default statis)
Direkomendasikan?	Tidak	Ya
Paling cocok untuk	Pengujian satu kali	Peluncuran di seluruh tim atau project

Mengganti pengontrol untuk resource tertentu

Anda dapat memaksa instance resource tertentu untuk berjalan dengan rekonsiliasi tertentu dengan menambahkan anotasi alpha.cnrm.cloud.google.com/reconciler ke metadata resource. Meskipun pendekatan ini tidak direkomendasikan karena alasan yang ditentukan di bagian sebelumnya, Anda mungkin memerlukannya untuk menguji konfigurasi untuk satu instance resource atau untuk mempertahankan konfigurasi lama.

apiVersion: bigquery.cnrm.cloud.google.com/v1beta1
kind: BigQueryDataset
metadata:
  name: my-bq-ds
  namespace: NAMESPACE_NAME
  annotations:
    alpha.cnrm.cloud.google.com/reconciler: direct
spec:
  ...

Nilai yang didukung untuk anotasi adalah direct, tf, atau dcl.

Mengganti pengontrol untuk namespace

Untuk mengonfigurasi penggantian di seluruh namespace menggunakan resource kustom ConfigConnectorContext, selesaikan langkah-langkah berikut:

Ambil nama dan grup dari definisi resource. Misalnya, untuk resource BigQueryDataset, jenis resource adalah BigQueryDataset dan grupnya adalah bigquery.cnrm.cloud.google.com.
Edit objek ConfigConnectorContext di dalam namespace yang berisi resource terkelola Anda:
```
kubectl edit configconnectorcontext configconnectorcontext.core.cnrm.cloud.google.com -n NAMESPACE_NAME
```
Ganti NAMESPACE_NAME dengan namespace target Anda.

Tambahkan penggantian target Anda. Misalnya, untuk mengganti semua instance BigQueryDataset di namespace ini agar berjalan dengan pengontrol langsung, tentukan konfigurasi sebagai berikut:

apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: NAMESPACE_NAME
spec:
  googleServiceAccount: "kcc-sa@my-project.iam.gserviceaccount.com"
  experiments:
    controllerOverrides:
      BigQueryDataset.bigquery.cnrm.cloud.google.com: direct

Simpan dan terapkan resource. Pengontrol induk secara otomatis menerapkan aturan perutean rekonsiliasi langsung baru secara dinamis ke semua resource yang cocok di namespace ini.

Batasan dan kasus penggunaan penggantian namespace

Persyaratan dukungan eksplisit: Agar penggantian berhasil, jenis pengontrol target harus diimplementasikan untuk jenis resource. Untuk memeriksa apakah jenis pengontrol didukung, lihat Mengidentifikasi pengontrol untuk resource. Jika jenis pengontrol yang Anda tentukan dalam penggantian tidak didukung, pengontrol induk akan mengabaikan penggantian dan rekonsiliasi default akan terus menangani resource.
Batas namespace: Penggantian di bawah ConfigConnectorContext berlaku secara kolektif untuk semua instance dari jenis resource yang berada di dalam namespace tertentu tersebut. Anda tidak dapat menargetkan instance resource individual dengan penggantian yang memiliki cakupan namespace.
Kontrol akses: Mengupdate objek ConfigConnectorContext biasanya memerlukan hak istimewa tim platform tingkat yang lebih tinggi dibandingkan dengan pengeditan resource standar.
Pelaporan status penggantian: Jika jenis pengontrol yang tidak valid atau tidak didukung ditentukan dalam penggantian ConfigConnectorContext, pengontrol induk akan menandai konteks sebagai tidak sehat. Anda dapat memverifikasinya dengan menjalankan kubectl get configconnectorcontext configconnectorcontext.core.cnrm.cloud.google.com -n NAMESPACE_NAME -o yaml dan memeriksa kolom .status.healthy dan .status.errors.
Kapan harus digunakan: Ini adalah pendekatan yang direkomendasikan untuk mengganti pengontrol. Gunakan untuk mengaktifkan seluruh namespace ke pengontrol modern (seperti langsung) atau untuk menerapkan konsistensi arsitektur di seluruh project.