Menginstal Config Sync secara manual menggunakan kubectl (tidak direkomendasikan)

Halaman ini menunjukkan cara menginstal Config Sync menggunakan perintah kubectl. Operator ConfigManagement adalah pengontrol yang mengelola Config Sync di cluster Kubernetes. Ikuti langkah-langkah ini untuk menginstal dan mengonfigurasi Operator di setiap cluster yang ingin Anda kelola menggunakan Sinkronisasi Konfigurasi.

Perhatian: Metode penginstalan yang digunakan di halaman ini tidak direkomendasikan karena tidak kompatibel dengan Konsol Google Cloud atau Google Cloud CLI.

Sebelum memulai

Bagian ini menjelaskan prasyarat yang harus dipenuhi sebelum menginstal Config Sync menggunakan kubectl.

Menyiapkan lingkungan lokal Anda

Sebelum menginstal Operator, pastikan Anda telah menyiapkan lingkungan lokal dengan menyelesaikan tugas berikut:

• Membuat atau memiliki akses ke sumber kebenaran.

• Instal dan inisialisasi Google Cloud CLI, yang menyediakan perintah gcloud, gsutil, kubectl, dan nomos yang digunakan dalam petunjuk ini. Jika Anda menggunakan Cloud Shell, Google Cloud CLI sudah terinstal.

• kubectl tidak diinstal secara default oleh Google Cloud CLI. Untuk menginstal kubectl, gunakan perintah berikut:

  gcloud components install kubectl
  

• Lakukan autentikasi ke Google Cloud menggunakan perintah gcloud auth login agar Anda dapat mendownload komponen Config Sync.

Menyiapkan cluster Anda

Membuat, atau memiliki akses ke, cluster edisi Google Kubernetes Engine (GKE) Enterprise yang memenuhi persyaratan untuk Config Sync.

Menyiapkan izin

Pengguna Google Cloud yang menginstal Config Sync memerlukan izin IAM untuk membuat peran baru di cluster Anda. Jika perlu, berikan peran ini dengan perintah berikut:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Ganti kode berikut:

• CLUSTER_NAME: nama cluster Anda
• USER_ACCOUNT: alamat email akun Google Cloud Anda

Bergantung pada cara Anda mengonfigurasi Google Cloud CLI di sistem lokal, Anda mungkin perlu menambahkan kolom --project dan --zone.

Jika Anda perlu memberi Operator akses ke OCI menggunakan gcpserviceaccount sebagai jenis autentikasi, untuk membuat binding kebijakan, Anda juga harus memiliki izin iam.serviceAccounts.setIamPolicy. Anda bisa mendapatkan izin ini dengan memberikan peran IAM Service Account Admin (roles/iam.serviceAccountAdmin). Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran standar lainnya.

Untuk mengetahui informasi lebih lanjut tentang cara memberikan peran, lihat Mengelola akses.

Mendaftarkan cluster

Untuk mendaftarkan cluster di Config Sync, selesaikan langkah-langkah berikut:

1. Men-deploy Operator
2. Beri Operator akses hanya baca ke salah satu opsi berikut:
   • Git
   • OCI
   • Helm
3. Mengonfigurasi Operator

Men-deploy Operator

Setelah memastikan semua prasyarat terpenuhi, Anda dapat men-deploy Operator dengan mendownload dan menerapkan manifes YAML.

1. Download manifes Operator versi terbaru menggunakan perintah berikut. Untuk mendownload versi tertentu, lihat Download.

   gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
   

2. Terapkan manifes:

   kubectl apply -f config-management-operator.yaml

Jika proses ini gagal karena ada masalah dengan objek ConfigManagement yang bukan akibat error sintaksis YAML atau JSON, objek mungkin akan dibuat instance-nya di cluster, tetapi mungkin tidak berfungsi dengan benar. Dalam situasi ini, Anda dapat menggunakan perintah nomos status untuk memeriksa error dalam objek.

Penginstalan yang valid tanpa masalah akan memiliki status PENDING atau SYNCED.

Penginstalan yang tidak valid akan menampilkan status NOT CONFIGURED dan mencantumkan salah satu error berikut:

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Untuk memperbaiki masalah ini, perbaiki error konfigurasi. Bergantung pada jenis error, Anda mungkin perlu menerapkan ulang manifes ConfigManagement ke cluster.

Jika masalahnya adalah Anda lupa membuat Secret git-creds, Config Sync akan mendeteksi Secret tersebut segera setelah membuatnya, dan Anda tidak perlu menerapkan ulang konfigurasi.

Memberikan akses hanya baca kepada Operator

Jika menyimpan konfigurasi di Git, Anda harus memberi Operator akses hanya baca ke Git. Jika menyimpan konfigurasi sebagai image OCI, Anda harus memberikan akses hanya baca kepada Operator ke OCI. Jika menyimpan konfigurasi di Helm, Anda harus memberi Operator akses hanya baca ke Helm.

Memberikan akses hanya baca Operator ke Git

Config Sync memerlukan akses hanya baca ke repositori Git Anda agar dapat membaca konfigurasi yang di-commit ke repositori dan menerapkannya ke cluster Anda.

