Pertanyaan Umum - GitOps dan Kubernetes dengan dukungan Azure Arc

  • Artikel

Artikel ini membahas pertanyaan yang sering diajukan tentang Kubernetes dan GitOps dengan dukungan Azure Arc.

Apa perbedaan antara Kube yang diaktifkan Azure Arc dan Azure Kubernetes Service (AKS)?

AKS adalah penawaran Kubernetes terkelola oleh Azure. AKS menyederhanakan penyebaran kluster Kubernetes terkelola di Azure dengan membongkar overhead kerumitan dan operasional ke Azure. Karena master Kubernetes dikelola oleh Azure, Anda hanya mengelola dan memelihara simpul agen.

Kube yang diaktifkan Azure Arc memungkinkan Anda untuk memperluas kemampuan manajemen Azure (seperti Azure Monitor dan Azure Policy) dengan menyambungkan kluster Kube ke Azure. Anda mempertahankan kluster Kubernetes yang mendasarinya sendiri.

Apakah saya perlu menyambungkan kluster AKS saya yang berjalan di Azure ke Azure Arc?

Saat ini, menghubungkan kluster Azure Kubernetes Service (AKS) ke Azure Arc tidak diperlukan untuk sebagian besar skenario. Anda mungkin ingin menyambungkan kluster untuk menjalankan layanan berkemampuan Azure Arc tertentu seperti App Services dan Data Services di atas kluster. Hal ini dapat dilakukan menggunakan fitur lokasi kustom Kube yang diaktifkan Azure Arc.

Haruskah saya menyambungkan kluster AKS-HCI dan kluster Kube di Azure Stack Edge ke Azure Arc?

Koneksi kluster AKS-HCI atau kluster Kubernetes di Azure Stack Edge ke Azure Arc menyediakan kluster dengan representasi sumber daya di Azure Resource Manager. Representasi sumber daya ini memperluas kemampuan seperti Konfigurasi Kluster, Azure Monitor, dan Azure Policy (Gatekeeper) ke kluster Kubernetes yang tersambung.

Jika kluster Kubernetes dengan dukungan Azure Arc ada di Azure Stack Edge, AKS pada Azure Stack HCI (>= pembaruan April 2021), atau AKS pada Pusat Data Windows Server 2019 (>= pembaruan April 2021), maka konfigurasi Kubernetes disertakan tanpa biaya.

Bagaimana cara mengatasi sumber daya Kubernetes dengan dukungan Azure Arc yang kedaluwarsa?

Identitas terkelola yang ditetapkan sistem yang terkait dengan kluster Kubernetes dengan dukungan Azure Arc hanya digunakan oleh agen Azure Arc untuk berkomunikasi dengan layanan Azure Arc. Sertifikat yang terkait dengan identitas terkelola yang ditetapkan sistem ini memiliki jendela kedaluwarsa 90 hari, dan agen akan mencoba memperbarui sertifikat ini antara Hari 46 hingga Hari 90. Untuk menghindari sertifikat identitas terkelola Anda kedaluwarsa, pastikan bahwa kluster online setidaknya sekali antara Hari 46 dan Hari 90 sehingga sertifikat dapat diperpanjang.

Jika sertifikat identitas terkelola kedaluwarsa, sumber daya dipertimbangkan Expired dan semua fitur Azure Arc (seperti konfigurasi, pemantauan, dan kebijakan) akan berhenti bekerja pada kluster.

Untuk memeriksa kapan sertifikat identitas terkelola akan kedaluwarsa untuk kluster tertentu, jalankan perintah berikut:

az connectedk8s show -n <name> -g <resource-group>

Dalam output, nilai managedIdentityCertificateExpirationTime menunjukkan kapan sertifikat identitas yang dikelola akan kedaluwarsa (tanda 90D untuk sertifikat itu).

