Tentang sumber kebenaran

Dokumen ini menjelaskan berbagai jenis sumber tepercaya yang dapat disinkronkan oleh Config Sync.

Konsep utama dalam alur kerja GitOps adalah sumber tepercaya, repositori pusat tempat file konfigurasi Anda disimpan. File konfigurasi biasanya berupa file YAML atau JSON yang menentukan resource Kubernetes. Biasanya, Anda dapat menerapkan objek Kubernetes secara manual dengan alat command line kubectl, tetapi Config Sync dapat menerapkan resource tersebut secara otomatis dari satu sumber tepercaya seperti repositori Git. Config Sync kemudian memantau sumber kebenaran yang Anda tentukan dan secara otomatis menerapkan perubahan apa pun ke cluster Anda.

Config Sync dapat menyinkronkan file konfigurasi dari tiga jenis sumber yang berbeda: repositori Git, image Open Container Initiative (OCI), dan diagram Helm. Dokumen ini menjelaskan setiap jenis sumber ini dan cara Config Sync berinteraksi dengannya. Membaca dokumen ini dapat membantu Anda memilih opsi sumber terbaik untuk alur kerja dan lingkungan Anda.

Repositori Git

Git adalah teknologi yang banyak digunakan untuk kontrol versi dan kolaborasi. Dengan Git, Anda dapat mengatur repositori sesuai kebutuhan dan mendapatkan manfaat dari kontrol versi dan percabangan, jika diperlukan. Karena Git adalah teknologi yang matang dan banyak digunakan, Anda akan mendapatkan berbagai opsi untuk penyedia dan alat.

Saat Anda mengonfigurasi Config Sync dengan repositori Git sebagai sumber tepercaya, Config Sync menggunakan penampung git-sync dalam Pod rekonsiliasi untuk menarik konfigurasi dari repositori Git. Anda dapat mengonfigurasi URL repositori, cabang, dan revisi (commit atau tag) untuk mendapatkan kontrol yang lebih besar atas tempat menarik konfigurasi dalam repositori Git Anda.

Contoh konfigurasi RootSync

Contoh berikut menunjukkan manifes RootSync yang disinkronkan dari repositori Git:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Konfigurasi ini menyiapkan Config Sync untuk menyinkronkan manifes dari repositori Git. Config Sync memantau direktori cluster-configs di cabang main repositori https://github.com/example/my-configs.git, memeriksa update setiap 60 detik tanpa menggunakan autentikasi.

Contoh kasus penggunaan: Pengelolaan terpusat

Bayangkan Anda adalah administrator platform yang ingin menggunakan repositori Git untuk menerapkan kebijakan dasar di semua cluster dalam fleet. Dalam skenario ini, Anda dapat menyimpan NetworkPolicies, RoleBindings, dan ResourceQuotas standar di repositori Git pusat bernama standard-configs. Saat cluster baru di-provisioning, Config Sync dikonfigurasi untuk menyinkronkan dari repositori standard-configs, sehingga membantu memastikan semua cluster memenuhi standar organisasi sejak awal.

Image OCI

Image OCI adalah format standar untuk mengemas aplikasi dan dependensinya. Pendekatan ini memperlakukan konfigurasi Anda sebagai artefak, mirip dengan cara Anda memperlakukan image container. Pendekatan ini menawarkan keuntungan seperti imutabilitas dan performa yang lebih cepat dalam skala besar. Dengan OCI, Anda dapat menggunakan infrastruktur dan alat image container seperti Artifact Registry untuk mengelola image, dan Workload Identity Federation untuk GKE guna membantu menyederhanakan autentikasi.

Menggunakan OCI sebagai sumber konfigurasi biasanya memerlukan proses terpisah untuk mem-build file konfigurasi Anda menjadi image OCI, lalu mengirimkannya ke platform registri seperti Artifact Registry. Pendekatan ini mungkin kurang mudah dibaca secara langsung oleh manusia dibandingkan konfigurasi yang disimpan sebagai file di repositori Git.

Saat Anda mengonfigurasi Config Sync dengan image OCI sebagai sumber kebenaran, Config Sync menggunakan container oci-sync dalam Pod reconciler untuk menarik image OCI yang berisi konfigurasi dari registry.

Contoh konfigurasi RootSync

Contoh berikut menunjukkan manifes RootSync yang disinkronkan dari image OCI yang disimpan di Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Konfigurasi ini menyiapkan Config Sync untuk menyinkronkan dari image OCI. Config Sync menarik image us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 dari Artifact Registry menggunakan akun layanan Kubernetes untuk autentikasi.

Contoh kasus penggunaan: Integrasi pipeline CI/CD

Bayangkan Anda ingin mengintegrasikan pembuatan image OCI ke dalam pipeline CI/CD organisasi Anda. Saat perubahan pada file konfigurasi digabungkan, Anda dapat menyiapkan pipeline untuk menjalankan pengujian validasi (seperti perintah nomos vet), membangun file YAML menjadi image OCI, dan mengirim image ke Artifact Registry. Config Sync kemudian akan mendeteksi dan menerapkan versi baru image ke kluster Anda secara otomatis, sehingga memastikan peluncuran semua perubahan konfigurasi yang divalidasi dan diberi versi.

