Dalam perjalanan kami membangun produk berbasis microservice ini sungguh kami sangat banyak belajar. Untuk produk yang satu ini kami memutuskan untuk menggunakan Kubernetes sebagai alat orkestrasi service-service yang ada.
Sangat menyenangkan tentunya belajar hal baru, selain banyak tutorial dan memang sedang hype belakangan ini. Hal yang sangat membantu kami adalah kebetulan kami bisa mengoprasikan kubernetes cluster nya dengan lihai.
Sampai suatu ketika muncul keluhan dari beberapa developer sejawat yang mengatakan bahwa salah satu service kadang-kadang tidak dapat di akses. Hanya satu service ini lah yang tidak berjalan sebagaimana mestinya. Nama servicenya tidak dapat kami ungkap, untuk kepentingan privasi yang bersangkutan (ia sangat lah pemalu).
Jadi si service bermasalah ini sebut saja dia Bunga ya. Tinggal di dalam sebuah Kubernetes Cluster dan berada di delakang API Gateway apabila ingin diakses dari luar atau internet. Kira-kira begini lah gambaran kasarnya
Si bunga ini bisa diakses di url httq://apigw.kube.crot.crit/v1/bunga/. Lalu apa sih keluhannya ? Ternyata para sahabat developer kami ini sering menemukan bahwa url tersebut memberikan balikan 502 timeout. Ngomong-ngomong API Gateway yang kami gunakan itu terbuat dari openresty. Nah si openresty ini lah yang memberikan balikan 502.
Setidaknya semua cara yang terbayang di pikiran kami sudah kami coba. Menaikan replica, mengecek koneksi ke database, menaikan timeout di API Gateway dan entah apa lagi. Semua nya tidak menghilangkan erorr tersebut, si 502 tetap kembali.
Sampai akhirnya setelah melakukan penelitian sedikit lebih dalam tentang bagaimana cara kerja Service di kubernetes kami menemukan penyebabnya. Ternyata penjahat nya adalah kami sendiri.
Service di kubernets itu seperti mini Loadbalancer yang membagikan trafik koneksi ke setiap Pod yang ada. Setiap pod akan terwakili dengan satu buah Endpoint. Ketika kami melakukan pengetesan mengakses setiap endpoint yang ada, ternyata koneksi selalu berhasil dan mengeluarkan data sebagai mana mestinya. Namun apabila kami mengakses lewat service maka kadang kala tidak berhasil.
Artinya kadang kala Service tidak dapat menjangkau endpoint tertentu yang terdaftar di manifest service. Setelah kami menyadari hal itu, kami langsung melakukan pengecekan di manifest untuk membuat cronjob. Dan viola disana kami menemukan kesalahan besar itu.
Manifest yang digunakan untuk membuat cronjob tersebut hasil copy-paste dari manifest deployment si Bunga ini. Sehingga pada bagian Metadata -> Labels -> app nya tidak diganti. Hal ini yang menyebabkan Service memasukan pod cronjob sebagai bagian dari nya. Sementara pod crontjob ini tidak meng-expose network port. Hal ini lah yang menyebabkan kadang-kadang akses lewat service tidak mengembalikan data.
Setelah kami rubah labels nya maka si service ini selalu mengembalikan data yang semestinya.
