Peluncuran yang aman dengan Config Sync

Dokumen ini menunjukkan kepada operator cluster dan administrator platform cara meluncurkan perubahan dengan aman di beberapa lingkungan menggunakan Config Sync. Pendekatan ini dapat membantu Anda menghindari error yang memengaruhi semua lingkungan secara bersamaan.

Config Sync memungkinkan Anda mengelola satu cluster, cluster multi-tenant, dan konfigurasi Kubernetes multi-cluster menggunakan file yang disimpan di repositori Git.

Konfigurasi dapat mewakili beberapa hal, termasuk hal berikut:

• Objek GKE standar, seperti resource NetworkPolicies, resource DaemonSets, atau resource RoleBindings.
• Resource Google Cloud, seperti database instance Compute Engine atau Cloud SQL, melalui Config Connector.
• Batasan pada konfigurasi itu sendiri, melalui Policy Controller.

Config Sync sangat cocok untuk men-deploy konfigurasi, kebijakan, dan beban kerja yang diperlukan untuk menjalankan platform yang Anda build di atas edisi Enterprise Google Kubernetes Engine (GKE)—misalnya, agen keamanan, agen pemantauan, dan pengelola sertifikat.

Meskipun Anda dapat men-deploy aplikasi yang ditampilkan kepada pengguna dengan Config Sync, sebaiknya jangan tautkan siklus proses rilisnya ke siklus proses rilis beban kerja administratif yang disebutkan sebelumnya. Sebagai gantinya, sebaiknya Anda menggunakan alat khusus untuk deployment aplikasi, seperti alat continuous deployment, sehingga tim aplikasi dapat bertanggung jawab atas jadwal rilis mereka.

Config Sync adalah produk canggih yang dapat mengelola banyak elemen, sehingga Anda memerlukan pembatasan untuk menghindari error yang memiliki dampak besar. Dokumen ini menjelaskan beberapa metode untuk membuat pembatasan. Bagian pertama mencakup peluncuran bertahap dan bagian kedua berfokus pada pengujian dan validasi. Bagian ketiga menunjukkan cara memantau deployment Anda.

Catatan: Tutorial ini menggunakan repositori Git untuk menjelaskan cara menerapkan peluncuran. Image OCI dan diagram Helm juga didukung.

Menerapkan peluncuran bertahap dengan Config Sync

Dalam lingkungan multi-cluster, yang merupakan situasi umum bagi pengguna GKE Enterprise, sebaiknya jangan terapkan perubahan konfigurasi di semua cluster secara bersamaan. Peluncuran bertahap, cluster per cluster, jauh lebih aman karena mengurangi potensi dampak error.

Ada beberapa cara untuk menerapkan peluncuran bertahap dengan Config Sync:

• Gunakan tag atau commit Git untuk menerapkan perubahan yang Anda inginkan secara manual ke cluster.
• Gunakan cabang Git untuk menerapkan perubahan secara otomatis saat perubahan digabungkan. Anda dapat menggunakan cabang yang berbeda untuk grup cluster yang berbeda.
• Gunakan objek ClusterSelector dan NamespaceSelector untuk menerapkan perubahan secara selektif ke subgrup cluster atau namespace.

Semua metode untuk peluncuran bertahap memiliki kelebihan dan kekurangan. Tabel berikut menunjukkan metode mana yang dapat Anda gunakan secara bersamaan:

Kompatibilitas	Tag atau commit Git	Cabang Git	Pemilih cluster	Pemilih namespace
Tag atau commit Git		Tidak kompatibel	Kompatibel	Kompatibel
Cabang Git	Tidak kompatibel		Kompatibel	Kompatibel
Pemilih cluster	Kompatibel	Kompatibel		Kompatibel
Pemilih namespace	Kompatibel	Kompatibel	Kompatibel

Pohon keputusan berikut dapat membantu Anda memutuskan kapan harus menggunakan salah satu metode peluncuran bertahap.

Catatan: Config Sync memungkinkan Anda menyinkronkan konfigurasi dari beberapa repositori: satu repositori untuk konfigurasi cakupan cluster, dan satu repositori opsional per namespace. Meskipun penggunaan pemilih namespace berbeda saat menggunakan beberapa repositori, Anda tetap dapat menerapkan semua metode lain yang dijelaskan di bagian ini ke repositori tempat Anda menyinkronkan konfigurasi.

