Menginstal Config Sync

Dengan Config Sync, Anda dapat mengelola resource Kubernetes menggunakan konfigurasi file yang disimpan dalam sumber kebenaran. Config Sync mendukung Git repositori, image OCI, dan diagram Helm sebagai sumber tepercaya. Halaman ini menunjukkan cara mengaktifkan dan mengonfigurasi Config Sync agar disinkronkan dari root Anda repositori resource. Config Sync tersedia di edisi Google Kubernetes Engine (GKE) Enterprise.

Saat Anda menginstal Config Sync menggunakan Konsol Google Cloud atau Google Cloud CLI, API RootSync, dan RepoSync diaktifkan secara default. Ini menyediakan fitur tambahan seperti menyinkronkan dari beberapa repositori dan menyinkronkan konfigurasi Kustomize dan Helm.

Sebelum memulai

Sebelum menginstal Config Sync, siapkan lingkungan, memastikan Anda memenuhi persyaratan cluster, dan memberikan peran pengguna yang tepat.

Menyiapkan lingkungan lokal Anda

Siapkan lingkungan lokal Anda dengan menyelesaikan tugas berikut:

  1. Buat, atau pastikan Anda memiliki akses ke, sumber yang terpercaya. Di sinilah Anda menambahkan konfigurasi yang disinkronkan dengan Config Sync. Untuk mempelajari lebih lanjut tentang cara mengatur konfigurasi dan sumber tepercaya, lihat salah satu panduan berikut:
  2. Instal dan lakukan inisialisasi Google Cloud CLI, yang menyediakan gcloud, dan nomos. Jika Anda menggunakan Cloud Shell, Google Cloud CLI sudah diinstal sebelumnya. Jika sebelumnya Anda menginstal Google Cloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.
  3. Aktifkan GKE Enterprise API.

    Mengaktifkan GKE Enterprise API

Persyaratan cluster

Untuk menggunakan Config Sync, cluster Anda harus memenuhi persyaratan berikut:

  • Harus berupa edisi Google Kubernetes Engine (GKE) Enterprise platform dan versi yang didukung.

  • (Opsional) Jika Anda menggunakan cluster GKE, pastikan Workload Identity Federation untuk GKE adalah mengaktifkan pembuatan versi. Cluster Autopilot mengaktifkan Workload Identity Federation untuk GKE secara default.

  • Memiliki izin penulisan metrik yang benar agar Config Sync dapat mengirimkan metrik ke Cloud Monitoring.

  • Jika Anda ingin mengupgrade versi Config Sync secara otomatis, pastikan Cluster GKE terdaftar di saluran rilis. Config Sync memperlakukan cluster yang tidak menggunakan saluran rilis GKE sebagai menggunakan saluran rilis Stabil.

  • Jika ingin menggunakan cluster GKE pribadi, konfigurasikan Cloud NAT untuk mengizinkan traffic keluar dari dan node GKE pribadi. Untuk mengetahui detailnya, lihat Contoh penyiapan GKE. Atau, Anda dapat mengaktifkan Akses Google Pribadi ke menghubungkan ke kumpulan alamat IP eksternal yang digunakan oleh API dan layanan Google.

  • Jika Anda ingin menggunakan akun layanan IAM saat Anda memberi Config Sync akses ke sumber kebenaran Anda, maka Anda harus menyertakan cakupan hanya baca di cakupan akses untuk node dalam cluster untuk Cloud Source Repositories.

    Anda dapat menambahkan cakupan hanya baca dengan menyertakan cloud-source-repos-ro di --scopes yang ditentukan pada waktu pembuatan cluster, atau dengan menggunakan cloud-platform cakupan pada waktu pembuatan cluster. Contoh:

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
    

    Anda tidak dapat mengubah cakupan akses setelah membuat node pool. Namun, Anda dapat membuat kumpulan node baru dengan cakupan akses yang tepat sekaligus menggunakan cluster yang sama. Cakupan gke-default default tidak menyertakan cloud-source-repos-ro.

  • Jika Anda memiliki persyaratan Firewall VPC yang ketat yang memblokir lalu lintas yang tidak diperlukan, Anda harus Membuat aturan firewall untuk mengizinkan traffic berikut di cluster GKE publik:

    • TCP: Mengizinkan traffic masuk dan keluar di port 53 dan 443

    • UDP: Mengizinkan traffic keluar di port 53

    Jika Anda tidak menyertakan aturan ini, Config Sync tidak akan disinkronkan dengan benar, dengan nomos status melaporkan error berikut:

    Error: KNV2004: unable to sync repo Error in the git-sync container

    Anda dapat melewati langkah ini jika menggunakan cluster GKE pribadi.

  • Config Sync harus dijalankan pada kumpulan node amd64. Backend Config Sync image container komponen hanya dibangun, didistribusikan, dan diuji untuk Arsitektur mesin amd64. Jika komponen Config Sync dijadwalkan pada Aktifkan node yang mengalami error exec format dan tidak berfungsi.

    Jika Anda memiliki node Arm di cluster, tambahkan satu atau beberapa node amd64 ke dan, jika Anda tidak menggunakan cluster GKE, tambahkan taint ke node ARM64, untuk menghindari penjadwalan Pod ke node ARM64 tanpa toleransi yang lebih spesifik. Node grup GKE sudah memiliki taint default, jadi Anda tidak perlu menambahkannya.

