Menginstal Config Sync secara manual menggunakan kubectl (tidak direkomendasikan)

Halaman ini menunjukkan cara menginstal Config Sync menggunakan perintah kubectl.

Sebelum memulai

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

Menyiapkan lingkungan lokal Anda

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

  • Buat, atau miliki 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 Google Kubernetes Engine yang memenuhi persyaratan untuk Config Sync.

Siapkan izin

Pengguna yang menginstal Config Sync memerlukan izin IAM untuk membuat peran baru di cluster Anda. Google Cloud 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 bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

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

Mendaftarkan cluster

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

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

Deploy Config Sync

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

  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. Di arsip yang Anda ekstrak pada langkah sebelumnya, ikuti petunjuk di README yang disediakan untuk mengedit penyesuaian.

  4. Untuk mengupdate penginstalan Config Sync, terapkan manifes yang dirender yang Anda buat 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 untuk cluster tersebut.

Jika hal ini gagal karena masalah pada Config Sync yang bukan disebabkan oleh error sintaks YAML atau JSON, objek mungkin di-instantiate 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, perbaiki error konfigurasi. Bergantung pada jenis error, Anda mungkin perlu menerapkan kembali manifes Config Sync ke cluster.

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

Memberikan akses hanya baca 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 memberi Config Sync akses hanya baca ke OCI. Jika menyimpan konfigurasi di Helm, Anda harus memberi Config Sync akses hanya baca ke Helm.

Memberi Config Sync akses hanya baca ke Git

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

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

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

Config Sync mendukung mekanisme berikut untuk autentikasi:

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

Mekanisme yang Anda pilih bergantung pada dukungan 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 atau Secure Source Manager, sebaiknya gunakan akun layanan Google karena prosesnya lebih sederhana. Jika organisasi Anda menghosting repositori Anda dan Anda tidak tahu metode autentikasi 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 Anda mengonfigurasi Config Sync menggunakan konsol Google Cloud , Anda menambahkan URL di kolom URL. Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud CLI, Anda menambahkan URL ke kolom syncRepo pada file konfigurasi.

Pasangan kunci SSH

Pasangan kunci SSH terdiri dari dua file, yaitu kunci publik dan kunci pribadi. 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 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 Anda inginkan agar Config Sync gunakan 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.

  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 (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 dalam secret git_creds. Untuk menonaktifkan pemeriksaan known_hosts, Anda dapat menghapus kolom known_hosts dari rahasia. Untuk menambahkan kunci host yang dikenal, jalankan:

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

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

    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 Anda menggunakan repositori di Cloud Source Repositories, Anda harus menggunakan format berikut saat 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

Cookiefile

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 beranda Anda, atau mungkin diberikan kepada Anda oleh administrator keamanan.

Untuk menggunakan cookiefile, selesaikan langkah-langkah berikut:

  1. Setelah Anda membuat dan mendapatkan cookiefile, tambahkan cookiefile 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-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

  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 GitLab, 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 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 pada 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 pada 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, hapus file cookie tersebut.

Akun layanan Google

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

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

  2. Berikan peran IAM yang benar ke akun layanan agar akun layanan dapat mengakses repositori:

    Cloud Source Repositories

    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 Memberi 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 di project Anda.

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

    Secure Source Manager

    Berikan peran IAM Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) dan Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader) ke akun layanan Google. Untuk mengetahui informasi selengkapnya tentang peran dan izin Secure Source Manager, lihat Pengelolaan peran 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/securesourcemanager.instanceAccessor \
  --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"

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

    • Untuk memberikan izin khusus repositori, Anda dapat menggunakan antarmuka web Secure Source Manager untuk repositori. Untuk mengetahui informasi selengkapnya, lihat Memberikan peran tingkat repositori kepada pengguna.

  3. Jika Anda mengonfigurasi Config Sync menggunakan konsol Google Cloud , pilih Workload Identity Federation untuk GKE sebagai Jenis Autentikasi, 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. Jika Anda menggunakan repositori di Secure Source Manager, Anda harus menggunakan format berikut saat mengonfigurasi Config Sync dan menambahkan URL untuk repositori Git Anda:

    https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git

    Ganti kode berikut:

    • INSTANCE_ID: nama instance Secure Source Manager Anda.
    • PROJECT_ID: ID project Google Cloud tempat instance berada.
    • PROJECT_NUMBER: nomor project Google Cloud tempat instance berada.
    • LOCATION: region tempat instance Anda berada.
    • REPO_NAME: nama repositori.

  5. 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 Anda menggunakan cluster yang terdaftar ke fleet, Anda hanya perlu membuat pengikatan kebijakan satu kali per fleet. Semua cluster yang terdaftar di fleet berbagi 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.

    Binding ini memungkinkan akun layanan Kubernetes Config Sync 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 Federation for GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation 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 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 akan otomatis membuat objek RootSync bernama 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 Federation for GKE dinonaktifkan, Anda dapat menggunakan gcenode sebagai jenis autentikasi Anda.

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

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

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

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

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

