Peluncuran yang aman dengan Config Sync

Dokumen ini menunjukkan kepada operator cluster dan administrator platform cara men-deploy 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 cluster tunggal, cluster multi-tenant, dan konfigurasi Kubernetes multi-cluster menggunakan file yang disimpan di repositori Git.

Konfigurasi dapat mewakili beberapa hal, termasuk berikut ini:

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

Config Sync sangat cocok untuk men-deploy konfigurasi, kebijakan, dan workload yang diperlukan untuk menjalankan platform yang Anda bangun di atas Google Kubernetes Engine—misalnya, agen keamanan, agen pemantauan, dan pengelola sertifikat.

Meskipun Anda dapat men-deploy aplikasi yang menghadap 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 deployment berkelanjutan, 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 berdampak 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

Di lingkungan multi-cluster, sebaiknya jangan menerapkan perubahan konfigurasi di semua cluster secara bersamaan. Peluncuran bertahap, cluster per cluster, jauh lebih aman karena mengurangi potensi dampak dari kesalahan apa pun.

Ada beberapa cara untuk menerapkan peluncuran bertahap dengan Config Sync:

• Gunakan commit atau tag Git untuk menerapkan perubahan yang Anda inginkan ke cluster secara manual.
• Gunakan cabang Git untuk menerapkan perubahan secara otomatis saat perubahan digabungkan. Anda dapat menggunakan cabang yang berbeda untuk berbagai kelompok cluster.
• 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	Commit atau tag Git	Cabang Git	Pemilih cluster	Pemilih namespace
Commit atau tag 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 commit atau tag Git

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

Dalam metode ini, Anda "menetapkan" setiap cluster ke versi tertentu (baik commit atau tag) 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 pada RootSync atau RepoSync resource kustom.

Jika Anda 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 Anda dalam urutan dan kecepatan yang Anda pilih.

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

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 begitu, 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 menggambarkan proses peluncuran untuk metode ini. Pertama, Anda melakukan commit perubahan ke repositori Config Sync, lalu Anda mengupdate definisi RootSync di semua cluster:

Sebaiknya lakukan tindakan berikut:

• Gunakan ID commit Git, bukan tag. Karena cara kerja Git, Anda memiliki jaminan bahwa file 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 mana yang Anda gunakan dalam log. Selain itu, tidak seperti tag, tidak ada langkah tambahan untuk melakukan ID.
• Jika lebih suka menggunakan tag Git daripada ID commit Git, Anda dapat melindungi tag jika menggunakan solusi Git yang mendukung perlindungan.
• Jika ingin memperbarui beberapa cluster secara bersamaan, Anda dapat melakukannya di konsol Google Cloud . Untuk memperbarui beberapa cluster sekaligus, cluster tersebut harus menjadi bagian dari fleet yang sama (dan berada di project yang sama).

Menggunakan cabang Git

Jika Anda ingin perubahan diterapkan ke cluster segera setelah digabungkan di repositori Git, konfigurasi Config Sync untuk menggunakan cabang Git, bukan commit atau tag. Dalam metode ini, Anda membuat beberapa cabang yang aktif dalam jangka waktu lama 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 berurusan dengan sejumlah besar cluster dan lingkungan, Anda mungkin memerlukan sejumlah besar cabang. Hal ini dapat dengan cepat menjadi sulit untuk dikelola. Itulah sebabnya kami merekomendasikan penggunaan commit Git daripada cabang.

Untuk cluster non-produksi, buat objek RootSync atau RepoSync dengan kolom spec.git.branch yang ditetapkan ke staging. Untuk cluster produksi, buat objek RootSync atau RepoSync dengan parameter spec.git.branch yang disetel 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 mengembalikan 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 setidaknya 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 belum ditinjau pada cabang tersebut. Untuk mengetahui informasi selengkapnya, lihat dokumentasi untuk GitHub, GitLab, dan Bitbucket.

Menggunakan objek ClusterSelector dan NamespaceSelector

