Halaman ini menyediakan titik awal untuk membantu Anda merencanakan dan merancang pipeline CI/CD GitOps 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 aplikasi dan konfigurasi. Dengan mempelajari beberapa praktik terbaik GitOps, Anda dapat membuat arsitektur yang stabil, teratur, dan aman.
Halaman ini ditujukan untuk Admin dan arsitek serta 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
Saat menyiapkan arsitektur GitOps, pisahkan repositori berdasarkan jenis file konfigurasi yang disimpan di setiap repositori. Pada tingkat tinggi, Anda dapat mempertimbangkan setidaknya empat jenis repositori:
- Repositori paket untuk grup konfigurasi terkait.
- Repositori platform untuk konfigurasi seluruh fleet untuk cluster dan namespace.
- Repositori konfigurasi aplikasi.
- Repositori kode aplikasi.
Diagram berikut menunjukkan tata letak repositori ini:
Pada 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 build.
Menggunakan repositori paket pribadi 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 terpusat dapat membantu tim menemukan informasi dengan cepat. Anda dapat menggunakan layanan seperti Artifact Registry atau repositori Git untuk mengatur repositori pusat.
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. Anggota organisasi lainnya dapat memiliki akses baca. Sebaiknya terapkan proses untuk mempromosikan paket ke repositori pusat dan menyiarkan update.
Meskipun pengelolaan repositori pusat dapat menambah overhead tambahan karena seseorang harus mengelola repositori pusat, dan menambahkan 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 gangguan akibat konektivitas atau churn upstream.
- Kombinasi peninjau otomatis dan manusia dapat memeriksa paket untuk masalah sebelum membuatnya tersedia secara luas.
- Repositori pusat menyediakan cara bagi tim untuk menemukan apa yang 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, menambahkan label, dan repositori image container.
Membuat repositori WET
WET adalah singkatan dari "Write Everything Twice". Hal ini berbeda dengan DRY, yang merupakan singkatan dari "Don't Repeat Yourself". Pendekatan ini mewakili dua jenis file konfigurasi yang berbeda:
- Konfigurasi DRY , tempat 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"), tempat 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 lebih mudah meninjau perubahan.
- Tidak ada pemrosesan yang diperlukan untuk melihat status file konfigurasi yang diinginkan.
Menguji 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 menggunakan fungsi validator 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 delta antara cabang produksi dan pengembangan adalah perubahan konfigurasi yang akan datang atau perbedaan permanen antara tampilan lingkungan prod dan dev.
Kelemahan utama dari 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, sedangkan diff cabang kurang umum di luar penyedia Git.
- Membedakan antara perbedaan permanen dan perbedaan yang tidak dipromosikan lebih mudah 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 subset 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 karakteristik ke cluster, seiring waktu, jumlah ClusterSelectors dapat bertambah, sehingga 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 menyinkronkannya 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 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 immutable: Banyak kolom Tugas yang immutable. Untuk mengubah kolom immutable, objek harus dihapus dan dibuat ulang. Namun, Config Sync tidak menghapus objek Anda kecuali jika Anda menghapusnya dari sumber.
Tugas yang tidak disengaja: Jika Anda menyinkronkan Tugas dengan Config Sync dan lalu Tugas tersebut dihapus dari cluster, Config Sync akan menganggapnya sebagai penyimpangan dari status yang Anda pilih dan membuat ulang Tugas. Jika Anda menentukan a waktu aktif Tugas (TTL), 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 untuk direkonsiliasi setelah diterapkan. Namun, Tugas dianggap direkonsiliasi saat mulai berjalan. Artinya, Config Sync tidak menunggu Tugas selesai sebelum terus menerapkan objek lain. Namun, jika Tugas gagal nanti, hal tersebut dianggap sebagai kegagalan untuk direkonsiliasi. Dalam beberapa kasus, hal ini dapat memblokir resource lain agar tidak disinkronkan 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.
Repositori hierarkis, sebagai perbandingan, menerapkan struktur tertentu seperti Definisi Resource Kustom (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, paket konfigurasi akan jauh lebih mudah dibagikan dan digunakan kembali. Namun, tanpa proses atau panduan yang ditentukan untuk mengatur repositori, struktur repositori dapat bervariasi di seluruh tim, sehingga dapat mempersulit penerapan alat di seluruh fleet.
Untuk mempelajari cara mengonversi repositori hierarkis, lihat Mengonversi repositori hierarkis menjadi repositori tidak terstruktur.
Memisahkan repositori kode dan konfigurasi
Saat menskalakan repositori mono, repositori ini memerlukan build khusus untuk setiap folder. Izin dan masalah untuk orang yang mengerjakan kode dan yang mengerjakan konfigurasi cluster umumnya berbeda.
Memisahkan repositori kode dan konfigurasi memiliki manfaat berikut:
- Menghindari commit "looping". 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 memakan waktu.
Menggunakan repositori terpisah untuk mengisolasi perubahan
Saat menskalakan repositori mono, izin yang berbeda diperlukan di folder yang berbeda. Karena hal ini, pemisahan repositori memungkinkan batas keamanan antara keamanan, platform, dan konfigurasi aplikasi. Sebaiknya pisahkan juga repositori produksi dan non-produksi.
Meskipun pengelolaan banyak repositori dapat menjadi tugas 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 sekaligus tetap mengizinkan izin baca. - Config Sync mendukung beberapa sinkronisasi per namespace yang dapat mencapai efek yang sama seperti mengambil file dari beberapa repositori.
Menyematkan versi paket
Baik menggunakan Helm maupun Git, Anda harus menyematkan versi paket konfigurasi ke sesuatu yang tidak sengaja dipindahkan tanpa peluncuran eksplisit.
Meskipun hal ini menambahkan pemeriksaan tambahan ke peluncuran Anda saat konfigurasi bersama diperbarui, hal ini mengurangi risiko update bersama yang memiliki dampak lebih besar dari yang dimaksudkan.
Menggunakan Workload Identity Federation for GKE
Anda dapat mengaktifkan Workload Identity Federation for GKE di cluster GKE, yang memungkinkan workload Kubernetes mengakses layanan Google dengan cara yang aman dan terkelola.
Meskipun beberapa layanan non-Google Cloud layanan, seperti GitHub dan GitLab, tidak mendukung Workload Identity Federation for GKE, Anda harus mencoba menggunakan Workload Identity Federation for GKE jika memungkinkan karena peningkatan keamanan dan pengurangan kompleksitas pengelolaan rahasia dan sandi.