Artikel Lainnya

1. Definisi GitOps dan Single Source of Truth (SSOT)

Pertama, mari kita pahami definisi Sistem GitOps. Seperti yang telah dijelaskan sebelumnya mengenai karakteristik Kubernetes yang berbasis deklaratif dan proses instalasinya, semua sumber daya dalam Kubernetes dapat dikonfigurasi menggunakan kode. Sistem GitOps adalah konsep di mana konfigurasi tersebut disimpan dalam repositori Git, dan sistem memastikan bahwa kondisi operasional saat ini (Ops) selalu selaras dengan kode yang tersimpan di Git.

Dalam lingkungan kerja, Sistem GitOps sering digunakan untuk mencegah perubahan langsung pada sistem produksi tanpa melalui proses commit dan push ke Git. Tanpa GitOps, seseorang bisa saja mengubah konfigurasi langsung dari sumber lokalnya atau melalui perintah manual, yang dapat menyulitkan pelacakan riwayat perubahan. Salah satu skenario umum yang sering terjadi adalah ketika hanya sebagian cluster mengalami masalah, dan setelah diperiksa, ternyata ada perubahan yang dilakukan secara manual tanpa terdokumentasi dengan baik. Selain itu, dalam proses membangun sistem baru, tanpa pendekatan GitOps, sering kali diperlukan upaya tambahan untuk mencari dan menerapkan konfigurasi yang benar.Sistem GitOps

Sistem GitOps mengadopsi konsep Single Source of Truth (SSOT), yang juga perlu dipahami dengan baik. SSOT adalah prinsip dalam manajemen data yang menyatakan bahwa hanya ada satu versi data yang akurat dan terpercaya yang digunakan di seluruh sistem. Konsep ini berperan penting dalam meningkatkan konsistensi, akurasi, dan efisiensi dalam pengelolaan sistem.

  • Konsistensi: Semua komponen sistem mengacu pada sumber data yang sama, sehingga memastikan bahwa tidak ada perbedaan dalam informasi yang digunakan.
  • Akurasi: Mengurangi kemungkinan duplikasi atau inkonsistensi, sehingga meningkatkan keakuratan data.
  • Efisiensi: Dengan adanya satu lokasi utama untuk penyimpanan dan pemeliharaan data, proses pembaruan dan manajemen menjadi lebih efisien.

Dengan menerapkan Sistem GitOps dan konsep SSOT, organisasi dapat menjaga stabilitas sistem, meningkatkan keandalan operasional, dan mempermudah manajemen infrastruktur berbasis Kubernetes.

Dalam Sistem GitOps, repositori Git berperan sebagai Single Source of Truth (SSOT) untuk konfigurasi dan status sistem. Dengan menyimpan serta membuat versi dari seluruh kondisi kode dan infrastruktur di dalam repositori Git, sistem dapat dikelola dan diotomatisasi menggunakan pendekatan deklaratif. Ini berarti bahwa perubahan terhadap kondisi operasional tidak dilakukan secara manual oleh individu melalui perintah langsung atau sumber lokal yang belum dikomit, melainkan hanya melalui repositori Git yang terpusat.

Salah satu keuntungan terbesar dari Sistem GitOps, menurut saya, adalah kemampuannya untuk menjaga konsistensi sistem, yang pada akhirnya meningkatkan produktivitas kolaborasi tim. Karena semua sistem dan pengguna mengacu pada satu sumber data yang sama, kemungkinan terjadinya inkonsistensi informasi berkurang, dan upaya serta biaya yang diperlukan untuk mengelola serta menyinkronkan data yang duplikat juga menurun. Selain itu, fitur pencarian untuk melihat kembali status sistem pada titik waktu tertentu juga sering dimanfaatkan.

Namun, menerapkan prinsip ini sering kali tidak mudah. Dalam kesibukan pekerjaan sehari-hari, ada banyak godaan untuk mengabaikan prinsip GitOps dan melakukan perubahan langsung tanpa melalui repositori Git. Oleh karena itu, penting untuk menggunakan alat GitOps yang dapat menegakkan kebijakan serta memastikan adanya arsitektur data, proses, dan alat manajemen yang tepat.

Untuk mengimplementasikan Sistem GitOps, terdapat berbagai alat yang dapat digunakan. Dalam hal Continuous Deployment (CD), ArgoCD adalah salah satu alat yang paling banyak digunakan karena beberapa alasan:

  1. Menyediakan antarmuka pengguna (UI) yang mudah digunakan.
  2. Mudah diintegrasikan dengan alat lain.
  3. Memiliki banyak pengguna, sehingga dokumentasi dan contoh kasusnya melimpah.

Dengan menggunakan ArgoCD, organisasi dapat menerapkan GitOps secara lebih efektif, menjaga konsistensi sistem, dan meningkatkan efisiensi operasional.

ArgoCD: Pemantauan dan Sinkronisasi Otomatis

ArgoCD secara terus-menerus memantau repositori Git yang ditentukan dan klaster Kubernetes. Jika terdeteksi perubahan dalam repositori, ArgoCD secara otomatis menyinkronkan status klaster agar sesuai dengan status di repositori. Selain mode otomatis, ArgoCD juga menyediakan opsi sinkronisasi manual, yang berguna dalam situasi tertentu. Jika terjadi masalah, sistem dapat dengan mudah dikembalikan ke keadaan sebelumnya (rollback). Berkat fitur manajemen versi Git, semua riwayat perubahan dapat dilacak, sehingga pemulihan ke kondisi yang stabil menjadi lebih mudah.

BACA JUGA : Cara Instalasi EKS di AWS Menggunakan Terraform

ArgoCD juga menyediakan dasbor visual yang memungkinkan pengguna untuk memantau status aplikasi secara real-time, melihat sinkronisasi, serta mengevaluasi kesehatan (Health) aplikasi. Saat aplikasi dikelola menggunakan Helm, sering kali sulit untuk memahami keseluruhan sumber daya yang digunakan. Namun, dengan dasbor ArgoCD, pengguna dapat dengan mudah melihat struktur aplikasi mereka, menjadikannya fitur yang sangat disukai. Selain itu, ArgoCD memungkinkan pengaturan kontrol akses berbasis proyek dan pengguna, sehingga anggota tim hanya mendapatkan akses sesuai dengan peran mereka.