Diagram Helm

Helm adalah pengelola paket populer untuk Kubernetes, yang menggunakan format paket yang disebut diagram. Config Sync dapat mengambil, merender, dan menyinkronkan resource yang ditentukan dalam chart Helm.

Helm menawarkan cara yang konsisten untuk mengemas dan menggunakan kembali aplikasi Kubernetes. Anda dapat menggunakan template atau diagram Helm bawaan untuk konfigurasi yang konsisten dan dapat digunakan kembali.

Jika Anda belum terbiasa dengan Helm, proses pembuatan template dan rilis dapat menambah kompleksitas pada pipeline pengelolaan konfigurasi Anda.

Saat Anda mengonfigurasi Config Sync dengan chart Helm sebagai sumber tepercaya, Config Sync menggunakan container helm-sync dalam Pod rekonsiliasi untuk menarik chart dari repositori Helm (seperti Artifact Registry) atau repositori Git, lalu merender chart untuk menghasilkan manifes Kubernetes. Atau, Anda dapat menggunakan Config Sync dengan Kustomize untuk merender diagram Helm. Untuk mengetahui informasi selengkapnya tentang pendekatan ini, lihat Menggunakan Config Sync dengan Kustomize dan Helm.

Contoh konfigurasi RootSync

Contoh berikut menunjukkan manifes RootSync yang disinkronkan dari diagram Helm yang disimpan di Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Konfigurasi ini menyiapkan Config Sync untuk menyinkronkan diagram Helm dari repositori OCI. Config Sync mengambil versi 1.2.0 diagram my-chart dari repositori oci://us-central1-docker.pkg.dev/my-project/my-helm-repo, dan melakukan autentikasi dengan akun layanan my-service-account@my-project.iam.gserviceaccount.com. Tindakan ini akan men-deploy resource diagram ke namespace my-app-namespace dengan nama rilis my-chart-release.

Contoh kasus penggunaan: Men-deploy aplikasi pihak ketiga

Bayangkan Anda adalah bagian dari tim aplikasi yang ingin men-deploy Prometheus ke cluster. Anda dapat mengonfigurasi Config Sync untuk menarik dari diagram Helm bawaan yang men-deploy Prometheus. Daripada menjalankan perintah Helm secara manual, Anda dapat menentukan sumber, versi, dan values kustom dalam objek RootSync atau RepoSync Config Sync. Kemudian, Config Sync akan menjaga deployment tetap sinkron dengan versi dan konfigurasi diagram yang ditentukan.

Memilih jenis sumber

Jenis sumber terbaik bergantung pada alat, alur kerja, dan preferensi tim Anda yang sudah ada. Anda dapat menggunakan tabel ini untuk memahami karakteristik utama setiap jenis sumber guna membantu Anda membuat keputusan yang tepat:

Fitur Repositori Git Gambar OCI Diagram Helm
Paling cocok untuk Pengelolaan konfigurasi serbaguna; fleksibilitas; dapat dibaca manusia Konfigurasi yang tidak dapat diubah dan diberi versi; memanfaatkan infrastruktur container Mengemas dan mendistribusikan aplikasi kompleks
Dapat Berubah Dapat diubah Tidak dapat diubah Dapat diubah (versi diagram tidak dapat diubah, tetapi nilai dapat berubah)
Rollback Mengembalikan commit atau mengubah cabang Men-deploy tag gambar sebelumnya Melakukan roll back ke versi diagram sebelumnya
Alat Klien Git standar, pipeline CI/CD Docker atau Podman, registry container Helm CLI, repositori Helm
Performa Dapat lebih lambat untuk repositori besar Lebih cepat, terutama dalam skala besar Cepat saat mengambil dari repositori diagram
Autentikasi Fleksibel (SSH, token), penyiapannya bisa lebih rumit Disederhanakan dengan Workload Identity Federation for GKE (misalnya, dengan Artifact Registry) Disederhanakan dengan Workload Identity Federation for GKE (misalnya, dengan Artifact Registry)

Anda juga dapat menggunakan berbagai jenis sumber untuk berbagai tujuan di cluster yang sama. Misalnya, cluster mungkin memiliki hal berikut:

  • RootSync disinkronkan dari repositori Git yang berisi resource dan kebijakan dasar di seluruh cluster yang dikelola oleh tim platform.
  • RepoSync di namespace tertentu yang disinkronkan dari diagram Helm untuk men-deploy instance Redis yang dikelola oleh tim aplikasi.
  • RepoSync lain di namespace yang berbeda yang disinkronkan dari image OCI yang berisi serangkaian konfigurasi khusus aplikasi yang dibuat oleh proses CI/CD terpisah.

Langkah berikutnya