Jika cluster Anda adalah cluster Autopilot, Anda juga harus mengetahui bahwa Autopilot menyesuaikan persyaratan resource container untuk memenuhi aturan berikut:

Berdasarkan aturan ini, untuk cluster Autopilot, Config Sync:

Menyiapkan cluster

Setelah membuat cluster yang sesuai, selesaikan langkah-langkah berikut:

  1. Berikan peran IAM yang diperlukan kepada pengguna yang mendaftarkan cluster.

  2. Jika Anda berencana menggunakan Google Cloud CLI untuk mengonfigurasi Config Sync atau menggunakan cluster di luar Google Cloud, memastikan bahwa Cluster GKE atau cluster di luar Google Cloud sekarang terdaftar ke sebuah fleet. Jika Anda berencana untuk menggunakan Konsol Google Cloud, Anda dapat mendaftarkan cluster GKE saat mengonfigurasi Config Sync.

Menginstal Config Sync

Pada bagian berikut, Anda memberikan akses Config Sync ke salah satu dari hal berikut sumber kebenaran:

Setelah memberikan akses, Anda dapat mengonfigurasi Config Sync.

Memberikan akses 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 Federasi Workload Identity GKE untuk GKE atau fleet Workload Identity Federation for GKE, 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 Federation for GKE 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 fleet yang memiliki Workload Identity Federation untuk GKEpool 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 Federation untuk GKE, sama seperti PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation for GKE, 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 Federation for GKE 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

Memberikan akses hanya baca Config Sync 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 Federasi Workload Identity GKE untuk GKE atau fleet Workload Identity Federation for GKE, 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 Workload Identity Federation untuk kumpulan GKE. 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 Federation untuk GKE, sama seperti PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation for GKE, 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 Federasi Workload Identity GKE untuk GKE atau fleet Workload Identity Federation for GKE, 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 Federation untuk GKE, sama seperti PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation for GKE, 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 dengan Workload Identity Federation for GKE 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.

Memberikan akses hanya baca pada Config Sync 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 Federasi Workload Identity GKE untuk GKE atau fleet Workload Identity Federation for GKE, 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 Workload Identity Federation untuk kumpulan GKE. 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 Federation untuk GKE, sama seperti PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation for GKE, 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 Federasi Workload Identity GKE untuk GKE atau fleet Workload Identity Federation for GKE, 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 Federation untuk GKE, sama seperti PROJECT_ID. Jika Anda menggunakan fleet Workload Identity Federation for GKE, 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 dengan Workload Identity Federation for GKE 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 Config Sync

Di bagian ini, Anda akan mengonfigurasi setelan untuk repositori root. Jika Anda menyinkronkan ke repositori Git, Anda dapat menggunakan Konsol Google Cloud untuk memandu Anda melalui proses instalasi dan mengotomatiskan beberapa langkah.

Saat Anda menginstal Config Sync menggunakan Konsol Google Cloud atau Google Cloud CLI, Config Sync secara otomatis membuat objek RootSync yang bernama root-sync. Anda dapat menggunakan perintah kubectl untuk mengubah root-sync dan menambahkan konfigurasi Config Sync tambahan. Untuk mempelajari lebih lanjut, lihat Konfigurasi Config Sync dengan perintah kubectl.

Konsol

Menginstal Config Sync

Untuk menginstal Config Sync, semua cluster harus terdaftar ke fleet. Saat Anda menginstal Config Sync di Konsol Google Cloud, memilih satu per satu cluster secara otomatis mendaftarkan cluster tersebut ke fleet Anda.

  1. Di konsol Google Cloud, buka halaman Config di bagian Features.

    Buka Konfigurasi

  2. Klik Install Config Sync.
  3. Pilih Upgrade otomatis (Pratinjau) untuk aktifkan Config Sync untuk mengupgrade versi secara otomatis atau pilih Upgrade manual untuk mengelola sendiri versi Config Sync. Untuk informasi selengkapnya tentang cara kerja upgrade otomatis, lihat Upgrade Config Sync.
  4. Di bagian Opsi penginstalan, pilih salah satu opsi berikut:
    • Instal Config Sync di seluruh fleet (direkomendasikan): Config Sync akan diinstal di semua cluster dalam fleet.
    • Instal Config Sync pada setiap cluster: semua cluster yang dipilih akan otomatis didaftarkan ke fleet. Config Sync akan diinstal di semua cluster dalam fleet.
  5. Jika Anda menginstal Config Sync pada masing-masing cluster, di Tabel Cluster yang tersedia, pilih cluster tempat Anda ingin menginstal Config Sync.
  6. Klik Install Config Sync. Di tab Setelan, setelah beberapa menit, Anda akan melihat Enabled di kolom Status untuk cluster di fleet Anda.