Menggunakan tag atau commit Git

Dibandingkan dengan metode peluncuran bertahap lainnya, menggunakan tag atau commit Git memberikan kontrol paling besar dan paling aman. Anda dapat menggunakan halaman Config Sync di konsol Google Cloud di konsol untuk mengupdate beberapa cluster secara bersamaan. Gunakan metode ini jika Anda ingin menerapkan perubahan ke cluster satu per satu, dan untuk mengontrol dengan tepat kapan hal ini terjadi.

Dalam metode ini, Anda "menyematkan" setiap cluster ke versi tertentu (commit atau tag) dari repositori Anda. Metode ini mirip dengan menggunakan commit Git sebagai tag image container. Anda mengimplementasikan metode ini dengan menentukan commit, tag, atau hash di kolom spec.git.revision dari resource kustom RootSync atau RepoSync.

Jika mengelola resource kustom RootSync atau RepoSync dengan alat seperti Kustomize, Anda dapat mengurangi jumlah pekerjaan manual yang diperlukan untuk peluncuran. Dengan alat tersebut, Anda hanya perlu mengubah parameter revision di satu tempat, lalu menerapkan resource kustom RootSync atau RepoSync baru secara selektif ke cluster dalam urutan, dan dengan kecepatan, yang Anda pilih.

Selain itu, Anda dapat menggunakan konsol Google Cloud untuk mengupdate parameter revision untuk beberapa cluster yang termasuk dalam armada yang sama secara bersamaan. Namun, jika Anda memiliki sistem otomatis untuk mengupdate konfigurasi, sebaiknya jangan gunakan konsol Google Cloud untuk melakukan perubahan konfigurasi.

Misalnya, definisi RootSync berikut mengonfigurasi Config Sync untuk menggunakan tag 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: [e-mail]:gke/config-sync.git
    revision: 1.2.3
    auth: ssh

Jika Anda menerapkan konfigurasi ini ke cluster, Config Sync akan menggunakan tag 1.2.3 dari repositori example.com:gke/config-sync.git.

Untuk memperbarui cluster, ubah kolom spec.git.revision ke nilai baru untuk cluster. Dengan demikian, Anda dapat menentukan cluster mana yang akan diupdate dan kapan. Jika Anda perlu mengembalikan perubahan, ubah kolom spec.git.revision kembali ke nilai sebelumnya.

Diagram berikut mengilustrasikan proses peluncuran untuk metode ini. Pertama, Anda melakukan commit perubahan ke repositori Config Sync, lalu Anda memperbarui definisi RootSync di semua cluster:

Sebaiknya lakukan tindakan berikut:

• Gunakan ID commit Git, bukan tag. Karena cara kerja Git, Anda memiliki jaminan bahwa hal tersebut tidak akan pernah berubah. Misalnya, git push --force tidak dapat mengubah commit yang digunakan Config Sync. Pendekatan ini berguna untuk tujuan audit dan untuk melacak commit yang Anda gunakan dalam log. Selain itu, tidak seperti tag, tidak ada langkah tambahan untuk melakukan ID.
• Jika lebih memilih menggunakan tag Git, bukan ID commit Git, Anda dapat melindungi tag jika menggunakan solusi Git yang mendukung perlindungan.
• Jika ingin mengupdate beberapa cluster secara bersamaan, Anda dapat melakukannya di konsol Google Cloud. Untuk mengupdate beberapa cluster sekaligus, cluster tersebut harus menjadi bagian dari fleet yang sama (dan berada dalam project yang sama).

Menggunakan cabang Git

Jika Anda ingin perubahan diterapkan ke cluster segera setelah digabungkan di repositori Git, konfigurasikan Config Sync untuk menggunakan cabang Git, bukan commit atau tag. Dalam metode ini, Anda membuat beberapa cabang yang berumur panjang di repositori Git, dan mengonfigurasi Config Sync di cluster yang berbeda untuk membaca konfigurasinya dari cabang yang berbeda.

Misalnya, pola sederhana memiliki dua cabang:

• Cabang staging untuk cluster non-produksi.
• Cabang main untuk cluster produksi.

Peringatan: Jika Anda menangani banyak cluster dan lingkungan, Anda mungkin memerlukan banyak cabang. Hal ini dapat dengan cepat menjadi rumit untuk dikelola. Itulah sebabnya kami merekomendasikan penggunaan commit Git di cabang.

