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 dalam Kubernetes. Ikuti langkah-langkah berikut untuk menginstal dan mengonfigurasi Operator di setiap cluster yang ingin Anda kelola menggunakan Sinkronisasi Konfigurasi.

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 berikut:

  • Buat, atau miliki akses ke sumber kebenaran.

  • 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 diinstal sebelumnya.

  • 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 sedang menginstal Config Sync memerlukan izin IAM untuk membuat peran baru di cluster Anda. Jika diperlukan, berikan peran ini dengan 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: email akun Google Cloud Anda Anda

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

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

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

Mendaftarkan cluster

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

  1. Men-deploy Operator
  2. Beri Operator akses hanya baca ke salah satu hal berikut:
  3. Mengonfigurasi Operator

Men-deploy Operator

Setelah memastikan bahwa semua prasyarat telah dipenuhi, 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.

    gcloud storage 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 ini gagal karena ada masalah dengan objek ConfigManagement yang tidak karena adanya kesalahan sintaksis YAML atau JSON, objek mungkin dibuat instance-nya dalam , 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. Tergantung pada jenis Anda mungkin perlu menerapkan ulang manifes ConfigManagement ke cluster.

Jika masalahnya adalah Anda lupa membuat Secret git-creds, Config Sync mendeteksi Secret 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 OCI image, Anda harus memberikan izin Akses hanya baca operator ke OCI. Jika Anda 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 dilakukan pada repositori dan menerapkannya ke klaster.

Jika repositori Anda tidak memerlukan otentikasi untuk akses hanya baca, Anda dapat lanjutkan untuk mengonfigurasi Config Sync dan gunakan none sebagai jenis autentikasi. Misalnya, jika Anda dapat menelusuri 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 otentikasi. Dalam kasus ini, Anda tidak perlu membuat Secret.

Namun, sebagian besar pengguna perlu membuat kredensial karena akses baca ke repositori dibatasi. Jika kredensial diperlukan, kredensial tersebut akan disimpan di git-creds Rahasia di setiap cluster yang terdaftar (kecuali jika Anda menggunakan layanan akun layanan). 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 menggunakan pasangan kunci SSH. Namun, jika Anda menggunakan repositori di Cloud Source Repositories, sebaiknya Anda menggunakan akun layanan Google alih-alih karena prosesnya lebih sederhana. Jika organisasi Anda menghosting repositori Anda dan Anda tidak tahu metode otentikasi mana yang didukung, hubungi administrator.

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

  1. Tampilkan daftar semua repositori:

    gcloud source repos list

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

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

    Anda perlu menggunakan URL ini saat konfigurasikan Config Sync di bagian berikutnya. Jika Anda mengonfigurasi Config Sync menggunakan Konsol Google Cloud, Anda dapat menambahkan URL di kolom URL. Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud CLI, Anda dapat menambahkan URL ke kolom syncRepo dalam file konfigurasi Anda.

Pasangan kunci SSH

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

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 mengotentikasi ke repositori untuk meng-clone atau membaca darinya. Lewati langkah ini jika keamanan administrator menyediakan pasangan kunci untuk Anda. Anda dapat menggunakan pasangan kunci tunggal untuk semua cluster, atau pasangan kunci per cluster, bergantung pada persyaratan keamanan dan kepatuhan Anda.

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

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

    Ganti kode berikut:

    • GIT_REPOSITORY_USERNAME: nama pengguna yang Anda ingin Config Sync digunakan untuk melakukan otentikasi 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, kita sebaiknya gunakan akun terpisah.

  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:

  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 dikenal menggunakan autentikasi SSH, Anda dapat menambahkan kunci host yang dikenal ke kolom data.known_hosts di Rahasia git_creds. Untuk menonaktifkan pemeriksaan known_hosts, Anda dapat menghapus 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 dengan cara lain.

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

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

    Ganti kode berikut:

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

File cookie

Proses untuk mendapatkan cookiefile bergantung pada konfigurasi resource repositori resource. Untuk contoh, lihat Membuat kredensial statis dalam dokumentasi Cloud Source Repositories. Kredensial biasanya disimpan di file .gitcookies di rumah Anda pribadi, atau mereka mungkin disediakan oleh administrator keamanan kepada Anda.

