Peluncuran aman dengan Config Sync

Dokumen ini menunjukkan kepada operator cluster dan administrator platform cara aman meluncurkan perubahan di berbagai lingkungan menggunakan Sinkronisasi Konfigurasi. Pendekatan ini dapat membantu Anda menghindari kesalahan yang memengaruhi semua lingkungan Anda secara bersamaan.

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

Konfigurasi dapat mewakili beberapa hal, termasuk berikut ini:

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

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

Meskipun Anda dapat men-deploy aplikasi yang ditampilkan kepada Config Sync, sebaiknya jangan menautkan rilis mereka siklus proses ke siklus proses rilis workload administratif yang disebutkan sebelumnya. Sebagai gantinya, kami menyarankan agar Anda menggunakan alat yang didedikasikan untuk seperti deployment deployment berkelanjutan sehingga tim aplikasi dapat bertanggung jawab atas jadwal rilis mereka.

Config Sync adalah produk canggih yang dapat mengelola banyak sehingga Anda memerlukan pagar pembatas untuk menghindari kesalahan yang berdampak besar. Ini dokumen ini menjelaskan beberapa metode untuk membuat pagar pembatas. Bagian pertama membahas 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 mengimplementasikan peluncuran. Image OCI dan diagram Helm juga didukung.

Menerapkan peluncuran bertahap dengan Config Sync

Dalam lingkungan multi-cluster, yang merupakan situasi umum bagi Bagi pengguna GKE Enterprise, sebaiknya jangan terapkan perubahan konfigurasi di semua cluster pada saat yang sama. Peluncuran bertahap, klaster per , jauh lebih aman karena mengurangi potensi dampak {i>error<i}.

Ada beberapa cara untuk menerapkan peluncuran bertahap dengan Sinkronisasi Konfigurasi:

• Gunakan commit atau tag Git untuk menerapkan perubahan yang ingin Anda lakukan secara manual klaster-klaster tersebut.
• Gunakan cabang Git untuk menerapkan perubahan secara otomatis saat perubahan digabungkan. Anda dapat menggunakan cabang yang berbeda untuk kelompok cluster yang berbeda.
• Menggunakan objek ClusterSelector dan NamespaceSelector untuk secara selektif menerapkan perubahan pada subgrup cluster atau namespace.

Semua metode untuk peluncuran bertahap memiliki kelebihan dan kekurangan. Tujuan 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.

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 pada repositori tempat Anda menyinkronkan konfigurasi.

Menggunakan commit atau tag Git

Dibandingkan dengan metode peluncuran bertahap lainnya, menggunakan commit atau tag Git memberikan kontrol paling banyak dan paling aman. Anda dapat menggunakan Halaman Konfigurasi Sinkronisasi di Konsol Google Cloud di konsol untuk mengupdate beberapa cluster sekaligus. Gunakan metode ini jika Anda ingin menerapkan perubahan pada cluster Anda satu per satu, dan untuk mengontrol kapan hal ini terjadi.

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

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

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

Misalnya, definisi RootSync berikut mengonfigurasi Sinkronisasi Konfigurasi 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 example.com:gke/config-sync.git.

Untuk memperbarui cluster, ubah kolom spec.git.revision ke nilai baru untuk gugus ini. Hal ini memungkinkan Anda menentukan cluster mana yang akan diupdate dan kapan. Jika Anda perlu melakukan roll back perubahan, ubah kolom spec.git.revision kembali ke nilai sebelumnya.

Diagram berikut mengilustrasikan proses peluncuran untuk metode ini. Pertama, Anda meng-commit perubahan pada repositori Config Sync, Anda memperbarui definisi RootSync pada semua cluster:

Sebaiknya lakukan tindakan berikut:

• Gunakan ID commit Git, bukan tag. Karena bagaimana Git fungsi, Anda memiliki jaminan bahwa mereka tidak akan pernah berubah. Misalnya, git push --force tidak dapat mengubah dan commit yang digunakan Config Sync. Pendekatan ini berguna untuk tujuan audit dan melacak {i>commit<i} mana yang Anda gunakan dalam log. Selain itu, tidak seperti tag, tidak ada langkah tambahan untuk melakukan commit ID.
• Jika Anda lebih suka menggunakan tag Git daripada ID commit Git, Anda dapat melindungi tag Anda jika Anda menggunakan solusi Git yang mendukung perlindungan.
• Jika Anda ingin memperbarui beberapa klaster sekaligus, Anda dapat melakukannya bahwa pada Konsol Google Cloud. Untuk memperbarui beberapa cluster sekaligus, cluster harus menjadi bagian dari sama fleet (dan berada di titik yang sama project).

Menggunakan cabang Git