Untuk cluster non-produksi, buat objek RootSync atau RepoSync dengan kolom spec.git.branch ditetapkan ke staging. Untuk cluster produksi, buat objek RootSync atau RepoSync dengan parameter spec.git.branch yang ditetapkan ke main.

Misalnya, definisi RootSync berikut mengonfigurasi Config Sync untuk menggunakan cabang main:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  git:
    repo: [e-mail]:gke/config-sync.git
    branch: main
    auth: ssh

Diagram berikut menggambarkan proses peluncuran untuk metode ini:

Anda dapat menyesuaikan pola ini dengan kebutuhan tertentu, menggunakan lebih dari dua cabang, atau menggunakan cabang yang dipetakan ke sesuatu selain lingkungan. Jika Anda perlu melakukan rollback perubahan, gunakan perintah git revert untuk membuat commit baru di cabang yang sama yang mengembalikan perubahan dari commit sebelumnya.

Sebaiknya lakukan tindakan berikut:

• Saat menangani beberapa cluster, gunakan minimal dua cabang Git untuk membantu membedakan antara cluster produksi dan non-produksi.
• Sebagian besar solusi Git memungkinkan Anda menggunakan fitur cabang yang dilindungi untuk mencegah penghapusan atau perubahan yang tidak ditinjau pada cabang tersebut. Untuk mengetahui informasi selengkapnya, lihat dokumentasi untuk GitHub, GitLab, dan Bitbucket.

Menggunakan objek ClusterSelector dan NamespaceSelector

Cabang Git adalah cara yang baik untuk melakukan peluncuran bertahap perubahan di beberapa cluster yang pada akhirnya akan memiliki kebijakan yang sama. Namun, jika Anda ingin meluncurkan perubahan hanya ke sebagian cluster atau namespace, gunakan objek ClusterSelector dan NamespaceSelector. Objek ini memiliki tujuan yang serupa: objek ini memungkinkan Anda menerapkan objek hanya ke cluster atau namespace yang memiliki label tertentu.

Contoh:

• Dengan menggunakan objek ClusterSelector, Anda dapat menerapkan kebijakan yang berbeda ke cluster, bergantung pada negara tempat cluster tersebut berada, untuk berbagai rezim kepatuhan.
• Dengan menggunakan objek NamespaceSelector, Anda dapat menerapkan kebijakan yang berbeda ke namespace yang digunakan oleh tim internal dan oleh kontraktor eksternal.

Objek ClusterSelector dan NamespaceSelector juga memungkinkan Anda menerapkan metodologi pengujian dan rilis lanjutan, seperti berikut:

• Rilis kebijakan Canary, tempat Anda men-deploy kebijakan baru ke sebagian kecil cluster dan namespace selama jangka waktu yang lama untuk mempelajari dampaknya.
• Pengujian A/B, yang memungkinkan Anda men-deploy berbagai versi kebijakan yang sama ke berbagai cluster untuk mempelajari perbedaan dampak versi kebijakan, lalu memilih versi terbaik untuk di-deploy di mana saja.

Misalnya, bayangkan sebuah organisasi dengan beberapa cluster produksi. Tim platform telah membuat dua kategori cluster produksi, yang disebut canary-prod dan prod, menggunakan objek Cluster, dan ClusterSelector (lihat Menggunakan ClusterSelectors).

Tim platform ingin meluncurkan kebijakan dengan Pengontrol Kebijakan untuk menerapkan kehadiran label tim di namespace guna mengidentifikasi tim mana yang menjadi milik setiap namespace. Mereka telah meluncurkan versi kebijakan ini dalam mode uji coba, dan sekarang mereka ingin menerapkannya pada sejumlah kecil cluster. Dengan menggunakan objek ClusterSelector, keduanya membuat dua resource K8sRequiredLabels yang berbeda yang diterapkan ke cluster yang berbeda.

• Resource K8sRequiredLabels diterapkan ke cluster jenis prod, dengan parameter enforcementAction yang ditetapkan ke dryrun:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: prod
  Spec:
    enforcementAction: dryrun
    match:
      kinds:
        - apiGroups: [""]
          kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

• Resource K8sRequiredLabels diterapkan ke cluster jenis canary-prod, tanpa parameter enforcementAction, yang berarti bahwa kebijakan benar-benar diterapkan:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: canary-prod
  spec:
    match:
      kinds:
        - apiGroups: [""]
      kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

