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…