Jika Anda ingin perubahan diterapkan ke cluster segera setelah digabungkan dalam repositori Git Anda, konfigurasikan Config Sync untuk menggunakan Git cabang, bukan commit atau tag. Dalam metode ini, Anda membuat beberapa yang sudah ada di repositori Git Anda, dan lakukan konfigurasi Config Sync di berbagai cluster untuk membaca konfigurasinya dari berbagai cabang.

Misalnya, pola sederhana memiliki dua cabang:

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

Peringatan: Jika Anda menangani cluster dan lingkungan dalam jumlah besar, Anda mungkin membutuhkan banyak cabang. Hal ini dapat dengan cepat menjadi rumit untuk mengelola. Inilah alasan kami merekomendasikan penggunaan commit Git melalui cabang.

Untuk cluster non-produksi, buat objek RootSync atau RepoSync dengan Kolom spec.git.branch disetel 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 mengilustrasikan 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 memerlukan untuk melakukan roll back perubahan, gunakan Perintah git revert untuk membuat commit baru pada 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 klaster produksi dan non-produksi.
• Sebagian besar solusi Git memungkinkan Anda menggunakan fitur cabang yang dilindungi untuk mencegah penghapusan atau perubahan yang belum ditinjau dari cabang-cabang tersebut. Untuk 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 klaster yang pada akhirnya akan memiliki kebijakan yang sama. Namun, jika Anda ingin meluncurkan perubahan hanya pada sebagian cluster atau namespace, lalu gunakan objek ClusterSelector dan NamespaceSelector. Objek ini memiliki tujuan yang sama: memungkinkan Anda menerapkan objek hanya pada cluster atau namespace yang memiliki label tertentu.

Contoh:

• Dengan menggunakan objek ClusterSelector, Anda dapat menerapkan kebijakan yang berbeda ke klaster, tergantung di negara mana mereka berada, untuk berbagai rezim kepatuhan.
• Dengan menggunakan objek NamespaceSelector, Anda dapat menerapkan kebijakan yang berbeda untuk namespace yang digunakan oleh tim internal dan kontraktor eksternal.

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

• Rilis kebijakan terbatas, tempat Anda men-deploy kebijakan baru ke subkumpulan cluster dan namespace dalam waktu yang lama untuk mempelajari dampaknya.
• Pengujian A/B, di mana Anda men-deploy versi berbeda dari kebijakan yang sama untuk berbagai klaster untuk mempelajari perbedaan di antara kedua versi kebijakan berdampak pada lalu pilih yang terbaik untuk di-deploy di mana saja.

Misalnya, bayangkan sebuah organisasi memiliki 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 menegakkan keberadaan label tim di namespace untuk mengidentifikasi masing-masing tim namespace. Mereka telah meluncurkan versi kebijakan ini di dry run, dan kini mereka ingin menerapkannya pada sejumlah kecil cluster. Dengan menggunakan objek ClusterSelector, mereka membuat dua K8sRequiredLabels yang berbeda resource yang diterapkan ke cluster berbeda.

• Resource K8sRequiredLabels diterapkan ke cluster jenis prod, dengan parameter enforcementAction yang disetel 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 tersebut 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 untuk menerapkan kebijakan hanya di cluster jenis canary-prod, sehingga mencegah efek samping yang tidak diinginkan dari penyebaran ke seluruh armada produksi. Untuk selengkapnya informasi 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, Anda harus berhati-hati. Jika Anda menggunakan Git commit, error apa pun hanya memengaruhi satu cluster pada satu waktu, karena Anda meluncurkan cluster per cluster. Tetapi jika Anda menggunakan cabang Git, kesalahan apa pun dapat memengaruhi semua cluster yang menggunakan cabang tersebut. Jika Anda menggunakan pemilih, error dapat memengaruhi semua klaster sekaligus.

Menerapkan ulasan, pengujian, dan validasi

Salah satu keuntungan Config Sync adalah mengelola semuanya secara deklaratif—resource Kubernetes, resource cloud, dan kebijakan. Artinya bahwa file dalam sistem manajemen kontrol sumber mewakili sumber daya (Git file, dalam kasus Config Sync). Karakteristik ini memungkinkan Anda menerapkan alur kerja pengembangan yang sudah Anda gunakan untuk kode sumber aplikasi: ulasan 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 dibuat pada repositori Config Sync.

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

• Latihan pengembangan berbasis trunk.
• Bekerja di kumpulan kecil.
• Pastikan bahwa peninjauan kode dilakukan secara sinkron atau setidaknya segera.
• Orang yang meninjau dan menyetujui perubahan tidak boleh sama orang yang menyarankan perubahan.

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

