Menginstal Config Sync secara manual menggunakan kubectl (tidak direkomendasikan)

Halaman ini menunjukkan cara menginstal Config Sync menggunakan perintah kubectl. ConfigManagement Operator adalah pengontrol yang mengelola Config Sync di cluster Kubernetes. Ikuti langkah-langkah berikut 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 Anda penuhi sebelum menginstal Config Sync menggunakan kubectl.

Menyiapkan lingkungan lokal Anda

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

• Buat, atau miliki akses ke sumber kebenaran.

• Instal dan lakukan 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

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 diperlukan, 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 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 kustom atau peran bawaan lainnya.

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

Mendaftarkan cluster

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

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

Men-deploy Operator

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

1. Download versi terbaru manifes Operator 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 pada objek ConfigManagement yang bukan disebabkan oleh error sintaksis YAML atau JSON, instance objek mungkin telah dibuat dalam 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 memiliki status PENDING atau SYNCED.

Penginstalan yang tidak valid memiliki 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 Anda membuatnya, dan Anda tidak perlu menerapkan ulang konfigurasi.

Berikan akses hanya baca kepada Operator

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

Berikan akses hanya baca kepada 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 Anda 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 yang disimpan, 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 dalam Secret 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 berikut untuk autentikasi:

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

Mekanisme yang Anda pilih bergantung pada apa yang didukung repositori Anda. Secara umum, kami merekomendasikan penggunaan pasangan kunci SSH. GitHub dan Bitbucket keduanya mendukung pasangan kunci SSH. Namun, jika Anda menggunakan repositori di Cloud Source Repositories, sebaiknya gunakan akun layanan Google karena prosesnya lebih sederhana. Jika organisasi 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, 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, Anda dapat menambahkan URL di kolom URL. Jika mengonfigurasi Config Sync menggunakan Google Cloud CLI, Anda dapat menambahkan URL ke kolom syncRepo file konfigurasi Anda.

Pasangan kunci SSH

Pasangan kunci SSH terdiri dari dua file, yaitu 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 satu pasangan kunci 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 guna 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 Anda membuat kunci deployment terpisah untuk memberikan akses hanya baca ke satu repositori GitHub.
   • GitLab

3. Tambahkan kunci pribadi ke Secret baru di 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 yang tidak memiliki akhiran .pub).

4. (Direkomendasikan) Untuk mengonfigurasi pemeriksaan host yang dikenal menggunakan autentikasi SSH, Anda dapat menambahkan kunci host yang diketahui ke kolom data.known_hosts di rahasia git_creds. Untuk menonaktifkan pemeriksaan known_hosts, Anda dapat menghapus kolom known_hosts dari rahasia. Untuk menambahkan kunci host yang diketahui, 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. Hapus kunci pribadi dari disk lokal atau lindungi dengan cara lain.

6. Saat 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, baca 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 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: Membuat PAT. Berikan cakupan repo pada token 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 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 file 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 memberikan akses Config Sync 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 di seluruh 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.

     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 Anda ke gcpServiceAccountEmail.

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

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

   Dengan binding ini, akun layanan Config Sync Kubernetes 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, ini 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 rekonsiliasi.
  • 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 Konsol Google Cloud atau Google Cloud CLI, Config Sync otomatis akan membuat objek RootSync yang bernama root-sync.
• REPOSITORY: nama repositori.
• POLICY_FILE: file JSON atau YAML dengan kebijakan Pengelolaan Akses dan Identitas.

Catatan: Pembuatan binding kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

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

Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud Console, 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 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.

Berikan akses hanya baca kepada Operator ke OCI

Config Sync memerlukan akses hanya baca ke image OCI Anda 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 terus mengonfigurasi Config Sync dan menggunakan none sebagai jenis autentikasi. Misalnya, jika image 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 image yang dibatasi. Config Sync mendukung mekanisme berikut untuk autentikasi:

• 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 Anda menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi di versi 1.17.2 dan yang lebih baru. Opsi ini direkomendasikan daripada gcpserviceaccount karena proses konfigurasinya yang disederhanakan.

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 di seluruh 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.

     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, ini adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiliasi.
     • 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 Konsol Google Cloud atau Google Cloud CLI, Config Sync otomatis akan membuat objek RootSync yang bernama root-sync.
   • REPOSITORY: ID repositori.
   • LOCATION: lokasi repositori regional atau multi-regional.
   Catatan: Pembuatan binding kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika menyimpan image OCI di Artifact Registry dan cluster menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Opsi ini meniadakan langkah-langkah tambahan untuk membuat akun layanan Google dan binding kebijakan IAM yang 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 di seluruh 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.

     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, ini 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 rekonsiliasi.
  • 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 Konsol Google Cloud atau Google Cloud CLI, Config Sync otomatis akan membuat objek RootSync yang bernama root-sync.
• REPOSITORY: ID repositori.
• LOCATION: lokasi repositori regional atau multi-regional.