Branch Git adalah cara yang baik untuk melakukan peluncuran perubahan bertahap di beberapa cluster yang pada akhirnya akan memiliki kebijakan yang sama. Namun, jika Anda ingin meluncurkan perubahan hanya ke sebagian kecil cluster atau namespace, gunakan objek ClusterSelector dan NamespaceSelector. Objek ini memiliki tujuan yang sama: 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 uji coba, tempat Anda men-deploy kebijakan baru ke subset kecil cluster dan namespace dalam waktu yang lama untuk mempelajari dampak kebijakan tersebut.
• Pengujian A/B, tempat Anda men-deploy berbagai versi kebijakan yang sama ke cluster yang berbeda untuk mempelajari perbedaan dampak versi kebijakan dan kemudian 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 ClusterSelector).

Tim platform ingin meluncurkan kebijakan dengan Pengontrol Kebijakan untuk menerapkan keberadaan label tim pada namespace guna mengidentifikasi tim yang memiliki 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, mereka membuat dua resource K8sRequiredLabels 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 armada 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 pada subset cluster atau namespace tanpa batas waktu atau untuk waktu yang lama.
• Jika Anda meluncurkan perubahan menggunakan pemilih, berhati-hatilah. Jika Anda menggunakan commit Git, setiap error hanya memengaruhi satu cluster dalam satu waktu, karena Anda men-deploy cluster satu per satu. 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 kemampuannya untuk mengelola semuanya secara deklaratif—resource Kubernetes, resource cloud, dan kebijakan. Artinya, file dalam sistem pengelolaan kontrol sumber merepresentasikan resource (file Git, dalam kasus Config Sync). Karakteristik ini memungkinkan Anda menerapkan alur kerja pengembangan yang sudah digunakan untuk kode sumber aplikasi: peninjauan dan pengujian otomatis.

Menerapkan ulasan

Karena Config Sync berbasis 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 peninjauan kode normal, sebagai berikut:

• Lakukan 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 orang yang sama dengan orang yang menyarankan perubahan.

Karena sensitivitas codebase Config Sync, kami juga merekomendasikan agar, jika memungkinkan dengan solusi Git Anda, Anda melakukan konfigurasi berikut:

• 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 menyempurnakan persetujuan yang diperlukan untuk menggabungkan perubahan:
  • Di GitHub, aktifkan peninjauan yang diperlukan.
  • 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 menyetujui permintaan sebelum digabungkan.
  • Di Bitbucket, gabungkan pemeriksa 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 Anda. 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 oleh rekan sejawat di repositori Anda dan lindungi cabang Git yang digunakan oleh cluster Anda.

Menerapkan 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 permintaan perubahan ditinjau oleh petugas. 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 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, dengan 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 di solusi continuous integration yang menjalankan container, bukan hanya Cloud Build.

Untuk memperketat loop masukan, Anda dapat meminta pengguna menjalankan perintah nomos vet sebagai Git pre-commit hook. Satu hal yang perlu diperhatikan 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:

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

Memantau peluncuran

Meskipun Anda menerapkan semua pembatasan yang dibahas dalam dokumen ini, error masih dapat terjadi. Berikut adalah dua jenis error 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 pada cluster, seperti manifes Kubernetes yang tidak valid, atau objek yang ditolak oleh pengontrol penerimaan. Metode yang dijelaskan sebelumnya akan mendeteksi sebagian besar error ini.

Mendeteksi error yang dijelaskan dalam poin sebelumnya yang pertama hampir tidak mungkin dilakukan di tingkat Config Sync karena memerlukan pemahaman tentang status setiap workload Anda. Oleh karena itu, sebaiknya deteksi error ini dilakukan oleh sistem pemantauan yang sudah ada yang akan 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 khusus. Secara default, Config Sync menulis error ke log-nya (yang akan Anda temukan, secara default, di Cloud Logging). Error juga ditampilkan di halaman konsol Config Sync Google Cloud . Log maupun konsol biasanya tidak cukup untuk mendeteksi error, karena Anda mungkin tidak memantaunya setiap saat. Cara paling sederhana untuk mengotomatiskan deteksi error adalah dengan menjalankan nomos status perintah, yang akan 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 Config Sync.

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 mengetahui 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 ada mekanisme ini yang eksklusif. Anda dapat memilih untuk menggunakan sebagian atau semuanya, untuk tujuan yang berbeda.

