Artikel Lainnya

Sebagai praktisi DevOps yang berpengalaman dengan Kubernetes Native dan Managed (EKS), saya akan menjelaskan tiga ciri utama Kubernetes dan perbedaan antara Kubernetes Native dan Managed dari sudut pandang operasional.

1. Manajemen Keadaan yang Diinginkan (Desired State Management

Salah satu ciri utama Kubernetes adalah kemampuannya untuk mengelola klaster menggunakan konsep inti yang disebut "keadaan yang diinginkan" (desired state). Sesuai dengan istilahnya, keadaan yang diinginkan mengacu pada proses mendefinisikan secara eksplisit bagaimana aplikasi dan sumber daya dalam klaster harus beroperasi. Kubernetes kemudian memastikan bahwa keadaan saat ini selalu sesuai dengan keadaan yang telah ditentukan.

Konsep ini merupakan salah satu prinsip inti Kubernetes dalam mengelola dan memelihara aplikasi serta infrastruktur secara otomatis. Sebagai contoh, jika salah satu proses yang sedang berjalan tiba-tiba berhenti, Kubernetes akan secara otomatis memulai ulang proses tersebut tanpa memerlukan intervensi pengguna. Dengan demikian, Kubernetes mampu menjaga keadaan yang diinginkan tetap konsisten, memberikan kemampuan yang sangat baik dalam menangani gangguan atau kegagalan.

Saya pernah menjadi administrator Solaris pada sistem Unix. Saat terjadi gangguan, saya sering menerima telepon dari tim pemantauan, bahkan di tengah malam, untuk masuk ke konsol dan secara manual menjalankan ulang proses yang bermasalah. Namun, kini Kubernetes mengambil alih tugas tersebut. Waktu tidur saya di malam hari menjadi jauh lebih nyenyak.

Manajemen keadaan yang diinginkan adalah konsep yang sering digunakan dalam budaya DevOps dan lingkungan cloud-native. Dengan pendekatan ini, efisiensi dan keandalan dalam pengelolaan sistem dapat meningkat secara drastis, karena proses-proses yang sebelumnya membutuhkan intervensi manual kini dapat ditangani secara otomatis oleh Kubernetes.

Mari kita cari tahu dengan sebuah contoh. Jalankan 'Deployment' NGINX seperti yang ditunjukkan di bawah ini. Deployment adalah sumber daya Kubernetes untuk mengelola dan men-deploy instance aplikasi. Perintah kubectl digunakan di bawah ini. Kami akan membahas penggunaan secara detail, termasuk cara menggunakan perintah kubectl, di seri mendatang. Untuk saat ini, ada baiknya jika kita fokus pada konsep inti saja.

Perintah tersebut akan menjalankan pod NGINX. Anda dapat memeriksa status terkini pod dengan menggunakan perintah k get pod. Pod adalah unit terkecil yang digunakan dalam Kubernetes untuk proses deployment, yang dapat berisi satu atau lebih container. Pod berfungsi sebagai host logis untuk container, di mana container dalam pod yang sama akan berbagi namespace jaringan, alamat IP, rentang port, serta penyimpanan yang sama

Kita akan membuat situasi gangguan secara sengaja. Untuk memantau perubahan status secara real-time, bagi jendela terminal menjadi dua. Pada jendela atas, hapus pod, dan pada jendela bawah, pantau perubahan status pod secara real-time menggunakan opsi -w (watch). Perintah untuk menghapus pod adalah k delete pod.

Pada jendela bawah, Anda dapat melihat bahwa pod yang dihapus secara otomatis dibuat kembali.

Pod dengan nama ‘nginx-748c667d99-d6bb5’ sedang dalam proses terminasi dan pod baru dengan nama ‘nginx-748c667d99-jmb7z’ sedang berjalan (Running). Kubernetes telah mengonfirmasi bahwa pod sebelumnya telah dihentikan dan secara otomatis menjalankan pod baru. Dengan kata lain, Kubernetes mendeteksi bahwa proses telah berhenti dan secara otomatis mengembalikan ke ‘status yang diinginkan’ semula. Sebagai catatan, nama ‘nginx-748c667d99-d6bb5’ dihasilkan oleh Kubernetes Deployment Resource yang secara otomatis menambahkan nilai hash acak ke nama deployment nginx.

BACA JUGA : Catatan Teknis Jennifer: Panduan Praktis Menguasai Kubernetes

Kita telah menjalankan pod dengan perintah kubectl create deployment pada awalnya. Dengan demikian, Kubernetes Deployment mendefinisikan ‘status yang diinginkan’ sebagai keadaan di mana pod sedang berjalan. Oleh karena itu, meskipun kita menghapus pod secara sengaja (atau karena gangguan sistem yang tidak terduga), Kubernetes akan secara otomatis menjaga agar status yang diinginkan, yaitu satu pod yang sedang berjalan, tetap terjaga dengan memulai kembali pod. Di dalamnya, Deployment Resource menggunakan pengontrol bernama ReplicaSet Controller untuk selalu menjaga agar tetap dalam status yang diinginkan. Jika jumlah pod dideklarasikan sebanyak 3, maka akan selalu ada 3 pod yang dijaga melalui ReplicaSet Controller. Dengan cara yang serupa, Kubernetes menggunakan berbagai pengontrol untuk selalu mempertahankan status yang diinginkan. Penanggung jawab mendefinisikan terlebih dahulu ‘status yang diinginkan’, dan Kubernetes secara otomatis menjaga status tersebut dengan menggunakan berbagai sumber daya ‘pengontrol’. Ini memungkinkan pemulihan otomatis (self-healing) dan memfasilitasi komunikasi yang lancar antara pengembang dan operator.

2. Pengelolaan Sumber Daya Menggunakan Kode

Semua sumber daya Kubernetes dikelola dengan kode. Misalnya, ketika menginstal aplikasi, pada lingkungan VM sebelumnya, kita menggunakan perintah yum seperti di bawah ini.

Kami berusaha untuk mencapai hasil yang diinginkan dengan menjalankan langkah-langkah secara bertahap menggunakan perintah. Khususnya, perintah tertentu harus dijalankan secara berurutan agar berfungsi dengan baik. Namun, seiring berjalannya waktu, status sistem berubah, membuatnya sangat sulit untuk melacak dan mengelola perubahan. Seringkali, pengelolaan dilakukan secara manual, tetapi tidak ada jaminan bahwa status sistem saat ini sesuai dengan dokumen manual yang ada (up-to-date).

Lingkungan Kubernetes juga dapat menggunakan perintah kubectl create deployment seperti pada contoh sebelumnya, tetapi hampir semua sumber daya dibuat dengan menggunakan file kode seperti di bawah ini.

Mengelola sumber daya Kubernetes dengan menggunakan kode, bukan perintah, berarti menggunakan pendekatan manajemen yang deklaratif. Kubernetes adalah platform yang secara kuat mengadopsi pendekatan deklaratif, di mana ‘bentuk deklaratif’ mengacu pada metode yang secara eksplisit mendefinisikan status akhir dan mengarahkan sistem untuk mencapai status tersebut. Dalam pendekatan deklaratif, kita tidak secara langsung menyebutkan proses atau langkah-langkah untuk melakukan tugas, melainkan mendefinisikan status akhir yang diinginkan, sehingga sistem diarahkan untuk mencapai hasil tersebut.

Dengan mendefinisikan sumber daya menggunakan kode, kita dapat secara jelas menentukan sumber daya apa yang diperlukan dan pengaturan apa yang harus ada. Ini memastikan bahwa sumber daya di dalam kluster dibuat dan dikonfigurasi secara konsisten, serta mencegah kesalahan konfigurasi yang tidak terduga atau konflik, sehingga meningkatkan stabilitas sistem. Sebelum menerapkan sumber daya secara nyata, kita dapat mengimplementasikannya dalam kode dan melakukan tinjauan bersama rekan (PR Review) untuk mencegah gangguan yang mungkin terjadi selama proses kerja. Selain itu, penggunaan kode yang sama sangat berguna untuk mereproduksi infrastruktur. Dengan menjalankan kode yang sama di lingkungan mana pun, sumber daya yang sama akan dikerahkan, sehingga menjaga konsistensi lingkungan di berbagai tahap seperti pengembangan, pengujian, dan produksi. Selain itu, melalui sistem kontrol versi (misalnya, Git), kita dapat melacak dan mengelola perubahan. Ini memudahkan untuk melacak riwayat perubahan dan berkolaborasi dengan rekan kerja, serta mengoordinasikan perubahan yang dilakukan.

Berbeda dengan pengembang, operator mungkin merasa keberatan untuk menggunakan kode. Namun, kode yang digunakan dalam Kubernetes tidak rumit seperti bahasa pemrograman umum, sehingga tidak terlalu membebani untuk dipelajari. Jika Anda hanya memahami sintaks dasar file YAML, Anda tidak akan mengalami kesulitan dalam penggunaannya. Selain itu, dengan menggunakan alat seperti VSCode, Anda dapat memanfaatkan fitur auto-complete dan pemeriksaan sintaks otomatis, yang membuatnya lebih nyaman.

3. Konfigurasi Ketersediaan Tinggi (Pet vs Cattle)

Pertama, mari kita memahami konsep Hewan Peliharaan dan Sapi (Pet vs Cattle). Hewan peliharaan dan sapi adalah metafora untuk dua pendekatan dalam pengelolaan infrastruktur.

Hewan peliharaan memerlukan perhatian dan pengelolaan yang individual dan khusus. Setiap hewan peliharaan diberikan nama dan mendapatkan perhatian khusus. Di sisi lain, sapi tidak memiliki nama yang unik; mereka digunakan dengan label atau nomor umum. Dalam contoh sebelumnya, nama pod (nginx-748c667d99-d6bb5) menggunakan nilai hash acak. Pendekatan ini membutuhkan kemampuan untuk dikelola secara besar-besaran dan memberikan kemampuan untuk diubah dan fleksibilitas.

Kubernetes, yang merupakan alat orkestra berbasis kontainer, mengadopsi pendekatan pengelolaan Sapi (Cattle). Kubernetes mengelola aplikasi yang terkontainerisasi dengan cara yang terstandarisasi, mengotomatisasi infrastruktur, dan membangunnya agar dapat diskalakan. Dengan demikian, Kubernetes dapat secara efisien melakukan tugas seperti penyebaran aplikasi, penskalaan, pembaruan bergulir, dan pemulihan otomatis.

Sebagai contoh, ketika Kubernetes menghubungkan aplikasi (web server) dengan aplikasi (database server), ia menggunakan sumber daya layanan (Service) dengan metode nama domain, bukan metode IP yang digunakan dalam lingkungan VM sebelumnya. Metode IP yang sebelumnya digunakan mengandalkan nilai tetap (Static); jika server database berubah, alamat IP-nya juga berubah, sehingga alamat IP yang ditetapkan dalam variabel lingkungan web server juga harus diubah. Namun, Kubernetes menggunakan metode nama domain yang dinamis (Dynamic), sehingga jika alamat IP berubah, koneksi akan otomatis diarahkan ke alamat IP yang baru.

Dengan cara yang serupa, Kubernetes mengasumsikan bahwa gangguan dapat terjadi kapan saja dan menyediakan berbagai fitur seperti load balancer, penjadwalan lanjutan, dan Readiness/Liveness Probe untuk memastikan pemulihan otomatis dan kelangsungan layanan bahkan jika terjadi gangguan.

Berikut adalah contoh sumber daya layanan (Service) Kubernetes.

Ketika menghubungkan antar pod, digunakan layanan yang bernama nginx. Layanan ini secara otomatis menghasilkan 'endpoints' dan akan memperbarui IP yang terpetakan ke layanan tersebut jika alamat IP pod berubah. Oleh karena itu, meskipun alamat IP berubah, nama layanan tetap tidak berubah, sehingga layanan nginx yang ada dapat terus digunakan untuk koneksi antar pod dengan nama yang sama.

4. Perbandingan Solusi Kubernetes Native vs Managed

Di lingkungan on-premise, penggunaan Kubernetes dapat dilakukan dengan menggunakan Kubernetes native versi resmi atau solusi dari vendor seperti OpenShift dan Tanzu. Untuk lingkungan cloud, biasanya digunakan Kubernetes terkelola yang disediakan oleh masing-masing CSP (Cloud Service Provider), seperti EKS (Amazon Elastic Kubernetes Service), AKS (Azure Kubernetes Service), dan GKE (Google Kubernetes Engine).

Native Kubernetes juga sering disebut sebagai Vanilla Kubernetes. Istilah "Vanilla Kubernetes" merujuk pada versi resmi Kubernetes yang dirilis secara resmi. "Vanilla" berarti sesuatu yang umum atau dalam keadaan aslinya, dan dalam konteks ini, istilah tersebut digunakan untuk membedakan versi resmi Kubernetes. Kubernetes sendiri adalah proyek open-source yang dikelola oleh CNCF (Cloud Native Computing Foundation). CNCF bertanggung jawab atas pengembangan dan pemeliharaan Kubernetes, serta menyediakan versi resmi dari Kubernetes. Menyebut versi resmi ini sebagai Vanilla Kubernetes mengindikasikan bahwa versi ini mencakup komponen inti dan fitur dasar Kubernetes, serta mencerminkan keadaan asli seperti yang disediakan oleh CNCF.

Perbedaan utama antara Native Kubernetes dan Managed Kubernetes terletak pada aspek pengelolaan. Native Kubernetes mengharuskan pengguna untuk melakukan instalasi, upgrade, dan pengelolaan control plane secara mandiri. Sebaliknya, Managed Kubernetes menyediakan panduan instalasi dan secara langsung mengelola control plane untuk pengguna. Selain itu, Managed Kubernetes biasanya terintegrasi dengan sumber daya lain milik penyedia layanan, sehingga konfigurasi penyimpanan (storage) dan jaringan (network) dalam lingkungan Kubernetes menjadi lebih mudah dibandingkan dengan lingkungan Native Kubernetes. Integrasi ini memberikan efisiensi dan kemudahan dalam mengelola infrastruktur Kubernetes.

Namun, dari sudut pandang deployment aplikasi dan pengoperasian layanan secara stabil, kedua layanan ini—Native Kubernetes dan Managed Kubernetes—tidak memiliki perbedaan yang signifikan. Keduanya berbasis sistem Kubernetes, sehingga pemahaman mendalam tentang Kubernetes tetap diperlukan. Selain itu, kemampuan untuk mengintegrasikan berbagai perangkat lunak open-source lainnya, seperti Helm, ArgoCD, dan Ingress, sangat penting untuk memastikan sistem berjalan dengan optimal. Menurut pendapat pribadi, sekitar 80% hingga 90% tugas harian yang dilakukan dalam kedua layanan ini adalah serupa. Menggunakan layanan Managed Kubernetes tidak secara otomatis mengurangi beban kerja atau secara drastis menurunkan tingkat kesulitan. Pemahaman dan keterampilan teknis tetap menjadi kunci keberhasilan dalam mengelola lingkungan Kubernetes, terlepas dari jenis layanan yang digunakan.

Sebagai contoh sederhana, dalam Native Kubernetes, Anda dapat melihat berbagai pod yang berjalan di dalam namespace kube-system. Namespace ini digunakan untuk komponen internal Kubernetes, seperti kube-apiserver, kube-scheduler, kube-controller-manager, dan lainnya yang diperlukan untuk menjalankan cluster Kubernetes.

Misalnya, dalam Native Kubernetes, Anda dapat menemukan berbagai pod yang membentuk control plane, seperti etcd, controller manager, scheduler, dan api-server, di dalam namespace kube-system. Pod-pod ini merupakan komponen inti yang bertanggung jawab untuk mengelola dan mengoordinasikan operasi cluster Kubernetes.

Namun, dalam EKS (Amazon Elastic Kubernetes Service), control plane dikelola langsung oleh AWS, sehingga Anda tidak dapat melihat pod seperti etcd, controller manager, scheduler, atau api-server. Saat memeriksa daftar pod yang berjalan di cluster, daftar tersebut cenderung lebih sederhana, karena hanya mencakup pod aplikasi pengguna dan beberapa komponen tambahan yang dikelola di tingkat node worker.

Namun, selain pengelolaan control plane, tugas lainnya—seperti mengelola berbagai open-source tools—tetap sama, baik dalam Native Kubernetes maupun Managed Kubernetes. Untuk operasional Kubernetes, penggunaan berbagai proyek open-source sangat penting. Daftar lengkap proyek-proyek open-source yang mendukung ekosistem Kubernetes dapat ditemukan di situs CNCF (Cloud Native Computing Foundation). CNCF menyediakan panduan dan sumber daya untuk membantu mengintegrasikan alat-alat ini ke dalam lingkungan Kubernetes Anda.

 

Tujuan Serial Blog EKS: Menyederhanakan Adopsi Kubernetes untuk Perusahaan

Masalah utama yang dihadapi perusahaan modern adalah memenuhi kebutuhan pelanggan yang beragam dengan cepat sambil menjaga stabilitas operasional. Respons cepat yang selaras dengan operasi stabil menjadi tantangan yang harus diatasi. Di sinilah Kubernetes, termasuk dalam konteks Catatan Teknis Jennifer, menjadi solusi orkestrasi container yang sangat efektif.

Kubernetes telah diadopsi oleh hampir semua perusahaan, setidaknya untuk pengujian. Dalam proyek baru, Kubernetes sering dianggap sebagai standar atau solusi "de facto." Namun, hambatan awal yang tinggi sering membuat banyak perusahaan ragu untuk mengadopsinya secara penuh. Banyak organisasi mengeluarkan biaya besar untuk solusi eksternal atau mengalihdayakan proyek mereka. Padahal, pengelolaan Kubernetes secara internal lebih ideal karena platform ini terus berkembang dengan berbagai opsi konfigurasi yang dapat disesuaikan dengan aplikasi perusahaan.

Mengapa Serial Blog Ini Penting?

Serial blog ini dirancang untuk memberikan panduan teknis praktis, termasuk panduan Catatan Teknis Jennifer, bagi perusahaan yang ingin mengadopsi dan mengoperasikan Amazon EKS (Elastic Kubernetes Service) atau Kubernetes asli. Dengan pendekatan berbasis praktik langsung, serial ini menawarkan solusi nyata yang sesuai untuk kebutuhan operasional sehari-hari.

Pendekatan langsung ini dipilih karena belajar Kubernetes melalui teori saja bisa memakan waktu lama. Seperti belajar matematika dasar, memulai dengan praktik sederhana lebih efektif untuk membangun pemahaman. Serial ini bertujuan untuk membawa pembaca dari pemula hingga mampu mengelola sistem Kubernetes yang andal dalam waktu singkat.

Serial ini juga dirancang seperti simulasi pekerjaan nyata. Pembaca diajak berperan sebagai pengelola Kubernetes di sebuah perusahaan yang bertugas membangun sistem baru. Dengan kombinasi pengalaman DevOps, kiat praktis, dan fokus pada efisiensi, serial ini membantu perusahaan mencapai layanan yang tinggi, efisien, dan hemat biaya.

Apa yang Akan Anda Pelajari?

Selain Kubernetes, pembaca akan belajar ekosistem pendukung seperti:

  • CI/CD (Continuous Integration/Continuous Delivery)
  • Pemantauan (Monitoring)
  • Alat tambahan seperti Helm, ArgoCD, Ingress, dan CSI Driver

Semua kode sumber yang diperlukan akan tersedia di GitHub, sehingga Anda dapat membangun kluster Kubernetes siap pakai dalam waktu sehari.

Pembaca Sasaran dan Persiapan Awal

Serial blog ini cocok untuk:

  • Pembaca yang memahami dasar-dasar Linux dan jaringan.
  • Tim kecil (1-2 orang) di startup, UKM, atau divisi R&D perusahaan besar.
  • Individu yang sudah memiliki pengetahuan dasar tentang Kubernetes, termasuk Catatan Teknis Jennifer.

Persiapan yang Dibutuhkan

  1. Akun AWS
    Anda perlu memiliki kredensial AWS untuk mengakses layanan seperti Amazon EKS.

  2. Lingkungan Pengembangan Lokal
    Pastikan Anda memiliki alat berikut:

    • Visual Studio Code untuk coding.
    • WSL (Windows Subsystem for Linux) dan Windows Terminal (bagi pengguna Windows).
    • iTerm2 untuk pengguna Mac.

Dengan mempersiapkan semua ini, Anda akan siap untuk mengikuti panduan praktik langsung yang ditawarkan serial blog ini.

BACA Juga : APM JENNIFER Kubernetes Versi Terbaru: Dukungan Lengkap (K8s)

Hari ini, saya akan memperkenalkan Aplikasi Insight Jennifer yang baru saja dikembangkan oleh Jennifer Soft. Jika dashboard Jennifer yang ada saat ini fokus pada pemantauan kinerja aplikasi di tingkat instansi individual, maka dashboard Aplikasi Insight memantau kinerja aplikasi dari perspektif domain (pekerjaan) yang dipilih, tanpa batasan jumlah instansi yang ada.

Fitur Utama Aplikasi Insight Jennifer

Dashboard Aplikasi Insight mencakup beberapa grafik yang pertama kali diperkenalkan oleh Jennifer. Dashboard ini dirancang untuk dimulai dengan pemahaman masalah secara komprehensif, kemudian dilanjutkan dengan analisis yang lebih mendetail.

Baca Juga : APM JENNIFER Kubernetes Versi Terbaru: Dukungan Lengkap (K8s)

Pengertian Masalah

Ketika jumlah instansi meningkat akibat penyiaran beban mendadak melalui auto-scaling, mungkin sulit untuk memahami status masing-masing instansi hanya dengan grafik layanan aktif yang tersedia.

Pada contoh yang diketahui di bawah ini, jumlah instansi yang masih dapat. Namun, jika terjadi penundaan secara bersamaan di beberapa instansi, memeriksa informasi detail layanan aktif untuk masing-masing instansi dapat menjadi tugas yang merepotkan.

Jika lebih penting untuk memahami masalah dari perspektif keseluruhan layanan daripada hanya mengetahui status masing-masing instansi, maka merangkum dan memvisualisasikan keseluruhan layanan aktif akan lebih efektif.

Selanjutnya, mari kita bahas grafik " Aplikasi Aktif  " yang dikembangkan oleh Jennifer untuk pemantauan layanan aktif dengan cara yang baru.

Pada semua grafik di dashboard Jennifer, warna merah digunakan untuk menunjukkan gangguan risiko atau penurunan kinerja. Begitu juga pada grafik ini, pemantauan harus fokus pada area yang berwarna merah. Saya akan menjelaskan lebih detail.

Grafik di atas mengatur waktu respon rata-rata dari ringkasan layanan aktif pada sumbu X dan jumlah total panggilan pada sumbu Y, dengan setiap aplikasi yang disampaikan oleh lingkaran.

Setiap lingkaran yang mewakili aplikasi memiliki elemen representasi sebagai berikut:

Jumlah Panggilan Lambat: Merujuk pada jumlah panggilan di mana waktu respon rata-rata aplikasi termasuk dalam kategori terakhir dari total 4 kategori pada layanan aktif.

  • Biru: Status normal
  • Merah: Ketika waktu respon rata-rata aplikasi termasuk dalam kategori terakhir dari layanan aktif (di sini, lebih dari 8 detik).
  • Jika salah satu layanan aktif yang menyusun informasi ringkasan aplikasi termasuk dalam kategori terakhir.
  • Ukuran: Meningkat sebanding dengan jumlah panggilan yang lambat.

Dengan menggunakan kombinasi warna dan ukuran ini, layanan aktif yang lambat yang mungkin tidak diwakili oleh rata-rata dapat ditampilkan dengan jelas. Selain itu, pengguna dapat dengan cepat menemukan aplikasi yang tertunda hanya dengan mengklik atau menyeret lingkaran merah yang terlihat pada grafik aplikasi aktif.

Cerita kedua tentang metode pemantauan kinerja aplikasi di lingkungan cloud Jennifer akan dilanjutkan di bagian berikutnya.

 

APM JENNIFER Kubernetes

EVOLUSI KE LINGKUNGAN KONTAINER

APM JENNIFER Kubernetes Teknologi virtualisasi container membawa virtualisasi ke tingkat yang lebih tinggi dibandingkan VM (Virtual Machine) yang memvirtualisasi mesin fisik. Teknologi ini kini berhasil diterapkan dalam lingkungan operasi, terutama bersama dengan aktivasi layanan mikro (microservice). Namun, lapisan kontainer hanya memberikan izin antara lingkungan eksekusi dan lingkungan operasi. Dari perspektif operasional langsung, teknologi ini lebih cocok untuk layanan berskala kecil. Namun, dalam layanan pengelolaan berskala besar di dunia nyata, sering kali muncul berbagai tantangan.

Sebagai contoh, seperti ditunjukkan pada "Gambar 1," ketika operator harus menangani banyak container sekaligus, kemungkinan terjadinya kesalahan dalam pengelolaan menjadi sangat tinggi.

APM JENNIFER Kubernetes

 

Untuk kelemahan mengatasi hal ini, kini tersedia alat orkestrasi yang dapat mengganggu pengelolaan wadah. Dengan demikian, seperti yang ditunjukkan pada "Gambar 2," operator sistem dapat menggunakan alat orkestrasi untuk mengelola banyak container sekaligus. Hal ini memungkinkan penerapan teknologi wadah untuk layanan berukuran besar menjadi lebih mudah dan efisien.

APM JENNIFER Kubernetes

Perusahaan yang menyediakan layanan cloud kini bergerak cepat untuk mengadopsi perubahan ini ke dalam lini produk mereka. Mengapa? Meskipun alat orkestrasi tersedia, pada akhirnya infrastruktur yang dapat mendukung teknologi wadah tetap diperlukan. Penyedia layanan cloud dapat menghadirkan layanan container yang sepenuhnya terabstraksi dengan menempatkan layanan Kubernetes (k8s) di atas infrastruktur virtual yang sudah ada. Pendekatan ini sejalan dengan upaya "pengurangan biaya pengelolaan infrastruktur" yang menjadi fokus utama semua layanan cloud.

Saat ini, mencerminkan tren tersebut, banyak layanan berbasis container yang telah beroperasi, seperti Azure Kubernetes Service (AKS) , Google Kubernetes Engine (GKE) , dan Amazon Elastic Kubernetes Service (EKS) .

APM JENNIFER Kubernetes

 

APM JENNIFER Kubernetes untuk k8s

Baca Juga : APM JENNIFER Kubernetes Segera Hadir Versi Terbaru (K8s)

Catatan:
Artikel ini menggunakan contoh lingkungan AKS (Azure Kubernetes Service). Namun, dari perspektif produk JENNIFER, intinya mendukung k8s , sehingga metode yang sama dapat diterapkan di semua lingkungan lainnya.

Selain itu, meskipun terdapat berbagai teknologi container, artikel ini akan fokus menjelaskan tentang Docker .

Secara prinsip, agen JENNIFER mendukung k8s dengan cara yang sama seperti mendukung lingkungan container lainnya. Pada dasarnya, kita perlu memberi tahu wadah tentang eksekusi file dan pengaturan variabel lingkungan. Sebelumnya, agen JENNIFER diaktifkan di lingkungan Docker melalui dua cara berikut:

  1. Tentukan volume dan variabel lingkungan untuk file biner agen.

APM JENNIFER Kubernetes

 2. Bangun dengan menyertakan file biner agen dan variabel lingkungan di dalam container Dockerfile yang sudah ada.

APM JENNIFER Kubernetes

Alat orkestrasi Kubernetes (k8s) melibatkan distribusi unit pod dengan membungkus container pada satu tingkat. Oleh karena itu, dukungan agen untuk k8s terbatas pada dua prinsip di atas. Dalam praktiknya, metode kedua dapat digunakan sebagaimana adanya di lingkungan k8s.

Namun berbeda dengan struktur yang ada yang langsung terhubung ke container, karakteristik k8s memungkinkan volume terhubung ke pod, yang dapat menjadi grup container. Oleh karena itu, koneksi antara file biner agen dan container dilakukan melalui PV (Persistent Volume) yang diatur oleh k8s.

Setelah volume yang berisi file biner agen disiapkan, pengguna hanya perlu menambahkan volume yang terhubung ke PV dan pengaturan envdalam file YAML untuk distribusi layanan selanjutnya.

APM JENNIFER Kubernetes

 

Setelah itu, pengguna dapat menggunakan perintah kubectl apply -f <nama_file>.yamluntuk menerapkan file YAML dan kemudian memeriksa apakah proses pemantauan berfungsi dengan baik.

APM JENNIFER Kubernetes

Sebagai kelebihan dari platform cloud, pengguna dapat dengan bebas menambahkan atau menghapus node walker infrastruktur abstrak ke k8s. Pada saat yang sama, pengguna dapat secara manual atau otomatis menskalakan jumlah instansi pod di aplikasi. K8s mendukung Horizontal Pod Autoscaling (selanjutnya, hpa) untuk penskalaan otomatis, dan pengguna juga dapat menggunakan perintah yang sama di AKS. Misalnya, jika satu instansi diatur dan dijalankan dalam distribusi "demo.yaml" di atas, dan maksimal 3 unit dijalankan tergantung pada beban, maka dapat dijalankan sebagai berikut.

Seperti yang terlihat di sini, meskipun tanpa beban, 1 pod dijalankan, tetapi tidak ada pod yang muncul di konsol Jennifer. Mengapa demikian? Karena saja bisa saja ada perbedaan antara pod yang diunggah dan permintaan yang dikirimkan ke aplikasi internal.

Tentu saja, jika dilakukan uji beban dalam kondisi ini,

3 pod akan diunggah secara otomatis, dan pengguna dapat memeriksa hasilnya di konsol Jennifer.

Jennifer kini menyediakan layanan chatbot secara online

Meskipun Jennifer ditawarkan sebagai perangkat lunak instalasi (on-premise), Jennifer Chatbot disediakan sebagai layanan online. Hal ini dilakukan karena beberapa alasan berikut:

  1. Kebutuhan Sumber Daya Tambahan: Untuk menyediakan model bahasa besar (LLM) dalam bentuk instalasi, pelanggan perlu menambahkan server di lingkungan mereka untuk mendukung proses pembelajaran. Ini dapat menjadi beban tambahan.
  2. Pembaruan Berkelanjutan: Chatbot membutuhkan pembaruan rutin untuk terus meningkatkan konten dan fungsinya. Dengan layanan online, pembaruan dapat dilakukan dengan lebih mudah dan cepat.
  3. Akses Mudah di Lingkungan Kerja: Chatbot dapat dengan mudah diakses melalui perangkat mobile, sehingga lebih fleksibel untuk digunakan dalam berbagai lingkungan kerja pelanggan.

BACA JUGA : Jennifer Replay: Inovasi Revolusioner untuk Pemantauan Real-Time

Mari kita mulai dengan melihat fungsi dasar Jennifer Chatbot.

Fungsi utama dari chatbot adalah menjawab pertanyaan yang diberikan, keunggulan Jennifer Chatbot adalah kemampuannya memberikan tautan bantuan terkait di bagian bawah setiap jawabannya.

Fitur ini memungkinkan pengguna untuk menilai apakah jawaban yang diberikan sudah memadai. Jika pengguna merasa jawabannya kurang lengkap, mereka dapat memilih tautan tersebut untuk mendapatkan informasi tambahan.

Berikut adalah contoh interaksi pengguna :

  1. Menampilkan Pertanyaan Pengguna : Chatbot akan menampilkan pertanyaan yang diketik oleh pengguna
  2. Membuat Jawaban dari AI : Sistem AI akan merangkum informasi dari bantuan terkait untuk menghasilkan jawaban.
  3. Menyediakan Tautan Referensi : Jawaban yang diberikan dilengkapi dengan tautan ke sumber bantuan terkait, sehingga pengguna dapat memeriksa referensinya.
  4. Kemampuan Bertanya Ulang : Jika pengguna masih memiliki pertanyaan tambahan setelah membaca jawaban, mereka dapat langsung menanyakannya kembali.

Keunggulan?

Jennifer Chatbot dirancang untuk menjawab dalam berbagai bahasa, seperti Korea, Inggris, dan Jepang, dengan mempertimbangkan tingkat keahlian pengguna terhadap produk. Mulai dari insinyur berpengalaman hingga pengguna baru Jennifer, semuanya dapat memanfaatkan layanan ini.

  • Solusi berbasis AI yang terintegrasi.
  • Didukung oleh JenniferSoft untuk meningkatkan efisiensi pengelolaan aplikasi.
  • Antarmuka yang mudah digunakan dan mendukung multibahasa.

Untuk mendukung fitur multibahasa ini, sistem chatbot dilengkapi dengan fungsi login terpisah.

Dukungan Mobile

Jennifer Chatbot tersedia dalam versi web yang dioptimalkan untuk perangkat mobile.

 

Bagaimana jika Anda dapat kembali ke saat kecacatan itu terjadi?

Bayangkan jika Anda bisa kembali ke saat di mana masalah sistem terjadi. Dengan Jennifer Replay , hal itu kini menjadi kenyataan. Fungsi inovatif ini memungkinkan Anda memutar ulang waktu secara real-time, menghadirkan solusi analisis sistem yang mendalam dan efisien.

Apa itu Jennifer Replay?

Jennifer adalah solusi Application Performance Monitoring (APM) yang dirancang untuk mendeteksi dan menganalisis masalah sistem dengan cepat dan akurat. Dengan dasbor yang intuitif, setiap perusahaan dapat menyesuaikan pengaturan sesuai dengan kebutuhan mereka. Namun, tantangan utama adalah menyatukan sistem secara real-time, terutama di luar jam kerja. Inilah mengapa fitur dashboard replay menjadi sangat penting.

BACA JUGA : APM JENNIFER KUBERNETES K8s Terbaru

Fitur Dashboard Replay memungkinkan Anda untuk:

  • Mengamati kembali status pemantauan pada waktu tertentu.
  • Menemukan penyebab masalah seperti menggunakan kotak hitam kendaraan.
  • Menganalisis data historis untuk menemukan pola dan solusi mendalam.

Fitur Utama Jennifer Replay

1. Pemutaran Ulang Event

Integrasi pemutaran ulang dasbor melalui jendela notifikasi

Integrasikan pemutaran ulang dasbor dalam analisis EVENT

fitur ini memungkinkan Anda mereproduksi titik waktu ketika masalah terjadi. Jennifer membuat event log untuk mempermudah mengidentifikasi waktu spesifik yang menyebabkan penurunan kinerja. Dengan dashboard replay, pengguna dapat meninjau kembali kondisi saat itu, memberikan wawasan mendalam tentang apa yang sebenarnya terjadi.

2. Kontrol Pemutaran yang Mudah

Seperti memutar video, dashboard Jennifer dilengkapi dengan imajinasi untuk:

  1. Putar tombol start/stop, mundur, maju cepat
  2. Kecepatan pemutaran (default, 2x, 3x, 4x)
  3. Bilah kontrol pemutaran (dapat diseret)
  4. Menampilkan waktu pemutaran saat ini/total
  5. Kapan peristiwa itu terjadi (warna berbeda tergantung tingkat keparahan peristiwa)

3. Reproduksi Kegagalan Sistem

 

 

Ketika terjadi kegagalan atau kebuntuan (deadlock), Anda dapat:

  • Mengamati peningkatan waktu respon secara signifikan.
  • Menganalisis akar masalah, misalnya pada database seperti PostgreSQL.
  • Membandingkan pola perubahan sebelum dan sesudah kejadian.

4. Pemutaran Ulang Transaksi dengan ERROR

Jennifer memungkinkan reproduksi kesalahan pada tingkat transaksi. Dengan replay, pengguna dapat melihat situasi keseluruhan sebelum dan setelah transaksi masalah terjadi, memberikan pemahaman yang lebih komprehensif tentang pola dan perubahan sistem.

Keunggulan Jennifer Replay

  1. Penyimpanan Data Detik per Detik
    Jennifer mencatat setiap momen sistem tanpa ada yang terlewatkan, memungkinkan pemantauan real-time yang sesungguhnya.

  2. Reproduksi Akurat Titik Kegagalan
    Dashboard replay membawa Anda kembali ke momen masalah yang terjadi, memberikan tampilan yang jelas seperti menyaksikan kejadian secara langsung.

  3. Analisis Intuitif
    Anda dapat menganalisis data langsung dari dasbor tanpa memerlukan alat tambahan. Setiap masalah dapat diidentifikasi secara akurat dan cepat.

Mengapa Memilih Jennifer APM?

Fitur Jennifer Replay adalah jawaban atas tantangan sistem modern yang kompleks. Dengan kemampuan untuk memutar ulang waktu, solusi ini membantu perusahaan memahami masalah secara komprehensif dan memperbaikinya dengan cepat.

Coba Jennifer Replay sekarang dan bawa kemampuan pemantauan Anda ke tingkat yang lebih tinggi!

Kebijakan Privasi

Website APM Geeks dimiliki oleh PT Sindigilive Teknologi Kreatif, yang akan menjadi pengontrol atas data pribadi Anda.

Kami telah mengadopsi Kebijakan Privasi ini untuk menjelaskan bagaimana kami memproses informasi yang dikumpulkan oleh APM Geeks, yang juga menjelaskan alasan mengapa kami perlu mengumpulkan data pribadi tertentu tentang Anda. Oleh karena itu, Anda harus membaca Kebijakan Privasi ini sebelum menggunakan website APM Geeks.

Kami menjaga data pribadi Anda dan berjanji untuk menjamin kerahasiaan dan keamanannya.

Informasi pribadi yang kami kumpulkan:

Saat Anda mengunjungi APM Geeks, kami secara otomatis mengumpulkan informasi tertentu mengenai perangkat Anda, termasuk informasi tentang browser web, alamat IP, zona waktu, dan sejumlah cookie yang terinstal di perangkat Anda. Selain itu, selama Anda menjelajahi Website, kami mengumpulkan informasi tentang setiap halaman web atau produk yang Anda lihat, website atau istilah pencarian apa yang mengarahkan Anda ke Website, dan cara Anda berinteraksi dengan Website. Kami menyebut informasi yang dikumpulkan secara otomatis ini sebagai "Informasi Perangkat". Kemudian, kami mungkin akan mengumpulkan data pribadi yang Anda berikan kepada kami (termasuk tetapi tidak terbatas pada, Nama, Nama belakang, Alamat, informasi pembayaran, dll.) selama pendaftaran untuk dapat memenuhi perjanjian.

Mengapa kami memproses data Anda?

Menjaga data pelanggan agar tetap aman adalah prioritas utama kami. Oleh karena itu, kami hanya dapat memproses sejumlah kecil data pengguna, sebanyak yang benar-benar diperlukan untuk menjalankan website. Informasi yang dikumpulkan secara otomatis hanya digunakan untuk mengidentifikasi kemungkinan kasus penyalahgunaan dan menyusun informasi statistik terkait penggunaan website. Informasi statistik ini tidak digabungkan sedemikian rupa hingga dapat mengidentifikasi pengguna tertentu dari sistem.

Anda dapat mengunjungi website tanpa memberi tahu kami identitas Anda atau mengungkapkan informasi apa pun, yang dapat digunakan oleh seseorang untuk mengidentifikasi Anda sebagai individu tertentu yang dapat dikenali. Namun, jika Anda ingin menggunakan beberapa fitur website, atau Anda ingin menerima newsletter kami atau memberikan detail lainnya dengan mengisi formulir, Anda dapat memberikan data pribadi kepada kami, seperti email, nama depan, nama belakang, kota tempat tinggal, organisasi, dan nomor telepon Anda. Anda dapat memilih untuk tidak memberikan data pribadi Anda kepada kami, tetapi Anda mungkin tidak dapat memanfaatkan beberapa fitur website. Contohnya, Anda tidak akan dapat menerima Newsletter kami atau menghubungi kami secara langsung dari website. Pengguna yang tidak yakin tentang informasi yang wajib diberikan dapat menghubungi kami melalui Alamat email ini dilindungi dari robot spam. Anda memerlukan Javascript yang aktif untuk melihatnya..

Hak-hak Anda:

Jika Anda seorang warga Eropa, Anda memiliki hak-hak berikut terkait data pribadi Anda:

  • Hak untuk mendapatkan penjelasan.
  • Hak atas akses.
  • Hak untuk memperbaiki.
  • Hak untuk menghapus.
  • Hak untuk membatasi pemrosesan.
  • Hak atas portabilitas data.
  • Hak untuk menolak.
  • Hak-hak terkait pengambilan keputusan dan pembuatan profil otomatis.

Jika Anda ingin menggunakan hak ini, silakan hubungi kami melalui informasi kontak di bawah ini.

Selain itu, jika Anda seorang warga Eropa, perlu diketahui bahwa kami akan memproses informasi Anda untuk memenuhi kontrak yang mungkin kami miliki dengan Anda (misalnya, jika Anda melakukan pemesanan melalui Website), atau untuk memenuhi kepentingan bisnis sah kami seperti yang tercantum di atas. Di samping itu, harap diperhatikan bahwa informasi Anda mungkin dapat dikirim ke luar Eropa, termasuk Kanada dan Amerika Serikat.

Link ke website lain:

Website kami mungkin berisi tautan ke website lain yang tidak dimiliki atau dikendalikan oleh kami. Perlu diketahui bahwa kami tidak bertanggung jawab atas praktik privasi website lain atau pihak ketiga. Kami menyarankan Anda untuk selalu waspada ketika meninggalkan website kami dan membaca pernyataan privasi setiap website yang mungkin mengumpulkan informasi pribadi.

Keamanan informasi:

Kami menjaga keamanan informasi yang Anda berikan pada server komputer dalam lingkungan yang terkendali, aman, dan terlindungi dari akses, penggunaan, atau pengungkapan yang tidak sah. Kami menjaga pengamanan administratif, teknis, dan fisik yang wajar untuk perlindungan terhadap akses, penggunaan, modifikasi, dan pengungkapan tidak sah atas data pribadi dalam kendali dan pengawasannya. Namun, kami tidak menjamin tidak akan ada transmisi data melalui Internet atau jaringan nirkabel.

Pengungkapan hukum:

Kami akan mengungkapkan informasi apa pun yang kami kumpulkan, gunakan, atau terima jika diwajibkan atau diizinkan oleh hukum, misalnya untuk mematuhi panggilan pengadilan atau proses hukum serupa, dan jika kami percaya dengan itikad baik bahwa pengungkapan diperlukan untuk melindungi hak kami, melindungi keselamatan Anda atau keselamatan orang lain, menyelidiki penipuan, atau menanggapi permintaan dari pemerintah.

Informasi kontak:

Jika Anda ingin menghubungi kami untuk mempelajari Kebijakan ini lebih lanjut atau menanyakan masalah apa pun yang berkaitan dengan hak perorangan dan Informasi pribadi Anda, Anda dapat mengirim email ke Alamat email ini dilindungi dari robot spam. Anda memerlukan Javascript yang aktif untuk melihatnya..

Artikel Selanjutnya...