Men-deploy paket

Setelah Anda mendaftarkan cluster ke fleet dan menginstal Config Sync, Anda dapat mengonfigurasi Config Sync untuk men-deploy paket ke cluster dari sumber ketepatan. Anda dapat men-deploy paket yang sama ke beberapa cluster atau men-deploy paket yang berbeda ke cluster yang berbeda. Anda dapat mengedit paket setelah men-deploy-nya, kecuali untuk beberapa setelan seperti nama paket dan jenis sinkronisasi. Untuk informasi selengkapnya, lihat Mengelola paket.

Untuk men-deploy paket, selesaikan langkah-langkah berikut:

  1. Di konsol Google Cloud, buka dasbor Config Sync.

    Buka dasbor Config Sync

  2. Klik Deploy Package.

  3. Di tabel Select clusters for package deployment, pilih cluster tempat Anda ingin men-deploy paket, lalu klik Continue.

  4. Pilih Paket yang dihosting di Git atau Paket yang dihosting di OCI sebagai jenis sumber, lalu klik Lanjutkan.

  5. Di bagian Package details, masukkan Package name, yang mengidentifikasi objek RootSync atau RepoSync.

  6. Di kolom Sync type, pilih Cluster Scope Sync atau Namespace scope sync sebagai jenis sinkronisasi.

    Sinkronisasi cakupan cluster membuat objek RootSync dan sinkronisasi cakupan Namespace membuat objek RepoSync. Untuk informasi selengkapnya tentang objek ini, lihat Arsitektur Sinkronisasi Konfigurasi.

  7. Di bagian Sumber, selesaikan langkah-langkah berikut:

    • Untuk sumber yang dihosting di repositori Git, masukkan kolom berikut:

      1. Masukkan URL repositori Git yang Anda gunakan sebagai sumber tepercaya sebagai Repository URL.
      2. Opsional: Perbarui kolom Revisi untuk memeriksa apakah Anda tidak menggunakan HEAD default.
      3. Opsional: Perbarui kolom Path jika Anda tidak ingin menyinkronkan dari repositori root.
      4. Opsional: Perbarui kolom Branch jika Anda tidak menggunakan default Cabang main.
    • Untuk sumber yang dihosting dalam gambar OCI, masukkan kolom berikut:

      1. Masukkan URL gambar OCI yang Anda gunakan sebagai sumber kebenaran sebagai Image.
      2. Masukkan jalur direktori yang akan disinkronkan, relatif terhadap direktori root, seperti Direktori.
  8. (Opsional): Luaskan bagian Setelan lanjutan untuk menyelesaikan tindakan berikut:

    1. Pilih Jenis autentikasi. Config Sync membutuhkan akses hanya baca ke sumber tepercaya Anda untuk membaca file konfigurasi dalam sumber dan menerapkannya ke cluster Anda. Kecuali sumber Anda tidak memerlukan otentikasi, seperti repositori publik, pastikan Anda memberikan Config Sync akses hanya baca ke repositori Git Anda, OCI image, atau Helm chart (khusus gcloud CLI). Pilih jenis autentikasi yang sama dengan yang Anda konfigurasi saat menginstal Sinkronisasi Konfigurasi:

      • Tidak ada: Tidak menggunakan autentikasi.
      • SSH: Autentikasi dengan menggunakan pasangan kunci SSH.
      • Cookiefile: Lakukan autentikasi menggunakan cookiefile.
      • Token: Autentikasi dengan menggunakan token akses atau sandi.
      • Google Cloud Repository: Gunakan akun layanan Google untuk mengakses ke repositori Cloud Source Repositories. Hanya pilih opsi ini jika Workload Identity Federation untuk GKE tidak diaktifkan di cluster Anda.
      • Workload Identity: Menggunakan akun layanan Google untuk mengakses ke repositori Cloud Source Repositories.
    2. Masukkan angka dalam detik untuk menetapkan Waktu tunggu sinkronisasi, yang menentukan berapa lama Config Sync menunggu di antara percobaan untuk mengambil dari sumber kebenaran.

    3. Masukkan URL proxy Git untuk proxy HTTPS yang akan digunakan saat berkomunikasi dengan sumber yang terpercaya.

    4. Pilih Hierarchy untuk mengubah Source format.

      Nilai default Tidak terstruktur direkomendasikan pada sebagian besar kasus karena memungkinkan Anda mengatur sumber kebenaran sesuai keinginan Anda.

  9. Klik Deploy Package.

    Anda akan dialihkan ke halaman Packages Config Sync. Setelah beberapa menit, Anda akan melihat Disinkronkan di Status sinkronisasi untuk cluster yang telah Anda konfigurasi.

