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

Dengan Config Sync, Anda dapat mengelola cluster tunggal, cluster multi-tenant, dan konfigurasi Kubernetes multi-cluster dengan menggunakan file yang disimpan dalam repositori Git.

Konfigurasi dapat mewakili beberapa hal, termasuk yang berikut:

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

Config Sync sangat cocok untuk men-deploy konfigurasi, kebijakan, dan workload yang diperlukan untuk menjalankan platform yang Anda bangun di edisi Google Kubernetes Engine (GKE) Enterprise—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 rilis ke siklus proses rilis dari beban kerja administratif yang disebutkan sebelumnya. Sebagai gantinya, sebaiknya gunakan alat khusus deployment aplikasi seperti alat deployment berkelanjutan, agar tim aplikasi dapat bertanggung jawab terhadap jadwal rilis mereka.

Config Sync adalah produk andal yang dapat mengelola banyak elemen, sehingga Anda memerlukan pagar pembatas untuk menghindari error yang berdampak besar. Dokumen ini menjelaskan beberapa metode untuk membuat pagar pembatas. 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 apa pun.

Ada beberapa cara untuk menerapkan peluncuran bertahap dengan Config Sync:

• Gunakan commit atau tag Git untuk menerapkan perubahan yang Anda inginkan pada cluster secara manual.
• 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 pada 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 metode peluncuran bertahap lainnya, penggunaan commit atau tag Git memberikan kontrol paling besar dan paling aman. Anda dapat menggunakan halaman Config Sync pada Google Cloud Console di konsol untuk memperbarui beberapa cluster secara bersamaan. Gunakan metode ini jika Anda ingin menerapkan perubahan pada cluster satu per satu, dan untuk mengontrol secara tepat kapan hal ini terjadi.

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

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 sesuai urutan, dan sesuai 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 memperbarui konfigurasi, sebaiknya jangan gunakan Konsol Google Cloud untuk membuat 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, Sinkronisasi Konfigurasi akan menggunakan tag 1.2.3 dari repositori example.com:gke/config-sync.git.

Untuk mengupdate cluster, ubah kolom spec.git.revision ke nilai baru untuk cluster. Hal ini memungkinkan Anda menentukan cluster mana yang akan diperbarui dan kapan. Jika Anda perlu me-roll back perubahan, ubah kolom spec.git.revision kembali ke nilai sebelumnya.

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

Sebaiknya lakukan tindakan berikut:

• Gunakan ID commit Git, bukan tag. Karena cara Git berfungsi, Anda memiliki jaminan bahwa Git tidak akan pernah berubah. Misalnya, git push --force tidak dapat mengubah commit yang digunakan Config Sync. Pendekatan ini berguna untuk keperluan audit dan melacak commit yang Anda gunakan dalam log. Selain itu, tidak seperti tag, tidak ada langkah tambahan untuk mengikat ID.
• Jika lebih suka menggunakan tag Git dan 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 Google Cloud Console. Untuk memperbarui beberapa cluster sekaligus, cluster 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 dalam repositori Git, konfigurasikan Config Sync agar menggunakan cabang Git, bukan commit atau tag. Dalam metode ini, Anda akan 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 menangani sejumlah besar cluster dan lingkungan, Anda mungkin memerlukan banyak cabang. Hal ini dapat dengan cepat menjadi rumit untuk dikelola. Oleh karena itu, kami merekomendasikan penggunaan commit Git daripada 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 mengilustrasikan proses peluncuran untuk metode ini:

Anda dapat menyesuaikan pola ini dengan kebutuhan spesifik, menggunakan lebih dari dua cabang, atau menggunakan cabang yang dipetakan ke sesuatu selain lingkungan. Jika Anda perlu me-roll back 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 banyak 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 cabang yang belum ditinjau. 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 perubahan bertahap di beberapa cluster yang pada akhirnya akan memiliki kebijakan yang sama. Namun, jika Anda ingin meluncurkan perubahan hanya ke subset cluster atau namespace, gunakan objek ClusterSelector dan NamespaceSelector. Objek ini memiliki tujuan yang serupa: 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, tergantung negara tempat cluster 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 dalam waktu yang lama untuk mempelajari dampak kebijakan.
• Pengujian A/B, tempat Anda men-deploy versi berbeda dari kebijakan yang sama ke cluster yang berbeda untuk mempelajari perbedaan dampak versi kebijakan, lalu memilih yang terbaik untuk di-deploy di mana saja.

