Praktik terbaik GitOps Kubernetes dengan Config Sync

Halaman ini memberikan titik awal untuk membantu Anda merencanakan dan merancang GitOps CI/CD pipeline untuk Kubernetes, yang dapat membantu Anda memaksimalkan Config Sync.

Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang ingin mengimplementasikan GitOps di lingkungannya. Untuk mempelajari lebih lanjut tentang peran umum dan contoh tugas yang kami rujuk di konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise yang umum.

GitOps sendiri adalah praktik terbaik universal untuk organisasi yang mengelola konfigurasi Kubernetes sebagai penskalaan. Namun, apabila terkait dengan merancang solusi itu, Anda punya banyak pilihan. Memahami opsi yang ada dan manfaat serta konsekuensi dari keputusan tersebut dapat membantu Anda menghindari arsitektur Anda di masa mendatang.

Anda tidak perlu menggunakan setiap praktik terbaik yang tercantum di halaman ini. Mana yang terbaik praktik yang Anda pilih akan tergantung pada situasi unik Anda. Sasaran dari halaman ini untuk membantu Anda membuat keputusan yang tepat saat menyiapkan GitOps Anda tentang arsitektur ini.

Menggunakan repositori paket pribadi yang terpusat

Menggunakan repositori pusat untuk paket publik atau internal (seperti Helm atau kpt) membantu tim menemukan paket dengan lebih mudah. Anda dapat menggunakan layanan seperti Artifact Registry atau repositori Git Anda.

Tim platform dapat menerapkan kebijakan yang dapat digunakan tim aplikasi paket hanya dari repositori pusat. Atau, mereka dapat menggunakan repositori pusat sebagai satu kumpulan paket yang telah diperiksa.

Anda dapat membatasi izin akses ke repositori hanya untuk sejumlah kecil insinyur/teknik. Seluruh organisasi dapat memiliki akses baca. Saran dari kami menerapkan proses untuk mempromosikan paket ke dalam repositori pusat dan pembaruan penyiaran.

Tabel berikut mencantumkan manfaat dan kelemahan dari penggunaan server data terpusat repositori paket pribadi:

Manfaat

Kelemahan

Serap paket publik dengan ritme yang ditentukan, yang akan membantu menghindari kerusakan oleh konektivitas atau churn upstream. Tinjau dan pindai paket yang dibagikan. Memberikan cara mudah untuk menemukan apa yang sedang digunakan dan didukung. Misalnya, tim dapat lebih mudah menemukan deployment Redis standar yang disimpan di repositori pusat. Melakukan perubahan pada paket upstream untuk memastikan bahwa paket tersebut memenuhi standar internal seperti nilai default, menambahkan label, dan repositori image container.

Seseorang harus mengelola repositori pusat. Menambahkan lebih banyak proses untuk tim aplikasi.

Membuat repositori basah

Buat repositori dengan output YAML yang sesuai dengan status yang diinginkan dari atau namespace. Perubahan pada repositori basah atau terhidrasi penuh harus mudah ditinjau dengan menggunakan {i>diff<i}. Praktik yang baik adalah membuat perubahan hanya repositori basah melalui proses peninjauan (misalnya, di GitHub, ini akan menjadi permintaan pull).

Tabel berikut mencantumkan manfaat dan kekurangan dari membuat repositori basah:

Manfaat	Kelemahan
Lebih mudah untuk memeriksa perbedaannya. Tidak diperlukan pemrosesan untuk melihat status konfigurasi yang diinginkan.	Konfigurasi hidrasi sepenuhnya dapat menyebabkan YAML berulang.

Geser ke kiri untuk memvalidasi konfigurasi

Menunggu hingga Config Sync mulai disinkronkan untuk memeriksa apakah ada masalah yang dapat terjadi commit Git yang tidak diperlukan, dan feedback loop yang panjang. Banyak masalah yang dapat ditemukan sebelum konfigurasi diterapkan ke cluster dengan menggunakan fungsi validator kpt.