gcloud

Sebelum melanjutkan, pastikan Anda telah mendaftarkan cluster Anda ke suatu fleet.

  1. Aktifkan fitur fleet ConfigManagement:

    gcloud beta container fleet config-management enable
    
  2. Siapkan konfigurasi dengan membuat apply-spec.yaml baru manifes atau menggunakan manifes yang ada. Menggunakan manifes yang ada memungkinkan Anda mengonfigurasi cluster dengan setelan yang sama dengan yang digunakan oleh cluster lain.

    Buat manifes baru

    Untuk mengonfigurasi Config Sync dengan setelan baru untuk cluster Anda, buat file bernama apply-spec.yaml dan salin file YAML berikut ke dalamnya.

    Anda dapat menetapkan semua kolom spec.configSync opsional yang diperlukan saat membuat manifes, dan kemudian menggunakan Perintah kubectl untuk konfigurasi. Anda juga hanya dapat menetapkan kolom spec.configSync.enabled sebagai true dan menghilangkan kolom opsional. Kemudian, Anda dapat menggunakan perintah kubectl untuk membuat objek RootSync tambahan atau RepoSync yang dapat Anda kelola sepenuhnya menggunakan perintah kubectl nanti.

    # apply-spec.yaml
    
    applySpecVersion: 1
    spec:
      # upgrades: UPGRADE_SETTING
      configSync:
        # Set to true to install and enable Config Sync
        enabled: true
        # If you don't have a source of truth yet, omit the
        # following fields. You can configure them later.
        sourceType: SOURCE_TYPE
        sourceFormat: FORMAT
        syncRepo: REPO
        syncRev: REVISION
        syncBranch: BRANCH
        secretType: SECRET_TYPE
        gcpServiceAccountEmail: EMAIL
        metricsGcpServiceAccountEmail: METRICS_EMAIL
        policyDir: DIRECTORY
        preventDrift: PREVENT_DRIFT
    

    Ganti kode berikut:

    • (Pratinjau) UPGRADE_SETTING: hapus tanda komentar pada kolom dan tetapkan ke auto untuk mengonfigurasi Config Sync agar dapat mengupgrade secara otomatis. Tetapkan ke manual untuk mengupgrade sendiri Config Sync secara manual. Nilai defaultnya adalah manual. Tanda ini hanya didukung untuk GKE di cluster Google Cloud. Untuk menggunakan {i>field <i}ini, Anda mungkin perlu mengupdate gcloud CLI dengan menjalankan gcloud components update.

    • SOURCE_TYPE: menambahkan git untuk disinkronkan dari repositori Git, oci untuk menyinkronkan dari image OCI, atau helm untuk disinkronkan dari diagram Helm. Jika tidak ada nilai yang ditentukan, defaultnya adalah git.

    • 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 untuk maksimal.

    • REPO: menambahkan URL sumber tepercaya. URL repositori Git dan Helm menggunakan protokol HTTPS atau SSH. Contoh, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Jika Anda berencana menggunakan SSH sebagai secretType, masukkan URL Anda dengan protokol SSH. Bidang ini wajib diisi dan jika Anda tidak memasukkan protokol, URL diperlakukan sebagai URL HTTPS.

      URL OCI menggunakan format berikut: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Secara default, gambar diambil dari tag latest, tetapi Anda dapat tarik 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
    • REVISION: revisi Git (tag atau hash) yang akan disinkronkan dari mereka. Kolom ini bersifat opsional dan nilai defaultnya adalah HEAD. Mulai dari Config Sync versi 1.17.0, Anda juga dapat menentukan di kolom syncRev. Saat menggunakan {i>hash <i}dalam versi 1.17.0 atau yang lebih baru, ID tersebut harus berupa hash lengkap, dan bukan bentuk yang disingkat.

    • BRANCH: cabang repositori yang akan disinkronkan. Kolom ini bersifat opsional dan default-nya adalah master. Mulai dari Config Sync versi 1.17.0, sebaiknya gunakan syncRev untuk menentukan nama cabang agar lebih praktis. Jika syncRev dan kolom syncBranch ditetapkan, syncRev akan mengambil yang lebih diutamakan daripada syncBranch.

    • SECRET_TYPE: salah satu dari secretTypes berikut:

      git

      • none: Tidak menggunakan autentikasi.
      • ssh: Menggunakan pasangan kunci SSH.
      • cookiefile: Gunakan cookiefile.
      • token: Menggunakan token.
      • gcpserviceaccount: Gunakan akun layanan Google untuk mengakses dan Cloud Source Repositories. Jika Anda memilih ini jenis autentikasi, Anda perlu membuat binding kebijakan IAM setelah selesai mengonfigurasi Config Sync. Untuk mengetahui detailnya, lihat tab akun layanan dari Memberikan akses hanya baca Config Sync ke Git bagian.
      • gcenode: Gunakan akun layanan Google untuk mengakses dan Cloud Source Repositories. Hanya pilih opsi ini jika Workload Identity Federation for GKE tidak diaktifkan di cluster Anda.

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

      oci

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

      helm

      • token: Menggunakan token.
      • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Hanya pilih opsi ini jika Workload Identity Federation untuk GKE tidak diaktifkan di cluster Anda.
      • gcpserviceaccount: Gunakan akun layanan Google untuk mengakses gambar.
    • EMAIL: Jika Anda menambahkan gcpserviceaccount sebagai secretType Anda, tambahkan layanan Google Anda alamat email Anda. Contoh, acm@PROJECT_ID.iam.gserviceaccount.com.

    • METRICS_EMAIL: email Google Cloud Akun Layanan (GSA) yang digunakan untuk mengekspor metrik Config Sync ke dan konfigurasi di Cloud Monitoring. GSA harus memiliki Penulis Metrik Pemantauan (roles/monitoring.metricWriter) Peran IAM. default Kubernetes ServiceAccount di namespace config-management-monitoring harus terikat dengan GSA.

    • DIRECTORY: jalur direktori yang akan disinkronkan, yang terkait dengan {i> root <i}repositori Git. Semua subdirektori dalam yang Anda tentukan akan disertakan dan disinkronkan ke cluster. Tujuan nilai defaultnya adalah direktori utama repositori.

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

    Untuk melihat daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat kolom gcloud.

    Gunakan manifes yang ada

    Untuk mengonfigurasi cluster Anda dengan setelan yang sama dengan yang digunakan oleh cluster lain, mengambil setelan dari cluster terdaftar:

    gcloud alpha container fleet config-management fetch-for-apply \
        --membership=MEMBERSHIP_NAME \
        --project=PROJECT_ID \
        > CONFIG_YAML_PATH
    

    Ganti kode berikut:

    • MEMBERSHIP_NAME: nama keanggotaan terdaftar cluster yang memiliki setelan Config Sync yang ingin Anda gunakan
    • PROJECT_ID: project ID Anda
    • CONFIG_YAML_PATH: jalur ke apply-spec.yaml yang berisi setelan yang diambil dari {i>cluster <i}(mengelompokkan)
  3. Terapkan file apply-spec.yaml. Jika Anda menggunakan manifes yang sudah ada, Anda harus menerapkan file tersebut ke cluster yang ingin Anda atur dengan setelan yang sudah Anda ambil di perintah sebelumnya:

    gcloud beta container fleet config-management apply \
        --membership=MEMBERSHIP_NAME \
        --config=CONFIG_YAML_PATH \
        --project=PROJECT_ID
    

    Ganti kode berikut:

    • MEMBERSHIP_NAME: nama keanggotaan fleet yang Anda pilih saat mendaftarkan cluster Anda. Anda dapat menemukan nama dengan gcloud container fleet memberships list.
    • CONFIG_YAML_PATH: jalur ke File apply-spec.yaml.
    • PROJECT_ID: project ID Anda.

