Network Troubleshooting #

Masalah jaringan di dalam kluster Kubernetes sering kali menjadi salah satu tantangan paling rumit yang dihadapi oleh platform engineer dan developer. Kerumitan ini terjadi karena komunikasi di Kubernetes melibatkan banyak lapisan abstraksi yang saling bertumpuk, mulai dari virtual ethernet (veth) pairs di tingkat kontainer, bridge lokal pada host, enkapsulasi jaringan overlay oleh CNI plugin (seperti VXLAN atau Geneve), aturan pemfilteran paket iptables/IPVS oleh kube-proxy, resolusi nama domain oleh CoreDNS, hingga kebijakan keamanan mikro-segmentasi tingkat L4 melalui NetworkPolicy dan perutean L7 melalui Ingress controller atau Gateway API.

Ketika terjadi gangguan konektivitas, gejala yang muncul sering kali samar, seperti connection timeout, resolusi DNS yang lambat, atau galat 502 Bad Gateway. Tanpa memiliki metodologi pelacakan yang sistematis, kita akan terjebak dalam siklus tebak-tebak berhadiah—seperti melakukan restart paksa pada Pod aplikasi atau node worker secara acak—yang justru mempersulit proses isolasi akar masalah (root cause). Artikel ini menyajikan pendekatan langkah-demi-langkah, instrumen diagnostik yang esensial, serta analisis skenario kegagalan jaringan yang umum terjadi di lingkungan produksi untuk membantu kita mendiagnosis dan menyelesaikan masalah jaringan secara efektif.

Metodologi: Isolasi Lapisan dari Luar ke Dalam #

Untuk mendiagnosis masalah jaringan tanpa kehilangan arah, kita harus menerapkan pendekatan sistematis yang mengisolasi setiap lapisan komunikasi dari yang paling sederhana (konektivitas lokal) hingga yang paling kompleks (perutean L7 dan enkripsi). Kita memulai investigasi dari status Pod individu, bergerak ke konektivitas IP dasar, lalu naik ke resolusi nama DNS, aturan penyeimbangan beban (load balancing), dan terakhir ke kebijakan otorisasi lalu lintas.

Alur diagnosis terstruktur ini membantu kita mengeliminasi kemungkinan penyebab masalah secara cepat, sehingga kita tidak menghabiskan waktu memeriksa konfigurasi Ingress yang rumit jika ternyata CoreDNS kluster sedang mengalami kegagalan fungsi.

Mari kita pelajari alur pohon keputusan diagnostik di bawah ini untuk memahami langkah pelacakan dari kondisi umum (broad) hingga kondisi spesifik (specific):

flowchart TD
    A["Mulai Investigasi Jaringan"] --> B{"1. Apakah Pod Running & Ready?"}
    B -- "Tidak" --> C["Selesaikan Siklus Hidup Pod (Cek Pending/CrashLoopBackOff)"]
    B -- "Ya" --> D{"2. Bisa Ping Pod Lain di Node yang Sama?"}
    
    D -- "Tidak" --> E["Periksa CNI DaemonSet & Interface veth Lokal Node"]
    D -- "Ya" --> F{"3. Bisa Ping Pod di Node Berbeda?"}
    
    F -- "Tidak" --> G["Periksa Routing Overlay (VXLAN/Geneve) & Keamanan Jaringan Node"]
    F -- "Ya" --> H{"4. nslookup kubernetes.default Berhasil?"}
    
    H -- "Tidak" --> I["Periksa CoreDNS Logs, Service, & NetworkPolicy Port 53"]
    H -- "Ya" --> J{"5. Akses Service via ClusterIP IP Berhasil?"}
    
    J -- "Tidak" --> K["Periksa Status kube-proxy & Aturan iptables/IPVS Node"]
    J -- "Ya" --> L{"6. Akses Service via Nama DNS Berhasil?"}
    
    L -- "Tidak" --> M["Periksa Nilai ndots & search domain di /etc/resolv.conf"]
    L -- "Ya" --> N{"7. Endpoints Service Terisi Pod yang Healthy?"}
    
    N -- "Tidak" --> O["Periksa Selector Service, Label Pod, & Status Readiness Probe"]
    N -- "Ya" --> P{"8. Routing Ingress / Gateway API Sukses?"}
    
    P -- "Tidak" --> Q["Periksa Ingress Controller, TargetPort Service, & TLS Certificate"]
    P -- "Ya" --> R["Sistem Jaringan Bekerja Normal"]