Catatan: Pembuatan binding kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda adalah GKE dengan Workload Identity dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi Anda. Config Sync menggunakan akun layanan default Compute Engine. Anda harus memberi 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 yang dikonfigurasi dengan sertifikat dari Certificate Authority (CA) yang belum tepercaya, Config Sync dapat dikonfigurasi untuk menggunakan sertifikat CA guna memverifikasi koneksi HTTPS ke server. Ini didukung untuk server Git, Helm, atau OCI. Sertifikat CA harus menyertakan sertifikat SSL lengkap (Root/Intermediate/Leaf). Jika server telah menggunakan CA tepercaya atau Anda tidak terhubung melalui HTTPS, Anda dapat melewati langkah ini dan membiarkan caCertSecretRef tidak disetel.

RootSync

1. Ambil sertifikat CA yang digunakan untuk menerbitkan sertifikat bagi server Git Anda, lalu simpan ke 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 mengonfigurasi Operator, tetapkan nilai kolom 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, lalu simpan ke 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 mengonfigurasi RepoSync, tetapkan nilai kolom caCertSecretRef.name dalam objek RepoSync ke NAMESPACE_CA_CERT_SECRET_NAME.

Memberikan akses hanya baca kepada Operator ke Helm

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

Jika repositori Anda 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 berikut untuk autentikasi:

• 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 dalam sumber tepercaya lain. 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 Anda menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi di versi 1.17.2 dan yang lebih baru. Opsi ini direkomendasikan daripada gcpserviceaccount karena proses konfigurasinya yang disederhanakan.

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 di seluruh 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.

     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, ini adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiliasi.
     • 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 repositori regional atau multi-regional.

Catatan: Pembuatan binding kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster menggunakan GKE Workload Identity atau fleet Workload Identity, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Opsi ini meniadakan langkah-langkah tambahan untuk membuat akun layanan Google dan binding kebijakan IAM yang 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 di seluruh 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.

     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, ini 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 rekonsiliasi.
  • 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 repositori regional atau multi-regional.

Catatan: Pembuatan binding kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda adalah GKE dengan Workload Identity dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi Anda. Config Sync menggunakan akun layanan default Compute Engine. Anda harus memberi 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. Beri akun layanan Compute Engine izin baca 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 dengan 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 (web webhook akses 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, lalu 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 disetel ke true, webhook penerimaan Config Sync dapat mencegah penyimpangan dengan menolak perubahan yang bertentangan agar tidak dikirim ke cluster aktif. Setelan default-nya 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: tambahkan URL repositori Git 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.
   • 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. Jika menggunakan hash pada 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 di 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: Menggunakan cookiefile
     • token: Gunakan 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 Secret Anda. Jika kolom ini disetel, Anda harus menambahkan kunci publik Secret ke penyedia Git. Kolom ini bersifat opsional.

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

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Rahasia Anda. Jika kolom ini disetel, penyedia Git Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Secret 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 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
       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_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 sebagai gantinya. Tentukan TAG atau DIGEST di PACKAGE_NAME:
     • Untuk menarik oleh TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Untuk menarik oleh 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 gambar.

     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_CA_CERT_SECRET_NAME: tambahkan nama Rahasia Anda. Jika kolom ini disetel, penyedia OCI Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Secret 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 penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan image 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
       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_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. Perintah ini hanya menetapkan namespace untuk resource yang berisi namespace: {{ .Release.Namespace }} dalam templatenya. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, namespace default config-management-system akan digunakan.
   • HELM_INCLUDE_CRDS: ditetapkan ke true jika Anda ingin template Helm juga menghasilkan 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 value.yaml diagram helm. 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 gambar.

     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.

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Rahasia Anda. Jika kolom ini disetel, penyedia Helm Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Secret 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 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 rekonsiliasi dengan awalan root-reconciler. Rekonsiliasi adalah Pod yang di-deploy sebagai Deployment. Layanan ini menyinkronkan manifes dari repositori Git ke cluster.

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

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

Untuk mengetahui cara menjelajahi status objek RootSync lebih lanjut, lihat Memantau objek RootSync dan RepoSync.

Setelah selesai mengonfigurasi repositori root, Anda dapat memilih untuk mengonfigurasi sinkronisasi dari beberapa repositori. Repositori ini akan berguna 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 penerimaan Config Sync.

Catatan: Jika mengupgrade dari versi yang tidak didukung, Anda harus melakukan upgrade langkah demi langkah dengan penambahan tidak lebih dari 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 mengupdate image ConfigManagement Operator. Kubernetes mengambil versi baru dan memulai ulang Pod Config Sync menggunakan versi baru. Saat dimulai, Config Sync akan menjalankan loop rekonsiliasi yang menerapkan kumpulan manifes yang dipaketkan dalam image 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: Menghapus objek RootSync atau RepoSync tidak akan membersihkan anotasi dan label Config Sync, dan webhook penerimaan Config Sync akan 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 sesuai.

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

1. Administrator pusat harus menghapus repo root:

   1. Jika Anda telah mengaktifkan webhook dan ingin mempertahankan resource, nonaktifkan pencegahan penyimpangan untuk resource yang diabaikan. Jika belum mengaktifkan webhook, Anda tidak perlu melakukan langkah tambahan apa pun untuk menyimpan resource.

   2. Hapus objek RootSync dengan menjalankan perintah berikut:

      kubectl delete -f root-sync.yaml
      

2. Hapus repositori apa pun.

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 akan memengaruhi konfigurasi apa pun yang sebelumnya diterapkan oleh Config Sync ke cluster Anda.

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

Langkah selanjutnya

• Temukan cara mengonfigurasi sinkronisasi dari beberapa repositori.