Untuk menggunakan cookiefile, selesaikan langkah-langkah berikut:

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

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

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

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

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

    Ganti kode berikut:

    • /path/to/COOKIEFILE: atribut yang sesuai jalur dan nama file
    • HTTPS_PROXY_URL: URL untuk proxy HTTPS yang Anda gunakan saat berkomunikasi dengan repositori Git

  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 GitHub (PAT), PAT GiLab atau 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:

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

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

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

    Ganti kode berikut:

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

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

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

    Ganti kode berikut:

    • USERNAME: nama pengguna yang ingin Anda gunakan.
    • TOKEN: token yang Anda buat di langkah sebelumnya.
    • HTTPS_PROXY_URL: URL untuk proxy HTTPS yang Anda gunakan saat berkomunikasi dengan repositori Git.

  3. Lindungi token jika Anda masih memerlukannya secara lokal. Jika tidak, menghapusnya.

Akun layanan Google

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

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

  2. Berikan Pembaca Cloud Source Repositories (roles/source.reader) Peran IAM ke akun layanan Google. Untuk selengkapnya informasi 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 di 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 di 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 sebagai Authentication Type, lalu tambahkan email akun layanan.

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

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

    Jika Anda menggunakan cluster yang didaftarkan ke fleet, Anda hanya harus membuat pengikatan kebijakan satu kali per fleet. Semua cluster yang terdaftar di sebuah fleet memiliki Workload Identitypool yang sama. Dengan konsep armada sama, jika Anda menambahkan kebijakan IAM ke akun layanan Kubernetes Anda dalam satu cluster, lalu akun layanan Kubernetes dari namespace yang sama di cluster lain dalam fleet yang sama juga mendapatkan IAM yang sama lebih lanjut.

    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 yang cluster terdaftar.
  • GSA_NAME: akun layanan Google kustom yang 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 secara otomatis membuat objek RootSync yang diberi nama root-sync.
  • REPOSITORY: nama repositori.
  • POLICY_FILE: file JSON atau YAML dengan Kebijakan Identity and Access Management.

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

Jika Anda mengonfigurasi Config Sync menggunakan Konsol Google Cloud, pilih Google Cloud Repository sebagai Jenis Autentikasi.

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 izin 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:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Ganti PROJECT_ID dengan project ID organisasi Anda, dan ganti PROJECT_NUMBER dengan project organisasi Anda angka

Berikan akses hanya baca kepada Operator ke OCI

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

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

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

  1. Berikan Pembaca Artifact Registry (roles/artifactregistry.reader) Peran IAM ke akun layanan Kubernetes dengan Kumpulan Workload Identity. Untuk selengkapnya informasi tentang peran dan izin Artifact Registry, lihat Konfigurasikan peran dan izin untuk Artifact Registry.

    • Berikan izin di seluruh project jika izin yang sama berlaku untuk semua repositori di 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 di project Anda.

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

    Ganti kode berikut:

    • PROJECT_ID: project ID organisasi.
    • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, ini adalah project ID fleet yang cluster 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 secara otomatis membuat objek RootSync yang diberi nama root-sync.
    • REPOSITORY: ID repositori.
    • LOCATION: regional atau multi-regional lokasi repositori.

Akun layanan Google

Jika Anda menyimpan image OCI di Artifact Registry dan cluster Anda menggunakan Workload Identity GKE atau fleet Workload Identity, Anda dapat menggunakan gcpserviceaccount sebagai jenis otentikasi. Mulai dari versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Ini menghilangkan langkah-langkah tambahan pembuatan akun layanan Google dan binding kebijakan IAM yang terkait.

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

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

    • Berikan izin di seluruh project jika izin yang sama berlaku untuk semua repositori di 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 di project Anda.

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

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

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

Ganti kode berikut:

  • PROJECT_ID: project ID organisasi.
  • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, ini adalah project ID fleet yang cluster terdaftar.
  • GSA_NAME: akun layanan Google kustom yang 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 secara otomatis membuat objek RootSync yang diberi nama root-sync.
  • REPOSITORY: ID repositori.
  • LOCATION: regional atau multi-regional lokasi repositori.

