Praktik terbaik GitOps Kubernetes dengan Config Sync

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

GitOps sendiri merupakan praktik terbaik universal untuk organisasi yang mengelola konfigurasi Kubernetes sebagai skala. Namun, dalam hal merancang solusi itu, Anda memiliki banyak pilihan. Memahami opsi Anda serta manfaat dan konsekuensi dari keputusan tersebut dapat membantu Anda menghindari penulisan ulang arsitektur di masa mendatang.

Anda tidak perlu menggunakan setiap praktik terbaik yang tercantum di halaman ini. Praktik terbaik mana yang Anda pilih untuk diterapkan akan bergantung pada situasi unik Anda. Tujuan halaman ini adalah untuk membantu Anda membuat keputusan yang tepat saat menyiapkan arsitektur GitOps.

Menggunakan repositori paket pribadi yang terpusat

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

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

Anda dapat membatasi izin tulis ke repositori hanya untuk sejumlah kecil engineer. Bagian lain di organisasi dapat memiliki akses baca. Sebaiknya implementasikan proses untuk mempromosikan paket ke repositori pusat dan menyiarkan update.

Tabel berikut mencantumkan manfaat dan kekurangan menggunakan repositori paket pribadi terpusat:

Manfaat

Kekurangan

Serap paket publik sesuai ritme yang ditentukan, yang akan membantu menghindari kerusakan oleh konektivitas atau churn upstream. Tinjau dan pindai paket bersama. Menyediakan cara mudah untuk menemukan apa yang digunakan dan didukung. Misalnya, tim dapat lebih mudah menemukan deployment Redis standar yang disimpan di repositori pusat. Lakukan perubahan pada paket upstream untuk memastikannya memenuhi standar internal seperti nilai default, penambahan label, dan repositori image container.

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

Membuat repositori basah

Buat repositori dengan output YAML yang sesuai dengan status cluster atau namespace yang diinginkan. Perubahan pada repositori yang basah atau terhidrasi sepenuhnya harus mudah ditinjau menggunakan operasi diff. Praktik yang baik adalah melakukan perubahan hanya pada repositori basah melalui proses peninjauan (misalnya, di GitHub, ini adalah permintaan pull).

Tabel berikut mencantumkan manfaat dan kekurangan membuat repositori basah:

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

Geser ke kiri untuk memvalidasi konfigurasi

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

Tabel berikut mencantumkan manfaat dan kekurangan memeriksa masalah sebelum menerapkan konfigurasi:

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

Menggunakan folder, bukan cabang

Gunakan folder untuk varian konfigurasi, bukan cabang. Dengan folder, Anda dapat menggunakan perintah tree untuk melihat varian. Misalnya, dengan cabang, Anda tidak dapat mengetahui apakah delta antara cabang prod dan cabang adalah perubahan yang akan datang dalam konfigurasi atau perbedaan permanen antara seperti apa stage dan produksi yang seharusnya.

Tabel berikut mencantumkan manfaat dan kekurangan menggunakan folder selain cabang:

Manfaat

Kekurangan

Penemuan folder lebih mudah daripada cabang. Melakukan diff pada folder dapat dilakukan dengan banyak alat CLI dan GUI, sedangkan diff cabang kurang umum 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.

Mempromosikan perubahan konfigurasi menggunakan permintaan perubahan pada file yang sama tidak dapat dilakukan.

Minimalkan penggunaan ClusterSelectors

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

Dengan Config Sync, Anda dapat menyinkronkan beberapa RootSyncs dan RepoSyncs sekaligus, yang berarti Anda dapat menambahkan konfigurasi yang relevan ke repositori terpisah, lalu menyinkronkannya ke cluster yang Anda inginkan.

Tabel berikut mencantumkan manfaat dan kekurangan jika tidak menggunakan ClusterSelectors:

Manfaat	Kekurangan
Lebih mudah untuk menyusun konfigurasi yang akan ada di cluster ke dalam folder, daripada membuat keputusan di cluster. Mengurangi beban mental untuk memahami apa yang sebenarnya akan diterapkan pada klaster.	Label adalah cara ringan untuk menambahkan karakteristik ke cluster, dan lebih kompleks untuk membuat `RepoSync` baru.

Menghindari pengelolaan Tugas dengan Config Sync

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

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

• Menjalankan Tugas yang tidak diinginkan: Jika Anda menyinkronkan Tugas dengan Config Sync lalu Tugas tersebut dihapus dari cluster, Config Sync akan mempertimbangkan penyimpangan tersebut dari status yang Anda pilih dan membuat ulang Tugas tersebut. Jika Anda menetapkan Job time to live (TTL), Tugas akan otomatis dihapus dan Config Sync akan otomatis membuat ulang Tugas tersebut, memulai ulang Tugas, hingga Anda menghapus Tugas dari sumber tepercaya. Sering kali, hal ini bukanlah yang dimaksudkan, karena Config Sync menjalankan Tugas lagi.

• Masalah rekonsiliasi: Config Sync biasanya menunggu objek untuk direkonsiliasi setelah diterapkan. Namun, Tugas akan dianggap direkonsiliasi saat sudah mulai berjalan. Ini berarti Config Sync tidak menunggu Tugas selesai sebelum melanjutkan untuk menerapkan objek lain. Namun, jika Tugas nanti gagal, hal tersebut dianggap sebagai kegagalan rekonsiliasi. Dalam beberapa kasus, hal ini dapat memblokir sinkronisasi resource lain dan menyebabkan error sampai Anda memperbaikinya. Dalam kasus lain, sinkronisasi mungkin berhasil dan hanya rekonsiliasi yang gagal.

