Pada infrastruktur tersebut akan dibuat kubernetes cluster dengan berbagai layanan di dalamnya. Layanan tersebut terdiri dari content management system, web profile, file sharing, aplikasi meeting, dan monitoring. Layanan content management system menggunakan container dari wordpress, layanan web profile menggunakan container spring-petclinic, layanan file sharing menggunakan container dari owncloud, layanan aplikasi meeting menggunakan container dari jitsi, dan layanan monitoring menggunakan kubernetes dashboard dari kubernetes serta layanan monitoring VM instances bawaan dari Google Cloud Platform. Selain, itu, pembuatan kubernetes cluster tersebut dilakukan melalui automasi menggunakan Ansible serta akan dilakukan testing menggunakan jmeter.
Diperlukan sebanyak 8 instance dengan spesifikasi seperti di bawah ini. Pastikan OS yang digunakan adalah Ubuntu 20.04 dan storage yang diperlukan dari masing-masing instance minimal adalah 10 GB.
Instalasi Ansible dapat dilakukan pada PC lokal atau menggunakan instance VM di cloud sebagai control node. Tutorial ini menggunakan WSL pada PC lokal untuk memudahkan konfigurasi. Referensi instalasi lebih lanjut dapat dilihat melalui dokumentasi Ansible atau melalui sumber berikut https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-ansible-on-ubuntu-20-04. Berikut merupakan tahap yang dilakukan.
- Install Ansible pada WSL.
sudo apt update
sudo apt install ansible
Pastikan ansible sudah terinstall
- Menghubungkan control node dengan managed node.
Setelah ansible telah diinstall, ansible perlu melakukan komunikasi dengan setiap node yang ada. Dengan demikian, pastikan anda dapat SSH ke setiap VM instance yang telah dibuat. Untuk dapat SSH ke setiap VM instance, buatlah ssh key terlebih dahulu pada PC lokal.
- Input:
# Generate key pada control node. Ikuti langkah pembuatannya
ssh-keygen -t rsa -f ~/.ssh/<FILE_NAME> -C <USER> -b 2048
# Lihat isi key yang dibuat kemudian copy isi file tersebut.
cat ~/.ssh/<FILE_NAME>.pub
Ubah <FILE_NAME>
dan <USER>
sesuai kebutuhan.
- Output
Setelah itu, tambahkan isi dari output tersebut ke SSH Keys
pada GCP Project agar PC lokal dapat SSH ke setiap VM instance pada project.
- Clone repository ini pada PC lokal dan lakukan penyesuaian pada file
hosts
. Ubah IP pada tiap baris sesuai denganExternal IP
dari VM Instance dan sesuaikanansible_user
dengan<USER>
dari ssh tadi.
Akan lebih baik apabila dapat diautomasi dari pembuatan instance hingga memasukkan IP yang sesuai ke file
host
dari instance tersebut. Hal tersebut dapat dilakukan menggunakan Terraform atau menggunakan script linux secara manual. Namun, hal tersebut belum dapat dilakukan karena kami masih kurang familiar dengan tools tersebut.
- Jalankan
chmod +x ansible_script.sh
./ansible_script.sh
Scripts tersebut terdiri dari inisiasi host dan pembuatan user ubuntu
pada setiap node agar ansible dapat berkomunikasi dengan berbagai node untuk melakukan instalasi yang diperlukan. Setelah itu, dilakukan juga instalasi berbagai dependensi yang diperlukan untuk membuat kubernetes cluster. Luaran dari scripts tersebut adalah kubernetes cluster telah berjalan dengan node master
sebagai kubernetes master nya, dan node lainnya sebagai workers agar dapat dilakukan auto deployment dan auto scaling aplikasi dengan mudah pada tiap node. Pastikan tidak ada error setelah menjalankan scripts tersebut.
- SSH ke dalam master/controller node kubernetes
Setelah kubernetes cluster telah berhasil dibuat, node master dapat menjalankan berbagai perintah untuk melakukan deployment pada node lainnya. Untuk itu, lakukan SSH ke node master dari PC lokal.
ssh -i ~/.ssh/<FILE_NAME> ubuntu@<EXTERNAL_IP_MASTER>
Lakukan penyesuaian <FILE_NAME>
dari SSH yang telah dibuat tadi.
- Pastikan setiap VM instance telah terhubung
Perlu dipastikan bahwa kubernetes cluster telah muncul dan setiap node workers berstatus Ready
untuk menerima arahan dari node master.
Input:
kubectl get node
Output:
- Tambahkan label pada setiap node untuk memudahkan deployment pada step selanjutnya.
Penambahan label pada setiap node dilakukan agar nantinya pod terdeploy pada node yang sesuai dengan labelnya.
Input:
kubectl label nodes master group=master
kubectl label nodes wprofile1 group=wprofile
kubectl label nodes wprofile2 group=wprofile
kubectl label nodes wprofile3 group=wprofile
kubectl label nodes monitoring group=monitoring
kubectl label nodes file-sharing group=file-sharing
kubectl label nodes meeting-app group=meeting-app
kubectl label nodes db group=db
Pastikan label telah ditambahkan dengan:
kubectl get nodes --show-labels
- Clone scripts dari node master dan jalankan perintah berikut
git clone https://github.com/filedumpamal/k8s-ansible-gcp.git
cd k8s-ansible-gcp/scripts-kubernetes/
kubectl apply -f 1-web-profile-deployment/wordpress/
kubectl apply -f 1-web-profile-deployment/petclinic/
kubectl apply -k 3-file-sharing/owncloud/
kubectl apply -f 2-monitoring/
Untuk deployment meeting-app,
cd 4-meeting-application/
dan jalankan perintah pada README.md
Berbagai perintah tersebut dijalankan untuk membuat deployment aplikasi ke node yang sesuai dengan label. Agar pod terdeploy ke node dengan label yang sesuai, terdapat baris
...
nodeSelector:
group: wprofile
...
pada objek kubernetes dengan tipe deployment.
- Cek pod telah terdeploy di node yang sesuai dengan cara
kubectl get pods --output=wide
- Cek berbagai objek kubernetes yang telah dibuat dengan cara seperti pada gambar berikut
- Setting firewall pada GCP console untuk node yang menjalankan service pada port yang sesuai agar service dapat diakses darimanapun.
gcloud compute firewall-rules create <SETTING_NAME> --allow tcp:<PORT> --source-tags=<VM_INSTANCE_1>,<VM_INSTANCE_2>,<...> --source-ranges=0.0.0.0/0
- Cek masing-masing layanan dapat berjalan dengan lancar.
- Petclinic
- Wordpress
- Owncloud
- Jitsi
- Kubernetes Dashboard
Untuk dapat melihat kubernetes dashboard, jalankan perintah berikut agar mendapatkan token untuk login.
Input:
kubectl get svc -n kubernetes-dashboard
kubectl get secret -n kubernetes-dashboard $(kubectl get serviceaccount admin-user -n kubernetes-dashboard -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 --decode
Output:
Copy token tersebut ke halaman awal untuk login
- Apabila telah selesai, dapat exit dari node master dengan cara
exit
Untuk melakukan penghapusan semua objek kubernetes yang telah dibuat, dapat menggunakan perintah berikut.
- SSH ke node master
- cd directory github
kubectl delete -f 1-web-profile-deployment/wordpress/
kubectl delete -f 1-web-profile-deployment/petclinic/
kubectl delete -k 3-file-sharing/owncloud/
kubectl delete ns jitsi
kubectl delete -f 2-monitoring/
Akan dilakukan testing layanan dengan skenario pertama yaitu tanpa menggunakan load balancer, dan skenario kedua yaitu menggunakan load balancer. Load balancer yang digunakan adalah load balancer bawaan dari Kubernetes. Pada Kubernetes, setiap pods dimana aplikasi berjalan biasanya bersifat sementara dan mendapatkan IP address baru setiap deployment selanjutnya. Pods biasanya secara dinamis dihapus dan dibuat ulang pada setiap deployment. Tanpa adanya kubernetes service, diperlukan tracking terhadap IP adress dari setiap pod. Oleh karena itu, LoadBalancer service digunakan agar dapat mengekspose pod ke luar sesuai dengan metode yang digunakan oleh cloud provider dengan mudah. Layanan yang akan dilakukan pengetesan adalah petclinic dengan melakukan form filling sesuai dengan skenario yang akan dijelaskan lebih lanjut pada bagian selanjutnya.
Agar dapat melakukan monitoring secara komprehensif, dapat menggunakan layanan monitoring bawaan dari GCP. Untuk itu, perlu dilakukan instalasi agent pada tiap node dengan menuju halaman berikut.
Jalankan command tersebut di cloud shell hingga Ops Agent berstatus hijau.
Testing ini dilakukan menggunakan tools Apache JMeter. Untuk instalasi dapat mengacu pada https://jmeter.apache.org/usermanual/get-started.html. Selanjutnya, jalankan ApacheJMeter.jar untuk membuka aplikasi.
Secara umum, siklus penggunaan JMeter adalah:
- Menambahkan Thread Group;
- Menambahkan HTTP Request;
- Menambahkan report untuk menampilkan hasil Performance test;
- Menjalankan Performance test;
- Mengamati dan mengalisis report dari performance test.
Akan dibuat thread group dengan spesifikasi sebagai berikut:
- Number of Threads, yaitu jumlah user sebanyak 100 orang
- Ramp-up period, yaitu 200 detik
- Setiap 2 detik (Ramp-up period/Number of Threads = 200/100 = 2), akan mengirimkan 10 request ke server.
- Total jumlah sample = 1000 (100 x 10)
Berikut merupakan rincian dari pengetesan dan hasilnya.
Dapat dilihat dari gambar di atas, untuk pengetesan tanpa load balancer dimulai dari 13:54:17 hingga 13:57:42. Dan pengetesan menggunakan load balancer dari 13:59:00 hingga 14:02:27.
Warna hijau, biru tua, dan abu-abu masing-masing menunjukkan node wprofile1, wprofile2, dan wprofile3 untuk layanan web profile. Warna pink menunjukkan node master sebagai load balancer. Secara keseluruhan, dibandingkan dengan concurrent request dengan load balancer, aktivitas server cenderung lebih berat dari sisi CPU utilization dan network.
- Wordpress tidak dapat dibuka apabila dilakukan penyetingan menggunakan
nodeSelector
. Tanpa adanya setting tersebut, pod wordpress dapat dijalankan, tetapi akan dideploy pada node dengan label random yang tersedia. - Apabila dijalankan beberapa MySQL pada node db, terkadang muncul konflik sehingga sebagian pod lainnya akan berhenti dan error. Alasan yang mungkin adalah karena salah setting pada persistance volume. Terdapat berbagai jenis persistance volume dan penyusun laporan ini belum benar-benar memahami berbagai jenis pv tersebut dan cara menggunakannya. Sebagian besar, persistance volume menggunakan node dari tempat dideploynya pod. Hal tersebut kemungkinan besar memicu konflik direktori antara pod satu dan pod lainnya yang berbeda tujuan. Alasan lain yang mungkin adalah karena salah setting claim untuk persistance volume tersebut.
- Berdasarkan beberapa refensi, persistance volume aplikasi asli jarang sekali menggunakan hostPath. Biasanya menggunakan storage yang disediakan oleh cloud atau mengkonfigurasikannya sendiri pada node yang sesuai. Namun, penyusun laporan masih kurang paham caranya sehingga belum dapat dilakukan.
- Layanan meeting Jitsi hanya berhasil masuk sampai awal halaman, tetapi sering error saat klik mulai meeting. Terdapat banyak hal yang perlu dikonfigurasi dan kemungkinan terdapat salah konfigurasi. Aplikasi memerlukan self signed certificate untuk dapat dijalankan dengan HTTPS dan juga memerlukan domain, sehingga kemungkinan terdapat salah setting untuk bagian tersebut yang menyebabkan Jitsi tidak dapat dijalankan dan dilakukan testing video streaming.
- Layanan monitoring pada awalnya akan menggunakan Zabbix, tetapi konfigurasi Zabbix untuk Kubernetes cukup rumit sehingga belum dapat berjalan hingga saat ini dan akhirnya dicoba menggunakan kubernetes dashboard dengan limitasi tidak dapat melakukan monitoring secara historis atau hanya dapat melihat proses berjalannya saja dan kubernetes object mana yang berjalan atau tidak. Alternatif lainnya, penyusun laporan mencoba menggunakan layanan monitoring VM Instance bawaan dari Google Cloud Platform yang dapat diinstall dengan mudah.
Tes file sharing
https://www.blazemeter.com/blog/how-performance-test-upload-and-download-scenarios-apache-jmeter
Tes video streaming
https://www.blazemeter.com/blog/load-testing-video-streaming-with-jmeter-learn-how