Menginstal Config Sync secara manual menggunakan kubectl (tidak direkomendasikan)

Halaman ini menunjukkan cara menginstal Config Sync menggunakan perintah kubectl.

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

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

• Membuat, atau memiliki akses ke sumber tepercaya.

• Instal dan lakukan inisialisasi Google Cloud CLI, yang menyediakan perintah gcloud, 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

Buat, atau miliki akses ke, cluster edisi Enterprise Google Kubernetes Engine (GKE) 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 Anda perlu memberikan akses Config Sync 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 dapat mendapatkan izin ini dengan peran khusus atau peran standar 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 Config Sync
2. Berikan akses hanya baca ke Config Sync untuk salah satu hal berikut:
   • Git
   • OCI
   • Helm
3. Mengonfigurasi Config Sync

Men-deploy Config Sync

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

1.20.0 atau yang lebih baru

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

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. Ekstrak arsip:

   tar -xzvf config-sync.tar.gz

3. Dalam arsip yang Anda ekstrak di langkah sebelumnya, ikuti petunjuk dalam README yang disediakan untuk mengedit penyesuaian.

4. Untuk mengupdate penginstalan Config Sync, terapkan manifes yang dirender yang Anda build dengan mengikuti petunjuk README:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Ganti CONFIG_SYNC_MANIFEST dengan nama manifes yang dirender.

5. Ganti perintah nomos di semua klien dengan versi baru. Perubahan ini memastikan bahwa perintah nomos selalu dapat mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuknya.

1.19.2 atau yang lebih lama

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

2. Terapkan manifes Config Sync:

   kubectl apply -f config-management-operator.yaml
   

3. 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, akan mengaktifkan webhook izin Config Sync untuk mencegah drift dengan menolak perubahan yang bertentangan agar tidak didorong ke cluster aktif. Setelan default-nya adalah false. Config Sync selalu memperbaiki penyimpangan, apa pun nilai kolom ini.

4. Terapkan perubahan:

   kubectl apply -f config-management.yaml
   

5. Ganti perintah nomos di semua klien dengan versi baru. Perubahan ini memastikan bahwa perintah nomos selalu dapat mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuknya.

Jika gagal karena masalah pada Config Sync yang bukan akibat error sintaksis YAML atau JSON, objek mungkin 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 memiliki status PENDING atau SYNCED.

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

• missing git-creds Secret
• 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 Config Sync ke cluster.

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

Memberikan akses hanya baca ke Config Sync

Jika menyimpan konfigurasi di Git, Anda harus memberi Config Sync akses hanya baca ke Git. Jika menyimpan konfigurasi sebagai image OCI, Anda harus memberikan akses hanya baca ke OCI untuk Config Sync. Jika menyimpan konfigurasi di Helm, Anda harus memberikan akses hanya baca ke Helm untuk Config Sync.

Memberikan akses hanya baca ke Git untuk Config Sync

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 baca saja, Anda dapat melanjutkan untuk 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, 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 di setiap cluster yang terdaftar (kecuali jika Anda menggunakan akun layanan Google). Secret harus diberi nama git-creds karena ini adalah nilai tetap.

Sinkronisasi Konfigurasi mendukung mekanisme berikut untuk autentikasi:

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

Mekanisme yang Anda pilih bergantung pada apa yang didukung repositori Anda. Secara umum, sebaiknya gunakan pasangan kunci SSH. GitHub dan Bitbucket mendukung penggunaan 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 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 Anda:

1. Mencantumkan 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 harus menggunakan URL ini saat mengonfigurasi Config Sync di bagian berikut. Jika mengonfigurasi Config Sync menggunakan konsol Google Cloud, Anda dapat menambahkan URL di kolom URL. Jika mengonfigurasi Config Sync menggunakan Google Cloud CLI, Anda harus 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. API ini 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 mengautentikasi ke repositori untuk meng-clone atau membaca dari repositori tersebut. 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 ingin Anda gunakan oleh Config Sync untuk mengautentikasi ke repositori
   • /path/to/KEYPAIR_FILENAME: jalur ke pasangan kunci

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

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

