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 Rekonsiliasi 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. Fitur ini 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.

    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 penampung 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.

    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. Dengan begitu, Anda dapat mem-bootstrap 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 mempelajari lebih lanjut cara membuat objek RootSync dan RepoSync tambahan, lihat Mengonfigurasi sinkronisasi dari lebih dari satu sumber tepercaya.

    Langkah berikutnya