Disiplin CI/CD dan GitOps dengan Kubernetes dengan dukungan Azure Arc

  • Artikel

Sebagai konstruksi cloud-native, Kubernetes memerlukan pendekatan cloud-native untuk penyebaran dan operasi. Dengan GitOps, Anda menyatakan status penyebaran berbasis aplikasi yang diinginkan dalam file yang disimpan di repositori Git. Aplikasi memiliki objek Kubernetes yang perlu mereka jalankan, yang dapat mencakup Penyebaran, Horizontal-Pod-Autoscalers, Services, dan Config Peta. Operator Kubernetes berjalan di kluster dan terus merekonsiliasi status setiap kluster dengan status yang diinginkan yang dideklarasikan dalam repositori Git Anda. Operator ini menarik file dari repositori Git Anda dan menerapkan status yang diinginkan ke kluster Anda. Operator juga terus memastikan bahwa kluster Anda tetap dalam keadaan yang diinginkan.

Menerapkan GitOps memungkinkan Anda:

  • Tingkatkan visibilitas keseluruhan status dan konfigurasi kluster Kubernetes Anda.
  • Miliki audit sederhana dan riwayat versi perubahan pada kluster Anda melalui riwayat perubahan Git yang menunjukkan siapa yang membuat perubahan, kapan perubahan tersebut dilakukan, dan mengapa.
  • Secara otomatis mengoreksi penyimpangan yang dapat terjadi pada kluster Anda.
  • Gulung balik konfigurasi Kubernetes Anda ke versi sebelumnya melalui perintah pengembalian Git atau putar kembali Git. Pembuatan ulang penyebaran kluster untuk skenario pemulihan bencana juga menjadi proses yang cepat dan mudah karena konfigurasi kluster yang diinginkan Kubernetes disimpan di Git.
  • Tingkatkan keamanan dengan mengurangi jumlah akun layanan yang diperlukan untuk memiliki izin penyebaran ke kluster Anda.
  • Terapkan alur CI/CD untuk menyebarkan aplikasi ke kluster Anda.

GitOps di Kubernetes dengan dukungan Azure Arc menggunakan ekstensi yang mengimplementasikan Flux, set alat sumber terbuka populer. Flux adalah operator yang mengotomatiskan penyebaran konfigurasi GitOps di kluster Anda. Flux menyediakan dukungan untuk sumber file umum (repositori Git, repositori Helm, Bucket) dan jenis template (YAML, Helm, dan Kustomize). Flux juga mendukung manajemen dependensi multi-penyewaan dan penyebaran di antara fitur-fitur lainnya.

Arsitektur

Diagram berikut mengilustrasikan arsitektur referensi konseptual yang menyoroti provisi penginstalan ekstensi kluster Flux dalam kluster, proses konfigurasi GitOps untuk kluster Kubernetes dengan dukungan Azure Arc, dan Alur GitOps.

Proses provisi Ekstensi Kluster Flux v2:

Diagram that shows Flux extension installation.

Proses Konfigurasi GitOps:

Diagram that shows how to configure GitOps.

GitOps Flow memperlihatkan pembaruan aplikasi:

Diagram that shows a typical GitOps workflow.

Pertimbangan Desain

Tinjau pertimbangan desain berikut saat berencana mengimplementasikan GitOps untuk Kubernetes dengan dukungan Azure Arc.

Konfigurasi

Pertimbangkan berbagai lapisan konfigurasi di kluster Kubernetes Anda dan tanggung jawab yang terlibat dalam penyediaannya.

Lapisan konfigurasi

  • Konfigurasi aplikasi diperlukan untuk menyebarkan aplikasi dan objek Kubernetes terkait ke kluster seperti sumber daya Deployment, Service, HPA, dan ConfigMap. Konfigurasi aplikasi biasanya diterapkan pada konfigurasi GitOps tingkat namespace layanan, yang mengharuskan komponen aplikasi hanya dikonfigurasi dalam satu namespace layanan.
  • Konfigurasi seluruh kluster untuk pembuatan objek Kubernetes seperti Namespace layanan, ServiceAccounts, Peran dan RoleBindings, dan kebijakan seluruh kluster lainnya.
  • Komponen di seluruh kluster seperti Pengontrol Ingress, pemantauan dan tumpukan keamanan, dan berbagai agen yang beroperasi di seluruh kluster.

