Tentang sumber tepercaya

Config Sync memungkinkan Anda mengotomatiskan deployment resource Kubernetes di seluruh cluster dari sumber tepercaya pusat, menggantikan perintah kubectl manual. Dalam alur kerja GitOps, sumber kebenaran adalah repositori pusat tempat Anda menyimpan file konfigurasi YAML atau JSON yang menentukan resource cluster Anda. Config Sync terus memantau repositori ini dan otomatis menerapkan perubahan pada cluster Anda.

Anda dapat menyinkronkan file konfigurasi dari tiga jenis sumber: repositori Git, image Open Container Initiative (OCI), dan diagram Helm. Memahami cara Config Sync berinteraksi dengan setiap jenis sumber akan membantu Anda memilih opsi 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 kontrol versi dan percabangan, jika diperlukan. Karena Git sudah matang dan didukung secara luas, Anda mendapatkan berbagai opsi untuk penyedia dan alat.

Saat Anda mengonfigurasi Config Sync dengan repositori Git sebagai sumber kebenaran, Config Sync menggunakan container git-sync dalam Pod rekonsiler untuk mengambil konfigurasi dari repositori Git. Anda dapat mengonfigurasi URL, cabang, dan revisi (commit atau tag) repositori untuk kontrol yang lebih besar atas tempat untuk mengambil 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 dari 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 disediakan, 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 memaketkan aplikasi dan dependensinya. Pendekatan ini memperlakukan konfigurasi Anda sebagai artefak, mirip dengan cara Anda memperlakukan image container. Pendekatan ini menawarkan keunggulan seperti keabadian 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 for GKE guna membantu menyederhanakan autentikasi.

Penggunaan OCI sebagai sumber konfigurasi biasanya memerlukan proses terpisah untuk mem-build file konfigurasi Anda menjadi image OCI, lalu mengirimkannya ke platform registry seperti Artifact Registry. Pendekatan ini mungkin kurang dapat dibaca manusia secara langsung dibandingkan dengan 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 rekonsiler untuk mengambil 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 mengambil 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 otomatis mendeteksi dan menerapkan versi baru image ke cluster Anda, sehingga memastikan peluncuran yang divalidasi dan diberi versi untuk semua perubahan konfigurasi.

Diagram Helm

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

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

Jika Anda belum memahami Helm, proses pembuatan template dan rilis dapat menambah kompleksitas pada pipeline manajemen konfigurasi Anda.

Saat Anda mengonfigurasi Config Sync dengan chart Helm sebagai sumber kebenaran, Config Sync menggunakan container helm-sync dalam Pod rekonsiler untuk mengambil 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 dari 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 mengambil dari diagram Helm bawaan yang men-deploy Prometheus. Alih-alih menjalankan perintah Helm secara manual, Anda menentukan sumber chart, versi, dan values kustom apa pun dalam objek RootSync atau RepoSync Config Sync. Config Sync kemudian 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 Image OCI Diagram Helm
Paling cocok untuk Manajemen konfigurasi tujuan umum; fleksibilitas; dapat dibaca manusia Konfigurasi yang tidak dapat diubah dan berversi; memanfaatkan infrastruktur container Mengemas dan mendistribusikan aplikasi yang kompleks
Mutabilitas Dapat diubah Tidak dapat diubah Dapat diubah (versi diagram tidak dapat diubah, tetapi nilainya dapat berubah)
Rollback Mengembalikan commit atau mengubah cabang Men-deploy tag image sebelumnya Rollback ke versi diagram sebelumnya
Alat Klien Git standar, pipeline CI/CD Docker atau Podman, Container Registry 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 jenis sumber yang berbeda untuk tujuan yang berbeda di cluster yang sama. Misalnya, cluster mungkin memiliki hal berikut:

  • RootSync yang 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 berbeda yang disinkronkan dari image OCI yang berisi serangkaian konfigurasi khusus aplikasi yang dibuat oleh proses CI/CD terpisah.

Langkah berikutnya