Misalnya, bayangkan sebuah organisasi dengan beberapa klaster 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 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 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 fleet produksi. Untuk mengetahui 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 Git commit, error apa pun hanya memengaruhi satu cluster pada satu waktu, karena Anda meluncurkan cluster demi cluster. Namun, jika Anda menggunakan cabang Git, error dapat memengaruhi semua cluster yang menggunakan cabang tersebut. Jika Anda menggunakan pemilih, error dapat memengaruhi semua cluster sekaligus.

Menerapkan ulasan, pengujian, dan validasi

Salah satu keuntungan Config Sync adalah mengelola semuanya secara deklaratif—resource, resource cloud, dan kebijakan Kubernetes. 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 peninjauan

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 digunakan untuk meninjau perubahan yang dilakukan pada repositori Config Sync.

Praktik terbaik untuk meninjau perubahan pada repositori Anda sama seperti peninjauan kode biasa, sebagai berikut:

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

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

• Lindungi cabang yang langsung digunakan oleh cluster. Lihat dokumentasi untuk GitHub, GitLab, dan Bitbucket. GitLab juga memungkinkan Anda melindungi tag.
• Setelah cabang dilindungi, Anda dapat meningkatkan 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 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 yang berbeda ini, Anda dapat menerapkan persetujuan untuk setiap permintaan perubahan ke codebase Anda. Misalnya, Anda dapat memastikan bahwa setiap perubahan telah disetujui setidaknya oleh anggota tim platform (yang mengoperasikan fleet cluster), dan anggota tim keamanan (yang bertanggung jawab menentukan dan menerapkan kebijakan keamanan).

Sebaiknya lakukan tindakan berikut:

• Terapkan ulasan 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. Ini berarti Anda mengonfigurasi pengujian otomatis untuk dijalankan saat permintaan perubahan dibuat atau diperbarui. Pengujian otomatis dapat mendeteksi banyak error sebelum seseorang 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 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 Google Cloud Build GitHub. Pemicu build juga tersedia untuk GitHub, tetapi aplikasi GitHub adalah metode integrasi yang disukai.

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

Untuk lebih memperketat feedback loop, Anda dapat meminta pengguna menjalankan perintah nomos vet sebagai hook pre-commit Git. Salah satu kendalanya 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 ke pemeriksaan semantik dan sintaksis.

Sebaiknya lakukan tindakan berikut:

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

Memantau peluncuran

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

• Error yang tidak menimbulkan masalah pada Config Sync itu sendiri, tetapi membuat workload Anda tidak berfungsi dengan baik, 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 menangkap sebagian besar error ini.

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

Mendeteksi error yang dijelaskan dalam butir kedua sebelumnya—yang seharusnya jarang jika Anda telah menerapkan semua pagar pembatas—memerlukan penyiapan tertentu. Secara default, Config Sync menulis error pada log-nya (yang secara default akan Anda temukan di Cloud Logging). Error juga ditampilkan di halaman Konsol Google Cloud Config Sync. Log atau 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 peringatan otomatis untuk error. Config Sync mengekspos 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 ketika metrik gkeconfig_monitor_errors lebih besar dari 0. Untuk mengetahui informasi selengkapnya, baca artikel 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 dari mekanisme ini yang eksklusif. Anda dapat memilih menggunakan sebagian atau semuanya, untuk tujuan yang berbeda.