Tanggung jawab

  • Pengembang Aplikasi bertanggung jawab untuk mendorong kode sumber mereka, memicu build, dan membuat gambar kontainer.
  • Operator Aplikasi bertanggung jawab untuk mempertahankan repositori aplikasi, konfigurasi, variabel lingkungan, bagan helm khusus aplikasi, Kustomisasi, dll.
  • Operator kluster bertanggung jawab untuk menyiapkan garis besar kluster Anda. Mereka biasanya khawatir dengan penyiapan komponen dan kebijakan di seluruh kluster. Mereka mempertahankan direktori repositori Git atau direktori yang berisi alat infrastruktur umum seperti Namespace layanan, Akun Layanan, RoleBindings, CRD, kebijakan di seluruh kluster, komponen Ingress, dll.

Struktur Repositori

Pertimbangkan tradeoff saat memilih struktur repositori Git. Struktur yang Anda pilih akan menentukan status kluster Kubernetes Anda, yang mencakup aplikasi dan komponen di seluruh kluster. Bergantung pada tanggung jawab dan persona mana yang Anda identifikasi, penting untuk mempertimbangkan kolaborasi yang diperlukan atau kemandirian tim yang diinginkan yang diperlukan untuk opsi struktur repositori yang berbeda.

Anda dapat menggunakan strategi pencabangan apa pun yang Anda suka untuk repositori kode Anda, karena hanya digunakan oleh proses Integrasi Berkelanjutan (CI) Anda.

Untuk repositori konfigurasi GitOps Anda, pertimbangkan strategi berikut berdasarkan kebutuhan, ukuran, dan alat bisnis organisasi Anda:

  • Repositori tunggal (Cabang per lingkungan):
    • Memungkinkan fleksibilitas terbanyak untuk mengontrol kebijakan dan izin Git untuk setiap cabang yang mewakili lingkungan.
    • Kelemahannya adalah tidak ada berbagi konfigurasi umum di antara lingkungan, karena alat seperti Kustomize tidak berfungsi dengan cabang Git.
  • Repositori tunggal (Direktori per lingkungan):
    • Anda dapat menerapkan pendekatan ini menggunakan alat seperti Kustomize, yang memungkinkan Anda menentukan konfigurasi dasar untuk objek Kubernetes dan sekumpulan artefak (yaitu patch) untuk lingkungan Anda yang mengambil alih konfigurasi di dasar.
    • Pendekatan ini dapat mengurangi file YAML duplikat untuk setiap lingkungan, tetapi juga mengurangi pemisahan konfigurasi antar lingkungan. Membuat satu perubahan pada repositori berpotensi memengaruhi semua lingkungan sekaligus, jadi memahami efek perubahan pada direktori dasar harus sepenuhnya dipahami dan dilakukan dengan hati-hati.
  • Beberapa repositori (masing-masing melayani tujuan tertentu):
    • Ini dapat digunakan untuk memisahkan repositori konfigurasi untuk setiap aplikasi, tim, lapisan, atau penyewa.
    • Ini memungkinkan tim untuk memiliki kontrol yang lebih independen tetapi menjauh dari prinsip mendefinisikan status sistem Anda dalam satu repositori untuk meningkatkan konfigurasi pusat, visibilitas, dan kontrol penyebaran ke kluster.
    • Menyiapkan beberapa repositori harus dipertimbangkan untuk kebutuhan multi-penyewaan. Ada kontrol akses berbasis peran (RBAC) dan keamanan bawaan untuk membatasi konfigurasi apa yang dapat diterapkan oleh tim/penyewa ke repositori tertentu, seperti hanya mengizinkan penyebaran ke namespace layanan tertentu.

Lihat cara lain untuk menyusun repositori Anda di Panduan Fluks.

Konfigurasi aplikasi dan platform

