Halaman ini memberikan titik awal untuk membantu Anda merencanakan dan merancang pipeline GitOps CI/CD untuk Kubernetes. GitOps, bersama dengan alat seperti Config Sync, menawarkan manfaat seperti peningkatan stabilitas kode, keterbacaan yang lebih baik, dan otomatisasi.
GitOps adalah pendekatan yang berkembang pesat untuk mengelola konfigurasi Kubernetes dalam skala besar. Bergantung pada persyaratan untuk pipeline CI/CD, ada banyak opsi untuk cara Anda merancang dan mengatur kode konfigurasi dan aplikasi. Dengan mempelajari beberapa praktik terbaik GitOps, Anda dapat membuat arsitektur yang stabil, teratur dengan baik, dan aman.
Halaman ini ditujukan bagi Admin, arsitek, dan Operator yang ingin menerapkan GitOps di lingkungan mereka. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.
Mengatur repositori Anda
Saat menyiapkan arsitektur GitOps, pisahkan repositori Anda berdasarkan jenis file konfigurasi yang disimpan di setiap repositori. Secara umum, Anda dapat mempertimbangkan setidaknya empat jenis repositori:
- Repositori paket untuk grup konfigurasi terkait.
- Repositori platform untuk konfigurasi seluruh armada bagi cluster dan namespace.
- Repositori konfigurasi aplikasi.
- Repositori kode aplikasi.
Diagram berikut menunjukkan tata letak repositori ini:
Di Gambar 2:
- Tim pengembangan mengirimkan kode untuk aplikasi dan konfigurasi aplikasi ke repositori.
- Kode untuk aplikasi dan konfigurasi disimpan di tempat yang sama dan tim aplikasi memiliki kontrol atas repositori ini.
- Tim aplikasi mengirimkan kode ke dalam build.
Menggunakan repositori paket pribadi yang terpusat
Gunakan repositori pusat untuk paket publik atau internal, seperti diagram Helm,untuk membantu tim menemukan paket. Misalnya, jika repositori disusun secara logis atau berisi readme, penggunaan repositori paket pribadi yang terpusat dapat membantu tim menemukan informasi dengan cepat. Anda dapat menggunakan layanan seperti Artifact Registry atau repositori Git untuk mengatur repositori pusat Anda.
Misalnya, tim platform organisasi Anda dapat menerapkan kebijakan yang memungkinkan tim aplikasi menggunakan paket hanya dari repositori pusat.
Anda dapat membatasi izin tulis ke repositori hanya untuk sejumlah kecil engineer. Bagian organisasi lainnya dapat memiliki akses baca. Sebaiknya terapkan proses untuk mempromosikan paket ke repositori pusat dan menyiarkan update.
Meskipun mengelola repositori pusat dapat menambah beberapa overhead tambahan karena seseorang harus mengelola repositori pusat, dan menambah proses tambahan untuk tim aplikasi, ada banyak manfaat dari pendekatan ini:
- Tim pusat dapat memilih untuk menambahkan paket publik pada irama yang ditentukan, yang membantu menghindari kerusakan akibat konektivitas atau churn upstream.
- Kombinasi peninjau otomatis dan manual dapat memeriksa paket untuk menemukan masalah sebelum paket tersebut tersedia secara luas.
- Repositori pusat menyediakan cara bagi tim untuk menemukan apa yang sedang digunakan dan didukung. Misalnya, tim dapat menemukan deployment Redis standar yang disimpan di repositori pusat.
- Anda dapat mengotomatiskan perubahan pada paket upstream untuk memastikan paket tersebut memenuhi standar internal seperti nilai default, penambahan label, dan repositori image penampung.
Membuat repositori WET
WET adalah singkatan dari "Write Everything Twice" (Tulis Semuanya Dua Kali). Hal ini berbeda dengan DRY, yang merupakan singkatan dari "Don't Repeat Yourself" (Jangan Mengulangi Diri Sendiri). Pendekatan ini merepresentasikan dua jenis file konfigurasi yang berbeda:
- Konfigurasi DRY, dengan satu file konfigurasi menjalani tindakan transformasi untuk mengisi kolom dengan nilai yang berbeda untuk lingkungan yang berbeda. Misalnya, Anda dapat memiliki konfigurasi cluster bersama yang diisi dengan region yang berbeda atau setelan keamanan yang berbeda untuk lingkungan yang berbeda.
- Konfigurasi WET (atau terkadang, "fully-hydrated"), di mana setiap file konfigurasi mewakili status akhir.
Meskipun repositori WET dapat menyebabkan beberapa file konfigurasi berulang, repositori ini memiliki manfaat berikut untuk alur kerja GitOps:
- Anggota tim dapat meninjau perubahan dengan lebih mudah.
- Tidak ada pemrosesan yang diperlukan untuk melihat status yang diinginkan dari file konfigurasi.
Uji lebih awal saat memvalidasi konfigurasi
Menunggu hingga Config Sync mulai menyinkronkan untuk memeriksa masalah dapat membuat commit Git yang tidak perlu dan loop umpan balik yang panjang. Banyak masalah dapat ditemukan sebelum konfigurasi diterapkan ke cluster dengan menggunakan fungsi validasi kpt.
Meskipun Anda harus menambahkan alat dan logika tambahan ke proses commit, pengujian sebelum menerapkan konfigurasi memiliki manfaat berikut:
- Menampilkan perubahan konfigurasi dalam permintaan perubahan dapat membantu mencegah error masuk ke repositori.
- Mengurangi dampak masalah dalam konfigurasi bersama.
Menggunakan folder, bukan cabang
Gunakan folder untuk varian file konfigurasi, bukan cabang. Dengan
folder, Anda dapat menggunakan perintah tree untuk melihat varian. Dengan cabang, Anda tidak dapat mengetahui apakah perbedaan antara cabang produksi dan pengembangan adalah perubahan konfigurasi yang akan datang atau perbedaan permanen antara tampilan lingkungan prod dan dev.
Kelemahan utama pendekatan ini adalah penggunaan folder tidak memungkinkan Anda mempromosikan perubahan konfigurasi menggunakan permintaan perubahan ke file yang sama. Namun, penggunaan folder, bukan cabang, memiliki manfaat berikut:
- Penemuan folder lebih mudah daripada cabang.
- Melakukan diff pada folder dapat dilakukan dengan banyak alat CLI dan GUI, sementara diff cabang kurang umum di luar penyedia Git.
- Membedakan antara perbedaan permanen dan perbedaan yang tidak dipromosikan lebih mudah dilakukan dengan folder.
- Anda dapat men-deploy perubahan ke beberapa cluster dan namespace dalam satu permintaan perubahan, sedangkan cabang memerlukan beberapa permintaan perubahan ke cabang yang berbeda.
Meminimalkan penggunaan ClusterSelectors
ClusterSelectors memungkinkan Anda menerapkan bagian tertentu dari
konfigurasi ke sebagian cluster. Daripada mengonfigurasi objek RootSync atau RepoSync,
Anda dapat mengubah resource yang diterapkan atau menambahkan label
ke cluster. Meskipun ini adalah cara ringan untuk menambahkan ciri ke cluster,
seiring waktu, jumlah ClusterSelectors akan bertambah, sehingga akan sulit
untuk memahami status akhir cluster.
Karena Config Sync memungkinkan Anda menyinkronkan beberapa objek RootSync dan RepoSync
sekaligus, Anda dapat menambahkan konfigurasi yang relevan ke repositori terpisah, lalu
mengekspornya ke cluster yang diinginkan. Hal ini memudahkan Anda memahami
status akhir cluster dan Anda dapat mengumpulkan konfigurasi untuk cluster ke dalam folder, bukan menerapkan keputusan konfigurasi tersebut secara langsung di cluster.
Menghindari pengelolaan Tugas dengan Config Sync
Dalam sebagian besar kasus, Tugas dan tugas situasional lainnya harus dikelola oleh layanan yang menangani pengelolaan siklus prosesnya. Kemudian, Anda dapat mengelola layanan tersebut dengan Config Sync, bukan Tugas itu sendiri.
Meskipun Config Sync dapat menerapkan Tugas untuk Anda, Tugas tidak cocok untuk deployment GitOps karena alasan berikut:
Kolom yang tidak dapat diubah: Banyak kolom Job 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 jika Anda menghapusnya dari sumber.
Tugas berjalan tanpa disengaja: Jika Anda menyinkronkan Tugas dengan Config Sync, lalu Tugas tersebut dihapus dari cluster, Config Sync akan menganggapnya sebagai penyimpangan dari status yang Anda pilih dan membuat ulang Tugas tersebut. Jika Anda menentukan Masa aktif (TTL) tugas, Config Sync akan otomatis menghapus Tugas dan otomatis membuat ulang serta memulai ulang Tugas, hingga Anda menghapus Tugas dari sumber tepercaya.
Masalah rekonsiliasi: Config Sync biasanya menunggu objek direkonsiliasi setelah diterapkan. Namun, Tugas dianggap telah disesuaikan saat tugas tersebut mulai berjalan. Artinya, Config Sync tidak menunggu hingga Job selesai sebelum melanjutkan penerapan objek lainnya. Namun, jika Tugas gagal di kemudian hari, hal itu dianggap sebagai kegagalan untuk mencocokkan. Dalam beberapa kasus, hal ini dapat memblokir sinkronisasi resource lain dan menyebabkan error hingga Anda memperbaikinya. Dalam kasus lain, sinkronisasi mungkin berhasil dan hanya rekonsiliasi yang gagal.
Karena alasan ini, sebaiknya jangan menyinkronkan Tugas dengan Config Sync.
Menggunakan repositori 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 tertentu seperti
Custom Resource Definitions (CRD) dalam direktori cluster.
Hal ini dapat menyebabkan masalah saat Anda perlu membagikan 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 pada proses.
Dengan menggunakan repositori tidak terstruktur, akan jauh lebih mudah untuk membagikan dan menggunakan kembali paket konfigurasi. Namun, tanpa proses atau panduan yang jelas untuk mengatur repositori, struktur repositori dapat bervariasi di seluruh tim, sehingga menyulitkan penerapan alat di seluruh armada.
Untuk mempelajari cara mengonversi repositori hierarkis, lihat Mengonversi repositori hierarkis menjadi repositori tidak terstruktur.
Repositori kode dan konfigurasi terpisah
Saat menskalakan mono-repositori, build khusus untuk setiap folder diperlukan. Izin dan masalah bagi orang yang mengerjakan kode dan mengerjakan konfigurasi cluster umumnya berbeda.
Memisahkan repositori kode dan konfigurasi memiliki manfaat berikut:
- Menghindari commit "berulang". Misalnya, melakukan commit ke repositori kode dapat memicu permintaan CI, yang dapat menghasilkan image, yang kemudian memerlukan commit kode.
- Jumlah commit yang diperlukan dapat menjadi beban bagi anggota tim yang berkontribusi.
- Anda dapat menggunakan izin yang berbeda untuk orang yang mengerjakan kode aplikasi dan konfigurasi cluster.
Memisahkan repositori kode dan konfigurasi memiliki kekurangan berikut:
- Mengurangi penemuan untuk konfigurasi aplikasi karena tidak berada di repositori yang sama dengan kode aplikasi.
- Mengelola banyak repositori dapat menghabiskan banyak waktu.
Menggunakan repositori terpisah untuk mengisolasi perubahan
Saat menskalakan mono-repositori, izin yang berbeda diperlukan di folder yang berbeda. Oleh karena itu, pemisahan repositori memungkinkan batas keamanan antara konfigurasi keamanan, platform, dan aplikasi. Sebaiknya juga pisahkan repositori produksi dan non-produksi.
Meskipun mengelola banyak repositori bisa menjadi tugas yang besar, mengisolasi berbagai jenis konfigurasi di repositori yang berbeda memiliki manfaat berikut:
- Dalam organisasi dengan tim platform, keamanan, dan aplikasi, irama perubahan dan izin berbeda.
- Izin tetap berada di tingkat repositori. File
CODEOWNERSmemungkinkan organisasi membatasi izin tulis sambil tetap mengizinkan izin baca. - Config Sync mendukung beberapa sinkronisasi per namespace yang dapat mencapai efek serupa seperti mengambil file dari beberapa repositori.
Menyematkan versi paket
Baik menggunakan Helm maupun Git, Anda harus menyematkan versi paket konfigurasi ke sesuatu yang tidak akan berpindah secara tidak sengaja tanpa peluncuran eksplisit.
Meskipun menambahkan pemeriksaan tambahan pada peluncuran saat konfigurasi bersama diperbarui, tindakan ini mengurangi risiko pembaruan bersama yang berdampak lebih besar dari yang diinginkan.
Menggunakan Workload Identity Federation for GKE
Anda dapat mengaktifkan Workload Identity Federation untuk GKE di cluster GKE, yang memungkinkan workload Kubernetes mengakses layanan Google dengan cara yang aman dan mudah dikelola.
Meskipun beberapa layanan non-Google Cloud , seperti GitHub dan GitLab, tidak mendukung Workload Identity Federation untuk GKE, Anda harus mencoba menggunakan Workload Identity Federation untuk GKE jika memungkinkan karena peningkatan keamanan dan pengurangan kompleksitas dalam mengelola rahasia dan sandi.