Mekanisme	Efektif untuk	Yang tidak efektif	Contoh kasus penggunaan
ID dan tag commit Git	Gunakan ID atau tag commit Git tertentu untuk mengontrol secara tepat perubahan cluster mana yang diterapkan.	Jangan gunakan ID atau tag commit Git untuk perbedaan yang berlangsung lama antar-cluster. Gunakan pemilih cluster.	Semua cluster Anda dikonfigurasi untuk menerapkan commit 12345Git. Anda melakukan perubahan dengan commit baru, abcdef, yang ingin Anda uji. 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 berlangsung lama antara cluster. Cabang akan sangat berbeda dan akan sulit digabungkan kembali.	Pertama, gabungkan perubahan di cabang staging, tempat perubahan 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 yang berlangsung lama 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 di 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 teman sekelas	Gunakan peninjauan oleh rekan sejawat untuk memastikan tim yang relevan menyetujui perubahan.	Peninjau manual tidak dapat menemukan semua error, terutama item seperti error sintaksis.	Organisasi Anda mewajibkan tim keamanan meninjau perubahan konfigurasi yang memengaruhi beberapa sistem. Minta anggota tim keamanan meninjau perubahan.
Pengujian otomatis dalam pipeline continuous integration	Gunakan pengujian otomatis untuk menemukan kesalahan 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 melewati semua pengujian dan peninjauan Anda serta melakukan perubahan yang tidak valid pada repositori Config Sync. Perubahan ini tidak dapat diterapkan ke cluster Anda. Jika Anda 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 end-to-end di semua cluster dalam 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. Implementasi ini hanya masuk akal 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 uji coba" alih-alih "cluster uji coba".

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 memperbarui satu cluster (cluster "canary") di 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 mengulangi proses ini untuk setiap fleet. Secara teknis, Anda dapat menerapkan metode ini dengan commit Git apa pun, dari cabang mana pun. Namun, sebaiknya Anda menerapkan proses berikut untuk mengidentifikasi masalah sejak awal dalam 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, jalankan deployment penuh di semua fleet seperti yang dijelaskan sebelumnya.

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

Singkatnya, deployment end-to-end lengkap 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 OK, Anda menggabungkan permintaan perubahan di cabang utama.
5. Penggabungan memicu tugas otomatis untuk men-deploy commit ujung branch utama baru ke cluster uji coba di fleet pengembangan. Pengujian menyeluruh otomatis berjalan di cluster ini (untuk mendeteksi potensi ketidakcocokan antara dua permintaan perubahan yang telah dibuat dan digabungkan secara bersamaan).
6. Tugas berikut dijalankan satu per satu (Anda memicunya secara manual, atau setelah waktu yang telah ditentukan sebelumnya untuk memungkinkan laporan pengguna tentang regresi):
   1. Deploy ke semua cluster fleet pengembangan.
   2. Menjalankan pengujian dan validasi di cluster armada pengembangan.
   3. Deploy ke cluster canary fleet staging.
   4. Jalankan pengujian dan validasi di cluster canary fleet staging.
   5. Deploy ke semua cluster fleet penyiapan.
   6. Jalankan pengujian dan validasi di cluster fleet staging.
   7. Deploy ke cluster uji coba fleet produksi.
   8. Jalankan pengujian dan validasi di cluster canary fleet produksi.
   9. Deploy ke semua cluster fleet produksi.
   10. Menjalankan pengujian dan validasi di cluster armada produksi.

Langkah berikutnya

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