Teknologi cloud native memungkinkan organisasi untuk membangun dan menjalankan aplikasi yang dapat diskalakan dalam lingkungan modern yang dinamis. Di antara pola cloud native, container dan Kubernetes telah menjadi standar di berbagai bisnis. Menurut Survei Tahunan Cloud Native Computing Foundation 2022, 44% responden sudah menggunakan container untuk hampir semua aplikasi dan segmen bisnis mereka, sementara 35% lainnya menggunakan container untuk setidaknya beberapa aplikasi produksi.
Laporan Kubernetes in the Wild 2023 menunjukkan bahwa pada tahun 2021, dalam klaster Kubernetes yang tipikal, beban kerja aplikasi menyumbang sebagian besar dari Pods (59%). Sebaliknya, beban kerja non-aplikasi (sistem dan beban kerja tambahan) memiliki peran yang relatif lebih kecil. Pada tahun 2022, keadaan berubah. Beban kerja tambahan melebihi beban kerja aplikasi (63% vs. 37%) seiring dengan adopsi teknologi platform Kubernetes yang lebih canggih oleh organisasi, seperti kontrol keamanan, mesh layanan, sistem pesan, dan alat observabilitas. Jumlah total beban kerja tambahan dalam klaster Kubernetes meningkat sebesar 211% YoY, sementara beban kerja aplikasi meningkat sebesar 30% YoY. Mengoptimalkan infrastruktur beban kerja tambahan membebaskan lebih banyak sumber daya untuk mendukung aplikasi bisnis, meningkatkan kinerja dan tingkat layanan, serta mengendalikan biaya operasional.
Penyebaran Container Sidecar
Container sidecar adalah metode umum untuk menangkap berbagai aliran log di lingkungan Kubernetes. Container ini mengelola file log, menyimpannya di penyimpanan persisten, dan mengirimkannya ke aplikasi observabilitas yang relevan. Meskipun mereka membantu menjaga agar container aplikasi tetap kecil dan bebas dari agen, penggunaannya dalam skala besar berkontribusi pada peningkatan pemanfaatan sumber daya klaster dengan beban kerja tambahan. Selain itu, sumber daya sering kali diduplikasi di berbagai Pods. Misalnya, jika Anda memiliki 100 Pods, Anda mungkin memerlukan 100 container sidecar, masing-masing mengkonsumsi sumber daya komputasi dan memori, serta menambah penggunaan keseluruhan.
Sebagai alternatif dari container sidecar, pertimbangkan untuk menggunakan layanan penyimpanan AWS untuk ketahanan file log. Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), dan layanan file Amazon FSx memiliki driver Container Storage Interface (CSI) untuk menyediakan volume persisten bagi container Kubernetes. Volume dan share dapat dipasangkan dan dipasang melalui kubectl dan eksctl, mempermudah otomatisasi dan operasi pada skala besar. Untuk menyimpan file log, memilih layanan file (Amazon EFS atau Amazon FSx) membantu mengkonsolidasi entitas yang perlu dikelola. Satu volume dapat dibagikan sebagai klaim volume persisten di setiap Namespace Kubernetes, sehingga mengurangi kebutuhan untuk penyediaan volume per container sidecar dan operasi manajemen terkait.
Dalam penerapan skala besar, satu volume penyimpanan per Namespace bisa berarti banyak konektivitas dan operasi untuk dikonfigurasi. Untuk mengatasi overhead operasional ini, kita memerlukan solusi penyimpanan yang memungkinkan kita untuk melampirkan penyimpanan yang relevan ke beberapa node dan membuat volumenya tersedia di seluruh namespace. Di sinilah Amazon FSx untuk NetApp ONTAP memberikan kemampuan untuk mengatasi tantangan multi-attach dan lintas namespace.
FSx untuk ONTAP adalah sistem file ONTAP yang sepenuhnya dikelola dengan kemampuan berikut:
– Integrasi Kubernetes: NetApp Astra Trident CSI memungkinkan penyediaan dan operasi melalui API Kubernetes untuk volume block (iSCSI) dan file (NFS dan/atau SMB).
– Efisiensi Kapasitas: Duplikasi data dan kompresi native mengurangi jumlah ruang yang diperlukan untuk mengkonsolidasikan beberapa file aliran log hingga 70%.
– Replikasi Data Cerdas: Snapshot dan klon hemat ruang untuk memudahkan pemulihan dan pembuatan lingkungan, semuanya dikelola melalui kubectl.
– Optimisasi Biaya: Tingkat kapasitas dengan penyimpanan berbiaya rendah untuk optimisasi berkelanjutan.
– Opsi Ketersediaan Tinggi: Terapkan sistem file dalam konfigurasi Single-Availability Zone (AZ) atau Multi-AZ untuk failover cepat, dan izinkan container di AZ yang berbeda untuk menulis ke satu volume.
Driver NetApp Astra Trident memperluas kemampuan ini dengan fitur sumber daya TridentVolumeReference. Dengan sumber daya ini, PersistentVolumeClaim (PVC) untuk Namespace tertentu dapat dipasang oleh container di beberapa Namespace. Log di seluruh Namespace dapat ditulis ke volume yang sama, dan kemudian file log dapat dibaca oleh mesin agregator log di Namespace khusus. Solusi ini mengurangi overhead operasional dalam penerapan, konfigurasi, dan pemeliharaan agen logging sidecar di seluruh infrastruktur. Ini juga mengurangi overhead komputasi dan memori yang akan diklaim oleh setiap container sidecar di beberapa Pods, serta jumlah koneksi terbuka dan lalu lintas jaringan.
Masalah Multi-Log
Sebuah aplikasi dapat memiliki beberapa aliran log untuk tujuan yang berbeda, seperti log stdout umum, log akses, dan log audit. Selain itu, aplikasi yang berbeda mungkin menghasilkan aliran log mereka sendiri yang sesuai dengan kebutuhan observabilitas aplikasi.
Setiap aliran log memiliki format, frekuensi, dan konfigurasi izin yang berbeda, namun kita masih perlu mengumpulkan log-log ini dan mengirimkannya ke mesin agregator log kita. Tantangan utamanya adalah bahwa log-log ini terletak di penyimpanan Pod yang bersifat sementara dan tidak dapat diakses atau dialirkan dengan cara yang sama seperti aliran log default dari stdout/err.
Pengaturan Klaster Amazon EKS di Mana Setiap Pod Menulis Log ke stdout
Dalam arsitektur log yang umum digunakan (seperti yang ditunjukkan pada gambar sebelumnya), DaemonSet berfungsi untuk menjalankan agen kolektor yang mengalirkan log ke agen log pusat. Namun, mengelola arsitektur ini bisa menjadi kompleks ketika setiap aplikasi menghasilkan berbagai jenis log (dalam hal format, frekuensi penulisan, dll.). Tim operasional perlu mengetahui kapan jenis log baru ditambahkan dan mendapatkan pemahaman dari pengembang aplikasi tentang cara menangani dan memprosesnya.
Ada beberapa pendekatan untuk mengatasi tantangan ini. Pertama, Anda bisa menggunakan container sidecar dari mesin kolektor log untuk mengalirkan file log tambahan tersebut. Kedua, Anda bisa menyimpan file tambahan ini dalam Persistent Volume Claim (PVC) untuk ketahanan, lalu mengalirkannya ke mesin log.
Solusi A – Streaming dengan Container Sidecar
Container sidecar beroperasi sebagai aplikasi tambahan dengan fungsi khusus di dalam Pod aplikasi. Dalam hal ini, container sidecar berfungsi sebagai agen pengumpul log yang mengalirkan file log tambahan dari setiap Pod aplikasi langsung ke mesin pengumpul log. Hal ini dicapai dengan menggunakan mount lokal yang dibagikan oleh container utama dan sidecar (ditandai dengan warna merah muda pada gambar berikut).
Pengaturan Klaster Amazon EKS di Mana Setiap Pod Memiliki Collector Sidecar untuk Mengirim Log ke Sistem Logging Jarak Jauh
Keuntungan:
– Memungkinkan streaming file log individual sesuai kebutuhan masing-masing aplikasi.
Kekurangan:
– Sumber daya yang digunakan oleh sidecar terduplikasi; misalnya, jika ada 100 Pod, maka Anda memerlukan 100 sidecar, masing-masing memanfaatkan sumber daya (RAM, CPU) secara terpisah.
– Menyebabkan kebutuhan untuk konfigurasi, penyebaran, dan pemeliharaan komponen sidecar.
– Menambah jumlah koneksi terbuka ke mesin agregasi log dari puluhan atau ratusan sidecar.
Solusi B – Mengumpulkan Log di PVC
Karena PVC adalah objek yang berbasis namespace, kita dapat membuat volume terpisah untuk setiap namespace yang menyimpan semua aliran log aplikasi dalam namespace tersebut, seperti yang digambarkan pada gambar berikut. Selain itu, kita memerlukan satu collector per namespace untuk mentransfer data dari volume berbasis namespace ini ke sistem logging yang dituju. Konfigurasi ini memerlukan `accessType` “ReadWriteMany”.
Keuntungan:
– Menghilangkan kebutuhan akan container sidecar, sehingga pendekatan pengumpulan dan pengiriman log menjadi lebih terpusat.
– Mengurangi overhead sumber daya, karena hanya memerlukan satu agen log per namespace.
Kekurangan:
– Penggunaan PVC per namespace dapat menjadi mahal dan kurang efisien.
– Membutuhkan pengelolaan penyimpanan dan volume yang banyak.
Pengaturan Klaster Amazon EKS di Mana Setiap Namespace Memiliki PVC Kubernetes yang Digunakan oleh Collector Tunggal untuk Mengirim ke Sistem Logging Jarak Jauh
Solusi C – Berbagi Volume yang Dapat Diskalakan di Seluruh Namespace
Solusi ini merupakan perkembangan dari solusi sebelumnya (Solusi B), dengan memanfaatkan fitur unik dari FSx untuk ONTAP yang menghilangkan kebutuhan untuk mengelola banyak PVC per namespace.
Driver CSI ONTAP memiliki kemampuan untuk membagikan PVC di seluruh namespace (lihat dokumentasi Astra Trident ini). Ini dilakukan dengan menggunakan CustomResourceDefinition (CRD) yang disebut TridentVolumeReference, yang memungkinkan referensi ke PVC yang sudah ada. Dengan cara ini, kita dapat mengkonsolidasikan semua log aplikasi ke dalam satu volume, serta menjalankan satu collector yang memiliki akses ke volume yang sama. Dengan demikian, kita tidak hanya mengurangi jumlah volume yang perlu dikelola, tetapi juga mengurangi penggunaan sumber daya komputasi yang berlebihan di klaster kita. Karena FSx untuk ONTAP adalah solusi ONTAP yang dikelola, ia dapat digunakan dengan Amazon Elastic Kubernetes Service (Amazon EKS) Anda untuk mewujudkan arsitektur ini, seperti yang ditunjukkan pada gambar berikut.
Pengaturan Klaster Amazon EKS dengan Penyimpanan Bersama di Beberapa Namespace dan Satu Pengumpul Log yang Mengirim Log ke Sistem Logging Jarak Jauh
Keuntungan:
– Satu volume yang dapat digunakan oleh semua aplikasi, tanpa memandang namespace tempat aplikasi tersebut berjalan.
– Tidak memerlukan kontainer sidecar.
– Menghindari konsumsi sumber daya komputasi yang berlebihan, karena hanya membutuhkan satu agen logging per klaster.
– Konfigurasi volume dapat dikelola oleh pengembang platform, sehingga aplikasi hanya perlu merujuk ke volume tersebut menggunakan TridentVolumeReference.
Kekurangan:
– Konfigurasi jalur mount harus dilakukan dengan hati-hati untuk mendukung multi-tenancy, seperti penerapan konvensi penamaan jalur per namespace.
– Penggunaan objek selain yang didukung resmi oleh CSI (seperti TridentVolumeReference).
Memulai
Di bagian ini, kami akan memandu Anda melalui proses implementasi cepat untuk solusi ini.
Persyaratan
Untuk menyelesaikan bagian ini, Anda perlu memenuhi persyaratan berikut:
– AWS Command Line Interface (AWS CLI): Untuk berinteraksi dengan API AWS.
– kubectl: Untuk berkomunikasi dengan klaster EKS.
– Helm: Untuk menginstal pengontrol Trident.
– Trident CSI EKS Add-on: Untuk menggunakan Trident CSI EKS Add-on, Anda harus terlebih dahulu berlangganan add-on ini (perlu diingat bahwa berlangganan dan menggunakan add-on ini tidak dikenakan biaya tambahan, karena add-on ini tersedia secara gratis sebagai bagian dari add-on terkelola Amazon EKS). Untuk melakukannya, kunjungi tautan AWS Marketplace ini dan langganan add-on tersebut, seperti yang ditunjukkan pada gambar berikut.
Add-on Terkelola Amazon EKS untuk Driver CSI NetApp Astra Trident
Panduan Langkah-demi-Langkah
1. Menyiapkan Sistem File dan Amazon EKS menggunakan Terraform
– Versi klaster EKS: 1.29
– Sistem file FSx untuk ONTAP serta mesin virtual penyimpanan (SVM). Anda bisa mempelajari cara pembuatan sumber daya ini secara manual dalam panduan memulai FSx untuk ONTAP.
– Konfigurasikan backend Trident CSI agar terhubung dengan FSx untuk ONTAP.
2. Membuat Infrastruktur Pengumpulan Log Bersama
– Buat Persistent Volume Claim (PVC) bersama untuk log.
– Instal Fluent Bit untuk pengumpulan log, dan pastikan PVC bersama dipasang ke Pod Fluent Bit.
3. Menyebarkan Aplikasi Contoh
– Buat PVC yang merujuk ke PVC log bersama.
– Jalankan aplikasi contoh dan catat acara yang terjadi.
– Verifikasi aliran log menggunakan Fluent Bit.
Membuat Klaster EKS dan Sistem File FSx untuk ONTAP dengan Terraform
Pada bagian ini, kita akan membuat dan mengonfigurasi sistem file FSx untuk ONTAP bersama dengan Amazon EKS dan driver Trident CSI untuk penyimpanan persisten. Anda dapat menjalankan semua perintah dari mesin yang telah Anda siapkan di bagian Prerequisites. Clone repositori contoh dari GitHub dan buat sumber daya yang relevan menggunakan kode Terraform yang terdapat dalam repositori tersebut:
git clone https://github.com/aws-samples/amazon-eks-fsx-for-netapp-ontap
cd amazon-eks-fsx-for-netapp-ontap/eks-logs-fsxn/terraform
terraform init
terraform apply -auto-approve
Proses ini dapat memakan waktu antara 30 hingga 45 menit untuk diselesaikan. Setelah selesai, hasil dari perintah tersebut akan terlihat seperti berikut:
fsx-ontap-id = “<fs-id000000123456789>”
fsx-password = <GENERATED-PASSWORD>
fsx-svm-name = “ekssvm”
region = “us-east-2”
secret_arn = “arn:aws:secretsmanager:us-east-2:<ACCOUNT-ID>:secret:fsxn_password_secret-<RANDOM-STRING”
zz_update_kubeconfig_command = “aws eks update-kubeconfig –name fsx-eks-<RANDOM-STRING> –region us-east-2”
Next, copy and run the AWS CLI command from the preceding update_kubeconfig_command output and check that we can reach the cluster by running kubectl get nodes:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-1-156.us-east-2.compute.internal Ready <none> 54d v1.27.9-eks-5e0fdde
ip-10-0-2-221.us-east-2.compute.internal Ready <none> 54d v1.27.9-eks-5e0fdde
Next use, kubectl to make sure the FSxN Trident CSI driver is up and running.
kubectl get pods -n trident
NAME READY STATUS RESTARTS AGE
trident-controller-659fcc67bc-wvb96 6/6 Running 0 25s
trident-node-linux-b246t 2/2 Running 0 25s
trident-node-linux-r4kdm 2/2 Running 0 25s
trident-operator-bf899d55f-ln8t9 1/1 Running 0 33s
Verifikasi bahwa Trident CSI telah dikonfigurasi untuk menggunakan sistem file FSx untuk ONTAP
Karena konfigurasi Terraform telah membuat StorageClass dan TridentBackendConfig untuk digunakan, kita perlu memverifikasi bahwa konfigurasi tersebut berhasil. Jalankan perintah berikut dan pastikan bahwa hasilnya mirip dengan tanggapan yang Anda terima dari cluster.
kubectl get tridentbackendconfig -n trident
NAME BACKEND NAME BACKEND UUID PHASE STATUS
backend-tbc-ontap-nas tbc-ontap-nas 35b1d73a-61eb-48b8-a28c-2bc7dd677a0b Bound Success
kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 54d
trident-csi-nas csi.trident.netapp.io Delete Immediate true
Membuat infrastruktur pengumpulan log bersama
Setelah kita selesai menginstal driver Trident CSI dan menghubungkannya ke sistem file FSx untuk ONTAP, kita dapat membuat infrastruktur pengumpulan log bersama dan menghubungkannya ke PVC bersama. Untuk artikel ini, kita akan menggunakan Fluent-bit sebagai pengumpul log.
1. Buat namespace “fluent”, serta PersistentVolumeClaim yang dibagikan di seluruh namespace (fluent dan aplikasi contoh).
cd..
kubectl apply -f ./manifests/log-collection/primarypvc.yaml
Perhatikan anotasi “https://trident.netapp.io/shareToNamespace: ‘*’”, yang memberi tahu driver Trident CSI untuk membagikan PVC ini ke namespace lain.
2. Tambahkan repositori Helm untuk Fluent-bit dan pasang operator Fluent-bit.
helm repo add fluent https://fluent.github.io/helm-charts
helm upgrade –install fluent-operator –create-namespace -n fluent fluent/fluent-operator -f ./manifests/log-collection/fluentbit-values.yaml
“fluent” has been added to your repositories
NAME: fluent-operator
LAST DEPLOYED: Tue Apr 30 12:35:40 2024
NAMESPACE: fluent
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing fluent-operator
Your release is named fluent-operator
To learn more about the release, try the following:
$ helm status fluent-operator -n fluent
$ helm get fluent-operator -n fluent
Catat konfigurasi Fluent Bit dalam file `./manifests/log-collection/fluentbit-values.yaml`.
Kami mengonfigurasi Fluent Bit untuk membaca file log dari direktori `/var/log/*/*/*.log`, tempat di mana Pods aplikasi contoh kami menyimpan file log mereka. Untuk kejelasan panduan ini, output dikonfigurasi ke stdout, sehingga Anda dapat menjalankan perintah `kubectl logs` pada Pods Fluent Bit untuk melihat catatan log (alih-alih mengonfigurasi layanan sistem log seperti Amazon CloudWatch atau Amazon OpenSearch).
Menerapkan Aplikasi Contoh
Aplikasi contoh kami dideploy ke dua namespace berbeda, di mana masing-masing “app” menulis tanggal dan waktu ke dalam file yang kemudian diharapkan dapat dikumpulkan oleh Fluent Bit yang telah kami pasang sebelumnya.
Manifest aplikasi contoh dapat ditemukan di `./manifests/sample-application/`. Jika Anda melihat file-file tersebut, Anda akan menemukan bahwa pertama-tama dibuat objek bernama TridentVolumeReference, yang merujuk ke PVC yang telah dibuat sebelumnya di namespace `fluent`. Selanjutnya, objek PVC tersebut dibuat agar aplikasi contoh dapat menggunakannya. Namun, karena TridentVolumeReference telah dibuat sebelumnya, objek ini memberi tahu driver Trident CSI untuk tidak membuat PersistentVolume (PV) yang sebenarnya untuk PVC tersebut, melainkan untuk mengarah ke PV yang telah dibuat di namespace `fluent`.
- Buat volume bersama untuk aplikasi contoh dan referensi volumenya.
kubectl apply -f ./manifests/sample-application/time-writer-ns1.yaml
kubectl apply -f ./manifests/sample-application/time-writer-ns2.yaml
namespace/ns1 created
tridentvolumereference.trident.netapp.io/ns-app-pvc created
persistentvolumeclaim/ns1-app-pvc created
deployment.apps/time-writer-ns1 created
namespace/ns2 created
tridentvolumereference.trident.netapp.io/ns-app-pvc created
persistentvolumeclaim/ns2-app-pvc created
deployment.apps/time-writer-ns2 created
2. Saat ini, aplikasi kami telah berhasil menuliskan tanggal ke jalur yang telah ditentukan. Anda sekarang dapat memeriksa logs dari Pods Fluent Bit dan melihat bahwa catatan output dari kedua deployment aplikasi contoh sudah tersedia.
Perlu dicatat bahwa catatan log ini berasal dari dua Pods yang berada di namespace berbeda (lihat “ns1” dan “ns2” pada nama catatan log).
ubectl logs -n fluent –selector app.kubernetes.io/name=fluent-bit
[0] kube.var.log.ip-10-0-2-149.eu-west-1.compute.internal.time-writer-ns2-584c57cf89-5cn6v.time.log: [[1716417762.756066266, {}], {“log”=>”Wed May 22 22:42:42 UTC 2024”}]
[0] kube.var.log.ip-10-0-2-149.eu-west-1.compute.internal.time-writer-ns1-76dffcbb8-vcp45.time.log: [[1716417772.851480648, {}], {“log”=>”Wed May 22 22:42:52 UTC 2024”}]
Pembersihan
Untuk membersihkan semua sumber daya, langkah pertama adalah menghapus deployment-deployment berikut:
kubectl delete -f ./manifests/sample-application/time-writer-ns1.yaml
kubectl delete -f ./manifests/sample-application/time-writer-ns2.yaml
Setelah itu, hapus instalasi Fluent Bit dengan menjalankan perintah berikut:
helm -n fluent uninstall fluent-operator
kubectl patch -n fluent FluentBit fluent-bit -p ‘{“metadata”:{“finalizers”:[]}}’ –type=merge
kubectl delete ns fluent
Terakhir, hapus seluruh sumber daya dengan menjalankan perintah `Terraform destroy`.
cd terraform
terraform apply -auto-approve -destroy
ingin tahu lebih banyak mengenai awscloud, silahkan hubungi awscloud@ilogoindonesia.id