Jika repositori tidak memerlukan autentikasi untuk akses hanya baca, Anda dapat terus mengonfigurasi Config Sync dan menggunakan none sebagai jenis autentikasi. Misalnya, jika Anda dapat menjelajahi repositori menggunakan antarmuka web tanpa login, atau jika Anda dapat menggunakan git clone untuk membuat clone repositori secara lokal tanpa memberikan kredensial atau menggunakan kredensial tersimpan, maka Anda tidak perlu melakukan autentikasi. Dalam hal ini, Anda tidak perlu membuat Secret.

Namun, sebagian besar pengguna perlu membuat kredensial karena akses baca ke repositori mereka dibatasi. Jika diperlukan, kredensial akan disimpan di Rahasia git-creds pada setiap cluster yang terdaftar (kecuali jika Anda menggunakan akun layanan Google). Secret harus diberi nama git-creds karena ini adalah nilai tetap.

Config Sync mendukung mekanisme autentikasi berikut:

• Pasangan kunci SSH (ssh)
• File cookie (cookiefile)
• Token (token)
• Akun layanan Google (gcpserviceaccount)
• Akun layanan default Compute Engine (gcenode)

Mekanisme yang Anda pilih bergantung pada repositori yang didukung. Secara umum, kami merekomendasikan penggunaan pasangan kunci SSH. baik GitHub maupun Bitbucket, menggunakan pasangan kunci SSH. Namun, jika Anda menggunakan repositori di Cloud Source Repositories, sebaiknya gunakan akun layanan Google karena prosesnya lebih sederhana. Jika organisasi Anda menghosting repositori Anda dan Anda tidak tahu metode autentikasi mana yang didukung, hubungi administrator Anda.

Untuk menggunakan repositori di Cloud Source Repositories sebagai repositori Config Sync Anda, selesaikan langkah-langkah berikut untuk mengambil URL Cloud Source Repositories:

1. Tampilkan daftar semua repositori:

   gcloud source repos list
   

2. Dari output, salin URL dari repositori yang ingin Anda gunakan. Contoh:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   Anda perlu menggunakan URL ini saat mengonfigurasi Config Sync di bagian berikut. Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud Console, tambahkan URL di kolom URL. Jika mengonfigurasi Config Sync menggunakan Google Cloud CLI, Anda dapat menambahkan URL ke kolom syncRepo file konfigurasi.

Pasangan kunci SSH

Pasangan kunci SSH terdiri dari dua file, kunci publik dan kunci pribadi. Kunci publik biasanya memiliki ekstensi .pub.

Peringatan: Lindungi file yang dibuat oleh perintah ini. Keduanya memberikan kemampuan untuk membaca dari repositori Anda.

Untuk menggunakan pasangan kunci SSH, selesaikan langkah-langkah berikut:

1. Buat pasangan kunci SSH agar Config Sync dapat melakukan autentikasi ke repositori Git Anda. Langkah ini diperlukan jika Anda perlu melakukan autentikasi ke repositori untuk meng-clone atau membaca dari repositori. Lewati langkah ini jika administrator keamanan memberi Anda pasangan kunci. Anda dapat menggunakan pasangan kunci tunggal untuk semua cluster, atau pasangan kunci per cluster, bergantung pada persyaratan keamanan dan kepatuhan Anda.

   Perintah berikut akan membuat kunci RSA 4096-bit. Nilai yang lebih rendah tidak direkomendasikan:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   Ganti kode berikut:

   • GIT_REPOSITORY_USERNAME: nama pengguna yang Anda inginkan untuk digunakan oleh Config Sync untuk melakukan autentikasi ke repositori
   • /path/to/KEYPAIR_FILENAME: jalur ke pasangan kunci

   Jika Anda menggunakan host repositori Git pihak ketiga seperti GitHub, atau ingin menggunakan akun layanan dengan Cloud Source Repositories, sebaiknya gunakan akun terpisah.

   Catatan: Anda harus membuat kunci SSH tanpa frasa sandi. Config Sync tidak mendukung frasa sandi kunci SSH.

2. Konfigurasi repositori Anda untuk mengenali kunci publik yang baru dibuat. Lihat dokumentasi untuk penyedia hosting Git Anda. Petunjuk untuk beberapa penyedia hosting Git populer disertakan untuk memudahkan:

   • Cloud Source Repositories
   • Bitbucket
   • GitHub Sebaiknya buat kunci deploy terpisah untuk memberikan akses hanya baca ke satu repositori GitHub.
   • GitLab

3. Tambahkan kunci pribadi ke Secret baru dalam cluster:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   Ganti /path/to/KEYPAIR_PRIVATE_KEY_FILENAME dengan nama kunci pribadi (kunci tanpa akhiran .pub).

4. (Direkomendasikan) Untuk mengonfigurasi pemeriksaan host yang dikenal menggunakan autentikasi SSH, Anda dapat menambahkan kunci host yang dikenal ke kolom data.known_hosts di secret git_creds. Untuk menonaktifkan pemeriksaan known_hosts, Anda dapat menghapus kolom known_hosts dari secret. Untuk menambahkan kunci host yang dikenal, jalankan:

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   Kemudian, di bagian data, tambahkan entri host yang diketahui:

   known_hosts: KNOWN_HOSTS_KEY
   

5. Menghapus kunci pribadi dari disk lokal atau melindunginya.