• Melindungi cabang yang langsung digunakan 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, mengaktifkan peninjauan yang diperlukan.
  • Untuk GitLab, gunakan Pemilik Kode untuk mendelegasikan izin akses persetujuan berdasarkan file atau direktori. Anda dapat menggunakan persetujuan permintaan penggabungan mewajibkan orang yang berbeda dari tim yang berbeda untuk menyetujui permintaan sebelum digabungkan.
  • Di Bitbucket, gabungkan peninjau default dengan pemeriksaan penggabungan default. Anda juga dapat menggunakan plugin Pemilik Kode untuk Bitbucket Server. di Marketplace Atlassian untuk mengontrol siapa yang dapat menyetujui perubahan pada subbagian repositori.

Dengan menggunakan fitur-fitur berbeda ini, Anda bisa menegakkan persetujuan untuk setiap perubahan ke codebase Anda. Sebagai contoh, Anda dapat memastikan bahwa setiap perubahan disetujui setidaknya oleh anggota tim platform (yang mengoperasikan armada cluster), dan oleh anggota tim keamanan (yang bertanggung jawab menetapkan dan menerapkan kebijakan keamanan).

Sebaiknya lakukan tindakan berikut:

• Terapkan peninjauan sejawat pada repositori 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 yang akan dijalankan saat permintaan perubahan dibuat atau diperbarui. Pengujian otomatis dapat mendeteksi banyak error sebelum peninjauan manual permintaan perubahan. Tindakan ini akan memperketat feedback loop bagi developer. Anda dapat mengimplementasikan 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 saat ada perubahan baru. Perintah ini memvalidasi bahwa Sintaksis repositori Config Sync valid. Anda dapat menerapkan pengujian ini dengan menggunakan Cloud Build dengan mengikuti memvalidasi konfigurasi tutorial. 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 metode integrasi yang disukai.

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

Untuk memperketat feedback loop, Anda dapat meminta pengguna menjalankan perintah nomos vet sebagai Hook pra-commit Git. Satu hal yang perlu diwaspadai adalah beberapa pengguna mungkin tidak memiliki akses ke cluster Kubernetes dikelola oleh Config Sync, dan mungkin tidak dapat dijalankan validasi penuh dari {i>workstation<i} mereka. Jalankan nomos vet --clusters "" untuk membatasi validasi ke pemeriksaan semantik dan sintaksis.

Sebaiknya lakukan tindakan berikut:

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

Memantau peluncuran

Bahkan jika Anda menerapkan semua pembatas yang dicakup dalam dokumen ini, kesalahan dapat masih terjadi. Berikut adalah dua jenis kesalahan umum:

• Error yang tidak menimbulkan masalah pada Config Sync itu sendiri, tetapi mencegah workload tidak berfungsi dengan baik, seperti pembatasan yang terlalu ketat NetworkPolicy 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 sebuah pengontrol tiket masuk. Metode yang dijelaskan sebelumnya akan dapat mendeteksi sebagian besar error ini.

Mendeteksi {i>error<i} yang dijelaskan di poin pertama sebelumnya hampir tidak mungkin dilakukan pada level Config Sync memerlukan pemahaman tentang status setiap workload Anda. Karena alasan ini, mendeteksi {i>error <i}ini paling baik dilakukan oleh sistem pemantauan yang ada yang memberi tahu Anda bila aplikasi berperilaku tidak semestinya.

Mendeteksi kesalahan yang dijelaskan dalam butir kedua sebelumnya—yang seharusnya jarang terjadi jika Anda telah menerapkan semua batasan—memerlukan pengaturan khusus. Menurut secara default, Config Sync menulis {i> error<i} ke log-nya (yang tidak akan menemukan, secara {i>default<i}, di Cloud Logging). Error juga ditampilkan di Halaman konsol Google Cloud Config Sync. Baik log maupun konsol biasanya tidak cukup untuk mendeteksi {i>error<i}, karena Anda mungkin tidak memantaunya setiap saat. Cara paling sederhana untuk mengotomatisasi error deteksi adalah menjalankan nomos status perintah, yang memberi tahu Anda jika terjadi kesalahan dalam sebuah {i>cluster<i}.

Anda juga dapat menyiapkan solusi yang lebih canggih dengan peringatan otomatis untuk error. Config Sync menampilkan metrik di Format Prometheus. Untuk informasi selengkapnya, lihat memantau Config Sync.

Setelah memiliki metrik Config Sync dalam 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. Tidak satu pun dari mekanisme ini yang eksklusif. Anda dapat memilih untuk menggunakan beberapa mereka atau semuanya, untuk tujuan yang berbeda.