Akun layanan default Compute Engine

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

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

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

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

Mengonfigurasi Operator untuk Certificate Authority

Untuk server yang dikonfigurasi dengan sertifikat dari Certificate Authority (CA) yang belum dipercaya, Config Sync dapat dikonfigurasi untuk menggunakan CA sertifikat untuk memverifikasi koneksi HTTPS ke server. Ini didukung untuk Git, Helm, atau server OCI. Sertifikat CA harus menyertakan sertifikat SSL lengkap (Root/Menengah/Leaf). Jika server Anda 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 Git dan menyimpannya ke sebuah file.

  2. Untuk objek RootSync, Secret harus dibuat di config-management-system namespace. 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 RootSync ke ROOT_CA_CERT_SECRET_NAME.

RepoSync

  1. Ambil sertifikat CA yang digunakan untuk menerbitkan sertifikat bagi Git dan menyimpannya ke sebuah file.

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

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

  3. Saat mengonfigurasi RepoSync, tetapkan nilai kolom caCertSecretRef.name di RepoSync ke NAMESPACE_CA_CERT_SECRET_NAME.

Memberikan akses hanya baca kepada Operator ke Helm

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

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

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)

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

  1. Berikan Pembaca Artifact Registry (roles/artifactregistry.reader) Peran IAM ke akun layanan Kubernetes dengan Kumpulan Workload Identity. Untuk selengkapnya informasi tentang peran dan izin Artifact Registry, lihat Konfigurasikan peran dan izin untuk Artifact Registry.

    • Berikan izin di seluruh project jika izin yang sama berlaku untuk semua repositori di 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 di project Anda.

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

    Ganti kode berikut:

    • PROJECT_ID: project ID organisasi.
    • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, ini adalah project ID fleet yang cluster 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: regional atau multi-regional lokasi repositori.

Akun layanan Google

Jika Anda menyimpan chart Helm di Artifact Registry dan cluster Anda menggunakan Workload Identity GKE atau fleet Workload Identity, Anda dapat menggunakan gcpserviceaccount sebagai jenis otentikasi. Mulai dari versi 1.17.2, sebaiknya gunakan k8sserviceaccount. Ini menghilangkan langkah-langkah tambahan pembuatan akun layanan Google dan binding kebijakan IAM yang terkait.

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

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

    • Berikan izin di seluruh project jika izin yang sama berlaku untuk semua repositori di 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 di project Anda.

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

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

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

Ganti kode berikut:

  • PROJECT_ID: project ID organisasi.
  • FLEET_HOST_PROJECT_ID: jika Anda menggunakan GKE Workload Identity, ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity, ini adalah project ID fleet yang cluster terdaftar.
  • GSA_NAME: akun layanan Google kustom yang 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: regional atau multi-regional lokasi repositori.

Akun layanan default Compute Engine

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

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

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

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