6. Saat Anda mengonfigurasi Config Sync dan menambahkan URL untuk repositori Git Anda, gunakan protokol SSH. Jika menggunakan repositori di Cloud Source Repositories, Anda harus menggunakan format berikut saat memasukkan URL:

   ssh://[e-mail]:2022/p/PROJECT_ID/r/REPO_NAME
   

   Ganti kode berikut:

   • EMAIL: nama pengguna Google Cloud Anda
   • PROJECT_ID: ID project Google Cloud tempat repositori berada
   • REPO_NAME: nama repositori

File cookie

Catatan: Penggunaan kredensial cookiefile hanya didukung dengan Cloud Source Repositories. Jika ingin menggunakan GitHub dengan autentikasi cookiefile, Anda dapat menggunakan Cloud Source Repositories untuk mencerminkan repositori GitHub Anda.

Proses untuk mendapatkan cookiefile bergantung pada konfigurasi repositori Anda. Sebagai contoh, lihat Membuat kredensial statis dalam dokumentasi Cloud Source Repositories. Kredensial biasanya disimpan dalam file .gitcookies di direktori utama Anda, atau mungkin diberikan kepada Anda oleh administrator keamanan.

Untuk menggunakan cookiefile, selesaikan langkah-langkah berikut:

1. Setelah Anda membuat dan mendapatkan cookiefile, tambahkan ke Secret baru di cluster.

   Jika Anda tidak menggunakan proxy HTTPS, buat Secret dengan perintah berikut:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   Jika Anda perlu menggunakan proxy HTTPS, tambahkan proxy tersebut ke Secret bersama dengan cookiefile dengan menjalankan perintah berikut:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Ganti kode berikut:

   • /path/to/COOKIEFILE: jalur dan nama file yang sesuai
   • HTTPS_PROXY_URL: URL untuk proxy HTTPS yang Anda gunakan saat berkomunikasi dengan repositori Git
   Catatan: Proxy HTTP tidak didukung karena alasan keamanan.

2. Lindungi konten cookiefile jika Anda masih memerlukannya secara lokal. Jika tidak, hapus token tersebut.

Token

Jika organisasi Anda tidak mengizinkan penggunaan kunci SSH, Anda dapat memilih untuk menggunakan token. Dengan Config Sync, Anda dapat menggunakan token akses pribadi (PAT) GitHub, PAT GiLab, atau men-deploy kunci, atau sandi aplikasi Bitbucket sebagai token Anda.

Untuk membuat Secret menggunakan token Anda, selesaikan langkah-langkah berikut:

1. Buat token menggunakan GitHub, GitLab, atau Bitbucket:

   • GitHub: Buat PAT. Beri token cakupan repo agar dapat membaca dari repositori pribadi. Karena Anda mengikat PAT ke akun GitHub, sebaiknya buat pengguna mesin dan ikat PAT Anda ke pengguna mesin.
   • GitLab: Membuat PAT atau membuat token deploy
   • Bitbucket: Membuat sandi aplikasi.

2. Setelah Anda membuat dan mendapatkan token, tambahkan token tersebut ke Secret baru di cluster.

   Jika Anda tidak menggunakan proxy HTTPS, buat Secret dengan perintah berikut:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   Ganti kode berikut:

   • USERNAME: nama pengguna yang ingin Anda gunakan.
   • TOKEN: token yang Anda buat di langkah sebelumnya.

   Jika Anda perlu menggunakan proxy HTTPS, tambahkan proxy tersebut ke Secret bersama dengan username dan token dengan menjalankan perintah berikut:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Ganti kode berikut:

   • USERNAME: nama pengguna yang ingin Anda gunakan.
   • TOKEN: token yang Anda buat di langkah sebelumnya.
   • HTTPS_PROXY_URL: URL untuk proxy HTTPS yang Anda gunakan saat berkomunikasi dengan repositori Git.
   Catatan: Proxy HTTP tidak didukung karena alasan keamanan.

3. Lindungi token jika Anda masih memerlukannya secara lokal. Jika tidak, hapus data tersebut.

Akun layanan Google

Jika repositori Anda berada di Cloud Source Repositories, dan cluster Anda menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat memberi Config Sync akses ke repositori dalam project yang sama dengan cluster terkelola Anda menggunakan akun layanan Google.

1. Jika Anda belum memiliki akun layanan, buat akun layanan.

2. Berikan peran IAM Cloud Source Repositories Reader (roles/source.reader) ke akun layanan Google. Untuk mengetahui informasi selengkapnya tentang peran dan izin Cloud Source Repositories, lihat Memberikan izin untuk melihat repositori.

   • Berikan izin lingkup project jika izin yang sama berlaku untuk semua repositori dalam project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Berikan izin khusus repositori jika Anda ingin akun layanan memiliki tingkat akses yang berbeda untuk setiap repositori dalam project Anda.

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud Console, pilih Workload Identity sebagai Authentication Type, lalu tambahkan email akun layanan Anda.

   Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud CLI, tambahkan gcpserviceaccount sebagai secretType, lalu tambahkan email akun layanan ke gcpServiceAccountEmail.

