Arsitektur Config Sync

Halaman ini memperkenalkan arsitektur Config Sync. Mempelajari komponen yang dibuat oleh Config Sync dapat memberi Anda pemahaman yang lebih mendalam tentang Config Sync dan mungkin membantu Anda men-debug dan memperbaiki masalah yang Anda alami.

Diagram berikut menunjukkan arsitektur Config Sync dan resource terkaitnya di cluster edisi Enterprise Google Kubernetes Engine (GKE):

Diagram yang menunjukkan hubungan antara objek dan resource Config Sync

Dalam diagram ini, pengguna membuat sumber tepercaya dan menginstal Config Sync menggunakan Pengelola Fitur.

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

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

    • Operator ConfigManagement dalam Deployment bernama config-management-operator. Operator ConfigManagement tidak diinstal jika Anda menggunakan upgrade otomatis.
    • Definisi resource kustom (CRD) dan objek ConfigManagement bernama config-management. CRD dan objek ConfigManagement tidak diinstal jika Anda menggunakan upgrade otomatis.
    • Pengelola Reconciler dalam Deployment bernama reconciler-manager.
    • Pengontrol ResourceGroup dalam Deployment bernama resource-group-controller-manager.
    • OpenTelemetry Collector di Deployment bernama otel-collector.
    • Opsional: Webhook Akses Config Sync dalam Deployment bernama admission-webhook. Webhook Penerimaan Config Sync hanya diinstal jika Anda mengaktifkan pencegahan drift.

    Sebagian besar resource dan objek ini dibuat secara otomatis saat menginstal Config Sync dan Anda tidak perlu mengubahnya.

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

    • Untuk setiap RootSync, Deployment rekonsiliator bernama root-reconciler-ROOTSYNC_NAME.
    • Untuk setiap RepoSync, Deployment rekonsiliator bernama ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH.

Deployment, Pod, dan penampung Config Sync

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

Nama Deployment Namespace deployment Deskripsi deployment Jumlah replika Regular expression nama pod Jumlah penampung Nama penampung
config-management-operator config-management-system Operator ConfigManagement berjalan di setiap cluster dengan Config Sync yang diinstal. Reconciler memantau objek ConfigManagement dan mengelola komponen Config Sync, seperti Pengelola Reconciler dan OpenTelemetry Collector. 1 config-management-operator-.* 1
  • manager
    		•
    reconciler-manager config-management-system Pengelola Reconciler berjalan di setiap cluster dengan Config Sync diaktifkan di objek ConfigManagement. Reconciler ini memantau objek RootSync dan RepoSync serta mengelola Deployment rekonsiliator untuk setiap objek. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Deployment rekonsiliator 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 penyelesai 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 diaktifkan di objek ConfigManagement. Alat ini mengumpulkan metrik dari komponen Config Sync yang berjalan di 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 ResourceGroup Controller berjalan di setiap cluster dengan Config Sync diaktifkan di objek ConfigManagement. Fungsi 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 guna membuat inventaris daftar objek yang diterapkan oleh rekonsiliator dari sumber tepercaya. 1 resource-group-controller-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    admission-webhook config-management-system Webhook Penerimaan Config Sync berjalan di setiap cluster dengan pencegahan drift diaktifkan di objek ConfigManagement. Fitur ini memantau permintaan Kubernetes API dan mencegah perubahan atau penghapusan resource yang dikelola oleh Config Sync. Webhook izin Config Sync dinonaktifkan secara default. 2 admission-webhook-.* 1
  • admission-webhook
    		•

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

    Komponen utama

    Bagian berikut membahas komponen Config Sync yang penting secara lebih mendetail.

    Operator dan objek ConfigManagement

    Operator ConfigManagement memantau objek ConfigManagement dan membuat serta mengelola komponen lain yang diperlukan agar Config Sync berfungsi:

    Pengaktifan operator

    Karena Operator ConfigManagement menginstal beberapa komponen yang memerlukan izin cluster-admin, Operator ConfigManagement juga memerlukan izin cluster-admin.

    Pengelola dan rekonsiliator Rekonsiliator

    Pengelola Penyelesai bertanggung jawab untuk membuat dan mengelola setiap penyelesaian yang memastikan konfigurasi cluster Anda tetap sinkron.

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

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

    Diagram berikut menunjukkan cara Pengelola Penyelesai menangani kontrol siklus proses setiap penyelesai root dan penyelesai namespace:

    Diagram yang menunjukkan cara Pengelola Penyelesai mengontrol penyelesai root Diagram yang menunjukkan cara Pengelola Reconciler mengontrol namespace reconciler

    Penampung rekonsiliator

    Penampung tertentu yang di-deploy di Pod rekonsiliator bergantung pada pilihan konfigurasi yang Anda buat. Tabel berikut menjelaskan lebih lanjut tentang tindakan yang dilakukan setiap penampung rekonsiliasi ini dan kondisi yang menyebabkan Config Sync membuatnya:

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

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

    Objek ResourceGroup Controller dan ResourceGroup

    Penyelesai 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. 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 objek ResourceGroup untuk mengetahui ringkasan status sinkronisasi, tanpa harus membuat kueri status setiap objek sendiri.

    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 dapat mengganggu operasi Config Sync.

    Webhook Akses

    Webhook Penerimaan Config Sync dibuat saat Anda mengaktifkan pencegahan drift. Pencegahan drift mencegat permintaan perubahan secara proaktif, memastikannya sesuai dengan sumber tepercaya sebelum mengizinkan perubahan.

    Jika Anda tidak mengaktifkan pencegahan penyimpangan, Config Sync masih menggunakan mekanisme perbaikan mandiri untuk mengembalikan penyimpangan konfigurasi. Dengan perbaikan 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 rekonsiliator root yang memantau sumber tepercaya yang ditentukan dan menerapkan objek dari sumber tersebut ke cluster. Secara default, rekonsiliator root untuk setiap objek RootSync memiliki izin cluster-admin. Dengan izin default ini, rekonsiliator 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 rekonsiliator namespace yang memantau sumber yang ditentukan dan menerapkan objek dari sumber tersebut ke namespace tertentu di cluster. Penyelesai 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 akan dikelola oleh layanan Fleet, berdasarkan input Anda ke Google Cloud API.

    Jika penginstalan Config Sync dikelola oleh layanan Fleet, Anda juga dapat meminta layanan tersebut untuk mengelola objek RootSync awal, yang bernama root-sync. Dengan begitu, Anda dapat mem-bootstrap GitOps di cluster tanpa perlu menerapkan apa pun secara langsung ke cluster secara manual. Jika memutuskan untuk tidak meminta 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 penerapan pengelolaan konfigurasi. Karena API ini hanya mengekspos sebagian kolom RootSync, kolom tersebut dianggap dikelola di root-sync, sedangkan kolom lainnya dianggap tidak dikelola. Kolom terkelola hanya dapat diedit menggunakan Google Cloud API. Bidang 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 tempat root-sync dikonfigurasi 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 selanjutnya