Mekanisme	Efektif untuk	Apa yang tidak baik untuk	Contoh kasus penggunaan
ID dan tag Git commit	Gunakan ID atau tag commit Git tertentu untuk mengontrol secara akurat cluster mana perubahan diterapkan.	Jangan gunakan ID atau tag Git commit untuk perbedaan jangka panjang antara klaster. Menggunakan pemilih cluster.	Semua cluster Anda dikonfigurasi untuk menerapkan Git 12345 dan melakukan commit. Anda membuat perubahan dengan commit baru, abcdef, yang Anda ingin diuji. Anda dapat mengubah konfigurasi cluster tunggal untuk menggunakan commit baru untuk memvalidasi perubahan.
Cabang Git	Gunakan beberapa cabang Git saat Anda ingin meluncurkan perubahan yang sama ke ke beberapa lingkungan, satu per satu.	Jangan gunakan beberapa cabang Git untuk perbedaan yang berumur panjang antara klaster. Cabang-cabangnya akan berbeda secara signifikan dan akan sulit digabungkan kembali menjadi satu.	Pertama, gabungkan perubahan di cabang staging, di mana ia akan digunakan oleh cluster staging. Kemudian gabungkan perubahan di cabang master, di mana ia akan digunakan oleh cluster produksi.
Pemilih cluster dan pemilih namespace	Gunakan pemilih untuk perbedaan jangka panjang antara cluster dan namespace.	Jangan menggunakan 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 membutuhkan akses penuh ke cluster pengembangan, tetapi akses hanya baca ke cluster produksi, gunakan ClusterSelector objek untuk menerapkan kebijakan RBAC yang benar hanya untuk cluster yang relevan.
Ulasan sejawat	Gunakan tinjauan sejawat untuk memastikan bahwa tim yang relevan menyetujui perubahan.	Petugas peninjau tidak mendeteksi semua error, terutama item seperti sintaksis yang sama.	Organisasi Anda mewajibkan tim keamanan untuk meninjau konfigurasi perubahan yang mempengaruhi beberapa sistem. Meminta peninjauan anggota tim keamanan perubahan tersebut.
Pengujian otomatis di pipeline continuous integration	Gunakan pengujian otomatis untuk menemukan error dalam 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 tersebut adalah Config Sync yang valid konfigurasi Anda.
Memantau error sinkronisasi	Pastikan bahwa Config Sync benar-benar menerapkan perubahan pada ke cluster Anda.	Error sinkronisasi hanya terjadi jika Config Sync mencoba menerapkan repositori yang tidak valid atau jika server Kubernetes API menolak objek tersebut.	Pengguna mengabaikan semua pengujian dan ulasan Anda serta melakukan perubahan yang tidak valid untuk repositori Config Sync. Perubahan ini tidak dapat yang diterapkan ke cluster Anda. Jika Anda memantau kesalahan sinkronisasi, Anda akan memberi peringatan jika terjadi kesalahan.

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/pengaturan. Strategi ini mengasumsikan bahwa Anda memiliki fleet yang terpisah untuk pengembangan, staging, dan produksi (seperti yang ditunjukkan dalam Contoh Perangkat 1 - Pendekatan 1).

Peringatan: Strategi peluncuran ini rumit. Hanya masuk akal untuk menerapkan jika Anda memiliki infrastruktur yang kompleks dengan setidaknya 2 armada, dan setidaknya 3 cluster per fleet. Jika Anda memiliki sejumlah besar armada, tetapi dengan satu cluster di setiap cluster tersebut, maka Anda dapat menyesuaikan strategi ini dengan memiliki "armada canary" bukan "cluster canary".

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

1. Anda memperbarui satu cluster ("canary") di fleet untuk menggunakan commit baru terlebih dahulu.
2. Anda memvalidasi bahwa semuanya berfungsi seperti yang diharapkan dengan menjalankan pengujian dan memantau peluncurannya.
3. Anda memperbarui cluster lain dalam 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 cluster perangkat seluler. Secara teknis, Anda dapat menerapkan metode ini dengan Git commit, dari . Namun, sebaiknya gunakan proses berikut untuk mengidentifikasi masalah di awal proses peninjauan:

1. Saat seseorang membuka permintaan perubahan di Git Config Sync repositori, 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 perangkat tertentu, sebaiknya men-deploy semua perubahan pada semua fleet pada akhirnya. Strategi ini dapat menghilangkan masalah dalam melacak fleet mana yang harus disinkronkan dengan commit mana. Berikan perhatian khusus pada perubahan yang hanya menargetkan produksi karena pengujian yang tepat tidak mungkin dilakukan pada armada sebelumnya. Sebagai Ini berarti menunggu lebih lama hingga masalah muncul antara cluster canary dan ke cluster lainnya.

Ringkasnya, deployment menyeluruh yang menyeluruh terlihat seperti ini:

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

Langkah selanjutnya

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