ArgoCD menggunakan repositori Git sebagai Single Source of Truth (SSOT) untuk memastikan bahwa status klaster Kubernetes selalu tersinkronisasi dan termonitor secara berkelanjutan. Dengan pendekatan ini, kolaborasi antara tim pengembang dan operasi (DevOps) menjadi lebih efektif, serta proses deployment menjadi lebih stabil dan cepat.

Praktik Langsung ArgoCD

Berikut adalah langkah-langkah praktikum yang akan kita lakukan:

  1. Instalasi ArgoCD
  2. Mendeploy Helm Chart NGINX menggunakan ArgoCD
  3. Eksperimen GitOps – Validasi Perubahan Manual di Lingkungan Lokal

Mari kita mulai dengan langkah pertama!

2. Instalasi Argo-CD

Instalasi Aplikasi di Kubernetes dengan Helm Dalam lingkungan Kubernetes, aplikasi biasanya diinstal menggunakan Helm. Helm adalah manajer paket untuk Kubernetes, mirip dengan APT atau YUM pada sistem operasi berbasis Linux. Dengan Helm, berbagai sumber daya Kubernetes dapat dikemas menjadi satu unit yang disebut chart, sehingga proses instalasi, pembaruan, dan penghapusan aplikasi menjadi lebih sederhana. Pembahasan lebih detail mengenai Helm akan dijelaskan pada Bab 11.

Sekarang, mari kita instal ArgoCD menggunakan Helm.

  • Pengguna Windows WSL dengan Homebrew dan pengguna macOS dapat menginstal Helm di PC lokal mereka menggunakan brew.

Sistem GitOps

Selanjutnya, unduh Helm Chart ArgoCD dari situs resmi ArgoCD.

Daftarkan repositori Helm ArgoCD yang ada di remote menggunakan perintah helm repo add, lalu unduh Helm Chart ke lokal dengan perintah helm pull.

Setelah itu, untuk menyesuaikan file konfigurasi Helm (Values.yaml) sesuai dengan lingkungan yang digunakan, salin file Values.yaml bawaan dan ubah namanya menjadi jerry-test-values.yaml.

Penjelasan lebih lanjut mengenai perintah Helm dapat ditemukan pada Bab 11.

Berikut adalah modifikasi dari Helm Values resmi (lihat referensi di GitHub penulis).

.configs.credentialTemplates.ssh-creds

Daftarkan informasi repositori GitHub yang akan digunakan dalam ArgoCD. Masukkan informasi kunci SSH yang telah terdaftar di GitHub Anda (biasanya terletak di ~/.ssh/id_rsa). Karena ini adalah informasi kunci pribadi, untuk alasan keamanan, informasi ini telah dimasking (xxxxx).

Informasi repositori dapat didaftarkan setelah instalasi ArgoCD selesai, dan juga bisa dilakukan melalui antarmuka grafis (GUI). Namun, disarankan untuk mengikuti filosofi GitOps dengan memasukkan informasi repositori Git ke dalam kode sumber. Meskipun mungkin terasa merepotkan di awal, menghindari penggunaan GUI akan lebih baik dalam hal keberlanjutan dan kemampuan untuk digunakan kembali di masa depan.

.repositories.k8s-class.name/url

Daftarkan nama dan URL repositori Git Anda.

Saat ini, pengaturan terkait Ingress belum dilakukan, sehingga pengaturan Helm Values yang berkaitan dengan Ingress masih belum ada. Setelah pengaturan Ingress di Bab 5 selesai, Anda dapat menambahkan konfigurasi Ingress untuk memudahkan akses menggunakan alamat Ingress.

Gunakan file Helm Values tersebut (jerry-test-values.yaml) untuk menginstal ArgoCD.

Setelah instalasi selesai, Anda dapat memeriksa pod yang terkait dengan ArgoCD.

3. Akses Pod Argo-CD Menggunakan Port-Forward

Mari kita akses pod ArgoCD yang telah diinstal menggunakan Port-forward. Untuk mengakses pod yang berjalan di dalam kluster dari luar kluster, kita umumnya menggunakan sumber daya Ingress Kubernetes. Penjelasan lebih lanjut mengenai hal ini akan disampaikan di Bab 5. Saat ini, kita akan menggunakan Port-forward agar administrator dapat dengan mudah mengakses pod tanpa melakukan pengaturan Ingress tambahan. Dalam praktiknya, pod yang tidak dikonfigurasi dengan Ingress karena alasan keamanan juga diakses menggunakan Port-forward.

Port-forward menggunakan perintah kubectl port-forward. Meskipun perintah port-forward agak panjang, perintah ini mendukung penyelesaian otomatis, sehingga tidak terlalu sulit untuk digunakan. Perintah port-forward memberikan kemampuan untuk meneruskan (port-forward) lalu lintas dari pod tertentu dalam kluster ke port tertentu di sistem lokal Anda. Dengan cara ini, Anda dapat mengakses sumber daya internal kluster secara langsung dari lingkungan pengembangan lokal. Karena port API server telah terhubung untuk menjalankan perintah kubectl, Anda hanya perlu melakukan pengaturan sederhana untuk terhubung ke port internal kluster.

Lalu lintas yang masuk ke port tertentu di sistem lokal akan diteruskan melalui API server ke port tertentu dari pod yang dipilih.

API server Kubernetes bertindak sebagai perantara dalam proses ini, sementara kubelet bertanggung jawab atas pengiriman lalu lintas yang sebenarnya. Sekarang, mari kita gunakan perintah di bawah ini untuk mengakses pod ArgoCD.

 

Kubernetes mengontrol lalu lintas pod melalui objek service. Menggunakan port-forward dengan service juga lebih nyaman. Penjelasan lebih rinci tentang service akan dibahas di bab berikutnya.