Mekanisme	Efektif untuk	Apa yang tidak baik untuk	Contoh kasus penggunaan
ID dan tag commit Git	Gunakan ID atau tag commit Git tertentu untuk mengontrol dengan akurat perubahan cluster yang akan diterapkan.	Jangan gunakan ID atau tag commit Git untuk perbedaan jangka panjang di antara cluster. Menggunakan pemilih cluster.	Semua cluster Anda sudah dikonfigurasi untuk menerapkan commit Git 12345. Anda membuat perubahan dengan commit baru, abcdef, yang ingin diuji. Anda dapat mengubah konfigurasi satu cluster agar menggunakan commit baru ini untuk memvalidasi perubahannya.
Cabang Git	Gunakan beberapa cabang Git saat Anda ingin meluncurkan perubahan yang sama ke beberapa lingkungan, satu per satu.	Jangan gunakan beberapa cabang Git untuk perbedaan jangka panjang antar-cluster. Cabang-cabang tersebut akan sangat berbeda dan akan sulit untuk digabungkan kembali.	Pertama-tama, gabungkan perubahan pada cabang staging, yang akan diambil oleh cluster staging. Kemudian, gabungkan perubahan di cabang master, tempat perubahan 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 dalam staging, lalu men-deploy modifikasinya 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 bahwa tim yang relevan menyetujui perubahan.	Peninjau manual tidak menangkap 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 dalam pipeline continuous integration	Gunakan pengujian otomatis untuk menemukan error pada perubahan yang disarankan.	Pengujian otomatis tidak dapat sepenuhnya menggantikan petugas peninjau. 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 bahwa Config Sync benar-benar menerapkan perubahan pada cluster 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 meng-commit perubahan yang tidak valid ke repositori Config Sync. Perubahan ini tidak dapat diterapkan pada cluster Anda. Jika Anda memantau error sinkronisasi, Anda akan diberi tahu jika terjadi error.

Contoh strategi peluncuran

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

Peringatan: Strategi peluncuran ini rumit. Sebaiknya hanya lakukan penerapan jika Anda memiliki infrastruktur kompleks dengan minimal 2 fleet, dan minimal 3 cluster per fleet. Jika Anda memiliki fleet yang banyak, tetapi dengan satu cluster di setiap fleet, Anda dapat menyesuaikan strategi ini dengan memiliki "armada canary", bukan "cluster canary".

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

1. Anda harus 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 dalam armada.
4. Anda memvalidasi lagi bahwa semuanya berfungsi seperti yang diharapkan.

Untuk men-deploy perubahan di semua cluster, Anda dapat mengulangi proses ini untuk setiap fleet. Secara teknis, Anda dapat menerapkan metode ini dengan commit Git apa pun, dari cabang mana pun. Namun, sebaiknya lakukan proses berikut untuk mengidentifikasi masalah di 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 deploy semua perubahan ke semua fleet pada akhirnya. Strategi ini menghilangkan masalah untuk melacak fleet mana yang harus disinkronkan dengan commit tertentu. Perhatikan dengan cermat perubahan yang hanya menargetkan armada produksi karena pengujian yang tepat tidak dapat dilakukan di fleet sebelumnya. Misalnya, ini berarti menunggu lebih lama hingga masalah muncul antara melakukan deployment ke cluster canary dan ke cluster lainnya.

Ringkasnya, deployment menyeluruh yang lengkap terlihat seperti ini:

1. Seseorang membuka permintaan perubahan.
2. Pengujian dan validasi otomatis berjalan, dan peninjauan manual dilakukan.
3. Anda memicu tugas secara manual untuk men-deploy perubahan pada cluster canary di fleet pengembangan. Pengujian menyeluruh otomatis berjalan di cluster ini.
4. Jika tidak ada masalah, gabungkan permintaan perubahan di cabang utama.
5. Penggabungan tersebut akan memicu tugas otomatis untuk men-deploy tip cabang utama yang baru commit ke cluster canary dalam fleet pengembangan. Pengujian menyeluruh otomatis berjalan di cluster ini (untuk mendeteksi potensi inkompatibilitas antara dua permintaan perubahan yang telah dibuat dan digabungkan pada waktu yang hampir bersamaan).
6. Tugas berikut berjalan satu demi satu (Anda memicunya secara manual, atau setelah waktu yang ditentukan untuk memungkinkan laporan regresi pengguna):
   1. Deploy ke semua cluster fleet pengembangan.
   2. Jalankan pengujian dan validasi di cluster fleet pengembangan.
   3. Deploy ke gugus canary armada staging.
   4. Jalankan pengujian dan validasi di cluster canary dari fleet staging.
   5. Deploy ke semua cluster armada staging.
   6. Jalankan pengujian dan validasi dalam cluster fleet staging.
   7. Men-deploy ke cluster canary 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 fleet produksi.

Langkah selanjutnya

• Baca cara memantau Config Sync.
• Baca tentang fleets.
• Pelajari cara memvalidasi aplikasi terhadap kebijakan perusahaan dalam pipeline continuous integration.