Anotasi configmanagement.gke.io/cluster-selector memungkinkan tim menerapkan kebijakan hanya dalam cluster jenis canary-prod, sehingga mencegah efek samping yang tidak diinginkan menyebar ke seluruh grup produksi. Untuk informasi selengkapnya tentang fitur uji coba Pengontrol Kebijakan, lihat membuat batasan.

Sebaiknya lakukan tindakan berikut:

• Gunakan objek ClusterSelector dan NamespaceSelector jika Anda perlu menerapkan perubahan konfigurasi hanya ke sebagian cluster atau namespace tanpa batas waktu atau untuk waktu yang lama.
• Jika Anda meluncurkan perubahan menggunakan pemilih, berhati-hatilah. Jika Anda menggunakan commit Git, error apa pun hanya akan memengaruhi satu cluster pada satu waktu, karena Anda meluncurkan cluster demi cluster. Namun, jika Anda menggunakan cabang Git, error apa pun dapat memengaruhi semua cluster yang menggunakan cabang tersebut. Jika Anda menggunakan pemilih, error dapat memengaruhi semua cluster sekaligus.

Menerapkan peninjauan, pengujian, dan validasi

Salah satu keunggulan Config Sync adalah mengelola semuanya secara deklaratif—resource Kubernetes, resource cloud, dan kebijakan. Artinya, file dalam sistem pengelolaan kontrol sumber mewakili resource (file Git, dalam kasus Config Sync). Karakteristik ini memungkinkan Anda menerapkan alur kerja pengembangan yang sudah Anda gunakan untuk kode sumber aplikasi: peninjauan dan pengujian otomatis.

Menerapkan ulasan

Karena Config Sync didasarkan pada Git, Anda dapat menggunakan solusi Git pilihan Anda untuk menghosting repositori Config Sync. Solusi Git Anda mungkin memiliki fitur peninjauan kode, yang dapat Anda gunakan untuk meninjau perubahan yang dilakukan pada repositori Config Sync.

Praktik terbaik untuk meninjau perubahan pada repositori Anda sama dengan tinjauan kode normal, sebagai berikut:

• Praktikkan pengembangan berbasis trunk.
• Bekerja dalam batch kecil.
• Pastikan peninjauan kode dilakukan secara sinkron atau setidaknya dengan cepat.
• Orang yang meninjau dan menyetujui perubahan tidak boleh sama dengan orang yang menyarankan perubahan.

Karena sensitivitas codebase Config Sync, sebaiknya Anda juga membuat konfigurasi berikut, jika memungkinkan dengan solusi Git Anda:

• Lindungi cabang yang digunakan langsung oleh cluster. Lihat dokumentasi untuk GitHub, GitLab, dan Bitbucket. GitLab juga memungkinkan Anda melindungi tag.
• Setelah cabang dilindungi, Anda dapat menyaring persetujuan yang diperlukan untuk menggabungkan perubahan:
  • Di GitHub, aktifkan peninjauan wajib.
  • Untuk GitLab, gunakan Pemilik Kode untuk mendelegasikan izin persetujuan berdasarkan file atau direktori. Anda dapat menggunakan persetujuan permintaan penggabungan untuk mewajibkan orang yang berbeda dari tim yang berbeda untuk menyetujui permintaan sebelum digabungkan.
  • Di Bitbucket, gabungkan peninjau default dengan pemeriksaan penggabungan default. Secara opsional, gunakan plugin Pemilik Kode untuk Bitbucket Server yang tersedia di Atlassian Marketplace untuk mengontrol siapa yang dapat menyetujui perubahan untuk subbagian repositori.

Dengan menggunakan berbagai fitur ini, Anda dapat menerapkan persetujuan untuk setiap permintaan perubahan pada codebase. Misalnya, Anda dapat memastikan bahwa setiap perubahan disetujui setidaknya oleh anggota tim platform (yang mengoperasikan kumpulan cluster), dan oleh anggota tim keamanan (yang bertanggung jawab untuk menentukan dan menerapkan kebijakan keamanan).

Sebaiknya lakukan tindakan berikut:

• Terapkan peninjauan sejawat pada repositori Anda dan lindungi cabang Git yang digunakan oleh cluster Anda.

Mengimplementasikan pengujian otomatis