4. Setelah mengonfigurasi Config Sync, buat binding kebijakan IAM antara akun layanan Kubernetes dan akun layanan Google. Akun layanan Kubernetes tidak akan dibuat hingga Anda mengonfigurasi Config Sync untuk pertama kalinya.

   Jika menggunakan cluster yang terdaftar ke suatu fleet, Anda hanya perlu membuat binding kebijakan satu kali per fleet. Semua cluster yang terdaftar dalam fleet memiliki Workload Identitypool yang sama. Dengan konsep fleet kesamaan, jika Anda menambahkan kebijakan IAM ke akun layanan Kubernetes dalam satu cluster, akun layanan Kubernetes dari namespace yang sama di cluster lain dalam fleet yang sama juga akan mendapatkan kebijakan IAM yang sama.

   Dengan binding ini, akun layanan Kubernetes Config Sync dapat bertindak sebagai akun layanan Google:

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Ganti kode berikut:

• PROJECT_ID: project ID organisasi.
• FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, adalah project ID fleet tempat cluster Anda terdaftar.
• GSA_NAME: akun layanan Google kustom yang ingin Anda gunakan untuk terhubung ke Artifact Registry. Akun layanan harus memiliki peran IAM Artifact Registry Reader (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiler.
  • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME. Jika Anda menginstal Config Sync menggunakan Google Cloud Console atau Google Cloud CLI, Config Sync akan otomatis membuat objek RootSync yang bernama root-sync.
• REPOSITORY: nama repositori.
• POLICY_FILE: file JSON atau YAML dengan kebijakan Identity and Access Management.

Catatan: Untuk membuat binding kebijakan ini, diperlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika repositori Anda berada di Cloud Source Repositories, dan cluster Anda adalah GKE di Google Cloud dengan Workload Identity dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi.

Jika Anda mengonfigurasi Config Sync menggunakan Konsol Google Cloud, pilih Google Cloud Repository sebagai Authentication Type.

Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud CLI, tambahkan gcenode sebagai secretType.

Dengan memilih Google Cloud Repository atau gcenode, Anda akan dapat menggunakan akun layanan default Compute Engine. Anda harus memberikan peran IAM Cloud Source Repositories Reader (roles/source.reader) ke akun layanan default Compute Engine. Untuk mengetahui informasi selengkapnya tentang peran dan izin Cloud Source Repositories, lihat Memberikan izin untuk melihat repositori.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:[e-mail]"

Ganti PROJECT_ID dengan project ID organisasi Anda, dan ganti PROJECT_NUMBER dengan nomor project organisasi Anda.

Memberikan akses hanya baca Operator ke OCI

Config Sync memerlukan akses hanya baca ke image OCI yang disimpan di Artifact Registry agar dapat membaca konfigurasi yang disertakan dalam image dan menerapkannya ke cluster Anda.

Jika image Anda tidak memerlukan autentikasi untuk akses hanya baca, Anda dapat melanjutkan untuk mengonfigurasi Config Sync dan menggunakan none sebagai jenis autentikasi. Misalnya, jika gambar Anda bersifat publik dan dapat diakses oleh siapa saja di internet, Anda tidak perlu melakukan autentikasi.

Namun, sebagian besar pengguna perlu membuat kredensial untuk mengakses gambar yang dibatasi. Config Sync mendukung mekanisme autentikasi berikut:

• Akun layanan Kubernetes (k8sserviceaccount)
• Akun layanan Google (gcpserviceaccount)

• Akun layanan default Compute Engine (gcenode)

Akun layanan Kubernetes

Jika Anda menyimpan image OCI di Artifact Registry dan cluster menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi pada versi 1.17.2 dan yang lebih baru. Opsi ini lebih direkomendasikan daripada gcpserviceaccount karena proses konfigurasinya yang lebih sederhana.

1. Berikan peran IAM Artifact Registry Reader (roles/artifactregistry.reader) ke akun layanan Kubernetes dengan kumpulan Workload Identity. Untuk mengetahui informasi selengkapnya tentang peran dan izin Artifact Registry, lihat Mengonfigurasi peran dan izin untuk Artifact Registry.

   • Berikan izin lingkup project jika izin yang sama berlaku untuk semua repositori dalam project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Berikan izin khusus repositori jika Anda ingin akun layanan memiliki tingkat akses yang berbeda untuk setiap repositori dalam project Anda.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Ganti kode berikut:

   • PROJECT_ID: project ID organisasi.
   • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiler.
     • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME. Jika Anda menginstal Config Sync menggunakan Google Cloud Console atau Google Cloud CLI, Config Sync akan otomatis membuat objek RootSync yang bernama root-sync.
   • REPOSITORY: ID repositori.
   • LOCATION: lokasi regional atau multi-regional repositori.
   Catatan: Untuk membuat binding kebijakan ini, diperlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika Anda menyimpan image OCI di Artifact Registry dan cluster Anda menggunakan GKE Workload Identity atau Workload Identity Fleet, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Dengan opsi ini, Anda tidak perlu lagi melakukan langkah-langkah tambahan dalam membuat akun layanan Google dan binding kebijakan IAM terkait.

1. Jika Anda belum memiliki akun layanan, buat akun layanan.

2. Berikan peran IAM Artifact Registry Reader (roles/artifactregistry.reader) ke akun layanan Google. Untuk mengetahui informasi selengkapnya tentang peran dan izin Artifact Registry, lihat Mengonfigurasi peran dan izin untuk Artifact Registry.

   • Berikan izin lingkup project jika izin yang sama berlaku untuk semua repositori dalam project.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Berikan izin khusus repositori jika Anda ingin akun layanan memiliki tingkat akses yang berbeda untuk setiap repositori dalam project Anda.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Buat binding kebijakan IAM antara akun layanan Kubernetes dan akun layanan Google dengan menjalankan perintah berikut:

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Ganti kode berikut:

• PROJECT_ID: project ID organisasi.
• FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, adalah project ID fleet tempat cluster Anda terdaftar.
• GSA_NAME: akun layanan Google kustom yang ingin Anda gunakan untuk terhubung ke Artifact Registry. Akun layanan harus memiliki peran IAM Artifact Registry Reader (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiler.
  • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME. Jika Anda menginstal Config Sync menggunakan Google Cloud Console atau Google Cloud CLI, Config Sync akan otomatis membuat objek RootSync yang bernama root-sync.
• REPOSITORY: ID repositori.
• LOCATION: lokasi regional atau multi-regional repositori.

Catatan: Untuk membuat binding kebijakan ini, diperlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda adalah GKE di Google Cloud dengan Workload Identity dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi. Config Sync menggunakan akun layanan default Compute Engine. Anda harus memberikan akses pembaca akun layanan default Compute Engine ke Artifact Registry.

1. Beri akun layanan Compute Engine izin baca ke Artifact Registry dengan menjalankan perintah berikut:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/artifactregistry.reader
   

   Ganti PROJECT_ID dengan project ID organisasi Anda, dan ganti PROJECT_NUMBER dengan nomor project organisasi Anda.

Mengonfigurasi Operator untuk Certificate Authority

Untuk server Git yang dikonfigurasi dengan sertifikat dari Certificate Authority (CA) yang belum dipercaya, Config Sync dapat dikonfigurasi agar menggunakan sertifikat CA guna memverifikasi koneksi HTTPS ke server Git. Sertifikat CA harus menyertakan sertifikat SSL lengkap (Root/Intermediate/Leaf). Jika server Git Anda sudah menggunakan CA tepercaya atau Anda tidak terhubung melalui HTTPS, Anda dapat melewati langkah ini dan tidak menyetel caCertSecretRef.

RootSync

1. Ambil sertifikat CA yang digunakan untuk menerbitkan sertifikat bagi server Git Anda dan simpan ke sebuah file.

2. Untuk objek RootSync, Secret harus dibuat di namespace config-management-system. Contoh:

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Saat Anda mengonfigurasi Operator, tetapkan nilai kolom spec.git.caCertSecretRef.name di objek RootSync ke ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Ambil sertifikat CA yang digunakan untuk menerbitkan sertifikat bagi server Git Anda dan simpan ke sebuah file.

2. Untuk objek RepoSync, Secret harus dibuat dalam namespace yang sama dengan RepoSync. Contoh:

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Saat Anda mengonfigurasi RepoSync, tetapkan nilai kolom spec.git.caCertSecretRef.name dalam objek RepoSync ke NAMESPACE_CA_CERT_SECRET_NAME.

Memberikan akses hanya baca Operator ke Helm

Config Sync memerlukan akses hanya baca ke repositori Helm agar dapat membaca diagram Helm di repositori Anda dan menginstalnya di cluster Anda.

Jika repositori tidak memerlukan autentikasi untuk akses hanya baca, Anda dapat terus mengonfigurasi Config Sync dan menggunakan none sebagai jenis autentikasi. Misalnya, jika repositori Helm Anda bersifat publik dan dapat diakses oleh siapa saja di internet, Anda tidak perlu melakukan autentikasi.

Namun, sebagian besar pengguna perlu membuat kredensial untuk mengakses repositori Helm pribadi. Config Sync mendukung mekanisme autentikasi berikut:

• Token (token)
• Akun layanan Kubernetes (k8sserviceaccount)
• Akun layanan Google (gcpserviceaccount)
• Akun layanan default Compute Engine (gcenode)

Catatan: Config Sync tidak mendukung konfigurasi helm sebagai jenis sumber menggunakan Konsol Google Cloud atau Google Cloud CLI. Anda dapat mengonfigurasi objek RootSync atau RepoSync untuk disinkronkan dari repositori Helm menggunakan Kubernetes API, atau mendeklarasikan di sumber tepercaya lainnya. Lihat Konfigurasi untuk repositori Helm untuk mengetahui informasi selengkapnya.

Token

Buat Secret dengan nama pengguna dan sandi repositori Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Ganti kode berikut:

• SECRET_NAME: nama yang ingin Anda berikan Secret Anda.
• USERNAME: nama pengguna repositori Helm.
• PASSWORD: sandi repositori Helm.

Saat Mengonfigurasi Operator ConfigManagement, Anda akan menggunakan nama Secret yang Anda pilih untuk spec.helm.secretRef.name.

Akun layanan Kubernetes

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi pada versi 1.17.2 dan yang lebih baru. Opsi ini lebih direkomendasikan daripada gcpserviceaccount karena proses konfigurasinya yang lebih sederhana.

1. Berikan peran IAM Artifact Registry Reader (roles/artifactregistry.reader) ke akun layanan Kubernetes dengan kumpulan Workload Identity. Untuk mengetahui informasi selengkapnya tentang peran dan izin Artifact Registry, lihat Mengonfigurasi peran dan izin untuk Artifact Registry.

   • Berikan izin lingkup project jika izin yang sama berlaku untuk semua repositori dalam project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Berikan izin khusus repositori jika Anda ingin akun layanan memiliki tingkat akses yang berbeda untuk setiap repositori dalam project Anda.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Ganti kode berikut:

   • PROJECT_ID: project ID organisasi.
   • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiler.
     • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME.
   • REPOSITORY: ID repositori.
   • LOCATION: lokasi regional atau multi-regional repositori.

Catatan: Untuk membuat binding kebijakan ini, diperlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda menggunakan GKE Workload Identity atau Workload Identity Fleet, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Dengan opsi ini, Anda tidak perlu lagi melakukan langkah-langkah tambahan dalam membuat akun layanan Google dan binding kebijakan IAM terkait.

1. Jika Anda belum memiliki akun layanan, buat akun layanan.

2. Berikan peran IAM Artifact Registry Reader (roles/artifactregistry.reader) ke akun layanan Google. Untuk mengetahui informasi selengkapnya tentang peran dan izin Artifact Registry, lihat Mengonfigurasi peran dan izin untuk Artifact Registry.

   • Berikan izin lingkup project jika izin yang sama berlaku untuk semua repositori dalam project.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Berikan izin khusus repositori jika Anda ingin akun layanan memiliki tingkat akses yang berbeda untuk setiap repositori dalam project Anda.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Buat binding kebijakan IAM antara akun layanan Kubernetes dan akun layanan Google dengan menjalankan perintah berikut:

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
       --project=PROJECT_ID
   

Ganti kode berikut:

• PROJECT_ID: project ID organisasi.
• FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, adalah project ID fleet tempat cluster Anda terdaftar.
• GSA_NAME: akun layanan Google kustom yang ingin Anda gunakan untuk terhubung ke Artifact Registry. Akun layanan harus memiliki peran IAM Artifact Registry Reader (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiler.
  • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME.
• REPOSITORY: ID repositori.
• LOCATION: lokasi regional atau multi-regional repositori.

Catatan: Untuk membuat binding kebijakan ini, diperlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda adalah GKE di Google Cloud dengan Workload Identity dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi. Config Sync menggunakan akun layanan default Compute Engine. Anda harus memberikan akses pembaca akun layanan default Compute Engine ke Artifact Registry. Anda mungkin perlu memberikan cakupan akses storage-ro untuk memberikan izin hanya baca untuk mengambil gambar.

1. Berikan izin baca akun layanan Compute Engine ke Artifact Registry:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=roles/artifactregistry.reader
   

   Ganti PROJECT_ID dengan project ID organisasi Anda, dan ganti PROJECT_NUMBER dengan nomor project organisasi Anda.

Mengonfigurasi Operator

Untuk mengonfigurasi sinkronisasi dari repositori root, Anda harus mengaktifkan mode multi-repo di objek ConfigManagement dan membuat objek RootSync yang menyinkronkan repositori root ke cluster. Anda hanya dapat membuat satu repositori root per cluster dan repositori root dapat berupa repositori tidak terstruktur atau repositori hierarkis.

1. Jika Anda menggunakan webhook penerimaan Config Sync (webhook penerimaan dinonaktifkan secara default) dan menginstal Config Sync di cluster pribadi, tambahkan aturan firewall untuk mengizinkan port 10250. Webhook penerimaan Config Sync menggunakan port 10250 untuk pencegahan penyimpangan.

2. Buat file bernama config-management.yaml dan salin file YAML berikut ke dalamnya:

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   Ganti kode berikut:

   • PREVENT_DRIFT: Jika ditetapkan ke true, mengaktifkan webhook penerimaan Config Sync untuk mencegah penyimpangan dengan menolak perubahan yang bertentangan agar tidak dikirim ke cluster live. Setelan defaultnya adalah false. Config Sync selalu memperbaiki penyimpangan, apa pun nilai kolom ini.

3. Terapkan perubahan:

   kubectl apply -f config-management.yaml
   

4. Tunggu hingga CRD RootSync dan RepoSync tersedia:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

5. Simpan salah satu manifes berikut sebagai root-sync.yaml. Gunakan versi manifes yang sesuai dengan jenis sumber untuk konfigurasi Anda.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ganti kode berikut:

   • ROOT_SYNC_NAME: tambahkan nama objek RootSync.
   • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Kolom ini bersifat opsional dan nilai defaultnya adalah hierarchy. Sebaiknya tambahkan unstructured karena format ini memungkinkan Anda mengatur konfigurasi dengan cara yang paling nyaman bagi Anda.
   • ROOT_REPOSITORY: menambahkan URL repositori Git untuk digunakan sebagai repositori root. Anda dapat memasukkan URL menggunakan protokol HTTPS atau SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
   • ROOT_REVISION: menambahkan revisi Git (tag atau hash) yang akan disinkronkan. Kolom ini bersifat opsional dan nilai defaultnya adalah HEAD. Mulai dari Config Sync versi 1.17.0, Anda juga dapat menentukan nama cabang di kolom revision. Saat menggunakan hash di versi 1.17.0 atau yang lebih baru, hash tersebut harus berupa hash lengkap, bukan bentuk singkat.
   • ROOT_BRANCH: menambahkan cabang repositori yang akan disinkronkan. Kolom ini bersifat opsional dan nilai defaultnya adalah master. Mulai dari Config Sync versi 1.17.0, sebaiknya gunakan kolom revision untuk menentukan nama cabang agar lebih mudah. Jika kolom revision dan kolom branch ditentukan, revision akan lebih diprioritaskan daripada branch.
   • ROOT_DIRECTORY: menambahkan jalur dalam repositori Git ke direktori utama yang berisi konfigurasi yang ingin Anda sinkronkan. Kolom ini bersifat opsional dan defaultnya adalah direktori utama (/) repositori.

   • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

     • none: Tidak menggunakan autentikasi
     • ssh: Menggunakan pasangan kunci SSH
     • cookiefile: Gunakan cookiefile
     • token: Menggunakan token
     • gcpserviceaccount: Menggunakan akun layanan Google untuk mengakses Cloud Source Repositories.
     • gcenode: Menggunakan akun layanan Google untuk mengakses Cloud Source Repositories. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.

     Untuk mengetahui informasi selengkapnya tentang jenis autentikasi ini, lihat Memberikan akses hanya baca Config Sync ke Git.

     Kolom ini wajib diisi.

   • ROOT_EMAIL: Jika Anda menambahkan gcpserviceaccount sebagai ROOT_AUTH_TYPE, tambahkan alamat email akun layanan Google Anda. Contoh, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: tambahkan nama Rahasia Anda. Jika kolom ini ditetapkan, Anda harus menambahkan kunci publik Secret ke penyedia Git. Kolom ini bersifat opsional.

   • ROOT_NO_SSL_VERIFY: Untuk menonaktifkan verifikasi sertifikat SSL, tetapkan kolom ini ke true. Nilai defaultnya adalah false.

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Secret Anda. Jika kolom ini disetel, penyedia Git Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Secret ini harus berisi sertifikat CA dengan kunci bernama cert. Kolom ini bersifat opsional.

     Untuk mempelajari lebih lanjut cara mengonfigurasi objek Secret untuk sertifikat CA, lihat Mengonfigurasi Operator untuk Certificate Authority

   Untuk mengetahui penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan Git sebagai sumber.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
   

   Ganti kode berikut:

   • ROOT_SYNC_NAME: tambahkan nama objek RootSync.
   • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Kolom ini bersifat opsional dan nilai defaultnya adalah hierarchy. Sebaiknya tambahkan unstructured karena format ini memungkinkan Anda mengatur konfigurasi dengan cara yang paling nyaman bagi Anda.
   • ROOT_IMAGE: URL image OCI yang akan digunakan sebagai repositori root, misalnya LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Secara default, gambar diambil dari tag latest, tetapi Anda dapat menarik gambar dengan TAG atau DIGEST. Tentukan TAG atau DIGEST di PACKAGE_NAME:
     • Untuk menarik menurut TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Untuk menarik menurut DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   Perhatian: Config Sync mengharuskan lapisan OCI dikompresi di tar atau tar+gzip. Format lain (misalnya, tar+bz2) tidak akan dikenali oleh Config Sync. Beralih dari REPO yang valid ke image OCI dengan format yang tidak didukung akan menyebabkan resource terkelola dipangkas tanpa error.

   • ROOT_DIRECTORY: menambahkan jalur dalam repositori ke direktori utama yang berisi konfigurasi yang ingin Anda sinkronkan. Kolom ini bersifat opsional dan defaultnya adalah direktori utama (/) repositori.

   • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

     • none: Tidak menggunakan autentikasi
     • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.
     • gcpserviceaccount: Menggunakan akun layanan Google untuk mengakses image.

     Kolom ini wajib diisi.

   • ROOT_EMAIL: Jika Anda menambahkan gcpserviceaccount sebagai ROOT_AUTH_TYPE, tambahkan alamat email akun layanan Google Anda. Contoh, acm@PROJECT_ID.iam.gserviceaccount.com.

   Untuk mengetahui penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan gambar OCI sebagai sumber.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
   

   Ganti kode berikut:

   • ROOT_SYNC_NAME: tambahkan nama objek RootSync.
   • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Kolom ini bersifat opsional dan nilai defaultnya adalah hierarchy. Sebaiknya tambahkan unstructured karena format ini memungkinkan Anda mengatur konfigurasi dengan cara yang paling nyaman bagi Anda.
   • ROOT_HELM_REPOSITORY: URL repositori Helm yang akan digunakan sebagai repositori root. Anda dapat memasukkan URL menggunakan protokol HTTPS atau SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
   • HELM_CHART_NAME: menambahkan nama diagram Helm. Kolom ini wajib diisi.
   • HELM_CHART_VERSION: versi diagram Anda. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, versi terbaru akan digunakan.
   • HELM_RELEASE_NAME: nama rilis Helm. Kolom ini bersifat opsional.
   • HELM_RELEASE_NAMESPACE: namespace target untuk rilis. Class ini hanya menetapkan namespace untuk resource yang berisi namespace: {{ .Release.Namespace }} dalam template-nya. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, namespace default config-management-system akan digunakan.
   • HELM_INCLUDE_CRDS: disetel ke true jika Anda ingin template Helm juga membuat CustomResourceDefinition. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, defaultnya adalah false dan CRD tidak akan dibuat.
   • VALUE: nilai yang akan digunakan, bukan nilai default yang menyertai diagram Helm. Format kolom ini dengan cara yang sama seperti file helm chart's values.yaml. Kolom ini bersifat opsional.

   • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

     • none: Tidak menggunakan autentikasi
     • token: Menggunakan nama pengguna dan sandi untuk mengakses repositori Helm pribadi.
     • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.
     • gcpserviceaccount: Menggunakan akun layanan Google untuk mengakses image.

     Kolom ini wajib diisi.

   • ROOT_EMAIL: Jika Anda menambahkan gcpserviceaccount sebagai ROOT_AUTH_TYPE, tambahkan alamat email akun layanan Google Anda. Contoh, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: tambahkan nama Secret Anda jika token adalah ROOT_AUTH_TYPE. Kolom ini bersifat opsional.

   Untuk mengetahui penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan Helm sebagai sumber.

6. Terapkan perubahan:

   kubectl apply -f root-sync.yaml
   

Memverifikasi status sinkronisasi repositori root

Anda dapat menggunakan perintah nomos status untuk memeriksa status sinkronisasi repositori root:

nomos status

Anda akan melihat output yang mirip dengan contoh berikut ini:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Memverifikasi penginstalan RootSync

Saat Anda membuat objek RootSync, Config Sync akan membuat rekonsiler dengan awalan root-reconciler. Rekonsiler adalah Pod yang di-deploy sebagai Deployment. Menyinkronkan manifes dari repositori Git ke cluster.

Anda dapat memverifikasi bahwa objek RootSync berfungsi dengan benar dengan memeriksa status Deployment root-reconciler:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Ganti ROOT_SYNC_NAME dengan nama RootSync.

Anda akan melihat output yang mirip dengan contoh berikut ini:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Cara lain untuk mempelajari status objek RootSync Anda dapat dilihat di Memantau objek RootSync dan RepoSync.

Setelah selesai mengonfigurasi repositori root, Anda juga dapat memilih untuk mengonfigurasi sinkronisasi dari beberapa repositori. Repositori ini sangat membantu jika Anda menginginkan repositori yang berisi konfigurasi cakupan namespace yang disinkronkan ke namespace tertentu di seluruh cluster.

Upgrade Config Sync

Catatan: Mengupgrade dari versi yang lebih lama dari 1.10.0 akan menghapus semua resource webhook akses masuk Config Sync.

Catatan: Jika mengupgrade dari versi yang tidak didukung, Anda harus melakukan upgrade langkah demi langkah dengan penambahan hingga tiga versi minor sekaligus. Misalnya, jika versi Config Sync saat ini adalah 1.10.0, lanjutkan ke upgrade ke versi 1.13.0, lalu ke versi 1.16.0, dan seterusnya.

Untuk mengupgrade Config Sync, jalankan perintah berikut untuk setiap cluster yang terdaftar:

1. Download manifes Config Sync dan perintah nomos untuk versi baru.

2. Terapkan manifes Config Sync:

   kubectl apply -f config-management-operator.yaml
   

   Perintah ini memperbarui image ConfigManagement Operator. Kubernetes mengambil versi baru dan memulai ulang Pod Config Sync menggunakan versi baru. Saat Config Sync dimulai, Config Sync akan menjalankan loop rekonsiliasi yang menerapkan kumpulan manifes yang dipaketkan dalam gambar baru. Tindakan ini akan mengupdate dan memulai ulang setiap Pod komponen.

3. Ganti perintah nomos pada semua klien dengan versi baru. Perubahan ini memastikan bahwa perintah nomos selalu bisa mendapatkan status semua cluster terdaftar dan dapat memvalidasi konfigurasi untuk cluster tersebut.

Meng-uninstal Config Sync

Perhatian: Ini adalah masalah umum ketika menghapus objek RootSync atau RepoSync tidak membersihkan anotasi dan label Config Sync, dan webhook akses masuk Config Sync menolak permintaan yang mencoba menghapus resource ini jika Config Sync masih diaktifkan di cluster. Solusinya adalah membatalkan pengelolaan atau menghapus resource terkelola ini sebelum menghapus objek RootSync atau RepoSync yang terkait.

Untuk meng-uninstal Config Sync, selesaikan langkah-langkah berikut:

1. Administrator pusat harus menghapus repo root:

   1. Batalkan pengelolaan atau hapus resource yang dikelola oleh objek RootSync dengan mengikuti petunjuk pemecahan masalah.

   2. Hapus objek RootSync dengan menjalankan perintah berikut:

      kubectl delete -f root-sync.yaml
      

2. Hapus semua repositori.

3. Hapus kolom spec.enableMultiRepo di file config-management.yaml Anda.

4. Terapkan file config-management.yaml ke cluster Anda.

Catatan: Menonaktifkan fitur ini tidak memengaruhi konfigurasi apa pun yang sebelumnya diterapkan Config Sync ke cluster Anda.

Jika Anda ingin meng-uninstal Config Sync sepenuhnya, lihat Menghapus Operator ConfigManagement.

Langkah selanjutnya

• Pelajari cara mengonfigurasi sinkronisasi dari beberapa repositori.