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 dapat memberi Anda pemahaman yang lebih mendalam tentang Config Sync dan dapat membantu Anda men-debug dan memperbaiki masalah yang Anda alami.

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 objek ConfigManagement Operator atau ConfigManagement lama. 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 Rekonsiliasi 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 objek RootSync, Deployment rekonsiliasi bernama root-reconciler-ROOTSYNC_NAME. Untuk objek RootSync bernama root-sync, Deployment rekonsiliasi diberi nama root-reconciler.
    • Untuk setiap objek RepoSync, Deployment rekonsiliasi bernama ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Untuk objek RepoSync bernama repo-sync, Deployment rekonsiliasi bernama ns-reconciler.

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 Regular expression nama pod Jumlah container Nama penampung
reconciler-manager config-management-system Pengelola Penyesuaian berjalan di setiap cluster dengan Config Sync diaktifkan di objek ConfigManagement. Operator ini memantau objek RootSync dan RepoSync serta mengelola Deployment rekonsiliasi untuk setiap objek. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Deployment root reconciler 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 namespace reconciler 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 diaktifkan di objek ConfigManagement. Mengumpulkan metrik dari komponen Config Sync yang berjalan di bawah namespace config-management-system dan resource-group-system, 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 di objek ConfigManagement. Objek ini memantau objek ResourceGroup dan memperbaruinya dengan status rekonsiliasi saat ini dari setiap objek dalam inventarisnya. Objek ResourceGroup dibuat untuk setiap objek RootSync dan RepoSync untuk menginventarisasi daftar objek yang diterapkan oleh rekonsiliator 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 diaktifkan dalam objek ConfigManagement. Memantau permintaan Kubernetes API dan mencegah modifikasi atau penghapusan resource yang dikelola oleh Config Sync. Webhook penerimaan Config Sync dinonaktifkan secara default. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 Untuk mengetahui detail tentang kapan penampung ini dibuat, lihat Penampung rekonsiliasi.

    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 rekonsiliasi untuk mengetahui detailnya.

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

    Komponen utama

    Bagian berikut membahas komponen penting Config Sync secara lebih mendalam.

    Layanan armada dan objek ConfigSync

    Di Config Sync versi 1.20.0 dan yang lebih baru, layanan Hub Fleet mengelola komponen Config Sync di cluster Anda secara langsung:

    Pengelolaan Config Sync

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

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

    Pengelola rekonsiliasi dan petugas rekonsiliasi

    Pengelola Penyesuai bertanggung jawab untuk membuat dan mengelola penyesuai individual yang memastikan konfigurasi cluster Anda tetap disinkronkan.

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

    Root dan namespace reconciler secara otomatis mengambil konfigurasi dari sumber kebenaran 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 rekonsiliasi

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

    Nama penampung Deskripsi Kondisi
    reconciler Menangani sinkronisasi dan perbaikan penyimpangan. Selalu diaktifkan.
    otel-agent Menerima metrik dari penampung rekonsiliasi lainnya dan mengirimkannya ke OpenTelemetry Collector. Selalu diaktifkan.
    git-sync Menarik konfigurasi dari repositori Git Anda ke direktori lokal yang dapat dibaca oleh penampung rekonsiliasi. Diaktifkan saat spec.sourceType adalah git.
    helm-sync Mengambil dan merender diagram Helm dari repositori diagram Anda ke direktori lokal yang dapat dibaca oleh container rekonsiliasi. Diaktifkan saat spec.sourceType adalah helm.
    oci-sync Mengambil image OCI yang berisi konfigurasi Anda dari container registry ke direktori lokal yang dapat dibaca oleh container rekonsiliasi. Diaktifkan saat spec.sourceType adalah oci.
    gcenode-askpass-sidecar Meng-cache kredensial Git 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 rekonsiliasi. Diaktifkan saat sumber menyertakan file kustomize.yaml.

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

    Permintaan resource rekonsiliasi

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

    Permintaan resource sama untuk semua versi Config Sync yang didukung.

    Tabel berikut mencantumkan permintaan resource untuk cluster Standard:

    Nama penampung 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 penampung 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 batas resource.

    Versi Helm dan Kustomize yang dibundel

    Config Sync memanfaatkan file yang dapat dieksekusi Helm dan Kustomize untuk merender konfigurasi. Tabel berikut berisi daftar versi Config Sync yang mendukung fitur rendering, beserta versi Helm dan Kustomize yang disertakan.

    Versi Config Sync Versi Helm Versi Kustomize
    1.22.0 v3.15.3 v5.3.0
    1.21.0 v3.15.3 v5.3.0
    1.20.0 v3.15.3 v5.3.0

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

    Pengontrol ResourceGroup dan objek ResourceGroup

    Penyelarasan 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 rekonsiliator untuk objek RootSync atau RepoSync tersebut. ResourceGroup Controller kemudian memantau semua objek dalam objek ResourceGroup dan mengupdate status objek ResourceGroup dengan status rekonsiliasi saat ini dari objek yang disinkronkan. Dengan demikian, Anda dapat memeriksa status objek ResourceGroup untuk mendapatkan ringkasan status sinkronisasi, alih-alih harus membuat kueri status setiap objek satu per satu.

    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 pengoperasian Config Sync.

    Webhook Penerimaan

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

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

    Objek RootSync dan RepoSync

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

    Objek RepoSync mengonfigurasi Config Sync untuk membuat rekonsiliasi namespace yang memantau sumber yang ditentukan dan menerapkan objek dari sumber tersebut ke namespace tertentu di cluster. Namespace reconciler 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 Google Cloud konsol, Google Cloud CLI, Config Connector, atau Terraform, Config Sync dikelola oleh layanan Fleet, berdasarkan input Anda ke Google Cloud API.

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

    Objek RootSync bernama root-sync dibuat berdasarkan input Anda ke Google Cloud API, khususnya bagian spec.configSync dari API penerapan config-management. Karena API ini hanya mengekspos subset 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 fields 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 root-sync untuk disinkronkan. 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