Toolkit Debug: Instrumen Diagnostik Esensial #

Untuk menjalankan metodologi di atas, kita membutuhkan instrumen yang tepat. Di lingkungan Kubernetes produksi yang aman, kontainer aplikasi biasanya dibangun menggunakan citra minimal (distroless atau alpine-slim) yang tidak memiliki utilitas jaringan dasar seperti curl, ping, tcpdump, atau nslookup demi menjaga efisiensi ukuran dan meminimalkan celah keamanan (attack surface). Kita dapat memanfaatkan beberapa teknik di bawah ini untuk menyuntikkan perkakas debug ke dalam kluster tanpa merusak integritas aplikasi.

1. Debugging dengan Ephemeral Containers #

Ephemeral container adalah jenis kontainer khusus yang dapat kita jalankan sementara di dalam Pod yang sudah ada untuk melakukan tugas-tugas administratif seperti debugging. Kontainer ini berbagi namespaces jaringan, proses, dan volume yang sama dengan kontainer aplikasi utama, sehingga kita dapat memantau aktivitas jaringan langsung dari dalam konteks Pod tersebut tanpa perlu melakukan restart.

Kita dapat menggunakan citra pengetesan komprehensif seperti nicolaka/netshoot (yang berisi perkakas lengkap seperti tcpdump, tshark, nmap, dig, curl, iperf, dan bind-tools) dengan perintah berikut:

# Jalankan ephemeral container debug di dalam Pod aplikasi yang bermasalah
kubectl debug -it order-processor-85df9b7754-abcde \
  --image=nicolaka/netshoot \
  --target=order-processor-container

Parameter --target sangat penting karena memungkinkan kontainer debug untuk berbagi process namespace dengan kontainer aplikasi target, sehingga kita bisa menjalankan perintah seperti netstat atau memeriksa /proc untuk melihat koneksi soket aktif yang dibuat oleh proses aplikasi utama.

2. Menjalankan Pod Debug Mandiri (Temporary Pod) #

Jika kita hanya ingin menguji resolusi DNS global kluster, konektivitas keluar, atau memindai port layanan tertentu dari dalam jaringan internal kluster, kita bisa membuat Pod debug mandiri yang akan langsung dihapus setelah sesi interaktif kita selesai.

# Jalankan Pod interaktif sementara di namespace default
kubectl run netshoot-temp --image=nicolaka/netshoot -it --rm --restart=Never -- sh

# Jalankan Pod debug di namespace tertentu (misalnya production)
kubectl run netshoot-temp -n production --image=nicolaka/netshoot -it --rm --restart=Never -- sh

Flag --rm memastikan Kubernetes secara otomatis membersihkan objek Pod ini dari etcd saat kita mengetikkan perintah exit di dalam terminal.

3. Memeriksa Status Jaringan dari CLI Control Plane #

Sebelum melompat ke analisis paket data, kita wajib memeriksa kebenaran data konfigurasi jaringan yang disimpan oleh Kubernetes API Server menggunakan perintah-perintah berikut:

# 1. Periksa alokasi IP Pod dan Node tempat Pod berjalan
kubectl get pods -o wide -n production

# 2. Cek apakah Endpoint Service terisi secara dinamis
kubectl get endpoints order-service -n production
kubectl get endpointslices -l kubernetes.io/service-name=order-service -n production

# 3. Deskripsikan konfigurasi port Service secara detail
kubectl describe service order-service -n production

Skenario 1: Pod Gagal Berkomunikasi Lintas Node (Konektivitas CNI) #

Salah satu masalah yang paling sering terjadi setelah instalasi kluster baru atau penambahan node worker baru adalah ketidakmampuan Pod di Node A untuk mengirimkan paket data ke Pod di Node B, meskipun komunikasi antar Pod di dalam Node A berjalan dengan mulus. Gejala utama dari skenario ini adalah koneksi yang langsung mengalami timeout tanpa respon penolakan (connection refused).

Masalah Enkapsulasi Paket dan Jalur Protokol Node #