Operator Platform dan Operator Aplikasi memiliki beberapa opsi untuk mengelola konfigurasi Kubernetes:

  • File YAML Kubernetes mentah yang mewakili spesifikasi YAML untuk setiap objek API Kubernetes yang Anda sebarkan dapat bekerja dengan baik untuk satu lingkungan. Kelemahan untuk menggunakan file YAML mentah adalah penyesuaian menjadi sulit ketika Anda mulai menggabungkan beberapa lingkungan, karena Anda perlu menduplikasi file YAML dan tidak ada metode penggunaan kembali yang baik.
  • Helm adalah alat manajemen paket untuk objek Kubernetes. Ini adalah opsi yang valid yang dapat digunakan Operator Kluster untuk menginstal aplikasi off-the-shelf pihak ketiga. Pastikan Anda tidak menggunakan templat terlalu berat sebagai alat manajemen konfigurasi untuk aplikasi internal, karena dapat menjadi kompleks untuk dikelola saat templat Anda tumbuh.
    • Jika menggunakan Helm, Flux menyertakan Pengontrol Helm yang memungkinkan Anda mengelola rilis Bagan Helm secara deklaratif dengan manifes Kubernetes. Anda dapat membuat objek HelmRelease untuk mengelola proses tersebut.
  • Kustomize adalah alat manajemen konfigurasi asli Kubernetes yang memperkenalkan cara bebas templat untuk menyesuaikan konfigurasi aplikasi.
    • Jika menggunakan Kustomize, Flux menyertakan pengontrol Kustomisasi yang mengkhususkan diri dalam menjalankan alur pengiriman berkelanjutan untuk infrastruktur dan beban kerja yang ditentukan dengan manifes Kubernetes dan dirakit dengan Kustomisasi. Anda dapat membuat objek Kustomisasi untuk mengelola proses tersebut.
  • Dengan Kubernetes dengan dukungan Azure Arc, alih-alih perlu mengelola siklus hidup dan dukungan komponen sendiri, Anda dapat menggunakan daftar ekstensi yang tersedia yang dikelola dan didukung Microsoft. Ekstensi ini dikelola melalui Azure Resource Manager. Beberapa ekstensi ini, seperti Penyedia Rahasia Azure Key Vault, memiliki alternatif sumber terbuka. Mengelola komponen di luar proses ekstensi memberi Anda lebih banyak kontrol atas komponen, tetapi juga membutuhkan lebih banyak overhead untuk dukungan dan manajemen siklus hidup.

Alur Integrasi Berkelanjutan dan Pengiriman Berkelanjutan (CI/CD)

Bagian berikut memberikan pertimbangan untuk alur aplikasi dan proses pembaruan komponen Anda.

Alur aplikasi

  • Pertimbangkan build, pengujian, dan validasi aplikasi yang perlu Anda sertakan dalam proses CI Anda. Ini dapat mencakup linting dan pengujian yang terkait dengan keamanan, integrasi, dan performa, yang Anda butuhkan untuk membuat kandidat rilis (RC) untuk penyebaran lingkungan.
  • Anda dapat menggunakan metode penyebaran push tradisional untuk menjenjang kesenjangan antara gambar kontainer build di alur CI Anda dan penyebarannya dalam kluster dengan memanggil API Kubernetes langsung dari alur penyebaran Anda.

Untuk menghindari modifikasi konfigurasi manual pada repositori GitOps, Anda dapat menjalankan alur CD sebagai akun layanan, yang memiliki izin untuk membuka permintaan pull (PR) atau menerapkan perubahan gambar kontainer baru langsung ke repositori konfigurasi. Perubahan ini juga dapat menyediakan semua objek YAML yang diperlukan untuk aplikasi Anda.

Diagram proses berikut mengilustrasikan proses CI aplikasi tradisional yang disertakan dengan perubahan yang mendukung GitOps.

Diagram that shows the standard GitOps process.