Aplikasi GitHub

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

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 ID klien 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. 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. 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 Config Sync ke OCI

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

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

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

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

  • Akun layanan default Compute Engine (gcenode)

Akun layanan Kubernetes

Anda dapat menggunakan akun layanan Kubernetes sebagai jenis autentikasi jika Anda menyimpan image OCI di Artifact Registry dan cluster Anda menggunakan Workload Identity Federation untuk GKE atau Workload Identity Federation fleet untuk GKE.

  1. Berikan peran IAM Pembaca Artifact Registry (roles/artifactregistry.reader) ke akun layanan Kubernetes dengan kumpulan Workload Identity Federation untuk 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 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 Federation for GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation untuk GKE, ini adalah project ID fleet tempat cluster Anda terdaftar.
    • KSA_NAME: akun layanan Kubernetes untuk rekonsiliasi.
      • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME. Jika Anda menginstal Config Sync menggunakan konsol Google Cloud atau Google Cloud CLI, Config Sync akan otomatis membuat objek RootSync bernama root-sync.
    • REPOSITORY: ID repositori.
    • LOCATION: lokasi regional atau multi-regional repositori.

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 ke Artifact Registry untuk akun layanan default Compute Engine Anda.

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

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
   --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. Cara ini didukung untuk server Git, Helm, atau OCI. Sertifikat CA harus mencakup 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 disetel.

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 Config Sync, 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 di 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 Config Sync ke Helm

Config Sync memerlukan akses hanya baca ke repositori Helm Anda agar dapat membaca diagram Helm di repositori Anda dan menginstalnya di 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 Anda. Misalnya, jika repositori Helm Anda bersifat publik dan dapat diakses oleh siapa saja di internet, Anda tidak perlu melakukan autentikasi.

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

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

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 pada Secret Anda.
  • USERNAME: nama pengguna repositori Helm.
  • PASSWORD: sandi repositori Helm.

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

Akun layanan Kubernetes

Anda dapat menggunakan akun layanan Kubernetes sebagai jenis autentikasi jika menyimpan diagram Helm di Artifact Registry dan cluster Anda menggunakan Workload Identity Federation untuk GKE atau Workload Identity Federation fleet untuk GKE.

  1. Berikan peran IAM Pembaca Artifact Registry (roles/artifactregistry.reader) ke akun layanan Kubernetes dengan kumpulan Workload Identity Federation untuk 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 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 Federation for GKE, nilai ini sama dengan PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation untuk GKE, ini adalah project ID fleet tempat cluster Anda terdaftar.
    • KSA_NAME: akun layanan Kubernetes untuk rekonsiliasi.
      • Untuk repositori root, jika nama RootSync adalah root-sync, gunakan root-reconciler. Jika tidak, gunakan root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: ID repositori.
    • LOCATION: lokasi regional atau multi-regional repositori.

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 ke Artifact Registry untuk akun layanan default Compute Engine Anda. Anda mungkin perlu memberikan cakupan akses storage-ro untuk memberikan izin hanya baca guna menarik gambar.

  1. Berikan izin baca akun layanan Compute Engine ke 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 nomor project organisasi Anda.