Mengonfigurasi Operator

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

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

  2. Buat file bernama config-management.yaml dan salin perintah berikut YAML 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 penerimaan Config Sync untuk mencegah penyimpangan dengan menolak perubahan yang berkonflik agar tidak didorong ke klaster yang aktif. Setelan default-nya adalah false. Config Sync selalu mengatasi penyimpangan tidak pada nilai {i>field<i} 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. Menggunakan 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: menambahkan nama RootSync .
    • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Bidang 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 ke Anda gunakan sebagai repositori {i>root<i}. Anda dapat memasukkan URL menggunakan HTTPS atau protokol SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
    • ROOT_REVISION: menambahkan revisi Git (tag atau ) yang akan disinkronkan. Bidang ini bersifat opsional dan nilai defaultnya adalah HEAD. Mulai dari Config Sync versi 1.17.0, Anda juga dapat tentukan nama cabang di kolom revision. Saat menggunakan {i>hash <i}di versi 1.17.0 atau yang lebih baru, itu harus berupa {i>hash<i}, dan bukan bentuk yang disingkat.
    • ROOT_BRANCH: menambahkan cabang repositori yang akan disinkronkan. Kolom ini bersifat opsional dan nilai default-nya adalah master. Mulai dari Config Sync versi 1.17.0, sekarang sebaiknya gunakan kolom revision untuk menentukan nama cabang kesederhanaan. Jika kolom revision dan kolom branch keduanya tertentu, revision akan lebih diprioritaskan daripada branch.
    • ROOT_DIRECTORY: menambahkan jalur di repositori Git untuk direktori {i>root<i} yang berisi konfigurasi yang ingin Anda sinkronkan tempat mesin terhubung. Bidang 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: Gunakan akun layanan Google untuk mengakses dan Cloud Source Repositories. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.

      Untuk informasi lebih lanjut 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 ini isian diatur, Anda harus menambahkan kunci publik Rahasia 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. Jika kolom ini disetel, penyedia Git Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Rahasia harus berisi sertifikat CA dengan kunci bernama cert. Kolom ini bersifat opsional.

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

    Untuk penjelasan tentang {i>field<i} dan daftar lengkap {i>field<i} yang Anda dapat ditambahkan 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: menambahkan nama RootSync .
    • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Bidang 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 gambar 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
    • ROOT_DIRECTORY: menambahkan jalur di repositori ke direktori {i>root<i} yang berisi konfigurasi yang ingin Anda sinkronkan tempat mesin terhubung. Bidang 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 dan Artifact Registry. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.
      • gcpserviceaccount: Gunakan 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. Jika kolom ini disetel, penyedia OCI Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Rahasia harus berisi sertifikat CA dengan kunci bernama cert. Kolom ini bersifat opsional.

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

    Untuk penjelasan tentang {i>field<i} dan daftar lengkap {i>field<i} yang Anda dapat ditambahkan 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: menambahkan nama RootSync .
    • ROOT_FORMAT: tambahkan unstructured untuk menggunakan repositori tidak terstruktur atau tambahkan hierarchy untuk menggunakan repositori hierarkis. Nilai ini peka huruf besar/kecil. Bidang 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 Helm repositori 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 HTTPS dan berperforma tinggi karena merupakan protokol biner. Kolom ini wajib diisi.
    • HELM_CHART_NAME: tambahkan nama Helm Anda diagram. Kolom ini wajib diisi.
    • HELM_CHART_VERSION: versi diagram Anda. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, versi terbaru akan data
    • HELM_RELEASE_NAME: nama rilis Helm. Kolom ini bersifat opsional.
    • HELM_RELEASE_NAMESPACE: namespace target untuk suatu 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 mau template Helm untuk 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: Gunakan nama pengguna dan sandi untuk mengakses Helm pribadi repositori resource.
      • gcenode: Gunakan Akun layanan default Compute Engine untuk mengakses image di dan Artifact Registry. Hanya pilih opsi ini jika Workload Identity tidak diaktifkan di cluster Anda.
      • gcpserviceaccount: Gunakan 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. Jika kolom ini disetel, penyedia Helm Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Rahasia harus berisi sertifikat CA dengan kunci bernama cert. Kolom ini bersifat opsional.

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

    Untuk penjelasan tentang {i>field<i} dan daftar lengkap {i>field<i} yang Anda dapat ditambahkan 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:

my_managed_cluster-1
  --------------------
  <root>   git@github.com: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:

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

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

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

Upgrade Config Sync

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

  1. Mendownload Config Sync manifes 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 Config Sync Pod menggunakan . Saat dimulai, Config Sync akan menjalankan loop rekonsiliasi yang menerapkan set manifes yang dipaketkan dalam image baru. Hal ini memperbarui dan akan memulai ulang setiap Pod komponen.

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

Meng-uninstal Config Sync

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

  1. Administrator pusat harus menghapus repo root:

    1. Jika Anda telah mengaktifkan webhook dan ingin menyimpan sumber daya Anda, nonaktifkan pencegahan penyimpangan untuk resource yang diabaikan. Jika belum mengaktifkan webhook, Anda tidak perlu melakukan tindakan apa pun langkah-langkah untuk menjaga sumber daya Anda.

    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.

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

Langkah selanjutnya