Tabel berikut mencantumkan manfaat dan kerugian dari memeriksa masalah sebelum menerapkan konfigurasi:

Manfaat	Kelemahan
Menampilkan perubahan konfigurasi dalam permintaan perubahan dapat membantu mencegah error agar tidak masuk ke dalam repositori. Mengurangi dampak masalah dalam konfigurasi bersama.	Harus menambahkan alat dan logika ke proses commit Anda untuk membantu menemukan masalah.

Menggunakan folder, bukan cabang

Gunakan folder untuk varian konfigurasi, bukan cabang. Dengan {i>folder<i}, Anda dapat menggunakan perintah tree untuk melihat varian. Misalnya, dengan cabang, Anda tidak dapat mengetahui apakah delta antara cabang prod dan bidang adalah perubahan yang atau perbedaan permanen antara tahap dan produksi apa yang harus terlihat suka.

Tabel berikut mencantumkan keuntungan dan kerugian menggunakan {i>folder <i}alih-alih cabang:

Manfaat

Kelemahan

Penemuan folder lebih mudah daripada cabang. Melakukan diff pada folder dapat dilakukan dengan banyak alat CLI dan GUI, sedangkan perbedaan cabang ({i>branch diff<i}) jarang terjadi di luar penyedia Git. Membedakan antara perbedaan permanen dan perbedaan yang tidak dipromosikan lebih mudah dengan folder. Anda dapat meluncurkan perubahan ke beberapa cluster dan namespace dalam satu permintaan perubahan, sedangkan cabang memerlukan beberapa permintaan perubahan ke cabang yang berbeda.

Anda tidak dapat mempromosikan perubahan konfigurasi menggunakan permintaan perubahan pada file yang sama.

Minimalkan penggunaan ClusterSelectors

ClusterSelectors memungkinkan Anda menerapkan bagian tertentu dari konfigurasi ke subset dari cluster. Alih-alih mengonfigurasi RootSync atau RepoSync, Anda dapat mengubah resource yang diterapkan atau menambahkan label ke cluster. Namun seiring waktu, seiring dengan bertambahnya jumlah ClusterSelectors, bisa menjadi rumit untuk memahami status akhir cluster.

Dengan Config Sync, Anda dapat menyinkronkan beberapa RootSyncs dan RepoSyncs sekaligus, artinya Anda dapat menambahkan konfigurasi yang relevan ke repositori terpisah dan kemudian sinkronkan ke cluster yang Anda inginkan.

Tabel berikut mencantumkan manfaat dan kekurangan dari tidak menggunakan ClusterSelectors:

Manfaat	Kelemahan
Lebih mudah menyusun konfigurasi yang akan ada di cluster ke dalam folder, bukan membuat keputusan tersebut di cluster. Mengurangi beban mental dalam memahami apa yang sebenarnya akan diterapkan ke cluster.	Label adalah cara yang mudah untuk menambahkan trait ke cluster dan lebih kompleks untuk membuat `RepoSync` baru.

Menghindari pengelolaan Tugas dengan Config Sync

Meskipun Config Sync dapat menerapkan Tugas untuk Anda, Pekerjaan tidak cocok untuk Deployment GitOps karena alasan berikut:

• Kolom yang tidak dapat diubah: Banyak kolom Tugas yang tidak dapat diubah. Untuk mengubah immutable , objek harus dihapus dan dibuat ulang. Namun, Config Sync tidak akan menghapus objek kecuali Anda menghapusnya dari sumbernya.

• Menjalankan Tugas yang tidak diinginkan: Jika Anda menyinkronkan Tugas dengan Config Sync dan lalu Tugas tersebut dihapus dari cluster, Config Sync menganggap bahwa melenceng dari status yang Anda pilih dan membuat ulang Tugas. Jika Anda menentukan Lowongan time to live (TTL), Tugas akan otomatis dihapus dan Config Sync secara otomatis membuatnya ulang, memulai ulang Tugas, sampai Anda menghapus Tugas tersebut dari sumbernya yang sesungguhnya. Sering kali, ini bukan yang dimaksudkan karena Config Sync menjalankan lagi Tugas tersebut.