Port 8080 di depan perintah 8080:80 mengacu pada port di localhost, sedangkan port 80 di belakangnya mengacu pada port yang digunakan oleh service di kluster. Dengan kata lain, perintah ini berarti menghubungkan port 8080 di localhost saya ke port 80 di service kluster. Sekarang, jika Anda memasukkan localhost:8080 di browser seperti di bawah ini, Anda akan dapat melihat tampilan ArgoCD.

Kata sandi pengguna 'admin' awal dapat dilihat melalui Secret. Secret adalah objek Kubernetes yang digunakan untuk menyimpan informasi sensitif, seperti kata sandi. Penjelasan lebih lanjut akan dibahas di bagian berikutnya, tetapi saat ini, kita akan mendekode Secret di bawah ini untuk melihat kata sandi dalam bentuk teks biasa.

Masukkan Username sebagai admin dan masukkan hasil output dari perintah di atas ke dalam Password di jendela login. Setelah login, pilih menu ‘Settings’ di sebelah kiri layar, lalu pilih ‘Repositories’, dan Anda akan melihat bahwa repositori GitHub yang telah Anda daftarkan di file Helm Values terdaftar dengan normal.

ArgoCD telah berhasil diinstal dengan normal.

4. Mendeploy NGINX dengan Argo-CD

Sekarang, kita akan mendeploy aplikasi menggunakan ArgoCD yang telah diinstal. Aplikasi yang akan kita deploy adalah Nginx, yang sering digunakan sebagai server web.

Nginx juga akan dideploy menggunakan Helm Chart.

Proses instalasi Helm ini sama seperti sebelumnya. Anda dapat menggunakan versi terbaru dari Nginx web server, tetapi jika Anda ingin konfigurasi yang sama seperti penulis, silakan tentukan versi (15.1.0).

Berikut adalah modifikasi sederhana dari file Helm Values.yaml. File tersebut dapat Anda temukan di GitHub penulis.

Ini adalah perubahan sederhana, seperti mengubah jumlah pod Nginx web server dari pengaturan default menjadi 2. Berdasarkan file Helm Values tersebut, kita akan mendeploy web server Nginx. ArgoCD memungkinkan Anda untuk melakukan pekerjaan ini melalui GUI web untuk mendeploy aplikasi ke lingkungan Kubernetes. Namun, untuk memudahkan penggunaan kembali dan agar sesuai dengan filosofi GitOps, disarankan untuk juga melakukan pengaturan mendeploy aplikasi dalam bentuk kode.

ArgoCD menggunakan Custom Resource Definition (CRD) yang disebut ‘Application’ agar dapat mendeploy melalui kode. CRD adalah fitur yang memungkinkan pengguna untuk mendefinisikan sumber daya khusus di Kubernetes. Secara default, Kubernetes menyediakan sumber daya inti seperti pod, service, dan deployment, tetapi pengguna juga dapat mendefinisikan dan menggunakan jenis sumber daya mereka sendiri.

Dengan menggunakan CRD, pengguna dapat mendefinisikan jenis sumber daya mereka sendiri dan menggunakannya di kluster seolah-olah itu adalah sumber daya bawaan. ArgoCD juga menyediakan sumber daya khusus yang disebut ‘Application’ untuk memudahkan mendeploy aplikasi.

Mari kita buat ArgoCD Application untuk mendeploy Nginx web server. (Lihat di GitHub penulis)

.metadata.finalizers

Opsi ini memungkinkan penghapusan sumber daya ‘Application’ untuk secara bersamaan menghapus sumber daya Kubernetes terkait (seperti pod, dll).

.spec.destination.server

Di sini, Anda menentukan tujuan tempat ArgoCD akan mendeploy aplikasi. Anda dapat menentukan kluster Kubernetes jarak jauh atau Kubernetes tempat ArgoCD diinstal. Jika Anda menetapkan alamat sebagai ‘https://kubernetes.default.svc’, maka itu akan merujuk pada Kubernetes tempat ArgoCD diinstal.

.spec.source.helm

ArgoCD mendukung berbagai bentuk instalasi aplikasi, seperti Helm dan manifest. Dalam praktik ini, karena kita akan menginstal Nginx menggunakan Helm, kita menetapkannya sebagai ‘helm’.

.spec.source.path, repoURL

Menentukan URL repositori GitHub tempat Helm Chart berada dan jalur Helm Chart tersebut.

.spec.syncPolicy.automated.prune/selfHeal

Opsi ini menentukan apakah ArgoCD akan secara otomatis mendeploy aplikasi. Jika Anda ingin Kubernetes secara otomatis mendeploy Helm saat kode sumber diunggah ke Git, Anda dapat menetapkan opsi ‘automated’.

Di lingkungan nyata, di lingkungan Dev dan Stage, opsi ‘automated’ sering digunakan, tetapi di lingkungan produksi, banyak yang tidak menggunakan opsi ‘automated’ untuk memeriksa riwayat perubahan (‘Diff’) secara manual sebelum mendeploy.

Prune adalah opsi yang menghapus sumber daya yang sudah tidak ada di Git, sedangkan opsi selfHeal secara otomatis memulihkan tugas yang gagal.

.spec.syncOptions.CreateNamespace

Opsi ini digunakan untuk secara otomatis membuat namespace.

Karena Application CRD juga merupakan sumber daya Kubernetes, Anda dapat membuat sumber daya tersebut menggunakan perintah ‘kubectl apply’.

Sebuah objek Kubernetes terpisah yang disebut ‘Application’ telah dibuat di ArgoCD. Application di ArgoCD bukanlah aplikasi program pada umumnya, melainkan salah satu jenis objek Kubernetes yang dibuat oleh ArgoCD itu sendiri.

Jika Anda memeriksa menu di sebelah kiri layar di web ArgoCD, Anda akan melihat bahwa argocd/nginx yang baru telah dibuat.