2. Konfigurasikan 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 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 tanpa akhiran .pub).

4. (Direkomendasikan) Untuk mengonfigurasi pemeriksaan host yang diketahui menggunakan autentikasi SSH, Anda dapat menambahkan kunci host yang diketahui 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 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 kunci pribadi tersebut.

6. Saat Anda mengonfigurasi Config Sync dan menambahkan URL untuk repositori Git, 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

Cookiefile

Catatan: Penggunaan kredensial cookiefile hanya didukung dengan Cloud Source Repositories. Jika ingin menggunakan GitHub dengan autentikasi cookiefile, Anda dapat menggunakan Cloud Source Repositories untuk menduplikasi 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 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, sebaiknya gunakan token. Dengan Config Sync, Anda dapat menggunakan token akses pribadi (PAT) GitHub, PAT atau kunci deployment GiLab, 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: Buat PAT atau buat token deploy
   • Bitbucket: Buat sandi aplikasi.

2. Setelah Anda membuat dan mendapatkan token, tambahkan token tersebut ke Secret baru dalam 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 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 token tersebut.

Akun layanan Google

Jika repositori Anda berada di Cloud Source Repositories, dan cluster Anda menggunakan GKE Workload Identity Federation for GKE atau fleet Workload Identity Federation for GKE, Anda dapat memberi Config Sync akses ke repositori dalam project yang sama dengan cluster terkelola 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 Anda.

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

3. Jika Anda mengonfigurasi Config Sync menggunakan konsol Google Cloud, pilih Workload Identity Federation for GKE 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 hingga Anda mengonfigurasi Config Sync untuk pertama kalinya.

   Jika menggunakan cluster yang terdaftar ke fleet, Anda hanya perlu membuat pengikatan kebijakan sekali per fleet. Semua cluster yang terdaftar dalam fleet memiliki Workload Identity Federation for GKEpool 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 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 Workload Identity Federation GKE untuk GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan Workload Identity Federation fleet untuk GKE, 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 Pembaca Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiliator.
  • 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 akan otomatis membuat objek RootSync bernama root-sync.
• REPOSITORY: nama repositori.
• POLICY_FILE: file JSON atau YAML dengan kebijakan Identity and Access Management.

Catatan: Membuat ikatan 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 Federation untuk GKE dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi.

Jika Anda mengonfigurasi Config Sync menggunakan konsol Google Cloud, pilih Repositori Google Cloud sebagai Authentication Type.

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

Dengan memilih Repositori Google Cloud 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 Repositori Sumber Cloud, 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.

Aplikasi GitHub

Catatan: Jenis autentikasi ini hanya didukung di versi 1.19.1 dan yang lebih baru.

Jika repositori Anda berada di GitHub, Anda dapat menggunakan githubapp sebagai jenis autentikasi.

Untuk menggunakan Aplikasi GitHub, selesaikan langkah-langkah berikut:

1. Ikuti petunjuk di GitHub untuk menyediakan Aplikasi GitHub dan memberinya izin untuk membaca dari repositori Anda.

2. Tambahkan konfigurasi Aplikasi GitHub ke Secret baru di cluster:

   Menggunakan Client ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Ganti CLIENT_ID dengan client ID untuk Aplikasi GitHub.
   • Ganti INSTALLATION_ID dengan ID penginstalan untuk Aplikasi GitHub.
   • Ganti /path/to/GITHUB_PRIVATE_KEY dengan nama file yang berisi kunci pribadi.
   • Ganti BASE_URL dengan URL dasar untuk endpoint GitHub API. Hal ini hanya diperlukan jika repositori tidak dihosting di www.github.com. Argumen dapat dihilangkan dan akan ditetapkan secara default ke https://api.github.com/.

   Menggunakan ID Aplikasi

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Ganti APPLICATION_ID dengan ID aplikasi untuk Aplikasi GitHub.
   • Ganti INSTALLATION_ID dengan ID penginstalan untuk Aplikasi GitHub.
   • Ganti /path/to/GITHUB_PRIVATE_KEY dengan nama file yang berisi kunci pribadi.
   • Ganti BASE_URL dengan URL dasar untuk endpoint GitHub API. Hal ini hanya diperlukan jika repositori tidak dihosting di www.github.com. Argumen dapat dihilangkan dan akan ditetapkan secara default ke https://api.github.com/.