Praktik terbaik umum saat mengerjakan codebase adalah menerapkan continuous integration. Artinya, Anda mengonfigurasi pengujian otomatis untuk dijalankan saat permintaan perubahan dibuat atau diperbarui. Pengujian otomatis dapat mendeteksi banyak error sebelum manusia meninjau permintaan perubahan. Hal ini memperketat feedback loop untuk developer. Anda dapat menerapkan ide yang sama, menggunakan alat yang sama, untuk repositori Config Sync.

Misalnya, tempat yang baik untuk memulai adalah dengan menjalankan perintah nomos vet secara otomatis pada perubahan baru. Perintah ini memvalidasi bahwa sintaksis repositori Config Sync Anda valid. Anda dapat menerapkan pengujian ini menggunakan Cloud Build dengan mengikuti tutorial memvalidasi konfigurasi. Anda dapat mengintegrasikan Cloud Build dengan opsi berikut:

• Bitbucket, menggunakan pemicu build.
• GitHub, dengan menggunakan aplikasi GitHub Google Cloud Build. Pemicu build juga tersedia untuk GitHub, tetapi aplikasi GitHub adalah metode integrasi yang lebih disukai.

Seperti yang dapat Anda lihat dalam tutorial memvalidasi konfigurasi, pengujian dilakukan dengan menggunakan image container. Oleh karena itu, Anda dapat menerapkan pengujian dalam solusi continuous integration apa pun yang menjalankan container, bukan hanya Cloud Build.

Untuk memperketat siklus masukan lebih lanjut, Anda dapat meminta pengguna untuk menjalankan perintah nomos vet sebagai hook pra-commit Git. Satu pengecualian adalah beberapa pengguna mungkin tidak memiliki akses ke cluster Kubernetes yang dikelola oleh Config Sync, dan mereka mungkin tidak dapat menjalankan validasi penuh dari workstation mereka. Jalankan perintah nomos vet --clusters "" untuk membatasi validasi pada pemeriksaan semantik dan sintaksis.

Sebaiknya lakukan tindakan berikut:

• Mengimplementasikan pengujian dalam pipeline continuous integration.
• Jalankan setidaknya perintah nomos vet pada semua perubahan yang disarankan.

Memantau peluncuran

Meskipun Anda menerapkan semua pembatasan yang dicakup dalam dokumen ini, error masih dapat terjadi. Berikut adalah dua jenis error yang umum:

• Error yang tidak menimbulkan masalah pada Config Sync itu sendiri, tetapi mencegah beban kerja Anda berfungsi dengan benar, seperti NetworkPolicy yang terlalu ketat yang mencegah komponen beban kerja Anda berkomunikasi.
• Error yang membuat Config Sync tidak dapat menerapkan perubahan ke cluster, seperti manifes Kubernetes yang tidak valid, atau objek yang ditolak oleh pengontrol akses. Metode yang dijelaskan sebelumnya akan mendeteksi sebagian besar error ini.

Mendeteksi error yang dijelaskan dalam poin pertama sebelumnya hampir tidak mungkin dilakukan di tingkat Config Sync karena hal ini memerlukan pemahaman tentang status setiap workload Anda. Oleh karena itu, deteksi error ini sebaiknya dilakukan oleh sistem pemantauan yang ada yang memberi tahu Anda saat aplikasi berperilaku tidak semestinya.

Mendeteksi error yang dijelaskan dalam poin kedua sebelumnya—yang seharusnya jarang terjadi jika Anda telah menerapkan semua pembatasan—memerlukan penyiapan tertentu. Secara default, Config Sync menulis error ke log-nya (yang akan Anda temukan, secara default, di Cloud Logging). Error juga ditampilkan di halaman konsol Google Cloud Config Sync. Log maupun konsol biasanya tidak cukup untuk mendeteksi error, karena Anda mungkin tidak memantaunya setiap saat. Cara termudah untuk mengotomatiskan deteksi error adalah dengan menjalankan perintah nomos status, yang memberi tahu Anda jika ada error dalam cluster.

Anda juga dapat menyiapkan solusi yang lebih canggih dengan pemberitahuan otomatis untuk error. Config Sync menampilkan metrik dalam format Prometheus. Untuk mengetahui informasi selengkapnya, lihat memantau Sinkronisasi Konfigurasi.