Dengan mengklik menu tersebut, Anda dapat memeriksa sumber daya Kubernetes yang diinstal menggunakan Helm Chart NGINX. Service dan Deployment telah diinstal.

Anda dapat memeriksa pod web server Nginx yang telah diinstal menggunakan perintah.

Dengan demikian, Anda dapat mendistribusikan pod aplikasi menggunakan ArgoCD.

Pada saat pertama kali melakukan distribusi ArgoCD, aplikasi diinstal menggunakan perintah ‘helm install’ di PC lokal. Setelah itu, NGINX tidak diinstal menggunakan perintah ‘helm install’, melainkan didistribusikan menggunakan ArgoCD.

Aplikasi yang diinstal menggunakan perintah di PC lokal tidak dapat disimpan di Git, sehingga sulit untuk dikelola di masa mendatang. Namun, dengan menggunakan ArgoCD, Anda dapat memaksa penyimpanan dan distribusi sumber kode di Git, sehingga lebih mudah untuk menerapkan kebijakan GitOps. Disarankan agar semua aplikasi yang diinstal di Kubernetes didistribusikan menggunakan ArgoCD.

ArgoCD mendukung antarmuka pengguna (UI) yang memudahkan Anda untuk memeriksa sumber daya apa yang telah diinstal menggunakan Helm.

5. Praktik GitOps

Mari kita lihat bagaimana ArgoCD mengimplementasikan GitOps dengan membuat status yang sedang berjalan (Ops) berbeda dari status di Git.

Alih-alih menggunakan kode sumber, kita akan mengubah jumlah pod NGINX dari 2 menjadi 5 menggunakan perintah. Bagi konsol lokal menjadi dua jendela; di bagian atas, kita akan mengubah jumlah pod, dan di bagian bawah, kita akan memantau perubahan secara real-time.

Jendela di bawah akan memantau perubahan pod secara real-time menggunakan perintah ‘k get pod -w (watch)’.

Di jendela atas, kita akan mengubah jumlah pod. Perubahan jumlah pod dilakukan dengan menggunakan perintah scale.

Meskipun kita telah menetapkan jumlah pod menjadi 5 dengan perintah, pod tersebut tidak bertambah. Statusnya menunjukkan 'ContainerCreating' dan pada saat yang sama juga 'Terminating'.

Jumlah pod masih tetap 2. Mengapa hal ini bisa terjadi?

Karena jumlah pod tidak diubah di sumber Git, ArgoCD secara otomatis mempertahankan jumlah pod tetap 2 untuk mencocokkan keadaan kluster saat ini dengan keadaan sumber yang disinkronkan di Git.

Sekarang, untuk memeriksa perbedaan, saya akan menghapus opsi 'automated' di ArgoCD. Opsi 'automated' adalah opsi yang secara otomatis mencocokkan keadaan saat ini dengan keadaan di Git. Dengan menghapus opsi tersebut, ArgoCD tidak akan secara otomatis memperbaiki keadaan saat ini.

Setelah itu, jalankan kembali perintah 'k scale deployment nginx --replicas 5' dan periksa di web ArgoCD; statusnya akan menunjukkan 'OutOfSync'. Seperti yang terlihat dari pesan tersebut, dapat dipastikan bahwa keadaan sumber yang disimpan di Git tidak sinkron dengan keadaan kluster yang sedang berjalan saat ini.

Dengan memeriksa menu 'APP DIFF', Anda dapat melihat pesan yang lebih rinci.

Anda dapat melihat bahwa angka replika pod, yaitu 5 dan 2, saling berbeda.

Dalam lingkungan operasi praktis, sering kali opsi 'automated' dinonaktifkan seperti di atas. Pengguna selalu memeriksa 'Diff' secara manual untuk memastikan adanya masalah dan mengikuti proses penerapan ke cluster yang sebenarnya.

Dengan demikian, jika pengguna mengubah jumlah pod secara manual menggunakan perintah, tetapi opsi 'Automated' diaktifkan, ArgoCD akan secara otomatis menyinkronkan status saat ini dengan sumber Git, sehingga jumlah pod tetap 2.

Sekarang, mari kita ubah jumlah pod dari 2 menjadi 1 di sumber Git. Kita akan mengubah opsi 'replicaCount' dalam file nilai Helm NGINX.

Setelah melakukan commit Git, lakukan push untuk menggabungkan ke main Git. Berikut adalah contoh tampilan layar Git Commit di VSCode yang saya gunakan.

Dengan mengklik ‘REFRESH’ di menu ArgoCD, jumlah pod otomatis berkurang menjadi 1.

Dengan perintah kubectl, jumlah pod juga berkurang menjadi 1.

Dengan cara ini, ArgoCD menyinkronkan status yang tercermin dalam sumber Git dengan status Kubernetes yang sebenarnya. Semua perubahan dilakukan tidak melalui perintah atau sumber lokal secara sembarangan, tetapi hanya dilakukan di repositori Git terpusat.

Demikian pula, pekerjaan infrastruktur yang menggunakan Terraform juga diterapkan ke status aktual setelah melalui tinjauan PR Git.

Screenshot di atas adalah pesan tinjauan PR yang saya gunakan saat melakukan upgrade EKS. Ini adalah contoh di mana saya telah meminta rekan untuk memverifikasi pekerjaan kode Terraform untuk upgrade EKS melalui tinjauan. Dengan memverifikasi kode yang terkait dengan pekerjaan sebelumnya, saya dapat mengurangi kemungkinan terjadinya masalah selama proses. Kode yang sudah diverifikasi kemudian digabungkan ke dalam branch utama untuk diterapkan ke status yang sebenarnya.

Selain kode Terraform, kode Python untuk pekerjaan lainnya juga disimpan di Git dan diperiksa melalui proses tinjauan.

Contoh di atas adalah kode Python yang mencetak daftar seluruh AWS MSK Cluster berdasarkan setiap region.

