Arsitektur Config Sync

Config Sync menggunakan komponen yang dihosting di Google Cloud dan komponen open source di cluster Google Kubernetes Engine Anda untuk terus merekonsiliasi status cluster dengan sumber kebenaran pusat. Memahami cara komponen-komponen ini berinteraksi akan membantu Anda mendesain alur kerja GitOps yang skalabel dan memecahkan masalah sinkronisasi atau rekonsiliasi.

Ringkasan arsitektur

Diagram 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.
    • Reconciler Manager dalam Deployment bernama reconciler-manager.
    • ResourceGroup Controller 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 rekonsiler bernama root-reconciler-ROOTSYNC_NAME. Untuk objek RootSync bernama root-sync, Deployment rekonsiler diberi nama root-reconciler.

    • Untuk setiap objek RepoSync, Deployment rekonsiler bernama ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Untuk objek RepoSync bernama repo-sync, Deployment rekonsiler 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 Reconciler Manager berjalan di setiap cluster dengan Config Sync yang diaktifkan di objek ConfigManagement. Pengontrol ini memantau objek RootSync dan RepoSync serta mengelola Deployment rekonsiler untuk masing-masing 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 rekonsiler 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 di objek ConfigManagement. Agen ini mengumpulkan metrik dari komponen Config Sync yang berjalan di namespace config-management-system dan resource-group-system, lalu mengekspor metrik ini ke Prometheus dan Cloud Monitoring. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system ResourceGroup Controller berjalan di setiap cluster dengan Config Sync yang diaktifkan di objek ConfigManagement. Pengontrol ini mengamati objek ResourceGroup dan memperbaruinya dengan status rekonsiliasi saat ini dari setiap objek dalam inventarisnya. Objek ResourceGroup dibuat untuk setiap objek RootSync dan RepoSync guna menginventarisasi daftar objek yang diterapkan oleh rekonsiler dari sumber kebenaran. 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 di objek ConfigManagement. Webhook ini memantau permintaan API Kubernetes 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 container ini dibuat, lihat Container rekonsiler.

    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 rekonsiler 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 penting

    Bagian berikut membahas komponen penting Config Sync secara lebih mendetail.

    Layanan fleet dan objek ConfigSync

    Layanan Hub Fleet mengelola komponen Config Sync di cluster Anda:

    Pengelolaan Config Sync

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

    Untuk mengubah 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 Pencocok dan pencocok

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

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

    Root dan namespace reconciler otomatis mengambil konfigurasi dari sumber kebenaran Anda dan menerapkannya untuk menerapkan status yang Anda inginkan dalam cluster.

    Diagram berikut menunjukkan cara Reconciler Manager menangani pengendalian siklus proses setiap root reconciler dan namespace reconciler:

    Diagram yang menunjukkan cara Reconciler Manager mengontrol root reconciler Diagram yang menunjukkan cara Reconciler Manager mengontrol rekonsiler namespace

    Container rekonsiliasi

    Container tertentu yang di-deploy di Pod rekonsiler bergantung pada pilihan konfigurasi yang Anda buat. Tabel berikut menjelaskan lebih lanjut fungsi setiap container rekonsiler 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 rekonsiler lain dan mengirimkannya ke OpenTelemetry Collector. Selalu diaktifkan.
    git-sync Mengambil konfigurasi dari repositori Git Anda ke direktori lokal yang dapat dibaca oleh container rekonsiler. Diaktifkan jika spec.sourceType adalah git.
    helm-sync Mengambil dan merender chart Helm dari repositori chart Anda ke direktori lokal yang dapat dibaca oleh container rekonsiler. Diaktifkan jika spec.sourceType adalah helm.
    oci-sync Mengambil image OCI yang berisi konfigurasi Anda dari container registry ke direktori lokal yang dapat dibaca oleh container reconciler. Diaktifkan jika spec.sourceType adalah oci.
    gcenode-askpass-sidecar Menyimpan kredensial Git ke dalam cache dari layanan metadata GKE untuk digunakan oleh container git-sync. Diaktifkan jika 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 rekonsiler. Diaktifkan jika sumber menyertakan file kustomize.yaml.

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

    Permintaan resource rekonsiler

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

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

    Versi Helm dan Kustomize yang dipaketkan

    Config Sync memanfaatkan file yang dapat dieksekusi Helm dan Kustomize untuk merender konfigurasi. Untuk menemukan versi Helm dan Kustomize yang dipaketkan untuk versi Config Sync Anda, lihat kolom HELM_VERSION dan KUSTOMIZE_VERSION di Makefile dari repositori open source Config Sync. Anda dapat beralih antar-cabang di GitHub untuk melihat versi 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.

    Objek ResourceGroup Controller dan ResourceGroup

    Root dan namespace reconciler 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. ResourceGroup Controller kemudian mengamati semua objek dalam objek ResourceGroup dan memperbarui status objek ResourceGroup dengan status rekonsiliasi saat ini dari objek yang disinkronkan. Dengan cara ini, Anda dapat memeriksa status objek ResourceGroup untuk mendapatkan ringkasan status sinkronisasi, tanpa harus mengkueri 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 operasi Config Sync.

    Webhook Penerimaan

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

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

    Objek RootSync dan RepoSync

    Objek RootSync mengonfigurasi Config Sync untuk membuat root reconciler yang memantau sumber tepercaya yang ditentukan dan menerapkan objek dari sumber tersebut ke cluster. Secara default, root reconciler untuk setiap objek RootSync memiliki izin cluster-admin. Dengan izin default ini, root reconciler dapat menyinkronkan resource yang tercakup dalam cluster dan namespace. Jika diperlukan, 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 rekonsiler namespace yang memantau sumber yang ditentukan dan menerapkan objek dari sumber tersebut ke namespace tertentu dalam 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 konsol Google Cloud , 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 memintanya mengelola objek RootSync awal, yang bernama root-sync. Dengan begitu, Anda dapat melakukan bootstrap GitOps di cluster tanpa perlu menerapkan apa pun secara manual ke cluster secara langsung. Jika Anda memutuskan untuk tidak mengizinkan layanan Fleet mengelola objek RootSync awal, Anda masih 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 API config-management apply. Karena API ini hanya mengekspos subset kolom RootSync, 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 kebenaran 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