Karena alasan ini, sebaiknya jangan sinkronkan Tugas dengan Config Sync.

Pada umumnya, Tugas dan tugas situasional lainnya harus dikelola oleh layanan yang menangani pengelolaan siklus prosesnya. Anda kemudian dapat mengelola layanan tersebut dengan Config Sync, bukan Tugas itu sendiri.

Tabel berikut mencantumkan manfaat dan kekurangan jika tidak menggunakan Config Sync untuk mengelola Tugas:

Manfaat

Kekurangan

Meningkatkan kompatibilitas GitOps. Tugas tidak berfungsi baik dengan pendekatan GitOps yang deklaratif dan dikontrol versi karena kolomnya yang tidak dapat diubah. Mengurangi konsekuensi yang tidak diinginkan. Menghilangkan risiko Config Sync secara otomatis membuat ulang Tugas yang telah dihapus, yang berpotensi menyebabkannya berjalan secara tidak terduga. Error sinkronisasi lebih sedikit. Potensi konflik dan error sinkronisasi yang dipicu oleh Tugas yang gagal 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. Metode ini direkomendasikan karena memungkinkan Anda mengatur repositori dengan cara yang paling nyaman bagi Anda. Repositori hierarkis, sebagai perbandingan, menerapkan struktur khusus. Misalnya, CRD harus berada dalam direktori tertentu. Hal ini dapat menyebabkan masalah saat Anda perlu berbagi konfigurasi. Misalnya, jika satu tim memublikasikan paket yang berisi CRD, tim lain yang perlu menggunakan paket tersebut harus memindahkan CRD ke direktori cluster, sehingga menambah overhead ke proses.

Tabel berikut mencantumkan manfaat dan kelemahan menggunakan repositori yang tidak terstruktur:

Manfaat	Kekurangan
Anda dapat menggunakan kembali paket konfigurasi bersama meskipun paket tersebut berisi CRD atau definisi seluruh cluster di dalamnya.	Tanpa proses atau pedoman, struktur repositori dapat bervariasi antar-tim sehingga dapat mempersulit penerapan alat di seluruh fleet.

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

Kode terpisah dan repositori konfigurasi

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 memisahkan kode dan repositori konfigurasi, setiap repositori dapat memiliki izin dan strukturnya sendiri.

Tabel berikut mencantumkan manfaat dan kekurangan memisahkan kode dan repositori konfigurasi:

Manfaat	Kekurangan
Menghindari commit "looping". Misalnya, melakukan commit ke repositori kode dapat memicu permintaan CI, yang mungkin menghasilkan image, yang kemudian memerlukan commit kode, dan seterusnya. Anda dapat menggunakan izin yang berbeda untuk orang yang mengerjakan kode aplikasi dan konfigurasi cluster.	Mengurangi penemuan konfigurasi aplikasi karena tidak berada dalam 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. Oleh karena itu, memisahkan repositori memungkinkan batas keamanan antara keamanan, platform, dan konfigurasi aplikasi. Sebaiknya pisahkan repositori produksi dan non-produksi.

Tabel berikut mencantumkan manfaat dan kekurangan dari mengisolasi perubahan di repositori terpisah:

Manfaat	Kekurangan
Dalam organisasi yang memiliki tim platform, keamanan, dan aplikasi, ritme perubahan dan izin dapat berbeda. Izin tetap berada di tingkat repositori. File CODEOWNERS memungkinkan organisasi membatasi izin tulis, tetapi tetap mengizinkan izin baca. Config Sync mendukung beberapa sinkronisasi per namespace yang dapat mencapai "campuran efek" dari beberapa repositori.	Mengelola banyak repositori adalah sebuah tugas. Jadi, jika Anda membuat repo baru per cluster, masalah penyiapan/penghapusan cluster sekarang perlu menyertakan pengelolaan repo.

Menyematkan versi paket

Baik menggunakan Helm maupun Git, Anda harus menyematkan versi paket konfigurasi ke sesuatu yang tidak akan dipindahkan secara tidak sengaja tanpa peluncuran eksplisit.

Tabel berikut mencantumkan manfaat dan kekurangan dari penyematan versi paket:

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

Menggunakan Workload Identity

Anda dapat mengaktifkan Workload Identity di cluster GKE, yang memungkinkan workload Kubernetes mengakses layanan Google dengan cara yang aman dan mudah dikelola.

Tabel berikut mencantumkan manfaat dan kekurangan menggunakan Workload Identity:

Manfaat	Kekurangan
Mengurangi kerumitan dan potensi masalah dengan rahasia dan {i>password<i}.	Layanan di luar Google Cloud (seperti GitHub dan GitLab) tidak mendukung Workload Identity.

Arsitektur tingkat tinggi

Pada tingkat tinggi, Anda mungkin menginginkan setidaknya empat jenis repositori:

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

Diagram berikut menunjukkan tata letak repositori ini:

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

Langkah selanjutnya

• Mulai menggunakan Config Sync