Setelah Anda memiliki metrik Config Sync di sistem pemantauan, buat pemberitahuan untuk memberi tahu Anda saat metrik gkeconfig_monitor_errors lebih besar dari 0. Untuk informasi selengkapnya, lihat mengelola kebijakan pemberitahuan untuk Cloud Monitoring, atau aturan pemberitahuan untuk Prometheus.

Ringkasan mekanisme untuk peluncuran yang aman dengan Config Sync

Tabel berikut merangkum berbagai mekanisme yang dijelaskan sebelumnya dalam dokumen ini. Tidak satu pun mekanisme ini yang eksklusif. Anda dapat memilih untuk menggunakan beberapa atau semuanya, untuk tujuan yang berbeda.

Mekanisme	Efektif untuk	Hal yang tidak cocok	Contoh kasus penggunaan
ID dan tag commit Git	Gunakan tag atau ID commit Git tertentu untuk mengontrol dengan tepat perubahan cluster mana yang diterapkan.	Jangan gunakan ID atau tag commit Git untuk perbedaan yang bertahan lama antar-cluster. Menggunakan pemilih cluster.	Semua cluster Anda dikonfigurasi untuk menerapkan commit 12345 Git. Anda membuat perubahan dengan commit baru, abcdef, yang ingin diuji. Anda mengubah konfigurasi satu cluster untuk menggunakan commit baru ini guna memvalidasi perubahan.
Cabang Git	Gunakan beberapa cabang Git jika Anda ingin meluncurkan perubahan yang sama ke beberapa lingkungan, satu per satu.	Jangan gunakan beberapa cabang Git untuk perbedaan yang bertahan lama di antara cluster. Cabang akan menyimpang secara signifikan dan akan sulit digabungkan kembali.	Pertama, gabungkan perubahan di cabang staging, tempat perubahan tersebut akan diambil oleh cluster staging. Kemudian, gabungkan perubahan di cabang master, tempat perubahan tersebut akan diambil oleh cluster produksi.
Pemilih cluster dan pemilih namespace	Gunakan pemilih untuk perbedaan jangka panjang antara cluster dan namespace.	Jangan gunakan pemilih untuk peluncuran bertahap di beberapa lingkungan. Jika Anda ingin menguji modifikasi terlebih dahulu di staging, lalu men-deploy-nya dalam produksi, gunakan cabang Git terpisah.	Jika tim aplikasi memerlukan akses penuh ke cluster pengembangan, tetapi akses hanya baca ke cluster produksi, gunakan objek ClusterSelector untuk menerapkan kebijakan RBAC yang benar hanya ke cluster yang relevan.
Ulasan sejawat	Gunakan peninjauan sejawat untuk memastikan tim yang relevan menyetujui perubahan.	Peninjau manual tidak mendeteksi semua error, terutama item seperti error sintaksis.	Organisasi Anda mewajibkan tim keamanan untuk meninjau perubahan konfigurasi yang memengaruhi beberapa sistem. Minta anggota tim keamanan meninjau perubahan tersebut.
Pengujian otomatis di pipeline continuous integration	Gunakan pengujian otomatis untuk menemukan error dalam perubahan yang disarankan.	Pengujian otomatis tidak dapat sepenuhnya menggantikan peninjau manual. Gunakan keduanya.	Menjalankan perintah nomos vet pada semua perubahan yang disarankan akan mengonfirmasi bahwa repositori adalah konfigurasi Config Sync yang valid.
Memantau error sinkronisasi	Pastikan Config Sync benar-benar menerapkan perubahan ke kluster Anda.	Error sinkronisasi hanya terjadi jika Config Sync mencoba menerapkan repositori yang tidak valid atau jika server Kubernetes API menolak beberapa objek.	Pengguna mengabaikan semua pengujian dan peninjauan Anda serta melakukan perubahan yang tidak valid ke repositori Config Sync. Perubahan ini tidak dapat diterapkan ke cluster Anda. Jika memantau error sinkronisasi, Anda akan diberi tahu jika terjadi error.

Contoh strategi peluncuran

Bagian ini menggunakan konsep yang diperkenalkan di bagian lain artikel ini untuk membantu Anda membuat strategi peluncuran menyeluruh di semua cluster di organisasi Anda. Strategi ini mengasumsikan bahwa Anda memiliki fleet terpisah untuk pengembangan, staging, dan produksi (seperti yang ditunjukkan dalam Contoh Fleet 1 - Pendekatan 1).