3. Hapus kunci pribadi dari disk lokal atau lindungi kunci pribadi tersebut.

4. Saat Anda mengonfigurasi Config Sync dan menambahkan URL untuk repositori Git, gunakan jenis autentikasi githubapp.

Memberikan akses hanya baca ke OCI untuk Config Sync

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 baca saja, 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. Sinkronisasi Konfigurasi 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 Federation untuk GKE atau Workload Identity Federation fleet untuk GKE, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi dalam 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 Workload Identity Federation untuk kumpulan GKE. 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 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 Workload Identity Federation GKE untuk GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan Workload Identity Federation fleet untuk GKE, ini adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiliator.
     • 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 akan otomatis membuat objek RootSync bernama root-sync.
   • REPOSITORY: ID repositori.
   • LOCATION: lokasi repositori regional atau multi-regional.
   Catatan: Membuat ikatan kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika Anda menyimpan image OCI di Artifact Registry dan cluster Anda menggunakan GKE Workload Identity Federation untuk GKE atau Workload Identity Federation fleet untuk GKE, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai dari versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Opsi ini menghilangkan langkah tambahan untuk membuat akun layanan Google dan binding kebijakan IAM terkait.

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

2. Berikan peran IAM Pembaca Artifact Registry (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 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 Workload Identity Federation GKE untuk GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan Workload Identity Federation fleet untuk GKE, 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 Pembaca Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiliator.
  • 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 akan otomatis membuat objek RootSync bernama root-sync.
• REPOSITORY: ID repositori.
• LOCATION: lokasi repositori regional atau multi-regional.

Catatan: Membuat ikatan kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan diagram Helm di Artifact Registry dan cluster Anda adalah GKE dengan Workload Identity Federation untuk GKE 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. Berikan izin baca akun layanan Compute Engine 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 Config Sync 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. Hal ini didukung untuk server Git, Helm, atau OCI. Sertifikat CA harus menyertakan sertifikat SSL lengkap (Root/Intermediate/Leaf). Jika server Anda sudah menggunakan CA tepercaya atau Anda tidak terhubung melalui HTTPS, Anda dapat melewati langkah ini dan membiarkan caCertSecretRef tidak ditetapkan.

RootSync

1. Ambil sertifikat CA yang digunakan untuk menerbitkan sertifikat untuk server Git Anda dan 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 Anda mengonfigurasi Sinkronisasi Konfigurasi, tetapkan nilai kolom caCertSecretRef.name dalam objek RootSync ke ROOT_CA_CERT_SECRET_NAME.

RepoSync

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

Memberikan akses hanya baca ke Helm untuk Config Sync

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

Jika repositori Anda tidak memerlukan autentikasi untuk akses baca saja, Anda dapat melanjutkan untuk 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. Sinkronisasi Konfigurasi 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 mendeklarasikannya di sumber tepercaya lain. Lihat Konfigurasi untuk repositori Helm untuk 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 ke Secret.
• USERNAME: nama pengguna repositori Helm.
• PASSWORD: sandi repositori Helm.

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

Akun layanan Kubernetes

Jika Anda menyimpan diagram Helm di Artifact Registry dan cluster Anda menggunakan GKE Workload Identity Federation untuk GKE atau Workload Identity Federation fleet untuk GKE, Anda dapat menggunakan k8sserviceaccount sebagai jenis autentikasi dalam 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 Workload Identity Federation untuk kumpulan GKE. 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 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 Workload Identity Federation GKE untuk GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan Workload Identity Federation fleet untuk GKE, ini adalah project ID fleet tempat cluster Anda terdaftar.
   • KSA_NAME: akun layanan Kubernetes untuk rekonsiliator.
     • 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: Membuat ikatan kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan Google

Jika Anda menyimpan diagram Helm di Artifact Registry dan cluster Anda menggunakan GKE Workload Identity Federation untuk GKE atau Workload Identity Federation fleet untuk GKE, Anda dapat menggunakan gcpserviceaccount sebagai jenis autentikasi. Mulai dari versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Opsi ini menghilangkan langkah tambahan untuk membuat akun layanan Google dan binding kebijakan IAM terkait.

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

2. Berikan peran IAM Pembaca Artifact Registry (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 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 Workload Identity Federation GKE untuk GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan Workload Identity Federation fleet untuk GKE, 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 Pembaca Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: akun layanan Kubernetes untuk rekonsiliator.
  • 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: Membuat ikatan kebijakan ini memerlukan izin iam.serviceAccounts.setIamPolicy.

Akun layanan default Compute Engine

Jika Anda menyimpan diagram Helm di Artifact Registry dan cluster Anda adalah GKE dengan Workload Identity Federation untuk GKE 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 guna 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 Config Sync

Untuk mengonfigurasi sinkronisasi dari repositori root, Anda perlu 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 izin Config Sync (webhook izin dinonaktifkan secara default) dan menginstal Config Sync di cluster pribadi, tambahkan aturan firewall untuk mengizinkan port 10250. Webhook izin Config Sync menggunakan port 10250 untuk pencegahan drift.

2. 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
   

3. 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 Anda.
   • 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: tambahkan revisi Git (tag atau hash) atau cabang yang akan disinkronkan. Kolom ini bersifat opsional dan nilai defaultnya adalah HEAD. Saat menggunakan hash, hash tersebut harus berupa hash lengkap, bukan bentuk singkatan.
   • ROOT_BRANCH: menambahkan cabang repositori yang akan disinkronkan. Kolom ini bersifat opsional dan nilai defaultnya adalah master. Sebaiknya gunakan kolom revision untuk menentukan nama cabang agar lebih sederhana. Jika kolom revision dan kolom branch ditentukan, revision akan lebih diprioritaskan daripada branch.
   • ROOT_DIRECTORY: tambahkan jalur di repositori Git ke direktori root yang berisi konfigurasi yang ingin Anda sinkronkan. Kolom ini bersifat opsional dan defaultnya adalah direktori utama (/) repositori.

   • ROOT_AUTH_TYPE: menambahkan salah satu jenis autentikasi berikut:

     • none: Tidak menggunakan autentikasi
     • ssh: Menggunakan pasangan kunci SSH
     • cookiefile: Menggunakan 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 Federation for GKE tidak diaktifkan di cluster Anda.

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

     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 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 ditetapkan, penyedia Git Anda harus menggunakan sertifikat yang dikeluarkan 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 Certificate Authority

   Untuk penjelasan 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 Anda.
   • 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 mengambil 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 dalam 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: tambahkan jalur di repositori ke direktori root yang berisi konfigurasi yang ingin Anda sinkronkan. Kolom ini bersifat opsional dan defaultnya adalah direktori utama (/) repositori.

   • ROOT_AUTH_TYPE: menambahkan 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 Federation untuk GKE 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 secret Anda. Jika kolom ini ditetapkan, penyedia OCI Anda harus menggunakan sertifikat yang dikeluarkan 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 Certificate Authority

   Untuk penjelasan 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 Anda.
   • 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: tambahkan nama diagram Helm Anda. 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. 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: tetapkan 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 values.yaml diagram helm. Kolom ini bersifat opsional.

   • ROOT_AUTH_TYPE: menambahkan 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 Federation untuk GKE 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 secret Anda. Jika kolom ini ditetapkan, penyedia Helm Anda harus menggunakan sertifikat yang dikeluarkan 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 Certificate Authority

   Untuk penjelasan 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.

4. 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 rekonsiliator dengan awalan root-reconciler. Penyelesai adalah Pod yang di-deploy sebagai Deployment. Alat ini 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

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

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

Mengupgrade Config Sync

Langkah-langkah untuk mengupgrade Config Sync bergantung pada versi yang Anda upgrade dan dari mana Anda mengupgrade. Mulai versi 1.20.0, Config Sync disediakan sebagai penginstalan mandiri tanpa Operator ConfigManagement. Jika mengupgrade dari versi sebelum 1.20.0 ke versi 1.20.0 atau yang lebih baru, Anda harus meng-uninstal Operator ConfigManagement terlebih dahulu sebelum mengupgrade.

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.14.0, upgrade terlebih dahulu ke versi 1.17.0, lalu ke versi 1.20.0.

Meng-uninstal Operator ConfigManagement

Jika mengupgrade dari versi sebelum 1.20.0 ke versi 1.20.0 atau yang lebih baru, Anda harus meng-uninstal Operator ConfigManagement terlebih dahulu sebelum mengupgrade.

Anda dapat memeriksa apakah Config Management diinstal di cluster dengan menjalankan perintah berikut:

kubectl get configmanagement

Jika output tidak kosong, Config Management diinstal di cluster. Untuk meng-uninstal Config Management, selesaikan langkah-langkah berikut untuk meng-uninstal Config Management, tetapi biarkan Config Sync diinstal di cluster. Sebaiknya gunakan nomos CLI untuk meng-uninstal Operator ConfigManagement karena memiliki antarmuka yang lebih kaya dan penanganan error yang lebih andal. Anda hanya boleh menggunakan skrip shell jika tidak memiliki akses ke nomos CLI.

Perhatian: Pastikan Hierarchy Controller dinonaktifkan sebelum melanjutkan.

nomos (direkomendasikan)

1. Pastikan nomos CLI menggunakan versi terbaru.

2. Jalankan perintah berikut untuk mengupdate cluster dalam konteks kubectl saat ini:

   nomos migrate --remove-configmanagement
   

skrip shell

Salin skrip shell berikut ke file, lalu jalankan untuk mengupdate cluster dalam konteks kubectl Anda saat ini.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Menginstal versi Config Sync baru

Untuk mengupgrade Config Sync, selesaikan langkah-langkah berikut untuk setiap cluster yang terdaftar:

1.20.0 atau yang lebih baru

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

2. Ekstrak arsip:

   tar -xzvf config-sync.tar.gz

3. Dalam arsip yang Anda ekstrak di langkah sebelumnya, ikuti petunjuk dalam README yang disediakan untuk mengedit penyesuaian.

4. Untuk mengupdate penginstalan Config Sync, terapkan manifes yang dirender yang Anda build dengan mengikuti petunjuk README:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Ganti CONFIG_SYNC_MANIFEST dengan nama manifes yang dirender.

5. Ganti perintah nomos di semua klien dengan versi baru. Perubahan ini memastikan bahwa perintah nomos selalu dapat mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuknya.

1.19.2 atau yang lebih lama

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 Operator ConfigManagement. 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. 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, akan mengaktifkan webhook izin Config Sync untuk mencegah drift dengan menolak perubahan yang bertentangan agar tidak didorong ke cluster aktif. Setelan default-nya adalah false. Config Sync selalu memperbaiki penyimpangan, apa pun nilai kolom ini.

4. Terapkan perubahan:

   kubectl apply -f config-management.yaml
   

5. Ganti perintah nomos di semua klien dengan versi baru. Perubahan ini memastikan bahwa perintah nomos selalu dapat mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuknya.

Meng-uninstal Config Sync

Perhatian: Menghapus objek RootSync atau RepoSync tidak akan menghapus anotasi dan label Config Sync, dan webhook akses Config Sync akan menolak permintaan yang mencoba menghapus resource ini jika Config Sync masih diaktifkan di cluster. Solusi untuk mengatasinya adalah dengan 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 drift untuk resource yang ditinggalkan. Jika belum mengaktifkan webhook, Anda tidak perlu melakukan langkah tambahan untuk mempertahankan resource.

   2. Hapus objek RootSync dengan menjalankan perintah berikut:

      kubectl delete -f root-sync.yaml
      

2. Hapus repositori.

3. Dengan manifes yang digunakan untuk menginstal Config Sync, Anda juga dapat meng-uninstal Config Sync.

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

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

Langkah selanjutnya

• Temukan cara mengonfigurasi sinkronisasi dari beberapa repositori.