Kubernetes Cluster Mati Setelah Node Reboot: Postmortem Lengkap

Harusnya itu Minggu yang biasa-biasa aja. Tapi terus alert-nya mulai berdatangan.

Monitoring dashboard gue nyala jam 12:35 tanggal 6 April 2026. Log entry-nya tertulis: “Device rebooted after 1 year 275 days 22 hours 40 minutes 4 seconds.” Satu baris itu udah cukup buat bilang segalanya. Master node cluster Kubernetes production gue, yang udah jalan tanpa henti hampir dua tahun, baru aja reboot sendiri.

Yang terjadi setelahnya adalah sesi troubleshooting beberapa jam buat balikin enam node ke status Ready. Ini cerita lengkapnya: apa yang terjadi, apa penyebabnya, dan apa yang harus lo lakuin sekarang biar cluster lo survive di reboot berikutnya.

Timeline Insiden

12:35 - Reboot Terdeteksi

Monitoring system yang nangkep pertama. Node master-node-01, yang jadi Control Plane utama, reboot setelah 1 tahun 275 hari uptime tanpa henti. Reboot-nya cuma 247 detik, tapi itu cukup buat trigger cascading failure di seluruh cluster.

Tanda pertama dari luar kelihatannya kecil. Jalanin kubectl, hasilnya ini:

etcdserver: request timed out
500 Internal Server Error

Dalam hitungan menit, makin parah deh.

12:37 - Total Cluster Blackout

Port 6443, endpoint API Server, berhenti respond sama sekali. Semua perintah kubectl balik error yang sama:

Get "https://master-node-01:6443/api/v1/nodes?limit=500": dial tcp 192.168.1.10:6443: connect: connection refused - error from a previous attempt: unexpected EOF

Otak cluster-nya offline nih. Ga ada API Server artinya ga ada kubectl, ga ada pod scheduling, ga ada visibility ke apa pun.

12:38 - Root Cause Ketemu: Swap Memory

Ini hal yang sering bikin orang kaget yang baru kenal Kubernetes. Si kubelet, agent yang jalan di setiap node, hard-refuse buat start kalau swap memory aktif. Ini by design. Kubernetes butuh alokasi memori yang deterministik, dan swap ngancurin jaminan itu.

Waktu master-node-01 reboot, sistem operasinya otomatis nyalain swap lagi. Sebelumnya udah dimatiin manual pake swapoff -a, tapi perintah itu ga survive reboot. File /etc/fstab masih ada entry swap-nya. Sistem balikin swap online, dan kubelet nolak buat start.

Ga ada kubelet berarti ga ada Control Plane. Ga ada Control Plane berarti ga ada cluster.

12:45 - Worker Node Mulai Gagal

Sambil diagnosisin master node, worker node worker-node-01 dan worker-node-02 mulai kasih masalah sendiri. Log kubelet nunjukin error yang beda tapi masih berkaitan:

failed to connect to containerd: context deadline exceeded
dial unix /run/containerd/containerd.sock: connect: no such file or directory

Container runtime containerd ga ngehasilin socket file, yang artinya kubelet ga punya apa-apa buat disambungin. Penyebabnya adalah containerd masih di tengah-tengah proses recovery state dari hampir dua tahun data container. Systemd timeout-nya keburu jalan sebelum containerd selesai inisialisasi, ninggalin socket yang ga ada.

Node worker-node-03 dan worker-node-04 recover sendiri. Node worker-node-01 dan worker-node-02 stuck di NotReady.

Status Map Node

Proses Fix-nya

Phase 1: Balikin Control Plane

Fix buat master-node-01 straightforward banget setelah root cause-nya ketemu.

# Step 1: Disable swap langsung
sudo swapoff -a

# Step 2: Restart kubelet
sudo systemctl restart kubelet

# Step 3: Tunggu 2 menit, terus verifikasi
kubectl get nodes

Port 6443 terbuka dalam 90 detik setelah swap dimatiin. API Server balik online dan master-node-02 recover otomatis karena udah bisa rejoin cluster.

Phase 2: Recover Worker Node

Buat worker-node-01 dan worker-node-02, strateginya kasih containerd waktu lebih banyak terus restart chain-nya.

# Force containerd buat start dan tunggu
sudo systemctl start containerd
# Tunggu sampai socket muncul
sudo ls /run/containerd/containerd.sock

# Setelah socket terkonfirmasi, restart kubelet
sudo systemctl restart kubelet

