Halaman ini memperkenalkan arsitektur Config Sync, termasuk komponen yang dihosting yang berjalan di Google Cloud dan komponen open source yang berjalan di cluster edisi Enterprise Google Kubernetes Engine (GKE). Mempelajari arsitektur dapat memberi Anda pemahaman yang lebih mendalam tentang Config Sync dan mungkin membantu Anda men-debug serta memperbaiki masalah yang Anda alami.
Arsitektur Config Sync telah berubah dari waktu ke waktu:
- Di Config Sync versi 1.5.1, mode multi-repo baru telah ditambahkan. Mode ini menggunakan arsitektur multi-tenant yang lebih skalabel dengan rekonsiliator untuk setiap objek RootSync dan RepoSync, yang memungkinkan pengelolaan izin independen, penskalaan independen, dan beberapa domain error independen.
- Di Config Sync versi 1.18.0, fitur upgrade otomatis telah ditambahkan. Dengan upgrade otomatis diaktifkan, Operator ConfigManagement dan objek
ConfigManagement
akan dihapus dari cluster. Sebagai gantinya, layanan Fleet (GKE Hub) mengelola komponen open source di cluster secara langsung. Dengan upgrade otomatis dinonaktifkan, Operator ConfigManagement masih digunakan. - Di Config Sync versi 1.19.0, mode mono-repo opsional telah dihapus. Mode ini menggunakan arsitektur yang lebih sederhana dengan lebih sedikit komponen, tetapi sulit diskalakan dan tidak mendukung multi-tenancy. Karena alasan tersebut, mode ini diganti dengan mode multi-repo yang lebih baru. Untuk informasi selengkapnya, lihat bermigrasi ke mode multi-repo.
- Di Config Sync versi 1.20.0, Operator ConfigManagement dan objek
ConfigManagement
dihapus sepenuhnya, meskipun upgrade otomatis dinonaktifkan. Sebagai gantinya, layanan Fleet (GKE Hub) mengelola komponen open source di cluster secara langsung.
Bagian berikut menunjukkan arsitektur Config Sync, termasuk komponen dan dependensinya, baik di Google Cloud maupun di cluster edisi Enterprise Google Kubernetes Engine (GKE), untuk berbagai versi Config Sync:
Di Config Sync versi 1.20.0 dan yang lebih baru, layanan Fleet
mengelola komponen Config Sync di cluster Anda secara langsung, tanpa
Operator ConfigManagement lama atau objek ConfigManagement
. Anda dapat mengonfigurasi layanan Fleet untuk mengupgrade Config Sync secara otomatis, atau Anda dapat mengupgrade Config Sync secara manual sesuai kebutuhan.
Arsitektur ini juga digunakan untuk Config Sync versi 1.18.0 dan yang lebih baru, saat upgrade otomatis diaktifkan.
Ada beberapa langkah untuk menginstal Config Sync dan setiap langkah ini men-deploy komponen tambahan di cluster Anda:
Mengaktifkan Config Sync di cluster akan menambahkan komponen berikut:
- Definisi resource kustom (CRD)
ConfigSync
- Objek
ConfigSync
bernamaconfig-sync
. - 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.
Resource dan objek ini dibuat secara otomatis saat Anda menginstal Config Sync dan tidak boleh diubah secara langsung.
- Definisi resource kustom (CRD)
Membuat objek
RootSync
danRepoSync
akan menambahkan komponen berikut:- Untuk setiap objek
RootSync
, Deployment rekonsiliator bernamaroot-reconciler-ROOTSYNC_NAME
. Untuk objekRootSync
bernamaroot-sync
, Deployment rekonsiliator diberi namaroot-reconciler
. - Untuk setiap objek
RepoSync
, Deployment rekonsiliator bernamans-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH
. Untuk objekRepoSync
bernamarepo-sync
, Deployment rekonsiliator bernamans-reconciler
.
- Untuk setiap objek
Di Config Sync versi 1.19.x dan yang lebih lama, saat menggunakan upgrade manual, layanan Fleet akan mengelola Operator ConfigManagement, yang pada akhirnya mengelola komponen Config Sync di cluster Anda.
Di Config Sync versi 1.18.x dan yang lebih baru, saat menggunakan upgrade otomatis, arsitektur 1.20.0 dan yang lebih baru akan digunakan.
Ada beberapa langkah untuk menginstal Config Sync dan setiap langkah ini men-deploy komponen tambahan di cluster Anda:
Mengaktifkan Config Sync di cluster akan menambahkan komponen berikut:
- Operator ConfigManagement dalam Deployment bernama
config-management-operator
. - Definisi resource kustom (CRD)
ConfigManagement
. - Objek
ConfigManagement
bernamaconfig-management
. - 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 Anda menginstal Config Sync dan tidak boleh diubah secara langsung. Namun, objek
ConfigManagement
memiliki beberapa kolom yang diizinkan untuk diubah secara langsung. Untuk informasi selengkapnya, lihat Kolom ConfigManagement.- Operator ConfigManagement dalam Deployment bernama
Membuat objek
RootSync
danRepoSync
akan menambahkan komponen berikut:- Untuk setiap objek
RootSync
, Deployment rekonsiliator bernamaroot-reconciler-ROOTSYNC_NAME
. Untuk objekRootSync
bernamaroot-sync
, Deployment rekonsiliator diberi namaroot-reconciler
. - Untuk setiap objek
RepoSync
, Deployment rekonsiliator bernamans-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH
. Untuk objekRepoSync
bernamarepo-sync
, Deployment rekonsiliator bernamans-reconciler
.
- Untuk setiap objek
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 cluster dengan Config Sync versi
1.19.x dan yang lebih lama diinstal, saat menggunakan upgrade manual. Komponen ini memantau
objek ConfigManagement dan mengelola komponen Config Sync
lainnya, seperti Pengelola Reconciler dan OpenTelemetry Collector. Di
Config Sync versi 1.20.0 dan yang lebih baru, Operator ConfigManagement diganti dengan ekstensi layanan Fleet (GKE Hub).
|
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 |
Pengontrol ResourceGroup 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 | 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 penting secara lebih mendetail.
Layanan armada dan objek ConfigSync
Di Config Sync versi 1.20.0 dan yang lebih baru, serta versi 1.18.0 dan yang lebih baru dengan upgrade otomatis diaktifkan, layanan GKE Fleet mengelola komponen Config Sync di cluster Anda secara langsung:
Layanan Fleet juga mengelola objek ConfigSync
di cluster Anda. Layanan
Fleet memperbarui spesifikasi objek ConfigSync
berdasarkan input Anda
ke Google Cloud API dan statusnya untuk mencerminkan status
komponen Config Sync.
Untuk membuat perubahan pada konfigurasi penginstalan Config Sync, Anda harus menggunakan Google Cloud API. Namun, Anda dapat menggunakan Google CloudAPI atau Kubernetes API untuk memantau konfigurasi dan kondisi penginstalan Config Sync.
Operator ConfigManagement dan objek ConfigManagement
Di Config Sync versi 1.19.x dan yang lebih lama, saat menggunakan upgrade manual, layanan GKE Fleet akan mengelola Operator ConfigManagement, yang pada gilirannya mengelola komponen Config Sync di cluster Anda:
Untuk membuat perubahan pada konfigurasi penginstalan Config Sync, Anda
secara utama menggunakan Google Cloud API. Namun, Anda juga dapat menggunakan
Kubernetes API untuk membuat beberapa perubahan pada objek ConfigManagement
. Untuk mengetahui informasi selengkapnya, lihat Kolom ConfigManagement.
Operator ConfigManagement memantau objek ConfigManagement
untuk perubahan spesifikasi,
mengelola komponen Config Sync di cluster Anda untuk mencerminkan spesifikasi,
dan memperbarui status objek ConfigManagement
untuk mencerminkan status
komponen Config Sync.
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:
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 dari registry container 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, memastikan permintaan tersebut selaras 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 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 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 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 berikutnya
- Sebaiknya pantau komponen Config Sync atau periksa lognya. Untuk pengantar, lihat Menggunakan pemantauan dan log.
- Pelajari Permintaan resource untuk komponen Config Sync.