Mengonfigurasi Config Sync

Untuk mengonfigurasi sinkronisasi dari repositori root, Anda harus membuat objek RootSync yang menyinkronkan repositori root ke cluster. Anda hanya dapat membuat satu repositori root per cluster dan repositori root dapat berupa repositori tidak terstruktur atau repositori hierarkis.

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

  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: tambahkan URL repositori Git yang akan digunakan sebagai repositori root. Anda dapat memasukkan URL menggunakan protokol HTTPS atau SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
    • ROOT_REVISION: 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, dan bukan bentuk singkat.
    • ROOT_BRANCH: tambahkan 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 diprioritaskan daripada branch.
    • ROOT_DIRECTORY: tambahkan jalur di repositori Git ke direktori root yang berisi konfigurasi yang ingin Anda sinkronkan ke. Kolom ini bersifat opsional dan defaultnya adalah direktori root (/) repositori.

    • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

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

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

      Kolom ini wajib diisi.

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

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

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

    • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Secret Anda. Jika kolom ini disetel, penyedia Git Anda harus menggunakan sertifikat yang 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 mengetahui 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 berdasarkan 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
    • ROOT_DIRECTORY: tambahkan jalur di repositori ke direktori root yang berisi konfigurasi yang ingin Anda sinkronkan ke. Kolom ini bersifat opsional dan defaultnya adalah direktori root (/) repositori.

    • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

      • none: Tidak menggunakan autentikasi
      • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Pilih opsi ini hanya 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 disetel, 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 mengetahui 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 Helm chart 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. Namespace ini hanya menetapkan namespace untuk resource yang berisi namespace: {{ .Release.Namespace }} dalam templatenya. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, namespace default config-management-system akan digunakan.
    • HELM_INCLUDE_CRDS: ditetapkan ke true jika Anda ingin template Helm juga 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 disertakan dalam diagram Helm. Format kolom ini dengan cara yang sama seperti file values.yaml helm chart. Kolom ini bersifat opsional.

    • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

      • none: Tidak menggunakan autentikasi
      • token: Menggunakan nama pengguna dan sandi untuk mengakses repositori Helm pribadi.
      • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Pilih opsi ini hanya 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 disetel, 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 mengetahui 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>   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. Reconciler 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 lain dalam menjelajahi 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 versi mana Anda melakukan upgrade. Mulai dari versi 1.20.0, Config Sync disediakan sebagai penginstalan mandiri tanpa Operator ConfigManagement. Jika Anda mengupgrade dari versi sebelum 1.20.0 ke versi 1.20.0 atau yang lebih baru, Anda harus meng-uninstal ConfigManagement Operator terlebih dahulu sebelum mengupgrade.

Jika mengupgrade dari versi yang tidak didukung, Anda harus melakukan upgrade langkah demi langkah dengan kenaikan 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 Anda mengupgrade dari versi sebelum 1.20.0 ke versi 1.20.0 atau yang lebih baru, Anda harus meng-uninstal ConfigManagement Operator terlebih dahulu sebelum mengupgrade.

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

kubectl get configmanagement

Jika output tidak kosong, berarti 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 Anda tidak memiliki akses ke nomos CLI.

  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 memperbarui 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. Download perintah Config Sync manifest dan nomos untuk versi baru.

  2. Ekstrak arsip:

    tar -xzvf config-sync.tar.gz

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

  4. Untuk mengupdate penginstalan Config Sync, terapkan manifes yang dirender yang Anda buat 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 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 mempertahankan resource, nonaktifkan pencegahan penyimpangan untuk resource yang ditinggalkan. Jika Anda belum mengaktifkan webhook, Anda tidak perlu melakukan langkah tambahan untuk menyimpan resource.

    2. Hapus objek RootSync dengan menjalankan perintah berikut:

      kubectl delete -f root-sync.yaml

  2. Hapus repositori.

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

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

Langkah berikutnya