Aplikasi Kubernetes Tidak Bisa Terhubung ke Redis? Ini Cara Menemukan Akar Masalahnya
Ketika sebuah aplikasi yang berjalan di Kubernetes tiba-tiba mengalami CrashLoopBackOff, banyak administrator langsung mengira database atau Redis sedang bermasalah.
Padahal dalam praktiknya, akar masalah tidak selalu berada pada service yang dituju. Terkadang sumber gangguan justru berasal dari infrastruktur jaringan Kubernetes itu sendiri.
Pada artikel ini, kita akan membahas proses troubleshooting nyata ketika sebuah aplikasi gagal terhubung ke Redis meskipun Redis dalam kondisi normal.
Gejala yang Muncul
Beberapa gejala yang ditemukan antara lain:
- Pod aplikasi mengalami CrashLoopBackOff
- Aplikasi terus melakukan restart otomatis
- Log aplikasi menampilkan pesan DNS timeout
- Service Redis terlihat berjalan normal
- Redis dapat diakses dari pod lain
Contoh pesan error:
Could not connect to Redis:
lookup redis.service.cluster.local: i/o timeout
Sekilas error tersebut terlihat seperti Redis tidak aktif.
Namun setelah dilakukan investigasi lebih lanjut, ternyata penyebabnya berbeda.
Langkah 1: Verifikasi Redis
Langkah pertama adalah memastikan Redis benar-benar berjalan.
Beberapa hal yang perlu diperiksa:
Status Pod Redis
Pastikan pod Redis berstatus Running.
Service Redis
Pastikan service Redis tersedia dan memiliki ClusterIP yang valid.
Endpoint Redis
Pastikan endpoint mengarah ke pod Redis yang aktif.
Port Redis
Pastikan port 6379 dapat diakses.
Hasil pemeriksaan menunjukkan:
✅ Redis berjalan normal
✅ Service tersedia
✅ Endpoint aktif
✅ Port Redis terbuka
Kesimpulan sementara:
Redis bukan sumber masalah.
Langkah 2: Uji DNS dan Koneksi dari Pod Lain
Untuk memastikan DNS Kubernetes bekerja dengan baik, lakukan pengujian dari pod lain yang berjalan normal.
Beberapa pengujian yang dapat dilakukan:
Uji DNS
nslookup redis.service.cluster.local
Uji Port Redis
nc -vz redis.service.cluster.local 6379
Hasil:
✅ DNS berhasil melakukan resolusi
✅ Port Redis dapat diakses
Kesimpulan:
DNS cluster secara umum masih berfungsi dengan baik.
Langkah 3: Fokus ke Pod yang Bermasalah
Karena Redis dan DNS cluster normal, perhatian diarahkan ke pod aplikasi yang mengalami CrashLoopBackOff.
Dari log aplikasi ditemukan:
lookup redis.service.cluster.local: i/o timeout
Artinya:
Aplikasi gagal mendapatkan alamat Redis melalui DNS.
Dengan kata lain:
Masalah bukan pada Redis, tetapi pada proses pencarian alamat Redis.
Langkah 4: Membandingkan Node yang Sehat dan Bermasalah
Pengujian berikutnya dilakukan dengan menjalankan pod test pada node yang sama dengan aplikasi yang bermasalah.
Hasilnya cukup menarik.
Pada node lain:
✅ DNS berjalan normal
✅ Service dapat diakses
Pada node aplikasi:
❌ DNS timeout
❌ Tidak dapat menjangkau DNS service cluster
Temuan ini menunjukkan bahwa masalah hanya terjadi pada satu node tertentu.
Langkah 5: Investigasi Komponen Jaringan Kubernetes
Setelah dilakukan pemeriksaan lebih mendalam ditemukan indikasi bahwa node tersebut menyimpan informasi jaringan yang sudah tidak valid.
Akibatnya:
- DNS service tidak dapat dijangkau
- Rule jaringan tidak tersinkron
- Informasi endpoint yang digunakan sudah tidak relevan
Dalam kondisi seperti ini Kubernetes masih menganggap node “Ready”, tetapi state jaringan internal sebenarnya sudah tidak sinkron.
Akar Masalah yang Ditemukan
Akar masalah ternyata bukan:
❌ Redis
❌ Aplikasi
❌ CoreDNS
Melainkan:
✅ State jaringan pada salah satu node Kubernetes tidak sinkron dengan kondisi cluster saat ini.
Node tersebut masih menggunakan informasi lama sehingga gagal menghubungi layanan DNS cluster.
Akibatnya:
Aplikasi
↓
Mencari alamat Redis
↓
DNS timeout
↓
Redis tidak ditemukan
↓
CrashLoopBackOff
Solusi yang Dilakukan
Langkah perbaikan yang dilakukan cukup sederhana.
Restart layanan agent Kubernetes pada node yang bermasalah:
systemctl restart rke2-agent
Tujuan restart:
- Menyinkronkan ulang state jaringan
- Memperbarui informasi service
- Memperbarui rule jaringan Kubernetes
- Memastikan komunikasi ke control plane kembali normal
Hasil Setelah Perbaikan
Setelah layanan Kubernetes di-restart:
✅ DNS kembali normal
✅ Service dapat ditemukan
✅ Redis dapat diakses
✅ Pod aplikasi berhasil Running
✅ CrashLoopBackOff hilang
Aplikasi kembali beroperasi secara normal tanpa perubahan pada kode aplikasi maupun konfigurasi Redis.
Pelajaran Penting
Ketika terjadi masalah koneksi antar service di Kubernetes:
Jangan langsung menyalahkan aplikasi atau database.
Lakukan pemeriksaan secara bertahap:
- Verifikasi service tujuan
- Verifikasi endpoint
- Verifikasi DNS
- Verifikasi konektivitas jaringan
- Verifikasi node tempat pod berjalan
Pendekatan ini dapat menghemat banyak waktu dalam proses troubleshooting.
Kesimpulan
Kasus ini menunjukkan bahwa error koneksi ke Redis belum tentu disebabkan oleh Redis itu sendiri.
Dalam lingkungan Kubernetes, masalah dapat berasal dari node yang kehilangan sinkronisasi jaringan sehingga gagal mengakses DNS cluster.
Dengan proses troubleshooting yang sistematis, akar masalah dapat ditemukan lebih cepat dan perbaikan dapat dilakukan tanpa mengganggu layanan lain dalam cluster.
“Troubleshooting yang baik bukan tentang menebak-nebak, tetapi menghilangkan kemungkinan satu per satu hingga akar masalah ditemukan.”
FAQ
1. Apa itu CrashLoopBackOff?
CrashLoopBackOff adalah kondisi ketika container terus gagal berjalan dan Kubernetes mencoba menjalankannya kembali secara berulang.
2. Apakah Redis selalu menjadi penyebab jika muncul error koneksi Redis?
Tidak. Masalah bisa berasal dari DNS, jaringan, firewall, service, endpoint, atau node Kubernetes.
3. Mengapa DNS timeout bisa menyebabkan aplikasi gagal?
Karena aplikasi tidak dapat menemukan alamat IP tujuan sehingga koneksi tidak dapat dibuat.
4. Apa fungsi CoreDNS di Kubernetes?
CoreDNS bertugas menerjemahkan nama service menjadi alamat IP yang dapat diakses oleh pod.
5. Kapan perlu me-restart rke2-agent?
Ketika ditemukan indikasi state jaringan node tidak sinkron atau komunikasi dengan control plane mengalami gangguan.
Quote Menarik
“Semakin kompleks infrastrukturnya, semakin penting melakukan troubleshooting berdasarkan fakta, bukan asumsi.”
Pernah mengalami kasus serupa di Kubernetes atau Redis?
Bagikan pengalaman Anda di kolom komentar. Jika artikel ini bermanfaat, jangan lupa share kepada rekan tim DevOps, SysAdmin, dan Network Engineer lainnya.
Ikuti juga artikel terbaru seputar Linux Server, Kubernetes, Cloud Infrastructure, dan Administrasi Sistem agar tidak ketinggalan tips troubleshooting dunia nyata.