Terraform

Untuk setiap cluster yang ingin dikonfigurasi Config Sync, menerapkan blok resource google_gkehub_feature_membership yang berisi blok configmanagement dan config_sync:

git

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Ganti kode berikut:

  • EXISTING_CLUSTER_NAME: nama cluster yang ada.
  • EXISTING_CLUSTER_LOCATION: lokasi cluster yang ada.
  • MEMBERSHIP_ID: ID binding keanggotaan.
  • VERSION: (opsional) nomor versi Config Sync. Harus disetel ke versi 1.17.0 atau yang lebih baru. Jika dibiarkan kosong, versi defaultnya adalah versi terbaru.
  • REPO: URL ke repositori yang berisi file konfigurasi Anda.
  • BRANCH: cabang repositori, misalnya main.
  • DIRECTORY: jalur dalam repositori Git yang mewakili level teratas repositori yang ingin Anda sinkronkan.
  • SECRET: jenis autentikasi rahasia.

oci

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Ganti kode berikut:

  • EXISTING_CLUSTER_NAME: nama cluster yang ada.
  • EXISTING_CLUSTER_LOCATION: lokasi cluster yang ada.
  • MEMBERSHIP_ID: ID binding keanggotaan.
  • VERSION: (opsional) nomor versi Config Sync. Jika dibiarkan kosong, versi defaultnya adalah versi terbaru.
  • REPO: URL ke repositori image OCI yang berisi file konfigurasi Anda.
  • DIRECTORY: jalur absolut direktori berisi resource yang ingin Anda sinkronkan. Biarkan kosong untuk menggunakan direktori root.
  • SECRET: jenis autentikasi rahasia.

Ulangi proses ini untuk setiap cluster yang ingin Anda sinkronkan.