Tentu saja, dalam operasional nyata, sulit untuk mendapatkan tinjauan kode untuk setiap pekerjaan karena keterbatasan waktu. Namun, sangat efektif untuk mengadopsi proses di mana semua pekerjaan dilakukan dengan menulis kode terlebih dahulu dan membuat dokumentasi berdasarkan kode tersebut untuk mendapatkan tinjauan dari rekan kerja. Selain itu, setidaknya semua catatan pekerjaan harus disimpan dalam bentuk kode, karena ini akan sangat membantu saat melakukan pekerjaan yang sama di masa mendatang.

Sampai saat ini, saya telah berbagi contoh GitOps dengan ArgoCD. GitOps adalah kebijakan, jadi niat untuk mematuhi kebijakan tersebut sangat penting. Penting untuk melakukan tinjauan kode dengan cermat dan menjaga prosedur kerja, meskipun terasa merepotkan, setiap usaha sehari-hari diperlukan untuk menjaga stabilitas sistem.

1. Keuntungan Menggunakan Kode untuk Instalasi Kubernetes

Bayangkan pembaca artikel ini menjadi penanggung jawab Kubernetes dan diberi tugas untuk melakukan cara instalasi EKS dengan Terraform. Bagaimana cara terbaik untuk melakukannya? Mari kita pikirkan bagaimana proses instalasi telah dilakukan hingga saat ini dan apa pendekatan terbaik yang bisa diterapkan ke depannya.

EKS dapat diinstal melalui konsol Amazon menggunakan antarmuka GUI (Graphical User Interface) atau dengan perintah eksctl. Pendekatan ini cukup nyaman karena memungkinkan instalasi dilakukan dengan relatif mudah. Namun, metode ini memiliki kelemahan dari sisi penggunaan ulang (reusability). Setiap kali instalasi dilakukan, Anda harus melalui proses yang sama, yang berisiko menimbulkan kesalahan. Selain itu, jika Anda perlu membuat EKS untuk berbagai lingkungan, seperti lingkungan pengembangan, produksi, atau tujuan layanan lainnya, Anda harus mengulangi serangkaian langkah GUI dan perintah tersebut setiap kali. Jika instalasi awal memakan waktu 10 menit, proses berikutnya juga akan memakan waktu yang sama. Lebih jauh lagi, sulit untuk melakukan tinjauan bersama dengan rekan kerja karena semua perintah yang diperlukan untuk pekerjaan tersebut tidak dapat disiapkan sebelumnya.

Seperti yang telah dijelaskan sebelumnya, mengelola Kubernetes dengan kode memiliki banyak keuntungan. Hal yang sama berlaku untuk EKS; jika infrastruktur dikelola dengan kode, terdapat sejumlah manfaat signifikan.

Banyak dari Anda mungkin sudah tahu bahwa saat ini praktik Infrastructure as Code (IaC), seperti menggunakan Terraform, sudah umum digunakan untuk mengelola infrastruktur melalui kode. Terraform sering digunakan di lingkungan public cloud. Sebagai alat otomatisasi infrastruktur, Terraform memungkinkan Anda untuk menyediakan dan mengelola infrastruktur di lingkungan cloud maupun on-premises menggunakan kode. Dengan Terraform, Anda dapat mendefinisikan infrastruktur dalam bentuk kode, yang memudahkan untuk mengotomatisasi tugas berulang, melacak perubahan, dan menjaga konsistensi dalam lingkungan infrastruktur. Terraform menggunakan bahasa deklaratif untuk mendefinisikan sumber daya, memungkinkan Anda mengonfigurasi infrastruktur sesuai dengan kondisi yang diinginkan.

EKS juga dapat diinstal menggunakan Terraform, dan pendekatan ini memiliki beberapa kelebihan sebagai berikut.

  1. Pengelolaan Infrastruktur Menggunakan Kode
    Dengan menggunakan kode, Anda dapat meninjau kode sebelumnya untuk menemukan masalah, sehingga sangat mendukung kolaborasi. Selain itu, perubahan dapat dengan mudah dilacak dengan pengelolaan versi menggunakan platform seperti GitHub.
  2. Kemudahan Penggunaan Kembali dan Pemeliharaan
    Di dunia kerja, kami menggunakan beberapa kluster untuk pengembangan, staging, dan produksi. Ketika membuat kluster yang sama, kami dapat menggunakan kode yang ada tanpa perubahan, sehingga meningkatkan produktivitas.

Ada berbagai Cara Instalasi EKS dengan Terraform. Terraform mendukung modul EKS, yang memungkinkan Anda menginstal berbagai sumber daya terkait seperti VPC, Security Group, dan Subnet dengan nyaman sekaligus tanpa menduplikasi kode. Modul Terraform mengabstraksi dan mengenkapsulasi fungsi atau sumber daya tertentu, sehingga menyederhanakan dan memodulasi konfigurasi infrastruktur yang kompleks. Ini membantu meningkatkan kemampuan penggunaan kembali dan pemeliharaan kode.

Dengan menggunakan modul Terraform, Anda dapat mengenkapsulasi skenario atau pola umum, sehingga mudah untuk mengulang konfigurasi yang sama di berbagai proyek atau lingkungan. Saya juga menggunakan modul Terraform untuk menginstal EKS dengan mudah.

2. Instalasi EKS dengan Terraform

Mari kita lihat Cara Instalasi EKS dengan Terraform yang digunakan di lingkungan kerja nyata. Kode tersebut dapat ditemukan di GitHub saya. Jika Anda melihat kode Terraform EKS tanpa pemahaman yang cukup tentang EKS, banyak hal mungkin terasa asing dan sulit dipahami. Pada awalnya, tidak masalah jika Anda hanya mengenali istilah-istilahnya. Seiring waktu dan penggunaan, Anda akan mulai memahami berbagai konsep yang sebelumnya sulit. Saya ingin menekankan bahwa mencoba untuk belajar secara sempurna di awal akan memakan waktu yang terlalu lama. Saya percaya bahwa lebih efektif untuk menyelesaikan praktik secara keseluruhan terlebih dahulu, dan kemudian mengulang bagian-bagian yang sulit atau diperlukan masing-masing. Cara Instalasi EKS dengan Terraform