Proses pembaruan komponen di seluruh kluster

  • Operator Kluster perlu mengelola komponen di seluruh kluster, sehingga kemungkinan ini tidak akan berasal dari alur CD yang digunakan untuk menyebarkan aplikasi dan layanan Anda. Pertimbangkan untuk menentukan proses promosi khusus untuk Operator Kluster untuk memastikan perubahan dapat beralih dengan lancar dari satu lingkungan ke lingkungan lainnya.
  • Jika Anda perlu menerapkan konfigurasi GitOps yang identik dalam skala besar ke kluster Kubernetes yang didukung Azure Arc, pertimbangkan untuk menerapkan Azure Policy yang dapat menginstal ekstensi Flux secara otomatis dan menerapkan konfigurasi GitOps Anda ke kluster Kubernetes dengan dukungan Azure Arc yang ada atau ke kluster baru saat mereka di-onboarding ke Azure Arc.

Saat memperbarui konfigurasi, Anda mungkin ingin memverifikasi bahwa perubahan telah berhasil diterapkan ke lingkungan yang Anda inginkan. Anda dapat menentukan pemberitahuan di Flux untuk diintegrasikan dengan alat CI/CD, email, atau alat ChatOps Anda dan secara otomatis mengirimkan pemberitahuan mengenai perubahan yang berhasil dan kegagalan penyebaran. Anda juga dapat menemukan informasi status penyebaran di portal Azure dan melalui CLI dan ARM API konfigurasi k8s.

Pertimbangan keamanan

Tinjau pertimbangan keamanan berikut saat berencana mengimplementasikan GitOps untuk Kubernetes dengan dukungan Azure Arc.

Autentikasi repositori

  • Anda dapat menggunakan repositori Git publik atau privat dengan GitOps, tetapi karena sifat konfigurasi Kubernetes yang sensitif, kami sarankan Anda menggunakan repositori privat yang memerlukan autentikasi oleh kunci SSH atau kunci API. GitOps juga bekerja dengan repositori Git yang hanya dapat diakses dalam jaringan privat selama kluster Kubernetes Anda dapat mengaksesnya, tetapi pengaturan ini membatasi kemampuan Anda untuk menggunakan penyedia Git berbasis cloud seperti Azure Repos atau GitHub.
  • Protokol HTTPS dan SSH menawarkan koneksi yang andal dan aman yang dapat Anda gunakan untuk terhubung ke alat kontrol sumber Anda. Namun, HTTPS sering kali lebih mudah diatur, dan menggunakan port yang jarang mengharuskan Anda membuka lebih banyak port di firewall Anda.

Repositori dan keamanan cabang

  • Atur izin dan kebijakan cabang pada repositori konfigurasi Anda. Saat repositori Git Anda menjadi bagian pusat dari penyebaran Kubernetes, sangat penting bagi Anda untuk menyiapkan izin untuk mengontrol siapa yang dapat membaca dan memperbarui kode di cabang dan bahwa Anda menerapkan kebijakan untuk menegakkan kualitas kode dan manajemen perubahan tim Anda. Jika tidak, alur kerja GitOps Anda dapat mengirimkan kode yang tidak sesuai dengan standar organisasi Anda.
  • Alur permintaan pull (PR) dapat bekerja dengan kebijakan cabang Anda untuk memvalidasi konfigurasi YAML dan/atau menyebarkan lingkungan pengujian sesuai kebutuhan. Gates membantu menghilangkan kesalahan konfigurasi dan meningkatkan keamanan dan kepercayaan diri penyebaran.
  • Saat menetapkan izin akses, pertimbangkan pengguna mana di organisasi Anda yang harus memiliki akses baca repositori, akses pembuatan PR, dan akses persetujuan PR.

Manajemen rahasia

  • Hindari menyimpan teks biasa atau rahasia yang dikodekan base64 di repositori Git Anda. Sebagai gantinya, pertimbangkan untuk menggunakan penyedia rahasia eksternal seperti Azure Key Vault. Penyedia Azure Key Vault untuk Driver CSI Penyimpanan Rahasia memungkinkan Anda mengintegrasikan brankas kunci Azure sebagai penyimpanan rahasia dengan kluster Azure Kubernetes Service (AKS) menggunakan volume CSI. Layanan ini tersedia melalui ekstensi Kubernetes dengan dukungan Azure Arc. HashiCorp Vault adalah alternatif penyedia rahasia terkelola pihak ketiga.
  • Cara alternatif lain untuk mengelola rahasia adalah dengan menggunakan Rahasia Tersegel Bitnami, yang dioperasikan dari konsep kunci publik dan privat. Ini memungkinkan operator untuk menyimpan rahasia terenkripsi satu arah menggunakan kunci publik di Git, yang hanya dapat didekripsi melalui kunci privat, yang digunakan oleh pengontrol SealedSecrets yang berjalan di kluster Anda.