Setelah selesai mengonfigurasi repositori root, Anda dapat memilih memilih untuk mengonfigurasi sinkronisasi dari beberapa repositori, termasuk repositori root dan repositori namespace lainnya. Namespace akan sangat membantu jika Anda menginginkan repositori yang berisi cakupan namespace yang disinkronkan ke namespace tertentu di seluruh cluster.

Mengonfigurasi default tingkat fleet

Jika Anda memiliki edisi Google Kubernetes Engine (GKE) Enterprise yang diaktifkan, Anda dapat aktifkan dan konfigurasikan Config Sync sebagai default level fleet untuk cluster Anda. Artinya, setiap cluster GKE di Google Cloud yang baru yang dibuat dalam fleet akan mengaktifkan Config Sync pada cluster dengan setelan yang Anda tentukan. Anda kita bisa mencari tahu konfigurasi default fleet lebih lanjut di Kelola fitur tingkat fleet.

Jika hanya menggunakan konsol Google Cloud, Anda dapat mengaktifkan Config Sync secara default pada cluster Anda dan tetapkan versi Config Sync untuk fleet Anda. Jika Anda menggunakan Terraform, Anda dapat mengaktifkan Config Sync secara default pada cluster, mengatur versi Config Sync untuk perangkat Anda, dan mengatur koneksi ke di repositori Git atau repositori image OCI.

Guna mengonfigurasi default tingkat fleet untuk Config Sync, selesaikan langkah-langkah berikut langkah:

Konsol

  1. Di konsol Google Cloud, buka halaman Feature Manager.

    Buka Feature Manager

  2. Di panel Config Sync, klik Configure.

  3. Tinjau setelan tingkat fleet Anda. Semua cluster baru yang Anda buat di fleet mewarisi setelan ini.

  4. Opsional: Untuk mengubah setelan default, klik Sesuaikan fleet setelan. Dalam dialog yang muncul, lakukan hal berikut:

  5. Pilih Upgrade otomatis (Pratinjau) memiliki versi upgrade Config Sync secara otomatis atau pilih Upgrade manual untuk mengelola sendiri versi Config Sync. Untuk mengetahui informasi selengkapnya tentang cara kerja upgrade otomatis, lihat Mengupgrade Config Sync.

  6. Jika Anda memilih Upgrade manual, dalam daftar Version, pilih versi Config Sync yang ingin Anda gunakan.

  7. Klik Simpan perubahan.

  8. Klik Konfigurasikan.

  9. Pada dialog konfirmasi Configure fleet settings, klik Confirm. Jika belum pernah Anda mengaktifkan Config Sync, mengklik Confirm juga akan mengaktifkan API anthosconfigmanagement.googleapis.com.

Terraform

  1. Buat direktori untuk file Terraform konfigurasi default fleet. Ke direktori tersebut, tambahkan file main.tf dengan resource berikut yang mengonfigurasi setelan Config Sync:

    git

    terraform {
      required_providers {
        google = {
          source = "hashicorp/google"
          version = ">=5.16.0"
          }
        }
      }
    
    provider "google" {
      project = "PROJECT_ID"
    }
    
    resource "google_gke_hub_feature" "feature" {
      name = "configmanagement"
      location = "global"
      provider = google
      fleet_default_member_config {
        configmanagement {
        version = "VERSION"
        config_sync {
        source_format = "unstructured"
          git {
            sync_repo = "REPO"
            sync_branch = "BRANCH"
            policy_dir = "DIRECTORY"
            secret_type = "SECRET"
          }
        }
        }
      }
    }
    

    Ganti kode berikut:

    • PROJECT_ID: project ID host fleet.
    • VERSION: (opsional) nomor versi Config Sync. Jika dibiarkan kosong, versi defaultnya adalah versi terbaru.
    • REPO: URL ke repositori yang berisi file konfigurasi Anda.
    • BRANCH: cabang repositori, misalnya main.
    • DIRECTORY: jalur dalam repositori Git yang mewakili level teratas repositori yang ingin Anda sinkronkan.
    • SECRET: jenis autentikasi rahasia.

    Untuk mengetahui daftar lengkap setelan yang didukung dalam blok git Config Sync, baca dokumentasi referensi Terraform untuk fitur hub GKE.

    OCI

    terraform {
      required_providers {
        google = {
          source = "hashicorp/google"
          version = ">=5.16.0"
          }
        }
      }
    
    provider "google" {
      project = "PROJECT_ID"
    }
    
    resource "google_gke_hub_feature" "feature" {
      name = "configmanagement"
      location = "global"
      provider = google
      fleet_default_member_config {
        configmanagement {
        version = "VERSION"
        config_sync {
        source_format = "unstructured"
          oci {
            sync_repo = "REPO"
            policy_dir = "DIRECTORY"
            secret_type = "SECRET"
          }
        }
        }
      }
    }
    

    Ganti kode berikut:

    • PROJECT_ID: project ID host fleet.
    • VERSION: nomor versi Config Sync. Harus disetel ke versi 1.17.0 atau yang lebih baru. Jika dibiarkan kosong, versi defaultnya adalah versi terbaru.
    • REPO: URL ke repositori image OCI yang berisi file konfigurasi.
    • DIRECTORY: jalur absolut direktori berisi resource yang ingin Anda sinkronkan. Biarkan kosong untuk menggunakan direktori root.
    • SECRET: jenis autentikasi rahasia.

    Untuk mengetahui daftar lengkap setelan yang didukung dalam blok oci Config Sync, baca dokumentasi referensi Terraform untuk fitur hub GKE.

  2. Lakukan inisialisasi Terraform di direktori yang Anda buat:

    terraform init
    
  3. Pastikan perubahan yang Anda ajukan dengan Terraform sesuai dengan rencana yang diharapkan:

    terraform plan
    
  4. Buat konfigurasi anggota fleet default:

    terraform apply
    