BACA JUGA : Catatan Teknis Jennifer Panduan Praktis Menguasai Kubernetes

Unduh kode saya ke lokal menggunakan 'git clone'.

Cara Instalasi EKS dengan Terraform
Jika Anda memeriksa direktori 'terraform-eks' di bawah ini, Anda akan menemukan kode Terraform yang terkait dengan instalasi EKS.
Cara Instalasi EKS dengan Terraform

Pertama, ini adalah pengaturan terkait variabel locals. Variabel locals didefinisikan dalam Terraform menggunakan blok locals untuk membuat variabel lokal. Dengan mendefinisikan variabel menggunakan blok locals, variabel ini hanya dapat digunakan di dalam modul atau file pengaturan tersebut dan tidak dapat diakses dari luar. Variabel ini umumnya digunakan untuk menyimpan nilai yang berulang atau ekspresi yang kompleks, sehingga membuat kode lebih mudah dikelola. Cara Instalasi EKS dengan Terraform

Anda dapat menyimpan file variabel locals secara sembarangan, tetapi saya telah mendaftarkan blok locals di file main.tf.

Cara Instalasi EKS dengan Terraform

. name

Ini adalah nama EKS. Setelah dibuat, nama kluster tidak dapat diubah, sehingga penting untuk memutuskan nama kluster dengan hati-hati sejak awal. Jika perusahaan sudah memiliki Konvensi Penamaan yang ditentukan, ikutilah. Jika tidak ada, buatlah aturan yang dapat diterapkan secara konsisten dengan mempertimbangkan penyampaian makna yang jelas dan kemungkinan perluasan di masa mendatang. Menetapkan nama seperti test-01 tanpa aturan akan sangat merepotkan. Tentukan nama yang dapat menjelaskan dirinya sendiri (Self Explaining). Perusahaan saya biasanya menggunakan format {Nama Produk} – {Wilayah} – {Lingkungan (test/stage/prod)}. Ini mudah untuk ditentukan, jadi saya sangat menyarankan untuk menetapkannya sebelumnya. Cara Instalasi EKS dengan Terraform

. region

Secara umum, saya menggunakan ap-northeast-2, yaitu Seoul, tetapi karena ada EKS lain yang sudah diinstal di wilayah tersebut, saya memilih wilayah ap-southeast-1, yaitu Singapura, untuk membedakannya. Tentu saja, Anda juga bisa membedakan dengan menggunakan VPC di wilayah yang sama, tetapi demi kenyamanan, saya memisahkan hingga ke tingkat wilayah. Jika tidak ada alasan khusus seperti yang saya miliki, disarankan untuk memilih ap-northeast-2.

. vpc_cidr

Ini adalah pengaturan yang penting. CIDR (Classless Inter-Domain Routing) adalah sistem alamat jaringan yang digunakan untuk mengelola dan membagi ruang alamat IP secara efisien. Ini adalah konsep yang melengkapi dan mengembangkan sistem alamat berbasis kelas (Classful Network), yang memungkinkan penugasan alamat IP yang lebih fleksibel. Pilihlah rentang IP yang unik dan tidak tumpang tindih dengan rentang IP dari VPC lain yang sudah digunakan. Jika Anda menggunakan infrastruktur lokal (on-premises) bersama dengan AWS Cloud, sebaiknya gunakan rentang IP yang berbeda dari rentang IP lokal untuk memudahkan pengaturan Peering di masa depan.

Rentang IP juga sebaiknya memiliki aturan yang jelas. Misalnya, untuk lingkungan produksi, Anda dapat membaginya menjadi 10.1.0.0/16, 10.2.0.0/16, dan untuk staging menjadi 10.11.0.0/16, 10.12.0.0/16, serta membagi berdasarkan wilayah: Seoul dengan rentang 10.0.0.0/16 hingga 10.50.0.0/16 dan Tokyo dengan rentang 10.51.0.0/16 hingga 10.100.0.0/16. (Atau bisa juga menggunakan 172.16.0.0/16, 192.168.0.0/16, dll.) Banyak kasus di mana rentang yang sama digunakan di VPC yang berbeda karena tidak ada aturan yang ditetapkan di awal.Cara Instalasi EKS dengan Terraform

. azs

Pertimbangkan ketersediaan dengan membagi dan mengalokasikan ke dalam 3 AZ (Availability Zone). Atau, untuk kluster pengujian, Anda dapat menggunakan satu AZ untuk mengurangi biaya. Dalam lingkungan operasional yang sebenarnya, sering terjadi lalu lintas antar node dalam kluster, yang dapat menyebabkan biaya Transfer Data lebih tinggi dari yang diperkirakan.

Selanjutnya adalah pengaturan modul EKS.

Cara Instalasi EKS dengan Terraform

. cluster_endpoint_public_access

Karena ini adalah lingkungan kluster pengujian, akses publik ke layanan API EKS diizinkan. Namun, dalam lingkungan operasional yang sebenarnya, disarankan untuk membatasi akses dari luar demi keamanan.

Cara Instalasi EKS dengan Terraform

Dengan pengaturan di atas, akses hanya dapat dilakukan dari dalam VPC yang sama dengan EKS. Melalui server API EKS, semua operasi Kubernetes dapat dilakukan, seperti menghapus pod dan node atau bahkan menghapus seluruh kluster, sehingga perlu dilakukan dengan hati-hati. Saya menggunakan VPN untuk mengakses menggunakan rentang IP internal. Jika tidak menggunakan VPN, Anda juga bisa membatasi rentang IP publik yang dapat mengakses API.

. cluster_addons

EKS Addon adalah fitur yang menyediakan kemampuan untuk dengan mudah mengaktifkan dan mengelola fungsi atau layanan tertentu dalam kluster Amazon EKS. Fitur ini memudahkan pengelolaan elemen-elemen penting dalam konfigurasi EKS, seperti jaringan dan DNS. Dengan mengelola Coredns, Kube-proxy, Vpc-cni sebagai add-on sebelumnya, Anda dapat dengan nyaman melakukan upgrade EKS di masa mendatang hanya dengan menyebutkan informasi versi baru.