Containerd lambat karena dia perlu verifikasi state ratusan container. Setelah dibolehin selesai, socket-nya muncul dan kubelet bisa register ke API Server. Kedua node balik ke status Ready deh.

Pelajaran yang Gue Dapet

Pelajaran 1: swapoff Manual Ga Survive Reboot

Kalau lo pernah jalanin swapoff -a dan ngerasa udah selesai, cluster lo bakal rusak di reboot berikutnya. Fix permanennya cuma satu: comment out entry swap di /etc/fstab.

# Jalanin ini di setiap node cluster lo
sudo sed -i '/swap/s/^\(.*\)$/#\1/g' /etc/fstab

# Verifikasi swap tetap 0 setelah reboot
free -m

Setelah ini, baris Swap di free -m harusnya nunjukin semua nol bahkan setelah restart penuh.

Pelajaran 2: kubelet Ga Nunggu containerd

Konfigurasi systemd default ga ngejamin kubelet nunggu containerd buat fully ready dulu sebelum start. Di boot baru setelah uptime panjang, containerd bisa butuh beberapa menit buat recover state container. kubelet start terlalu cepat, socket-nya kelewat, dan masuk crash loop.

Fix ini dengan edit service override kubelet:

sudo systemctl edit kubelet

Terus tambahin ini:

[Unit]
After=containerd.service
Requires=containerd.service

Ini kasih tau systemd buat selalu start kubelet setelah containerd, dan treat containerd sebagai hard dependency. Kalau containerd ga jalan, kubelet ga akan coba start sama sekali.

Pelajaran 3: Disk Usage 79 Persen Itu Warning Sign

Waktu insiden, partisi /var di master node-nya lagi di angka 79 persen. Partisi itu tempat etcd simpen database-nya dan tempat log aplikasi numpuk. Kubernetes mulai evict pod kalau disk pressure nyampe 85 persen. Database etcd freeze dengan quota alarm kalau disk penuh.

Ini bukan penyebab insiden hari ini, tapi ini insiden berikutnya yang lagi nunggu giliran. Setup log rotation buat aplikasi lo bukan opsional di cluster yang udah lama jalan. Itu maintenance.

Pelajaran 4: Uptime Panjang Bikin Hidden Risk

Server yang udah jalan 1 tahun 275 hari udah akumulasi banyak state. Log numpuk. Container akumulasi metadata. Sistem operasi mungkin punya pending update yang ngubah behavior di boot berikutnya. Makin lama node ga di-reboot, makin unpredictable reboot berikutnya.

Scheduled rolling reboot, dilakuin satu node per satu waktu selama window traffic rendah, jauh lebih aman dibanding reboot dua tahun yang ga terduga di tengah Minggu sore.

Also Read: Kubernetes Logging yang Bener: Fluent Bit ke Elasticsearch

Hardening Checklist

Ini yang harus lo terapin sekarang ke cluster Kubernetes mana pun, bukan cuma setelah insiden.

# 1. Matiin swap secara permanent di semua node
sudo sed -i '/swap/s/^\(.*\)$/#\1/g' /etc/fstab

# 2. Edit kubelet supaya depend sama containerd
sudo systemctl edit kubelet
# Tambahin: After=containerd.service dan Requires=containerd.service

# 3. Cek disk usage
df -h /var

# 4. Cek status swap sekarang
free -m

# 5. Verifikasi kubelet jalan
sudo systemctl status kubelet

# 6. Verifikasi containerd jalan
sudo systemctl status containerd

Jalanin ini di master-node-01 sampai worker-node-04, atau apapun nama node lo. Masing-masing adalah potential failure point di reboot berikutnya yang ga terduga.

Also Read: Kubernetes Docker Swarm Instalasi Aman: Migrasi Zero Downtime

Status Sekarang

Semua enam node Ready. Cluster seimbang dan sehat. Insiden berlangsung sekitar 2 jam dari deteksi sampai recovery penuh. Fix permanent yang udah gue jelasin di atas sudah diterapkan ke semua node.

Monitoring system yang nangkep reboot jam 12:35 itu juga alasan kenapa recovery bisa dilakuin sama sekali. Kalau lo ga punya uptime monitoring di Kubernetes node lo, setup sekarang juga. Reboot 247 detik di server yang udah jalan hampir dua tahun bukan sesuatu yang pengen lo tau pertama kali dari komplain user.

Kubernetes itu resilient by design, tapi cuma kalau lo maintain node yang dia jalan di atasnya.