Jika Anda sudah memiliki cluster yang ingin diupdate untuk menggunakan cluster default Setelan Config Sync, gunakan konsol Google Cloud untuk menyinkronkan perangkat yang dipilih cluster ke default fleet Anda. Atau, Anda dapat secara manual mengonfigurasi cluster dengan setelan yang sama menggunakan Terraform atau gcloud CLI dengan dengan mengikuti petunjuk untuk mengonfigurasi Config Sync. Jika sebelumnya Anda menggunakan Untuk menentukan default fleet, gunakan configmanagement yang sama dan Blok config_sync yang Anda gunakan untuk menyetel default guna mengonfigurasi cluster yang dipilih.

Untuk menyinkronkan setelan default Config Sync di seluruh perangkat Anda, ikuti langkah-langkah berikut:

  1. Buka Feature Manager:

    Buka Feature Manager: Config Sync

  2. Di tabel cluster, pilih cluster yang ingin Anda sinkronkan ke setelan fleet.

  3. Klik Sinkronkan ke setelan inventaris.

Setelan default Config Sync akan diterapkan ke cluster mana pun yang pilih. Meskipun Konsol Google Cloud hanya menampilkan sebagian setelan, seperti versi Config Sync, semua setelan tingkat fleet disinkronkan ke klaster. Misalnya, jika Anda mengonfigurasi Config Sync untuk disinkronkan ke repositori Git dengan menggunakan Terraform, setelan tersebut akan disinkronkan ke cluster Anda, tetapi tidak ditampilkan di Konsol Google Cloud.

Memverifikasi penginstalan

Setelah menginstal dan mengonfigurasi Config Sync, Anda dapat memverifikasi bahwa instalasi berhasil diselesaikan.

Konsol

Selesaikan langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Config di bagian Features.

    Buka Konfigurasi

  2. Pada tab Packages, periksa kolom Sync status di tabel cluster. Penginstalan Config Sync yang berhasil akan memiliki status Terinstal. Sumber tepercaya yang berhasil dikonfigurasi memiliki status Disinkronkan.

gcloud

Jalankan perintah berikut:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Ganti PROJECT_ID dengan ID project Anda.

Penginstalan yang berhasil memiliki status SYNCED. Dimulai dalam Config Sync versi 1.18.0, outputnya juga menampilkan versi Config Sync mana diinstal dan setelan upgrade Config Sync.

Jika Anda melihat error setelah menjalankan perintah sebelumnya, pastikan Anda telah membuat git-creds Rahasia. Jika Anda telah membuat Secret, coba jalankan kembali perintah berikut:

gcloud beta container fleet config-management apply

Anda juga dapat menggunakan Perintah nomos status untuk periksa apakah Config Sync berhasil diinstal. Penginstalan yang valid tanpa masalah memiliki status PENDING atau SYNCED. Tidak valid atau tidak lengkap penginstalan memiliki status NOT INSTALLED ATAU NOT CONFIGURED. Output juga mencakup error yang dilaporkan.

Kontrol akses berbasis peran (RBAC) dan izin

Config Sync mencakup workload dengan hak istimewa tinggi. Tabel berikut mencantumkan izin untuk workload berikut:

Komponen Namespace Akun Layanan Izin Deskripsi
Operator ConfigManagement config-management-system config-management-operator admin cluster ConfigManagement Operator menginstal komponen lainnya dalam tabel ini. Beberapa komponen tersebut memerlukan izin admin cluster, sehingga Operator ConfigManagement juga memerlukannya.
Config Sync config-management-system Lihat Izin Config Sync untuk izin yang diperlukan.

Permintaan resource

Bagian berikut mencantumkan permintaan resource untuk Config Sync.

Tabel berikut mencantumkan persyaratan resource Kubernetes untuk Komponen Config Sync. Untuk informasi selengkapnya, lihat Mengelola Resource untuk Container dalam dokumentasi Kubernetes.