. vpc_id

Disarankan untuk menggunakan VPC terpisah untuk tujuan EKS agar dapat dibedakan dari VPC yang ada. EKS secara default menggunakan VPC_CNI (Container Network Interface) untuk mengelola jaringan Kubernetes. VPC_CNI menggunakan rentang IP yang sama untuk pod dan node, sehingga membutuhkan banyak alamat IP. Adalah hal yang umum jika jumlah pod melebihi 1.000, yang dapat menyebabkan kekurangan IP. Oleh karena itu, disarankan untuk menggunakan VPC terpisah.

. subnet_ids

Tentukan rentang Subnet di mana pod EKS akan dialokasikan. Kecuali dalam lingkungan khusus di mana pod harus berkomunikasi dengan alamat IP publik, sebaiknya untuk alasan keamanan, rentang Subnet ditetapkan sebagai rentang IP privat.

. control_plane_subnet_ids

Ini adalah rentang subnet di mana pod Control Plane dialokasikan. Control Plane adalah komponen inti dari kluster Kubernetes, yang berfungsi untuk mengelola dan mengontrol semua operasi di dalam kluster. Penjelasan lebih detail akan disertakan dalam praktik yang akan datang, dan saat ini cukup jika Anda hanya mengenal istilah tersebut. Rentang jaringan untuk Control Plane ditetapkan sebagai rentang Intra yang lebih aman, bukan publik atau privat. Control Plane tidak memiliki akses eksternal melalui internet gateway atau NAT gateway, dan merupakan sumber daya yang digunakan hanya di dalam VPC.

Selanjutnya adalah pengaturan nodegroup. Kubernetes memerlukan instansi VM untuk menjalankan aplikasi kontainer secara nyata. EKS dapat mengelola dan memperluas ini secara efisien menggunakan nodegroup. Belakangan ini, banyak yang mengelola node EC2 EKS menggunakan Karpenter daripada menggunakan node group yang ada. Karpenter mengelola ukuran sumber daya antara node dan pod untuk mengoptimalkan efisiensi sumber daya dalam kluster. Ini sangat membantu dalam meningkatkan kinerja dan ketersediaan kluster dengan mengotomatiskan penyesuaian ukuran sumber daya. Penjelasan lebih lanjut akan dibahas di ‘Bab 8. Autoscaling Node – Karpenter’.

Node yang dijalankan oleh Karpenter tidak dapat ditentukan oleh Karpenter itu sendiri, sehingga node group yang dijalankan oleh Karpenter didefinisikan seperti di bawah ini.(eks-cluster.tf)

Cara Instalasi EKS dengan Terraform

. eks_managed_node_group_defaults

Tentukan pengaturan dasar untuk node group. Pengaturan grup keamanan (security group) dan peran IAM (iam_role) mengikuti pengaturan dasar Terraform. Sementara itu, pengaturan kapasitas disk diubah menjadi 100Gi berbasis gp3 dengan lebih banyak ruang untuk mengantisipasi kemungkinan kegagalan, berbeda dari pengaturan dasar.

. eks_managed_node_groups.capacity_type, instance_types

Dalam kasus saya, lingkungan operasional ditetapkan menggunakan tipe instansi On-demand, sementara lingkungan Dev/Stage menggunakan Spot Instance untuk mengurangi biaya secara signifikan (sekitar 30% lebih murah dibandingkan On-demand). Untuk EKS pengujian, saya menetapkannya sebagai Spot Instance.

Sebagai catatan, jika Anda menentukan beberapa 'instance_types' di lingkungan Spot, Anda dapat mempersiapkan kemungkinan kekurangan sumber daya yang ditetapkan sebagai Spot. Bergantung pada situasinya, Anda dapat menentukan beberapa tipe, seperti [“t3.small”, “t3.large”, “m6i.large”].

Terakhir adalah pengaturan VPC. (vpc.tf)

Cara Instalasi EKS dengan Terraform

. module “vpc”.source

Terraform, seperti EKS, juga menyediakan modul VPC terpisah.

. private_subnets, [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]

Tambahkan 4 ke CIDR sebelumnya vpc_cidr = “10.110.0.0/16” untuk mendapatkan CIDR /20, yang akan dialokasikan ke 3 AZ (Availability Zone), yaitu jika di Seoul, maka ap-northeast-2a, ap-northeast-2b, dan ap-northeast-2c.

. public_subnets  = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]
  intra_subnets   = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 52)]

Dengan menambahkan /16 + 8, kita akan mengalokasikan CIDR /24 ke 3 AZ. IP yang dialokasikan berada setelah rentang jaringan privat sebelumnya.

Jika Anda memeriksa rentang IP yang diterapkan di konsol AWS, akan terlihat seperti di bawah ini.

Cara Instalasi EKS dengan Terraform

Tiga CIDR /20 bit dan enam CIDR /24 bit akan dialokasikan.

Setelah pengaturan selesai, Anda dapat menginstal EKS menggunakan Terraform. Pindah ke direktori tempat kode Terraform yang telah diunduh sebelumnya dengan 'git clone' disimpan.

Cara Instalasi EKS dengan Terraform

Instal EKS menggunakan perintah Terraform.

Cara Instalasi EKS dengan Terraform

Setelah sekitar 20 menit, instalasi akan selesai dengan normal. Setelah selesai, Anda dapat memeriksa di konsol AWS EKS seperti di bawah ini. Cari menu EKS di menu layanan AWS dengan mengetik 'eks'.

Cara Instalasi EKS dengan Terraform

 

Cara Instalasi EKS dengan Terraform

Tampilan konsol AWS EKS.

Jika Anda dapat memeriksa informasi EKS di layar konsol seperti di atas, itu berarti EKS telah terinstal dengan normal.