Ketika Pod A mengirimkan paket ke Pod B di node yang berbeda, CNI plugin bertanggung jawab untuk mengenkapsulasi paket tersebut (biasanya menggunakan protokol VXLAN pada port UDP 4789 atau Geneve pada port UDP 6081) atau merutenya secara langsung menggunakan BGP. Jika jaringan fisik di luar Kubernetes (seperti firewall VPC cloud provider atau switch on-premise) memblokir port UDP tersebut, atau jika terjadi bentrok alokasi subnet IP (PodCIDR collision), maka enkapsulasi paket akan gagal didekapsulasi di node tujuan.

Perbandingan Diagnostik Konektivitas Lintas Node #

Mari kita lihat perbedaan antara pendekatan penanganan yang salah (anti-pattern) dan pendekatan penanganan yang terstruktur (solusi):

# ANTI-PATTERN: Melakukan restart node secara paksa tanpa mendiagnosis
# Tindakan ini tidak menyelesaikan masalah jika penyebabnya adalah port firewall VPC yang tertutup.
sudo reboot  # ✗ Menghilangkan log penting dan mengganggu workload lain secara tidak perlu

# BENAR: Lakukan verifikasi alokasi CIDR, status CNI, dan konektivitas port overlay
# Langkah 1: Periksa apakah alokasi IP Pod (*PodCIDR*) antar node saling bentrok
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# Langkah 2: Jalankan tcpdump di node worker tujuan untuk mendeteksi kedatangan paket VXLAN
# (Jalankan di terminal Node B / Node tujuan)
sudo tcpdump -i any port 4789 -n -vv

# Langkah 3: Uji konektivitas UDP port 4789 dari Node A ke Node B menggunakan nc
nc -vzu <IP-Node-B> 4789

Jika perintah nc menunjukkan status koneksi tersendat (timeout), kita wajib membuka port UDP 4789 di sistem keamanan firewall infrastruktur kita (seperti Security Group di AWS/GCP atau aturan firewall lokal ufw/firewalld).

Skenario 2: Kegagalan Resolusi DNS (CoreDNS & NetworkPolicy) #

Aplikasi kita tiba-tiba memunculkan galat seperti dial tcp: lookup inventory-db on 10.96.0.10:53: no such host atau Temporary failure in name resolution. Masalah ini berakibat fatal karena aplikasi tidak dapat menemukan lokasi basis data atau mikroservis downstream meskipun Pod target berada dalam kondisi aktif dan sehat.

Bagaimana Name Resolution Bekerja di Kubernetes #

Kubelet secara otomatis mengonfigurasi berkas /etc/resolv.conf di setiap kontainer dengan mengarahkan alamat nameserver ke IP ClusterIP dari Service CoreDNS (biasanya berakhiran .10 di subnet Service). Berkas ini juga mendefinisikan parameter search domain agar aplikasi dapat memanggil service lain hanya dengan menggunakan nama pendek (short name):

nameserver 10.96.0.10
search production.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Jika terjadi masalah pada CoreDNS, resolusi DNS akan terhenti sepenuhnya. Masalah ini bisa disebabkan oleh CoreDNS Pod yang mengalami kehabisan memori (OOMKilled), beban kueri yang terlalu tinggi akibat konfigurasi ndots yang tidak efisien, atau adanya NetworkPolicy baru yang memblokir lalu lintas keluar dari Pod ke port 53 UDP/TCP di namespace kube-system.

Perbandingan Penanganan Isu DNS #

Berikut adalah visualisasi kode perbandingan antara penanganan bypass yang buruk dengan diagnosa akar masalah yang benar:

# ANTI-PATTERN: Menulis DNS eksternal langsung di manifes Pod untuk mem-bypass CoreDNS
# ✗ Ini merusak prinsip portabilitas kluster dan memutus akses ke Service internal kluster
apiVersion: v1
kind: Pod
metadata:
  name: web-app-bad
spec:
  containers:
  - name: app
    image: my-app:v1
  dnsConfig:
    nameservers:
      - 8.8.8.8  # Bypassing CoreDNS - Aplikasi tidak bisa lagi mengakses database-service.local!
---
# BENAR: Buat NetworkPolicy yang secara eksplisit mengizinkan kueri DNS ke CoreDNS
# ✓ Ini menjaga keamanan zero-trust tanpa mengorbankan fungsionalitas DNS internal
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}  # Berlaku untuk semua Pod di namespace ini
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns  # Arahkan ke Pod CoreDNS
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Untuk mendiagnosis apakah CoreDNS berfungsi dengan baik, kita dapat menjalankan perintah pengujian resolusi DNS interaktif dari Pod debug:

# Kueri DNS ke Service internal menggunakan FQDN lengkap
dig @10.96.0.10 kubernetes.default.svc.cluster.local

# Periksa log CoreDNS untuk mendeteksi adanya error forwarding atau kueri loop
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100

Skenario 3: Service ClusterIP Tidak Dapat Diakses (Kube-Proxy & Endpoints) #

Kita memiliki Service bertipe ClusterIP yang dikonfigurasi untuk mengekspos aplikasi backend. Namun, ketika frontend mencoba mengirim permintaan HTTP ke alamat ClusterIP tersebut, koneksi selalu berakhir dengan status connection refused atau timeout. Menariknya, jika kita mencoba menghubungi IP Pod backend secara langsung, koneksi berjalan dengan lancar.

Kube-proxy dan Mekanisme Penerusan Paket Virtual IP #

ClusterIP bukanlah antarmuka jaringan fisik (virtual network interface) yang nyata. Alamat ClusterIP hanyalah aturan IP virtual (VIP) yang didaftarkan di dalam memori kernel Node oleh agen kube-proxy. Kube-proxy beroperasi dalam dua mode utama:

iptables mode: Kube-proxy menulis rantai (chains) iptables yang panjang untuk mencegat paket yang ditujukan ke IP ClusterIP, lalu melakukan translasi alamat (DNAT) secara acak ke salah satu IP Pod backend yang sehat.
IPVS mode: Kube-proxy menggunakan tabel hash IPVS di tingkat kernel Linux yang jauh lebih efisien untuk kluster berskala besar dengan ribuan service.

Jika kita tidak bisa mengakses Service via ClusterIP, kemungkinan besar penyebabnya adalah:

Endpoints Kosong: Tidak ada Pod backend yang lolos verifikasi Readiness Probe, sehingga Service tidak memiliki target rute.
Selector Salah: Label yang didefinisikan pada Service selector tidak cocok dengan label yang dipasang pada Pod aplikasi.
Kube-proxy Macet: Agen kube-proxy di node tempat client berjalan gagal menyelaraskan aturan iptables/IPVS dari API Server.

Perbandingan Diagnostik Service #

Mari kita bandingkan tindakan perbaikan yang keliru dengan langkah verifikasi aturan perutean yang tepat:

# ANTI-PATTERN: Menulis IP Pod secara statis di aplikasi untuk mem-bypass Service
# ✗ Ini merusak skalabilitas kluster karena IP Pod bersifat ephemeral (sementara)
curl http://10.244.2.35:8080  # Menghubungi IP Pod langsung secara hardcode

# BENAR: Verifikasi kecocokan label selector dan periksa aturan iptables di Node worker
# Langkah 1: Cek apakah ada endpoints aktif yang terikat pada Service kita
kubectl get endpoints order-service

# Langkah 2: Jika endpoints kosong, bandingkan selector Service dengan label Pod aktual
kubectl get service order-service -o jsonpath='{.spec.selector}'
kubectl get pods -l app=order-processor --show-labels

# Langkah 3: Periksa aturan NAT iptables yang dibuat oleh kube-proxy di dalam node worker
# (Jalankan dengan hak akses root di Node worker tempat Pod client berada)
sudo iptables-save -t nat | grep order-service

Aturan iptables yang benar akan memunculkan entri rantai seperti KUBE-SVC-XXXX yang melakukan perutean probabilitas (statistic mode random) ke IP Pod backend yang terdaftar di endpoints.

Skenario 4: Ingress Mengembalikan Galat 502 / 503 (Upstream Mismatch) #

Pengguna luar yang mencoba mengakses aplikasi kita melalui domain publik mendapatkan halaman galat 502 Bad Gateway atau 503 Service Unavailable yang berasal dari Ingress Controller (seperti ingress-nginx).

HTTP/1.1 502 Bad Gateway
Server: nginx/1.25.3
Content-Type: text/html
Content-Length: 150

Membedakan Letak Kegagalan: Ingress Controller ke Service, atau Service ke Pod #

Galat 502/503 menunjukkan bahwa Ingress Controller berhasil menerima permintaan dari internet, namun gagal meneruskan paket tersebut ke aplikasi backend (upstream). Letak kegagalan ini dapat diisolasi dengan memeriksa hubungan port antara Ingress, Service, dan Pod:

[Client] ---> (Port 443) Ingress ---> Service (Port 80) ---> Pod (TargetPort 8080)
                                      ^                      ^
                                  Salah Port?            Crash/Not Ready?

Sering kali, developer salah menuliskan konfigurasi service.port di manifes Ingress, mengarahkan port ke port kontainer langsung (targetPort) alih-alih port logis Service (port), atau aplikasi di dalam kontainer mati mendadak sehingga tidak ada soket yang mendengarkan (listening) di port target.

Perbandingan Konfigurasi Perutean Ingress #

Mari kita pelajari contoh perbaikan manifes perutean di bawah ini:

# ANTI-PATTERN: Menghubungkan Ingress langsung ke targetPort kontainer aplikasi
# ✗ Ini salah karena Ingress wajib menunjuk ke port logis yang didefinisikan pada Service
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-ingress-bad
spec:
  rules:
  - host: orders.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 8080  # ✗ SALAH: Ini adalah targetPort kontainer, bukan port Service!
---
# BENAR: Selaraskan port Ingress dengan port publik Service secara konsisten
# ✓ Ingress menunjuk ke Service port 80, yang kemudian diteruskan Service ke targetPort Pod
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-ingress-good
spec:
  rules:
  - host: orders.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 80  # ✓ BENAR: Port ini cocok dengan Service spec.ports[0].port

Untuk memverifikasi konektivitas ini secara langsung, kita dapat menggunakan teknik port-forwarding untuk mem-bypass seluruh lapisan Ingress dan Service:

# Teruskan lalu lintas lokal port 9000 langsung ke port kontainer 8080 di Pod
kubectl port-forward pod/order-processor-85df9b7754-abcde 9000:8080

# Uji aplikasi dari terminal lokal kita
curl -I http://localhost:9000/healthz

Jika pengujian di atas berhasil namun Ingress tetap mengembalikan galat 502, kita wajib memeriksa berkas log dari Ingress Controller untuk melihat detail kegagalan koneksi ke upstream:

kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=50

Skenario 5: Paket Data Hilang Misterius (Pendeteksian Drop NetworkPolicy) #

Kita baru saja menerapkan kerangka kerja keamanan zero-trust dengan memasang kebijakan NetworkPolicy default-deny untuk mengisolasi lingkungan database produksi. Namun, setelah kebijakan tersebut dipasang, mikroservis backend kita kehilangan kemampuan untuk menyimpan data ke database PostgreSQL. Tidak ada log error jaringan yang jelas di sisi backend selain pesan timeout koneksi basis data.

Pemantauan Paket Drop di Tingkat Kernel #

NetworkPolicy diimplementasikan oleh CNI plugin menggunakan modul kernel Linux (seperti aturan pencocokan iptables,ipset, atau program eBPF yang dimuat ke dalam antarmuka jaringan kontainer). Ketika paket data diblokir oleh NetworkPolicy, sistem operasi secara diam-diam akan membuang (drop) paket tersebut tanpa mengirimkan paket balasan ICMP penolakan ke pengirim. Akibatnya, aplikasi pengirim hanya akan mendeteksi status timeout.

Jika kita menggunakan CNI modern berbasis eBPF seperti Cilium, kita memiliki kemampuan luar biasa untuk memantau pembuangan paket ini secara real-time langsung di tingkat kernel menggunakan utilitas monitor Cilium.

Perbandingan Analisis Drop Jaringan #

Mari kita bandingkan pendekatan tebak-tebakan dengan teknik pemantauan paket drop yang canggih:

# ANTI-PATTERN: Menghapus NetworkPolicy di lingkungan produksi untuk pengujian
# ✗ Ini sangat berbahaya karena membuka celah keamanan bagi tenant lain selama pengujian
kubectl delete networkpolicy secure-database-policy -n production

# BENAR: Pantau pembuangan paket secara real-time menggunakan monitor CNI Cilium
# Langkah 1: Temukan nama Pod CNI Cilium yang berjalan di node worker aplikasi
kubectl get pods -n kube-system -l k8s-app=cilium -o wide

# Langkah 2: Jalankan cilium monitor dengan filter tipe pembuangan paket (drop)
# (Perintah ini akan mendeteksi alasan pembuangan paket beserta identitas policy-nya)
kubectl exec -it -n kube-system cilium-xxxxx -- cilium monitor --type drop

Output monitor Cilium akan memberikan kejelasan yang sangat presisi tentang alasan pembuangan paket:

xx drop at L3: packet dropped by local policy (egress) flow-id=102345 saddr=10.244.1.45 daddr=10.244.2.12 dport=5432

Dengan informasi ini, kita tahu pasti bahwa ada kebijakan egress pada Pod pengirim (10.244.1.45) yang memblokir lalu lintas keluar ke port 5432 milik database (10.244.2.12). Kita dapat segera memperbaikinya dengan menulis aturan NetworkPolicy egress yang tepat tanpa perlu mematikan pengamanan kluster kita.

Checklist Diagnostik Jaringan Produksi #

Gunakan daftar periksa di bawah ini sebagai panduan cepat saat kita dipanggil untuk menangani insiden jaringan di tengah malam:

STATUS POD & KELAYAKAN DASAR:
  □ Periksa status siklus hidup Pod (`kubectl get pods -o wide`)
  □ Pastikan kontainer tidak sedang restart atau dalam status CrashLoopBackOff
  □ Verifikasi status Readiness Probe aplikasi (`kubectl describe pod`)

KONEKTIVITAS IP (PING & ROUTING):
  □ Ping IP Pod tujuan dari kontainer debug di node yang sama
  □ Ping IP Pod tujuan dari kontainer debug di node worker yang berbeda
  □ Uji konektivitas port enkapsulasi overlay CNI (port UDP 4789 / 6081) antar host

RESOLUSI DNS (CORE_DNS):
  □ Jalankan `nslookup kubernetes.default` dari dalam Pod yang mengalami masalah
  □ Periksa log kesalahan CoreDNS (`kubectl logs -n kube-system -l k8s-app=kube-dns`)
  □ Pastikan NetworkPolicy mengizinkan egress UDP/TCP ke port 53 di namespace kube-system
  □ Cek opsi `ndots` di `/etc/resolv.conf` jika resolusi eksternal lambat

ATURAN SERVICE & PENERUSAN BEBAN:
  □ Pastikan Service memiliki list Endpoints yang tidak kosong (`kubectl get endpoints`)
  □ Cocokkan selector label Service dengan label aktual yang terpasang pada Pod
  □ Periksa kesehatan kube-proxy pod di node worker (`kubectl get pods -n kube-system -l k8s-app=kube-proxy`)

RUTE L7 & INGRESS CONTROLLER:
  □ Lakukan pengujian port-forward ke Pod backend secara langsung untuk memvalidasi aplikasi
  □ Periksa kecocokan port logis Service dengan target port kontainer aplikasi
  □ Analisis log kesalahan upstream pada pod Ingress Controller (`kubectl logs -n ingress-nginx`)

Ringkasan #

Terapkan teknik isolasi bertahap: Mulai diagnosa jaringan dari status Pod, lalu konektivitas IP mentah, resolusi DNS, aturan Service, hingga aturan rute L7 Ingress. Jangan melompat ke konfigurasi Ingress sebelum memastikan IP backend dapat dihubungi.

Gunakan Ephemeral Container untuk debug: Manfaatkan perintah kubectl debug dengan citra nicolaka/netshoot agar kita bisa mengakses perkakas diagnostik lengkap di dalam Pod tanpa harus mengubah citra produksi aplikasi kita.

Pantau Endpoints Service: Jika Service mengembalikan koneksi gagal, periksa apakah daftar Endpoints kosong. Hal ini sering disebabkan oleh kegagalan aplikasi melewati Readiness Probe atau kesalahan penulisan label selector.

Waspadai dampak ndots pada latensi DNS: Aturan ndots:5 bawaan Kubernetes memaksa pencarian nama domain eksternal melakukan iterasi kueri internal terlebih dahulu. Gunakan tanda titik di akhir domain (FQDN trailing dot) untuk mempercepat resolusi.

Buka port enkapsulasi CNI di firewall: Pastikan port lalu lintas enkapsulasi CNI (seperti port UDP 4789 untuk VXLAN) terbuka di tingkat firewall jaringan fisik atau cloud provider guna menjamin kelancaran komunikasi lintas node.

Gunakan instrumen CNI untuk melacak drop: Manfaatkan alat pemantauan bawaan CNI (seperti cilium monitor) untuk melihat paket yang dibuang secara diam-diam oleh aturan NetworkPolicy yang terlalu ketat.

Navigasi #

← Sebelumnya: Ingress Controller Comparison Berikutnya: Anti-Pattern Networking →