Tidak semua komponen yang tercantum dibuat. Kondisi berikut menyebabkan setiap komponen yang akan dijadwalkan:

  • config-management-operator diinstal saat Config Sync diaktifkan.
  • reconciler-manager diinstal saat Config Sync diaktifkan.
  • admission-webhook diinstal saat pencegahan penyimpangan diaktifkan.
  • reconciler diinstal untuk setiap RootSync dan RepoSync.
  • otel-collector diinstal saat Config Sync diaktifkan.

Untuk mempelajari komponen ini lebih lanjut, lihat Arsitektur Sinkronisasi Konfigurasi.

1,18

Nama deployment Permintaan CPU (m) per replika Permintaan memori (Mi) per replika
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (satu per RootSync dan RepoSync) Lihat deployment rekonsiliasi untuk mengetahui detailnya.

1 Webhook penerimaan memiliki dua replika, jadi jika menghitung total permintaan sumber daya, Anda perlu melipatgandakan nilainya jika Anda menggunakan webhook penerimaan. Webhook penerimaan dinonaktifkan secara default.

1,17

Nama deployment Permintaan CPU (m) per replika Permintaan memori (Mi) per replika
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (satu per RootSync dan RepoSync) Lihat deployment rekonsiliasi untuk mengetahui detailnya.

1 Webhook penerimaan memiliki dua replika, jadi jika menghitung total permintaan sumber daya, Anda perlu melipatgandakan nilainya jika Anda menggunakan webhook penerimaan. Webhook penerimaan dinonaktifkan secara default.

1.16

Nama deployment Permintaan CPU (m) per replika Permintaan memori (Mi) per replika
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (satu per RootSync dan RepoSync) Lihat deployment rekonsiliasi untuk mengetahui detailnya.

1 Webhook penerimaan memiliki dua replika, jadi saat menghitung total permintaan sumber daya, Anda perlu melipatgandakan nilainya jika Anda menggunakan webhook penerimaan. Webhook penerimaan dinonaktifkan secara default.

Deployment rekonsiliasi

Untuk setiap objek RootSync dan RepoSync, Config Sync membuat dan deployment rekonsiliasi independen untuk menangani sinkronisasi. Deployment rekonsiliasi terdiri dari beberapa container. Untuk mempelajari container ini lebih lanjut, lihat Penampung rekonsiliasi.

Pada Config Sync versi 1.17.0 dan yang lebih baru, resource default meminta rekonsiliasi berbeda untuk cluster Standar dan Autopilot. Semua jenis cluster lainnya gunakan {i>Default<i} standar.

Cluster standar

1,18

Nama penampung Permintaan CPU (m) Permintaan memori (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Opsional) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Opsional) 10 20
helm-sync 75 128
oci-sync 25 32

1,17

Nama penampung Permintaan CPU (m) Permintaan memori (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Opsional) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Opsional) 10 20
helm-sync 75 128
oci-sync 25 32

1.16

Nama penampung Permintaan CPU (m) Permintaan memori (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Opsional) 10 100
git-sync 10 200
gcenode-askpass-sidecar (Opsional) 10 20
helm-sync 50 256
oci-sync 10 200

Cluster Autopilot

1,18

Nama penampung Permintaan dan batas CPU (m) Permintaan dan batas memori (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Opsional) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Opsional) 50 64
helm-sync 250 384
oci-sync 50 64

1,17

Nama penampung Permintaan dan batas CPU (m) Permintaan dan batas memori (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Opsional) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Opsional) 50 64
helm-sync 150 256
oci-sync 50 64

1.16

Pada versi Config Sync yang lebih lama dari 1.17.0, resource meminta sama untuk {i>Standard<i} dan {i>Autopilot<i}.

Untuk mempelajari cara mengganti permintaan dan batas resource default, lihat penggantian resource.

Versi Paket Helm dan Kustomize

Config Sync memanfaatkan file yang dapat dieksekusi Helm dan Kustomize untuk merender di balik layar. Tabel berikut berisi daftar Versi Config Sync yang mendukung fitur rendering, bersama dengan yakni versi Helm dan Kustomize.

Versi Sinkronisasi Konfigurasi Versi Helm Menyesuaikan versi
1.18.0 v3.14.3 v5.3.0
1.17.1 dan 1.17.3 v3.13.3 v5.3.0
1.16.3 dan 1.17.0 v3.13.1 v5.1.1
1.16.1 dan 1.16.2 v3.12.3 v5.1.1
1.16.0 v3.12.2 v5.1.1
1.15.3 v3.12.2 v5.1.0
1.15.1 hingga 1.15.2 v3.11.3 v5.0.3
1.15.0 v3.11.3 v5.0.1
1.11.0 hingga 1.14.3 v3.6.3 v4.5.2

Untuk mengetahui informasi tentang cara merender Helm melalui Kustomize, lihat Mengonfigurasi Kubernetes dengan Kustomize. Sebagai informasi tentang penggunaan Helm API, lihat Menyinkronkan chart Helm dari Artifact Registry.

Langkah selanjutnya