3. Pengaturan lingkungan operasi Kubectl lokal – Konfigurasi file lingkungan Kubernetes (~/.kube/config) dan pemanfaatan plugin Krew.

Untuk mengelola Kubernetes, diperlukan alat perintah 'kubectl'. Kubectl adalah antarmuka baris perintah (CLI) yang digunakan untuk berinteraksi dengan kluster Kubernetes. Ini adalah alat penting bagi pengguna untuk mengelola dan memantau sumber daya kluster. Di lingkungan Mac, Anda dapat menginstalnya dengan mudah menggunakan Homebrew.

Cara Instalasi EKS dengan Terraform

Sebagai catatan, Homebrew juga dapat digunakan di lingkungan Ubuntu. Saya menggunakan WSL Ubuntu dan telah menginstal Homebrew untuk digunakan.(Rujuk ke metode instalasi) Anda dapat menginstal 'kubectl' dengan perintah yang sama seperti di atas.

Tentu saja, Anda juga dapat menggunakan manajer paket apt. Anda dapat menemukan metode instalasi yang lebih rinci di situs resmi Kubernetes.

Setelah instalasi, selesaikan pengaturan penyelesaian otomatis dan alias sesuai panduan di situs resmi Kubernetes.

Selain itu, jika Anda mendaftarkan alias di bawah ini, Anda dapat menjalankan perintah kubectl dengan lebih cepat.

Instalasi alat kubectl telah selesai. Selanjutnya, untuk mengelola kluster EKS jarak jauh dari lokal, perlu memodifikasi file konfigurasi Kubernetes di PC pribadi (/.kube/config). File ‘/.kube/config’ di Kubernetes berisi informasi alamat kluster Kubernetes jarak jauh, kredensial pengguna, dan lain-lain. Format file konfigurasi adalah YAML, dan Anda dapat mengeditnya secara langsung atau menggunakan perintah ‘kubectl config’.

Berikut adalah file konfigurasi Kubernetes yang terdaftar di PC saya. Jika Anda mengatur dengan cara yang sama, informasi yang diperlukan untuk mengakses Kubernetes jarak jauh akan terdaftar.

 Struktur Kubernetes Config terdiri dari tiga bagian utama seperti di bawah ini.

  • Cluster (Klaster): Berisi alamat server klaster dan informasi autentikasi TLS dasar. Informasi ini sangat penting untuk menghubungkan ke klaster.
  • Contexts (Konteks): Memuat informasi tentang klaster, pengguna, dan namespace. Konteks memungkinkan perpindahan cepat antara beberapa klaster dan pengguna.
  • Users (Pengguna): Berisi informasi autentikasi klien untuk berkomunikasi dengan klaster. Ini mencakup token autentikasi, sertifikat klien, nama pengguna, dan kata sandi. Perlu dicatat bahwa EKS dan Kubernetes on-premise menggunakan metode autentikasi yang berbeda.

Selanjutnya, file ~/.kube/config pada bagian 'Clusters' dan 'Users' akan disesuaikan untuk memungkinkan pengelolaan klaster Kubernetes jarak jauh dari PC pribadi Anda. Informasi tambahan tentang file konfigurasi Kubernetes untuk EKS dapat ditemukan di dokumentasi resmi AWS.

Langkah pertama adalah memeriksa informasi alamat server dan sertifikat autentikasi pada bagian 'clusters'. Informasi ini dapat dilihat di menu 'Overview' (Ikhtisar) pada konsol manajemen AWS EKS.

Salin informasi tersebut, dan berdasarkan tangkapan layar yang diberikan, daftarkan ke dalam file konfigurasi lokal ~/.kube/config. Masukkan 'API Server Endpoint' ke dalam bagian 'server' dan masukkan informasi sertifikat otoritas, yaitu 'Certificate Authority', ke dalam 'certificate-authority-data'.

Tentukan nama untuk cluster, context, dan user. Nama-nama ini dapat ditentukan secara bebas, jadi pilih nama yang sesuai untuk Anda. Dalam kasus ini, saya menggunakan nama yang sama untuk ketiganya, yaitu switch-singapore-test.

Langkah terakhir adalah mengisi bagian 'user'. Pada bagian '--cluster-name', masukkan nama klaster yang digunakan saat instalasi (contoh: singapore-test). Kemudian, untuk env:name dan env:value, masukkan informasi kredensial AWS Anda. Informasi kredensial AWS dapat ditemukan dalam file ~/.aws/credentials. Gunakan informasi kredensial yang sama dengan yang digunakan saat menginstal EKS.

  • Pada env:name, masukkan AWS_PROFILE.
  • Pada env:value, masukkan nama profil dari file kredensial AWS Anda.

Setelah semua konfigurasi selesai, Anda kini dapat menjalankan perintah kubectl dari lingkungan lokal Anda untuk mengelola klaster Kubernetes.

Jika perintah di atas berhasil dijalankan, maka semua persiapan untuk mengelola kluster jarak jauh dari lingkungan lokal Anda telah selesai. Anda dapat mencoba membuat pod uji, dan pod tersebut akan berjalan dengan normal.

Selain itu, jika Anda memeriksa di AWS Console, Anda akan melihat bahwa VPC, Subnet, NAT Gateway, dan lainnya telah secara otomatis disertakan. Terraform dengan praktis menginstal semua sumber daya yang diperlukan untuk pengaturan EKS dalam satu modul.

Demikianlah cara memasang EKS menggunakan Terraform.

Dengan menggunakan Terraform, Anda tidak hanya dapat menginstal EKS, tetapi juga berbagai sumber daya yang diperlukan untuk menjalankan EKS dengan mudah. Terraform dirancang dengan abstraksi yang baik sehingga Anda tidak perlu memahami secara mendalam semua pengaturan detail dari berbagai sumber daya untuk dapat melakukan instalasi dan pengoperasian dengan lancar. Anda cukup menyesuaikan dan mengoptimalkan konfigurasi sesuai dengan kebutuhan masing-masing perusahaan.

 

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.

 

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 kubectl 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 kubectl 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.

 

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!

More Articles ...