Arsitektur Config Sync

Halaman ini memperkenalkan arsitektur Config Sync, termasuk komponen yang dihosting yang berjalan di Google Cloud dan komponen open source yang berjalan di cluster Google Kubernetes Engine Anda. Mempelajari arsitektur ini dapat memberi Anda pemahaman yang lebih mendalam tentang Config Sync dan dapat membantu Anda men-debug dan memperbaiki masalah yang Anda temui.

Bagian berikut menunjukkan arsitektur Config Sync, termasuk komponen dan dependensinya, baik di Google Cloud maupun di cluster GKE Anda:

Diagram yang menunjukkan hubungan antara objek dan resource Config Sync

Layanan Fleet mengelola komponen Config Sync di cluster Anda secara langsung, tanpa ConfigManagement Operator lama atau objek ConfigManagement. Anda harus mengupgrade Config Sync secara manual sesuai kebutuhan.

Ada beberapa langkah untuk menginstal Config Sync dan setiap langkah ini men-deploy komponen tambahan di cluster Anda:

  1. Mengaktifkan Config Sync di cluster Anda akan menambahkan komponen berikut:

    • Definisi resource kustom (CRD) ConfigSync
    • Objek ConfigSync bernama config-sync.
    • Pengelola Reconciler dalam Deployment bernama reconciler-manager.
    • Pengontrol ResourceGroup dalam Deployment bernama resource-group-controller-manager.
    • OpenTelemetry Collector dalam Deployment bernama otel-collector.
    • Opsional: Webhook penerimaan Config Sync dalam Deployment bernama admission-webhook. Webhook penerimaan Config Sync hanya diinstal jika Anda mengaktifkan pencegahan penyimpangan.

    Resource dan objek ini dibuat secara otomatis saat Anda menginstal Config Sync dan tidak boleh diubah secara langsung.

  2. Membuat objek RootSync dan RepoSync akan menambahkan komponen berikut:

    • Untuk setiap RootSync objek, Deployment reconciler bernama root-reconciler-ROOTSYNC_NAME. Untuk objek RootSync bernama root-sync, Deployment reconciler diberi nama root-reconciler.

    • Untuk setiap objek RepoSync, Deployment reconciler bernama ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Untuk objek RepoSync bernama repo-sync, Deployment reconciler diberi nama ns-reconciler-REPOSYNC_NAMESPACE.

Deployment, Pod, dan container Config Sync

Tabel berikut memberikan informasi selengkapnya tentang Deployment, Pod, dan container Config Sync:

Nama Deployment Namespace Deployment Deskripsi Deployment Jumlah replika Ekspresi reguler nama Pod Jumlah container Nama container
reconciler-manager config-management-system Pengelola Reconciler berjalan di setiap cluster dengan Config Sync diaktifkan dalam objek ConfigManagement. Pengelola Reconciler memantau RootSync dan RepoSync objek, serta mengelola Deployment reconciler untuk setiap objek. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Deployment reconciler root dibuat untuk setiap objek RootSync. 1 root-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler-.* config-management-system Deployment reconciler namespace dibuat untuk setiap objek RepoSync. 1 ns-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    otel-collector config-management-monitoring OpenTelemetry Collector berjalan di setiap cluster dengan Config Sync yang diaktifkan dalam objek ConfigManagement. OpenTelemetry Collector mengumpulkan metrik dari komponen Config Sync yang berjalan di bawah config-management-system dan resource-group-system namespace, serta mengekspor metrik ini ke Prometheus dan Cloud Monitoring. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system Pengontrol ResourceGroup berjalan di setiap cluster dengan Config Sync diaktifkan dalam objek ConfigManagement. Pengontrol ResourceGroup memantau ResourceGroup objek dan memperbaruinya dengan status rekonsiliasi saat ini dari setiap objek dalam inventarisnya. Objek ResourceGroup dibuat untuk setiap RootSync dan RepoSync guna menginventaris daftar objek yang diterapkan oleh reconciler dari sumber tepercaya. 1 resource-group-controller-manager-.* 2
  • manager
  • otel-agent
    		•
    admission-webhook config-management-system Webhook Penerimaan Config Sync berjalan di setiap cluster dengan pencegahan penyimpangan yang diaktifkan dalam objek ConfigManagement. Webhook Penerimaan Config Sync memantau permintaan Kubernetes API dan mencegah modifikasi atau penghapusan resource yang dikelola oleh Config Sync. Webhook penerimaan Config Sync webhook dinonaktifkan secara default. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 Untuk mengetahui detail tentang kapan container ini dibuat, lihat Container reconciler.

    Permintaan resource Deployment

    Tabel berikut mencantumkan persyaratan resource Kubernetes untuk komponen Config Sync. Untuk mengetahui informasi selengkapnya, lihat Pengelolaan Resource untuk Pod dan Container dalam dokumentasi Kubernetes.

    Permintaan resource sama untuk semua versi Config Sync yang didukung.

    Nama Deployment Permintaan CPU (m) per replika Permintaan memori (Mi) per replika
    config-management-operator 100 200
    resource-group-controller-manager 110 300
    admission-webhook1 10 100
    otel-collector 200 400
    reconciler-manager 20 150
    reconciler (satu per RootSync dan RepoSync) Lihat permintaan resource reconciler untuk mengetahui detailnya.

    1 Webhook penerimaan memiliki dua replika. Jika Anda menggunakan webhook penerimaan dan perlu menghitung total permintaan resource, gandakan nilainya. Webhook penerimaan dinonaktifkan secara default.

    Komponen utama

    Bagian berikut membahas komponen Config Sync penting secara lebih mendetail.

    Layanan Fleet dan objek ConfigSync

    Layanan Fleet Hub mengelola komponen Config Sync di cluster Anda:

    Pengelolaan Config Sync

    Layanan Fleet juga mengelola objek ConfigSync di cluster Anda. Layanan Fleet memperbarui spesifikasi objek ConfigSync berdasarkan input Anda ke API dan statusnya untuk mencerminkan status komponen Config Sync. Google Cloud

    Untuk membuat perubahan pada konfigurasi penginstalan Config Sync, Anda harus menggunakan Google Cloud API. Namun, Anda dapat menggunakan Google Cloud API atau Kubernetes API untuk memantau konfigurasi dan kesehatan penginstalan Config Sync.

    Pengelola Reconciler dan reconciler

    Pengelola Reconciler bertanggung jawab untuk membuat dan mengelola reconciler individual yang memastikan konfigurasi cluster Anda tetap sinkron.

    Pengelola Reconciler membuat reconciler root untuk setiap objek RootSync dan reconciler namespace untuk setiap objek RepoSync. Config Sync menggunakan desain ini, bukan berbagi satu reconciler monolitik karena meningkatkan keandalan dengan mengurangi titik tunggal kegagalan dan memungkinkan reconciler individual diskalakan secara independen.

    Reconciler root dan namespace secara otomatis mengambil konfigurasi dari sumber tepercaya Anda dan menerapkannya untuk menerapkan status yang Anda inginkan dalam cluster Anda.

    Diagram berikut menunjukkan cara Pengelola Reconciler menangani kontrol siklus proses setiap reconciler root dan reconciler namespace:

    Diagram yang menunjukkan cara Pengelola Rekonsiliasi mengontrol rekonsiliasi root Diagram yang menunjukkan cara Reconciler Manager mengontrol namespace reconciler

    Container reconciler

    Container tertentu yang di-deploy di Pod reconciler bergantung pada pilihan konfigurasi yang Anda buat. Tabel berikut menjelaskan lebih lanjut tentang fungsi setiap container reconciler ini dan kondisi yang menyebabkan Config Sync membuatnya:

    Nama container Deskripsi Kondisi
    reconciler Menangani sinkronisasi dan perbaikan penyimpangan. Selalu diaktifkan.
    otel-agent Menerima metrik dari container reconciler lainnya dan mengirimkannya ke OpenTelemetry Collector. Selalu diaktifkan.
    git-sync Mengambil konfigurasi dari repositori Git Anda ke direktori lokal yang dapat dibaca oleh container reconciler. Diaktifkan saat spec.sourceType adalah git.
    helm-sync Mengambil dan merender chart Helm dari repositori chart Anda ke direktori lokal direktori yang dapat dibaca oleh container reconciler. Diaktifkan saat spec.sourceType adalah helm.
    oci-sync Mengambil image OCI yang berisi konfigurasi Anda dari container registry ke a direktori lokal yang dapat dibaca oleh container reconciler. Diaktifkan saat spec.sourceType adalah oci.
    gcenode-askpass-sidecar Menyimpan kredensial Git dalam cache dari layanan metadata GKE untuk digunakan oleh container git-sync. Diaktifkan saat spec.sourceType adalah git dan spec.git.auth adalah gcenode atau gcpserviceaccount.
    hydration-controller Menangani pembuatan konfigurasi Kustomize ke direktori lokal yang dapat dibaca oleh container reconciler. Diaktifkan saat sumber menyertakan file kustomize.yaml.

    Seperti yang ditunjukkan dalam tabel sebelumnya, Anda biasanya dapat mengharapkan jumlah container tiga hingga lima dalam setiap Pod reconciler. Container reconciler dan otel-agent selalu ada. Menentukan jenis untuk sumber tepercaya Anda akan menentukan container sinkronisasi mana yang ditambahkan. Selain itu, container hydration-controller dan gcenode-askpass-sidecar dibuat jika Anda melakukan perubahan konfigurasi yang disebutkan dalam tabel.

    Permintaan resource reconciler

    Untuk setiap objek RootSync dan RepoSync, Config Sync membuat deployment reconciler independen untuk menangani sinkronisasi. Deployment reconciler terdiri dari beberapa container. Untuk mengetahui informasi selengkapnya tentang container ini, lihat Container reconciler.

    Permintaan resource sama untuk semua versi Config Sync yang didukung.

    Tabel berikut mencantumkan permintaan resource untuk cluster Standard:

    Nama container Permintaan CPU (m) Permintaan memori (Mi)
    reconciler 50 200
    otel-agent 10 100
    hydration-controller (Opsional) 10 100
    git-sync 10 16
    gcenode-askpass-sidecar (Opsional) 10 20
    helm-sync 75 128
    oci-sync 25 32

    Tabel berikut mencantumkan permintaan resource untuk cluster Autopilot:

    Nama container Permintaan dan batas CPU (m) Permintaan dan batas memori (Mi)
    reconciler 700 512
    otel-agent 10 64
    hydration-controller (Opsional) 200 256
    git-sync 20 32
    gcenode-askpass-sidecar (Opsional) 50 64
    helm-sync 250 384
    oci-sync 50 64

    Untuk mengetahui informasi selengkapnya tentang cara mengganti permintaan dan batas resource default, lihat Mengganti permintaan dan resource.

    Versi Helm dan Kustomize yang dibundel

    Config Sync memanfaatkan executable Helm dan Kustomize untuk merender konfigurasi. Untuk menemukan versi Helm dan Kustomize yang dibundel untuk versi Config Sync Anda, lihat kolom HELM_VERSION dan KUSTOMIZE_VERSION di Makefile repositori open source Config Sync. Anda dapat beralih antar-cabang di GitHub untuk melihat versi untuk rilis Config Sync yang berbeda.

    Untuk mengetahui informasi tentang cara merender Helm melalui Kustomize, lihat Mengonfigurasi Kubernetes dengan Kustomize. Untuk mengetahui informasi tentang cara menggunakan Helm API, lihat Menyinkronkan chart Helm dari Artifact Registry.

    Pengontrol ResourceGroup dan objek ResourceGroup

    Reconciler root dan namespace membuat objek inventaris ResourceGroup untuk setiap objek RootSync dan RepoSync yang Anda siapkan. Setiap objek ResourceGroup berisi daftar objek yang disinkronkan ke cluster dari sumber tepercaya oleh reconciler untuk objek RootSync atau RepoSync tersebut. Pengontrol ResourceGroup kemudian memantau semua objek dalam objek ResourceGroup dan memperbarui status objek ResourceGroup dengan status rekonsiliasi saat ini dari objek yang disinkronkan. Hal ini memungkinkan Anda memeriksa status ResourceGroup objek untuk mendapatkan ringkasan status sinkronisasi, tanpa harus membuat kueri status setiap objek secara manual.

    Objek ResourceGroup memiliki nama dan namespace yang sama dengan objek RootSync atau RepoSync yang sesuai. Misalnya, untuk objek RootSync dengan nama root-sync di namespace config-management-system, objek ResourceGroup yang sesuai juga diberi nama root-sync di namespace config-management-system.

    Jangan membuat atau mengubah objek ResourceGroup, karena hal ini dapat mengganggu operasi Config Sync.

    Webhook Penerimaan

    Webhook Penerimaan Config Sync dibuat saat Anda mengaktifkan pencegahan penyimpangan. Pencegahan penyimpangan secara proaktif mencegat permintaan modifikasi, sehingga memastikan permintaan tersebut selaras dengan sumber tepercaya sebelum mengizinkan perubahan.

    Jika Anda tidak mengaktifkan pencegahan penyimpangan, Config Sync akan tetap menggunakan mekanisme pemulihan otomatis untuk memulihkan penyimpangan konfigurasi. Dengan pemulihan otomatis, Config Sync terus memantau objek terkelola dan secara otomatis membatalkan perubahan yang menyimpang dari status yang diinginkan.

    Objek RootSync dan RepoSync

    Objek RootSync mengonfigurasi Config Sync untuk membuat reconciler root yang memantau sumber tepercaya yang ditentukan dan menerapkan objek dari sumber tersebut ke cluster. Secara default, reconciler root untuk setiap objek RootSync memiliki izin cluster-admin. Dengan izin default ini, reconciler root dapat menyinkronkan resource cakupan cluster dan cakupan namespace. Jika diperlukan, Anda dapat mengubah izin ini dengan mengonfigurasi spec.override.roleRefs kolom. Objek RootSync dirancang untuk digunakan oleh admin cluster.

    Objek RepoSync mengonfigurasi Config Sync untuk membuat reconciler namespace yang memantau sumber yang ditentukan dan menerapkan objek dari sumber tersebut ke namespace tertentu di cluster. Reconciler namespace dapat menyinkronkan resource cakupan namespace apa pun di namespace tersebut dengan izin kustom yang ditentukan pengguna. Objek RepoSync dirancang untuk digunakan oleh tenant namespace.

    Cara layanan Fleet mengelola objek RootSync

    Saat Anda menginstal Config Sync dengan konsol Google Cloud , Google Cloud CLI, Config Connector, atau Terraform, Config Sync dikelola oleh layanan Fleet, berdasarkan input Anda ke API Google Cloud .

    Saat penginstalan Config Sync dikelola oleh layanan Fleet, Anda juga dapat memilih untuk mengelola objek RootSync awal, yang diberi nama root-sync. Hal ini memungkinkan Anda melakukan bootstrap GitOps di cluster tanpa perlu menerapkan apa pun ke cluster secara langsung. Jika Anda memutuskan untuk tidak menggunakan layanan Fleet untuk mengelola objek RootSync awal, Anda tetap dapat menerapkan objek RootSync dan RepoSync apa pun yang Anda inginkan langsung ke cluster.

    Objek RootSync bernama root-sync dibuat berdasarkan input Anda ke Google Cloud API, khususnya bagian spec.configSync dari config-management apply API. Karena API ini hanya mengekspos subset dari RootSync kolom, kolom tersebut dianggap dikelola di root-sync, sedangkan kolom lainnya dianggap tidak dikelola. Kolom terkelola hanya dapat diedit menggunakan Google Cloud API. Kolom yang tidak dikelola dapat diedit menggunakan kubectl, atau klien Kubernetes lainnya.

    Objek RootSync dan RepoSync tambahan

    Untuk membuat objek RootSync atau RepoSync tambahan, Anda dapat menggunakan alat command line kubectl atau klien Kubernetes lainnya. Anda juga dapat menggunakan objek root-sync awal untuk mengelola objek RootSync atau RepoSync tambahan dengan GitOps, dengan menambahkan manifes YAML-nya ke sumber tepercaya yang dikonfigurasi untuk disinkronkan oleh root-sync. Metode ini tidak dapat digunakan untuk mengelola konfigurasi root-sync awal, karena beberapa kolomnya dikelola oleh layanan Fleet. Untuk mengelola objek root-sync dengan GitOps, gunakan Config Connector atau Terraform. Untuk mengetahui informasi selengkapnya tentang cara membuat objek RootSync dan RepoSync tambahan, lihat Mengonfigurasi sinkronisasi dari lebih dari satu sumber tepercaya.

    Langkah berikutnya