Menginstal Config Sync secara manual menggunakan kubectl

Jika lingkungan Anda memerlukan pengelolaan resource Kubernetes command line langsung, menginstal Config Sync dengan perintah kubectl memungkinkan Anda menyinkronkan konfigurasi cluster dari source of truth pusat. Meskipun metode penginstalan ini didukung, metode ini tidak kompatibel dengan konsolCloud de Confiance atau Google Cloud CLI. Untuk mengelola Config Sync menggunakan alat tersebut, lihat Menyesuaikan penginstalan Config Sync.

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

• Membuat, atau memiliki akses ke sumber tepercaya.

• Instal dan lakukan inisialisasi Google Cloud CLI, yang menyediakan perintah gcloud, kubectl, dan nomos yang digunakan dalam petunjuk ini. Jika Anda menggunakan Cloud Shell, Google Cloud CLI sudah diinstal sebelumnya.

• kubectl tidak diinstal secara default oleh Google Cloud CLI. Untuk menginstal kubectl, gunakan perintah berikut:

  gcloud components install kubectl
  

• Lakukan autentikasi ke Cloud de Confiance by S3NS menggunakan perintah gcloud auth login agar Anda dapat mendownload komponen Config Sync.

Menyiapkan cluster Anda

Buat, atau miliki akses ke, cluster Google Kubernetes Engine yang memenuhi persyaratan untuk Config Sync.

Menyiapkan izin

Pengguna Cloud de Confiance yang menginstal Config Sync memerlukan izin IAM untuk membuat peran baru di cluster Anda. Jika diperlukan, berikan peran ini dengan perintah berikut:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Ganti kode berikut:

• CLUSTER_NAME: nama cluster Anda
• USER_ACCOUNT: alamat email akun Cloud de Confiance 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 Admin Akun Layanan (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:
   • Git
   • OCI
   • Helm
3. Mengonfigurasi Config Sync

Men-deploy Config Sync

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

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

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

2. Ekstrak arsip:

   tar -xzvf config-sync.tar.gz

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

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

   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 bisa mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuk cluster tersebut.

Jika gagal karena masalah pada Config Sync yang bukan disebabkan oleh error sintaksis YAML atau JSON, objek mungkin dibuat instance-nya di cluster, tetapi mungkin tidak berfungsi dengan benar. Dalam situasi ini, Anda dapat menggunakan perintah nomos status untuk memeriksa error pada 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 ulang manifes Config Sync ke cluster.

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

Memberikan akses hanya baca ke Config Sync

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

Memberikan akses hanya baca ke Git kepada Config Sync

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

Jika repositori Anda tidak memerlukan autentikasi untuk akses hanya baca, 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 yang disimpan, Anda tidak perlu melakukan autentikasi. Dalam hal ini, Anda tidak perlu membuat Secret.

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

Config Sync mendukung mekanisme berikut untuk autentikasi:

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

Mekanisme yang Anda pilih bergantung pada apa yang didukung repositori Anda. Umumnya, 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 dan Anda tidak tahu metode autentikasi mana yang didukung, hubungi administrator Anda.

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

1. Mencantumkan semua repositori:

   gcloud source repos list
   

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

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

   Anda harus menggunakan URL ini saat mengonfigurasi Config Sync di bagian berikut. Jika Anda mengonfigurasi Config Sync menggunakan Cloud de Confiance console, tambahkan URL di kolom URL. Jika Anda mengonfigurasi Config Sync menggunakan Google Cloud CLI, tambahkan URL ke kolom syncRepo pada file konfigurasi Anda.

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

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 hanya baca, Anda dapat melanjutkan untuk mengonfigurasi Config Sync dan menggunakan none sebagai jenis autentikasi Anda. Misalnya, jika image Anda bersifat publik dan dapat diakses oleh siapa saja di internet, Anda tidak perlu melakukan autentikasi.

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

• Kubernetes ServiceAccount (k8sserviceaccount)

• Akun layanan default Compute Engine (gcenode)

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

Mengonfigurasi Config Sync untuk Certificate Authority

Untuk server yang dikonfigurasi dengan sertifikat dari Certificate Authority (CA) yang belum dipercaya, Config Sync dapat dikonfigurasi untuk menggunakan sertifikat CA guna memverifikasi koneksi HTTPS ke server. Hal ini didukung untuk server Git, Helm, atau OCI. Sertifikat CA harus menyertakan sertifikat SSL lengkap (Root/Intermediate/Leaf). Jika server Anda sudah menggunakan CA tepercaya atau Anda tidak terhubung melalui HTTPS, Anda dapat melewati langkah ini dan membiarkan caCertSecretRef tidak ditetapkan.

Memberikan akses hanya baca ke Helm untuk Config Sync

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

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

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

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

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

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

Mengonfigurasi Config Sync

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

1. Jika Anda menggunakan webhook 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 pencegahan 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: unstructured
     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_REPOSITORY: tambahkan URL repositori Git untuk digunakan sebagai repositori root. Anda dapat memasukkan URL menggunakan protokol HTTPS atau SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
   • ROOT_REVISION: tambahkan revisi Git (tag atau hash) atau cabang yang akan disinkronkan. Kolom ini bersifat opsional dan nilai defaultnya adalah HEAD. Saat menggunakan hash, hash tersebut harus berupa hash lengkap, dan bukan bentuk singkatan.
   • 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 mudah. Jika kolom revision dan kolom branch ditentukan, revision akan lebih diprioritaskan daripada branch.
   • ROOT_DIRECTORY: tambahkan jalur di repositori Git ke direktori root yang berisi konfigurasi yang ingin Anda sinkronkan. Kolom ini bersifat opsional dan default-nya adalah direktori root (/) repositori.

   • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

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

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

     Kolom ini wajib diisi.

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

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

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

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Secret Anda. Jika kolom ini ditetapkan, penyedia Git Anda harus menggunakan sertifikat yang dikeluarkan oleh certificate authority (CA) ini. Secret harus berisi sertifikat CA di bawah kunci bernama cert. Kolom ini bersifat opsional.

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

   Untuk penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat Kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan Git sebagai sumber.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: unstructured
     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_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 berdasarkan TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Untuk menarik berdasarkan 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. Kolom ini bersifat opsional dan default-nya adalah direktori root (/) repositori.

   • ROOT_AUTH_TYPE: tambahkan salah satu jenis autentikasi berikut:

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

     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.s3ns.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Secret Anda. Jika kolom ini ditetapkan, penyedia OCI Anda harus menggunakan sertifikat yang diterbitkan oleh certificate authority (CA) ini. Secret harus berisi sertifikat CA di bawah kunci bernama cert. Kolom ini bersifat opsional.

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

   Untuk penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat Kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan image OCI sebagai sumber.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: unstructured
     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_HELM_REPOSITORY: URL repositori Helm yang akan digunakan sebagai repositori root. Anda dapat memasukkan URL menggunakan protokol HTTPS atau SSH. Misalnya, https://github.com/GoogleCloudPlatform/anthos-config-management-samples menggunakan protokol HTTPS. Kolom ini wajib diisi.
   • HELM_CHART_NAME: tambahkan nama diagram Helm Anda. Kolom ini wajib diisi.
   • HELM_CHART_VERSION: versi diagram Anda. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, versi terbaru akan digunakan.
   • HELM_RELEASE_NAME: nama rilis Helm. Kolom ini bersifat opsional.
   • HELM_RELEASE_NAMESPACE: namespace target untuk rilis. Kustomize hanya menetapkan namespace untuk resource yang berisi namespace: {{ .Release.Namespace }} dalam template-nya. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, namespace default config-management-system akan digunakan.
   • HELM_INCLUDE_CRDS: tetapkan ke true jika Anda ingin template Helm juga membuat CustomResourceDefinition. Kolom ini bersifat opsional. Jika tidak ada nilai yang ditentukan, nilai defaultnya adalah false dan CRD tidak akan dibuat.
   • VALUE: nilai yang akan digunakan, bukan nilai default yang disertakan dengan 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: Jangan gunakan autentikasi
     • token: Gunakan nama pengguna dan sandi untuk mengakses repositori Helm pribadi.
     • gcenode: Gunakan akun layanan default Compute Engine untuk mengakses image di Artifact Registry. Hanya pilih opsi ini jika Workload Identity Federation untuk GKE tidak diaktifkan di cluster Anda.
     • gcpserviceaccount: Menggunakan akun layanan Google untuk mengakses image.

     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.s3ns.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: tambahkan nama Secret Anda jika token adalah ROOT_AUTH_TYPE. Kolom ini bersifat opsional.

   • ROOT_CA_CERT_SECRET_NAME: tambahkan nama Secret Anda. Jika kolom ini ditetapkan, penyedia Helm Anda harus menggunakan sertifikat yang dikeluarkan oleh certificate authority (CA) ini. Secret harus berisi sertifikat CA di bawah kunci bernama cert. Kolom ini bersifat opsional.

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

   Untuk penjelasan tentang kolom dan daftar lengkap kolom yang dapat Anda tambahkan ke kolom spec, lihat Kolom RootSync.

   Manifes ini membuat objek RootSync yang menggunakan Helm sebagai sumber.

4. Terapkan perubahan:

   kubectl apply -f root-sync.yaml
   

Berikan nama cluster untuk pemilih cluster (opsional)

Jika ingin menggunakan cluster-name-selectors, Anda harus memberikan nama cluster ke Config Sync. Langkah ini bersifat opsional dan hanya diperlukan jika Anda menggunakan pemilih nama cluster.

Untuk memberikan nama cluster, selesaikan langkah-langkah berikut:

1. Tambahkan variabel lingkungan CLUSTER_NAME ke deployment reconciler-manager:

   kubectl set env deployment/reconciler-manager -n config-management-system CLUSTER_NAME=CLUSTER_NAME
   

   Ganti CLUSTER_NAME dengan nama cluster atau nama keanggotaan Anda.

2. Untuk menerapkan nama cluster ke rekonsiler RootSync dan RepoSync, mulai ulang deployment reconciler-manager:

   kubectl rollout restart deployment/reconciler-manager -n config-management-system
   

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 rekonsiler dengan awalan root-reconciler. Rekonsiler adalah Pod yang di-deploy sebagai Deployment. Alat ini menyinkronkan manifes dari repositori Git ke cluster.

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

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Ganti ROOT_SYNC_NAME dengan nama RootSync.

Anda akan melihat output yang mirip dengan contoh berikut ini:

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

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

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

Mengupgrade Config Sync

Langkah-langkah untuk mengupgrade Config Sync bergantung pada versi yang Anda upgrade dan versi yang Anda gunakan. Mulai versi 1.20.0, Config Sync disediakan sebagai penginstalan mandiri tanpa ConfigManagement Operator. 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.

Untuk mengupgrade dari versi yang tidak didukung, lakukan upgrade langkah demi langkah dengan penambahan tidak lebih dari tiga versi minor sekaligus. Misalnya, jika versi Config Sync saat ini adalah 1.16.0, upgrade terlebih dahulu ke versi 1.19.0, lalu ke versi 1.22.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, Config Management telah diinstal di cluster. Untuk meng-uninstal Config Management, selesaikan langkah-langkah berikut untuk meng-uninstal Config Management, tetapi biarkan Config Sync tetap terinstal di cluster. Sebaiknya gunakan nomos CLI untuk meng-uninstal ConfigManagement Operator karena memiliki antarmuka yang lebih lengkap dan penanganan error yang lebih andal. Anda hanya boleh menggunakan skrip shell jika tidak memiliki akses ke nomos CLI.

 #!/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 manifes Config Sync dan perintah nomos untuk versi baru.

2. Ekstrak arsip:

   tar -xzvf config-sync.tar.gz

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

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

   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 bisa mendapatkan status semua cluster yang terdaftar dan dapat memvalidasi konfigurasi untuk cluster tersebut.

Meng-uninstal Config Sync

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

1. Administrator pusat harus menghapus repo root:

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

   2. Hapus objek RootSync dengan menjalankan perintah berikut:

      kubectl delete -f root-sync.yaml
      

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

• Temukan cara mengonfigurasi sinkronisasi dari beberapa repositori.