Jika nilai managedIdentityCertificateExpirationTime menunjukkan stempel waktu dari masa lalu, maka bidang connectivityStatus pada output di atas akan disetel ke Expired. Dalam kasus seperti itu, agar cluster Kubernetes Anda berfungsi dengan Azure Arc lagi:

  1. Hapus sumber daya dan agen Kubernetes dengan dukungan Azure Arc pada kluster.

    az connectedk8s delete -n <name> -g <resource-group>

  2. Buat ulang sumber daya Kube yang diaktifkan Azure Arc dengan menyebarkan agen di kluster.

    az connectedk8s connect -n <name> -g <resource-group>

Catatan

az connectedk8s delete juga akan menghapus konfigurasi dan ekstensi kluster di atas kluster. Setelah menjalankan az connectedk8s connect, buat ulang konfigurasi dan ekstensi kluster di kluster, baik secara manual atau menggunakan Kebijakan Azure.

Jika saya sudah menggunakan alur CI/CD, apakah saya masih dapat menggunakan konfigurasi Kubernetes atau AKS dan GitOps dengan dukungan Azure Arc?

Ya, Anda masih dapat menggunakan konfigurasi pada penyebaran penerimaan kluster melalui alur CI/CD. Dibandingkan dengan alur CI/CD tradisional, konfigurasi GitOps menampilkan beberapa manfaat tambahan.

Rekonsiliasi drift

ALur CI/CD hanya menerapkan perubahan sekali selama eksekusi alur. Namun, operator GitOps di kluster terus melakukan polling repositori Git untuk mengambil status sumber daya Kubernetes yang diinginkan di kluster. Jika operator GitOps menemukan status sumber daya yang diinginkan berbeda dari status sumber daya aktual di kluster, drift ini direkonsiliasi.

Menerapkan GitOps dalam skala besar

Alur CI/CD berguna untuk penyebaran yang didorong oleh kejadian ke kluster Kubernetes (misalnya, dorongan ke repositori Git). Namun, untuk menyebarkan konfigurasi yang sama ke semua kluster Kubernetes, Anda perlu mengonfigurasi kredensial setiap kluster Kubernetes secara manual ke alur CI/CD.

Untuk Kubernetes dengan dukungan Azure Arc, karena Azure Resource Manager mengelola konfigurasi GitOps, Anda dapat mengotomatiskan pembuatan konfigurasi yang sama di semua sumber daya Kubernetes dan AKS dengan dukungan Azure Arc menggunakan Azure Policy, dalam cakupan langganan atau grup sumber daya. Kemampuan ini bahkan berlaku untuk sumber daya Kubernetes dan AKS dengan dukungan Azure Arc yang dibuat setelah penetapan kebijakan.

Fitur ini menerapkan konfigurasi garis besar (seperti kebijakan jaringan, pengikatan peran, dan kebijakan keamanan pod) di seluruh inventaris kluster Kubernetes untuk memenuhi persyaratan kepatuhan dan tata kelola.

Kepatuhan kluster

Status kepatuhan setiap konfigurasi GitOps dilaporkan kembali ke Azure. Ini memungkinkan Anda melacak penyebaran yang gagal.

Apakah Kube yang diaktifkan Azure Arc menyimpan data pelanggan di luar wilayah kluster?

Di Azure, fitur untuk mengaktifkan penyimpanan data pelanggan dalam satu wilayah saat ini hanya tersedia di Kawasan Asia Tenggara (Singapura) dari Asia Timur Geo dan Brasil Selatan (Negara Bagian Sao Paulo) Wilayah Brasil Geo. Untuk semua wilayah lain, data pelanggan disimpan di Geo. Ini berlaku untuk ekstensi Open Service Mesh dan Azure Key Vault Secrets Provider dengan dukungan Azure Arc yang didukung di Kubernetes dengan dukungan Azure Arc. Untuk ekstensi kluster lainnya, silakan lihat dokumentasi mereka untuk mempelajari cara mereka menyimpan data pelanggan. Informasi selengkapnya, lihat Pusat Kepercayaan.

Langkah berikutnya