Monitoring Kubernetes dengan JENNIFER APM: Solusi AKS, EKS, & GKE

Perubahan Menuju Lingkungan Kontainer

Teknologi virtualisasi kontainer (Container Virtualization), yang menyediakan tingkat virtualisasi berbeda dari Virtual Machine (VM) yang memvirtualisasikan mesin fisik, telah diterapkan secara bertahap pada lingkungan operasional seiring dengan berkembangnya arsitektur microservices.

Namun, seiring bertambahnya jumlah layanan mikro, jumlah kontainer pun meningkat secara proporsional. Akibatnya, seperti yang terlihat pada [Gambar 1], jika operator harus mengelola multi-kontainer secara langsung, hal tersebut sangat berpotensi menimbulkan kesalahan manajemen.

Untuk mengatasi kelemahan tersebut, hadirlah tools orchestration yang mengabstraksikan manajemen kontainer. Dengan demikian, administrator sistem dapat menangani multi-kontainer menggunakan alat orkestrasi seperti pada [Gambar 2], yang pada gilirannya semakin mendorong adopsi teknologi kontainer untuk layanan berskala besar.

Penyedia layanan cloud juga dengan cepat mengadopsi perubahan lingkungan operasional ini ke dalam lini produk mereka. Hal ini dikarenakan, meskipun terdapat alat orkestrasi, infrastruktur tempat teknologi kontainer berjalan tetap mutlak diperlukan. Pada akhirnya, penyedia layanan cloud menyediakan layanan kontainer yang terabstraksi sempurna hanya dengan menempatkan layanan k8s di atas lingkungan infrastruktur virtual yang sudah ada, dan ini sangat selaras dengan jargon yang selalu ditekankan oleh layanan cloud, yaitu “pengurangan biaya pengelolaan infrastruktur”.

Saat ini, merefleksikan tren tersebut, berbagai layanan terkelola telah beroperasi secara representatif, seperti AKS dari Azure, GKE dari Google Cloud (GCP), dan EKS dari AWS.

Dukungan Agen JENNIFER untuk Kubernetes (k8s)

Catatan:

Meskipun artikel ini mengambil contoh lingkungan AKS (Azure Kubernetes Service), dari sudut pandang produk JENNIFER, pada dasarnya ini adalah tentang mendukung k8s, sehingga implementasi serupa dapat diterapkan di semua lingkungan. Selain itu, meskipun terdapat berbagai teknologi kontainer, penjelasan di sini berfokus pada Docker.

Struktur di mana agen JENNIFER mendukung k8s pada dasarnya tidak berbeda dengan cara mendukung lingkungan kontainer biasa. Pada akhirnya, diperlukan sebuah metode untuk memberi tahu kontainer mengenai pengaturan file binary agen serta environment variables. Sebelumnya, agen JENNIFER diaktifkan di lingkungan Docker melalui 2 metode berikut:

1. Menentukan volume tempat binary agen berada serta environment variables saat kontainer dijalankan (runtime).

2. Memasukkan binary agen beserta environment variables langsung ke dalam Dockerfile kontainer yang ada saat proses build.

Karena alat orkestrasi k8s bekerja dengan membungkus kontainer satu tingkat lebih tinggi dan menerapkannya dalam satuan Pod, dukungan agen untuk k8s pada hakikatnya tidak menyimpang dari kedua prinsip di atas.

Metode nomor 2 (memasukkan ke dalam Dockerfile) sebenarnya dapat digunakan langsung apa adanya di lingkungan k8s.

Namun, berbeda dengan struktur tradisional di mana volume dipasang langsung ke kontainer, koneksi volume pada k8s terhubung ke Pod (yang dapat berupa kumpulan kontainer). Karena karakteristik ini, binary agen dihubungkan ke kontainer melalui PV (Persistent Volume) yang ditentukan oleh k8s.

Setelah menyiapkan volume yang berisi binary agen, Anda cukup menambahkan pengaturan volumes dan env yang terhubung ke PV tersebut di dalam file YAML untuk deployment masing-masing layanan.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: net-razor31-sample
...[dihilangkan]...
spec:
...[dihilangkan]...
  template:
...[dihilangkan]...
    spec:
      containers:
...[dihilangkan]...
        env:
        - name: CORECLR_ENABLE_PROFILING
          value: "1"
        - name: CORECLR_PROFILER
          value: "{6C7CAF0F-D0E5-4274-A71B-6551761BBDC8}"
        - name: CORECLR_PROFILER_PATH
          value: "/netagent/bin/libAriesProfiler.so"
        - name: ARIES_SERVER_ADDRESS
          value: "127.0.0.1"
        - name: ARIES_SERVER_PORT
          value: "5000"
        - name: ARIES_DOMAIN_ID
          value: "1000"
        volumeMounts:
        - mountPath: "/netagent"
          name: volume
      volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: my-agent-file

Setelah itu, jika Anda menerapkan file YAML tersebut menggunakan perintah kubectl, Anda dapat melihat bahwa proses monitoring berjalan secara normal:

$ kubectl apply -f demo.yaml

Keunggulan dari platform cloud adalah fleksibilitas dalam menambah atau mengurangi worker node berbasis infrastruktur yang terabstraksi ke dalam k8s. Bersamaan dengan itu, jumlah instance Pod aplikasi juga dapat di-scale baik secara manual maupun otomatis.

Untuk kebutuhan auto-scaling, k8s mendukung fitur Horizontal Pod Autoscaler (HPA), dan perintah yang sama juga dapat digunakan pada AKS.

Sebagai contoh, jika Anda ingin agar deployment demo.yaml yang di-deploy di atas selalu menjalankan minimal 1 instance dan dapat bertambah hingga maksimal 3 instance sesuai dengan beban beban kerja (load), Anda dapat menjalankan perintah berikut:

$ kubectl autoscale deployment --max=3 net-razor31-sample --min=1
horizontalpodautoscaler.autoscaling/net-razor31-sample autoscaled

$ kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
net-razor31-sample-6b747bb886-c2kgk   1/1     Running   0          116s

Seperti yang terlihat, meskipun tidak ada beban trafik yang masuk, 1 Pod akan tetap berjalan. Namun, instance tersebut mungkin belum muncul di JENNIFER Console. Hal ini wajar, karena kondisi di mana Pod sudah aktif (running) berbeda dengan kondisi ketika permintaan (request) aplikasi di dalamnya telah diterima dan diproses.

Tentu saja, jika pengujian beban (load test) dilakukan dalam kondisi ini:

$ docker run --name loadtest --rm -it azch/loadtest http://...[Service URL]

3 Pod akan secara otomatis bertambah (scale out), dan Anda dapat melihat hasilnya secara langsung di JENNIFER Console.