Peringatan: Strategi peluncuran ini rumit. Hal ini hanya masuk akal untuk diterapkan jika Anda memiliki infrastruktur yang kompleks dengan minimal 2 fleet, dan minimal 3 cluster per fleet. Jika Anda memiliki banyak fleet, tetapi dengan satu cluster di setiap fleet, Anda dapat menyesuaikan strategi ini dengan memiliki "fleet kanari", bukan "cluster kanari".

Dalam skenario ini, Anda mengonfigurasi setiap cluster untuk disinkronkan dengan repositori Git menggunakan commit Git tertentu. Men-deploy perubahan ke fleet tertentu adalah proses 4 langkah:

1. Anda mengupdate satu cluster ("canary") dalam fleet untuk menggunakan commit baru terlebih dahulu.
2. Anda memvalidasi bahwa semuanya berfungsi seperti yang diharapkan dengan menjalankan pengujian dan memantau peluncuran.
3. Anda memperbarui cluster lainnya di fleet.
4. Anda memvalidasi lagi bahwa semuanya berfungsi seperti yang diharapkan.

Untuk men-deploy perubahan di semua cluster, Anda harus mengulangi proses ini untuk setiap fleet. Secara teknis, Anda dapat menerapkan metode ini dengan commit Git apa pun, dari cabang apa pun. Namun, sebaiknya Anda mengadopsi proses berikut untuk mengidentifikasi masalah sejak awal proses peninjauan:

1. Saat seseorang membuka permintaan perubahan di repositori Git Config Sync, deploy perubahan tersebut ke salah satu cluster pengembangan.
2. Jika permintaan perubahan diterima dan digabungkan di cabang utama Anda, jalankan deployment penuh di semua fleet seperti yang dijelaskan sebelumnya.

Meskipun beberapa perubahan mungkin hanya menargetkan fleet tertentu, sebaiknya Anda men-deploy semua perubahan ke semua fleet pada akhirnya. Strategi ini menghilangkan masalah pelacakan fleet mana yang harus disinkronkan dengan commit mana. Perhatikan dengan cermat perubahan yang hanya menargetkan fleet produksi karena pengujian yang tepat tidak akan dapat dilakukan di fleet sebelumnya. Misalnya, hal ini berarti menunggu lebih lama agar masalah muncul antara deployment ke cluster canary dan ke cluster lainnya.

Untuk meringkas, deployment menyeluruh menyeluruh akan terlihat seperti ini:

1. Seseorang membuka permintaan perubahan.
2. Pengujian dan validasi otomatis dijalankan, dan peninjauan manual dilakukan.
3. Anda memicu tugas secara manual untuk men-deploy perubahan ke cluster canary di fleet pengembangan. Pengujian menyeluruh otomatis berjalan di cluster ini.
4. Jika semuanya sudah benar, Anda akan menggabungkan permintaan perubahan di cabang utama.
5. Penggabungan memicu tugas otomatis untuk men-deploy commit ujung cabang utama baru ke cluster canary di fleet pengembangan. Pengujian menyeluruh otomatis berjalan di cluster ini (untuk mendeteksi potensi inkompatibilitas antara dua permintaan perubahan yang telah dibuat dan digabungkan kira-kira pada waktu yang sama).
6. Tugas berikut dijalankan satu per satu (Anda memicunya secara manual, atau setelah waktu yang telah ditentukan untuk memungkinkan laporan regresi pengguna):
   1. Men-deploy ke semua cluster fleet pengembangan.
   2. Jalankan pengujian dan validasi di cluster grup pengembangan.
   3. Deploy ke cluster canary dari fleet staging.
   4. Jalankan pengujian dan validasi di cluster canary dari grup staging.
   5. Men-deploy ke semua cluster fleet staging.
   6. Menjalankan pengujian dan validasi di cluster grup staging.
   7. Deploy ke cluster canary dari fleet produksi.
   8. Jalankan pengujian dan validasi di cluster canary dari fleet produksi.
   9. Deploy ke semua cluster fleet produksi.
   10. Jalankan pengujian dan validasi di cluster grup produksi.

Langkah selanjutnya

• Baca tentang memantau Config Sync.
• Baca tentang fleet.
• Pelajari cara memvalidasi aplikasi Anda berdasarkan kebijakan perusahaan di pipeline continuous integration.