Rekomendasi desain

Tinjau rekomendasi desain berikut saat berencana untuk mengimplementasikan GitOps untuk Kubernetes dengan dukungan Azure Arc.

Diagram berikut berisi arsitektur referensi yang mengilustrasikan tanggung jawab, repositori, dan alur yang diperlukan untuk menerapkan proses GitOps menggunakan Ekstensi Fluks Kubernetes dengan dukungan Azure Arc.

Diagram that shows a GitOps Reference flow.

Repositori

Tiga repositori Git disertakan dalam desain:

  • Repositori kode aplikasi
    • Repositori ini menyimpan kode aplikasi dan definisi alur dan skrip konfigurasi apa pun.
    • Gunakan strategi percabangan pengembangan yang mudah dipahami dan membatasi jumlah cabang jangka panjang yang tidak diinginkan.
  • Repositori konfigurasi aplikasi
    • Repositori ini menyimpan konfigurasi aplikasi, termasuk objek Kubernetes seperti objek Config Peta, Deployments, Services, dan HPA. Struktur repositori ini dengan direktori yang berbeda untuk setiap aplikasi. Flux akan menyinkronkan perubahan dari repositori ini dan cabang target ke kluster Anda.
    • Menggabungkan alat yang memudahkan pengembang dan operator aplikasi untuk membangun konfigurasi awal per lingkungan. Operator Aplikasi harus menentukan konfigurasi aplikasi khusus Kubernetes yang menggunakan manajer paket seperti Helm atau alat konfigurasi seperti Kustomisasi untuk membuat konfigurasi lebih sederhana.
    • Buat cabang untuk mewakili setiap jenis lingkungan. Hal ini memungkinkan kontrol halus perubahan ke setiap lingkungan tertentu, seperti lingkungan non-prod dan produksi.
    • Saat aplikasi disebarkan ke namespace tertentu, gunakan fitur cakupan namespace dalam konfigurasi GitOps untuk menerapkan konfigurasi hanya untuk namespace tertentu.
  • Repositori konfigurasi seluruh kluster
    • Tentukan komponen di seluruh kluster seperti Pengontrol Ingress, Namespace, RBAC, pemantauan, dan tumpukan keamanan untuk manajemen Operator Kluster. Fluks menyinkronkan perubahan dari repositori ini dan cabang target ke kluster Anda.
    • Struktur repositori ini dengan direktori yang berbeda yang mewakili komponen yang berbeda.
    • Buat cabang untuk mewakili setiap jenis lingkungan. Hal ini memungkinkan kontrol halus perubahan ke setiap lingkungan tertentu, seperti lingkungan non-prod dan produksi.
    • Operator Kluster harus menggunakan manajer paket seperti Helm atau alat konfigurasi seperti Kustomisasi overlay untuk membuat konfigurasi lebih sederhana.

CI/CD dan proses pembaruan konfigurasi

PEMBARUAN CI/CD dan gambar kontainer

  • Alur CI
    • Tim pengembangan harus menentukan alur CI melalui proses yang mencakup pembangunan, linting, pengujian, dan pendorongan aplikasi ke registri kontainer Anda.
  • Alur CD
    • Buat alur CD yang menjalankan skrip yang menargetkan perubahan terhadap repositori konfigurasi aplikasi Anda. Skrip ini membuat cabang sementara yang bersumber dari lingkungan target Anda, membuat perubahan pada versi tag gambar, menerapkan perubahan, dan membuka permintaan pull terhadap cabang lingkungan target Anda. Alur CD ini dapat memiliki tahap lingkungan dengan variabel lingkungan yang sesuai untuk menargetkan repositori dan cabang Konfigurasi GitOps yang benar.
    • Tentukan langkah persetujuan manual untuk tahap lingkungan untuk membatasi permintaan pull yang tidak diinginkan ke semua lingkungan.
  • Aktifkan kebijakan cabang pada repositori konfigurasi aplikasi Anda untuk memberlakukan tinjauan atau persetujuan serekan untuk lingkungan. Ini dapat melibatkan jumlah minimum ulasan yang diperlukan atau persetujuan otomatis untuk lingkungan yang lebih rendah. Pertimbangkan juga integrasi dan persetujuan pihak ketiga sesuai kebutuhan untuk memenuhi standar organisasi Anda.