• Masalah rekonsiliasi: Config Sync biasanya menunggu objek untuk merekonsiliasi setelah diterapkan. Namun, Lowongan dianggap dapat direkonsiliasi jika sudah mulai berjalan. Ini berarti bahwa Config Sync tidak menunggu Tugas yang harus diselesaikan sebelum melanjutkan untuk menerapkan objek lain. Namun, jika Pekerjaan kemudian gagal, yang dianggap kegagalan rekonsiliasi. Di beberapa lain yang terjadi, hal ini dapat memblokir sinkronisasi resource lain dan menyebabkan error sampai Anda memperbaikinya. Dalam kasus lain, sinkronisasi mungkin berhasil dan hanya rekonsiliasi gagal.

Oleh karena itu, sebaiknya jangan sinkronkan Tugas dengan Config Sync.

Dalam kebanyakan kasus, Pekerjaan dan tugas situasional lainnya harus dikelola oleh penyedia yang menangani pengelolaan siklus prosesnya. Anda kemudian dapat mengelola layanan tersebut dengan Config Sync, bukan Tugas itu sendiri.

Tabel berikut mencantumkan keuntungan dan kerugian dari tidak menggunakan Config Sync untuk mengelola Tugas:

Manfaat

Kelemahan

Meningkatkan kompatibilitas GitOps. Tugas tidak akan berfungsi baik dengan pendekatan GitOps deklaratif yang dikontrol versi karena kolomnya yang tidak dapat diubah. Mengurangi konsekuensi yang tidak diinginkan. Menghilangkan risiko Config Sync otomatis membuat ulang Tugas yang telah dihapus, yang berpotensi menyebabkan tugas tersebut berjalan secara tidak terduga. Lebih sedikit error sinkronisasi. Potensi konflik dan error sinkronisasi yang dipicu oleh Tugas yang gagal dapat dihindari.

Pengelolaan Tugas Manual. Anda perlu mencari layanan lain untuk mengelola Tugas.

Menggunakan repositori yang tidak terstruktur

Config Sync mendukung dua struktur untuk mengatur repositori: tidak terstruktur dan hierarkis. Tidak terstruktur adalah pendekatan yang direkomendasikan karena memungkinkan Anda mengatur repositori dengan cara yang paling nyaman bagi Anda. Sebagai perbandingan, repositori hierarkis menerapkan struktur spesifik. Sebagai misalnya, CRD harus berada di direktori tertentu. Hal ini dapat menyebabkan masalah ketika Anda perlu membagikan konfigurasi. Misalnya, jika satu tim memublikasikan paket yang berisi CRD, tim lain yang perlu menggunakan paket itu harus memindahkan CRD ke dalam direktori cluster, sehingga menambahkan lebih banyak overhead ke proses.

Tabel berikut mencantumkan manfaat dan kerugian dari penggunaan data yang tidak terstruktur repositori:

Manfaat	Kelemahan
Anda dapat menggunakan kembali paket konfigurasi bersama meskipun berisi CRD atau definisi tingkat cluster lainnya di dalamnya.	Tanpa proses atau panduan, struktur repositori dapat bervariasi antartim sehingga dapat mempersulit penerapan alat di seluruh fleet.

Untuk mempelajari cara mengonversi repositori hierarkis, lihat Mengonversi repositori hierarkis menjadi repositori tidak terstruktur.

Memisahkan repositori konfigurasi dan kode

Saat meningkatkan skala repositori mono, diperlukan build khusus untuk setiap folder. Izin dan permasalahan bagi orang yang mengerjakan kode dan mengerjakan konfigurasi cluster umumnya berbeda. Dengan menyimpan kode dan konfigurasi repositori terpisah, setiap repositori dapat memiliki izin akses dan karena ada berbagai struktur penetapan harga.

Tabel berikut mencantumkan manfaat dan kelemahan dari memisahkan kode dan repositori config:

Manfaat	Kelemahan
Menghindari "looping" melakukan commit. Misalnya, melakukan commit ke repo kode dapat memicu permintaan CI, yang mungkin menghasilkan gambar, yang kemudian memerlukan commit kode, dan seterusnya. Anda dapat menggunakan izin yang berbeda-beda untuk orang yang mengerjakan kode aplikasi dan konfigurasi cluster.	Mengurangi penemuan konfigurasi aplikasi karena tidak berada di repositori yang sama dengan kode aplikasi. Mengelola banyak repositori dapat memakan waktu.

Menggunakan repositori terpisah untuk mengisolasi perubahan

Saat meningkatkan skala repositori mono, izin yang berbeda diperlukan pada folder yang berbeda. Karena itu, memisahkan repositori memungkinkan keamanan batas antara keamanan, platform, dan konfigurasi aplikasi. Ini juga merupakan adalah ide yang bagus untuk memisahkan repositori produksi dan non-produksi.

Tabel berikut mencantumkan keuntungan dan kerugian dari perubahan isolasi pada repositori terpisah:

Manfaat	Kelemahan
Dalam organisasi dengan tim platform, keamanan, dan aplikasi, ritme perubahan dan izinnya berbeda. Izin tetap berada pada level repositori. File CODEOWNERS memungkinkan organisasi membatasi izin tulis sekaligus tetap mengizinkan izin baca. Config Sync mendukung beberapa sinkronisasi per namespace yang dapat mencapai "efek campuran" dari beberapa repositori.	Mengelola banyak repositori adalah tugas tersendiri. Jadi, dalam kasus di mana Anda membuat repo baru per cluster, masalah penyiapan/teardown cluster sekarang perlu menyertakan pengelolaan repo.

Menyematkan versi paket

Baik menggunakan Helm atau Git, Anda harus menyematkan versi paket konfigurasi ke sesuatu yang tidak sengaja bergerak maju tanpa peluncuran.

Tabel berikut mencantumkan manfaat dan kekurangan dari versi paket yang disematkan:

Manfaat	Kelemahan
Update konfigurasi bersama dapat memiliki dampak yang lebih besar dari yang diinginkan jika versi paket tidak disematkan.	Peluncuran memerlukan pemeriksaan saat paket bersama diupdate.

Menggunakan Workload Identity Federation untuk GKE

Anda dapat mengaktifkan Workload Identity Federation for GKE di GKE cluster, yang memungkinkan workload Kubernetes mengakses layanan Google dalam aman dan dapat dikelola.

Tabel berikut mencantumkan manfaat dan kekurangan menggunakan Workload Identity Federation untuk GKE:

Manfaat	Kelemahan
Mengurangi kerumitan dan potensi masalah terkait secret dan sandi.	Layanan di luar Google Cloud (seperti GitHub dan GitLab) tidak mendukung Workload Identity Federation untuk GKE.

Arsitektur tingkat tinggi

Pada level tinggi, Anda mungkin memerlukan setidaknya empat jenis repositori:

1. Repositori paket tempat penyimpanan konfigurasi bersama. Ini bisa juga berupa chart Helm yang disimpan di Artifact Registry.
2. Repositori platform tempat tim platform menyimpan konfigurasi di seluruh fleet untuk cluster dan namespace.
3. Repositori konfigurasi aplikasi.
4. Repositori kode aplikasi.

Diagram berikut menunjukkan tata letak repositori tersebut:

Diagram berikut menunjukkan alur konfigurasi dari kode aplikasi ke repositori konfigurasi aplikasi. Tim pengembangan mengirim kode untuk konfigurasi aplikasi dan aplikasi ke dalam repositori. Kode untuk keduanya aplikasi dan konfigurasi disimpan di tempat yang sama dan tim aplikasi memiliki kendali atas repositori tersebut. Tim aplikasi kemudian dapat mengirim kode ke build.

Langkah selanjutnya

• Memulai Config Sync