Pembaruan konfigurasi seluruh kluster dan aplikasi

  • Operator Kluster dan Operator Aplikasi masing-masing menentukan konfigurasi di repositori konfigurasi masing-masing. Pengguna ini tidak memerlukan alat alur untuk mendorong konfigurasi. Mereka sebaliknya menggunakan penerapan Git asli dan proses PR untuk menentukan konfigurasi dan mendorong perubahan ke cabang yang mewakili lingkungan.
  • Untuk definisi konfigurasi baru, mulailah dengan menentukan konfigurasi di lingkungan yang lebih rendah, seperti Dev, lalu promosikan ke lingkungan yang lebih tinggi melalui penggabungan dan permintaan pull. Pembaruan konfigurasi cherry-pick khusus untuk lingkungan tertentu sesuai kebutuhan.

Umpan balik dan pemberitahuan

  • Konfigurasikan Pemberitahuan Fluks untuk memperingatkan saat konfigurasi GitOps tidak dapat disinkronkan atau melemparkan kesalahan. Operator Aplikasi harus mengonfigurasi pemberitahuan untuk menentukan kapan penyebaran aplikasi telah berhasil dan sehat. Operator Kluster harus mengonfigurasi pemberitahuan untuk menentukan kapan rekonsiliasi komponen di seluruh kluster gagal dan ketika ada masalah sinkronisasi dengan repositori Git Anda.
  • Terapkan GitOps Koneksi or untuk mengintegrasikan umpan balik dari agen Flux ke alat CI/CD Anda.

Rekomendasi keamanan

  • Tinjau rekomendasi tata kelola dan keamanan untuk kluster Kubernetes dengan dukungan Azure Arc.
  • Hindari akses yang tidak diinginkan ke konfigurasi kluster apa pun dengan menggunakan repositori Git privat dengan autentikasi dan otorisasi yang dapat Anda gunakan untuk menentukan repositori konfigurasi apa pun.
  • Akses repositori Git Anda melalui protokol SSH dan kunci SSH jika penyedia Git Anda mendukungnya. Jika SSH tidak dapat digunakan karena pembatasan konektivitas keluar, atau jika penyedia Git Anda tidak mendukung pustaka SSH yang diperlukan, gunakan akun layanan khusus dan kaitkan kunci API dengan akun tersebut untuk digunakan Flux. Jika Anda memerlukan alternatif untuk SSH saat menggunakan GitHub, Anda dapat Membuat token akses pribadi untuk autentikasi.
  • Konfigurasikan kebijakan dan izin cabang yang sesuai dengan tanggung jawab kluster Anda. Atur jumlah minimum peninjau untuk menyetujui perubahan.
  • Konfigurasikan alur PR untuk memvalidasi konfigurasi dan sintaks YAML dan secara opsional menyebarkan kluster Kubernetes pengujian. Siapkan kebijakan cabang yang mengharuskan alur ini berjalan dengan sukses sebelum penggabungan apa pun dapat diterima.
  • Terapkan rahasia menggunakan Penyedia Azure Key Vault untuk Secrets Store CSI Driver, yang akan memungkinkan integrasi Azure Key Vault sebagai penyimpanan rahasia dengan kluster Kubernetes dengan dukungan Azure Arc melalui volume CSI.
  • Ekstensi Flux mendukung konfigurasi ruang nama dan cakupan kluster. Pilih cakupan namespace saat konfigurasi Anda seharusnya tidak memiliki akses di luar satu namespace.

Langkah berikutnya

Untuk informasi selengkapnya tentang perjalanan cloud hibrid dan multicloud Anda, lihat artikel berikut ini.