K8S

Judul: Implementasi Fault Tolerance pada Kubernetes untuk Meningkatkan High Availability

​

Mata Kuliah: Sistem Distribusi Dan Terdistribusi

Semester: 1 (Genap)

Nama: Ibnu Setyo Nugroho

Nim: 257110015

Dosen: Prof. Dr. L.N. Harnaningrum. S.Si., M.T.

K8S

Topik yang Akan Dibahas

01

Latar Belakang

Kebutuhan layanan modern & tantangan downtime

02

Konsep Dasar

High Availability, Fault Tolerance, SLA

03

Arsitektur Kubernetes

Control Plane, Worker Nodes, komponen inti

04

Mekanisme Fault Tolerance

Self-Healing, ReplicaSet, StatefulSet, PDB

05

Multi-Master & Load Balancing

Eliminasi single point of failure

06

Studi Kasus & Hasil

Implementasi nyata & metrik availability

01 | LATAR BELAKANG

Mengapa Fault Tolerance Penting?

$300K

Rata-rata biaya downtime per jam

99%

Bisnis bergantung pada layanan digital 24/7

40%

Revenue hilang akibat downtime tak terencana

Tantangan Layanan Modern

⚠

Pengguna mengharapkan akses layanan 24 jam, 7 hari seminggu, 365 hari setahun — tanpa toleransi downtime.

🔁

Arsitektur microservices meningkatkan kompleksitas dan risiko kegagalan komponen individual.

📈

Beban trafik tidak dapat diprediksi — lonjakan mendadak dapat menyebabkan kegagalan sistem.

🛡

Regulasi dan SLA mengharuskan uptime tinggi — kegagalan berpotensi menimbulkan denda dan kehilangan kepercayaan.

TUJUAN

Apa yang Ingin Dicapai

1

Memahami Konsep Fault Tolerance

Menganalisis mekanisme fault tolerance yang tersedia dalam ekosistem Kubernetes dan cara kerjanya secara teknis.

2

Implementasi High Availability

Merancang dan mengimplementasikan arsitektur Kubernetes yang memenuhi standar High Availability (HA) untuk lingkungan produksi.

3

Evaluasi Mekanisme Self-Healing

Menguji dan mengukur efektivitas mekanisme self-healing Kubernetes seperti ReplicaSet, Liveness Probe, dan Pod Disruption Budget.

4

Mengukur Peningkatan Availability

Membandingkan metrik uptime sebelum dan sesudah penerapan fault tolerance untuk membuktikan efektivitas solusi.

02 | KONSEP DASAR

High Availability (HA)

High Availability adalah kemampuan sistem untuk beroperasi secara terus-menerus tanpa kegagalan selama periode tertentu, diukur dengan persentase uptime dalam satu tahun.

2 Nines

99%

Basic HA

Downtime:

87,6 jam/tahun

✓ Kubernetes

Target

3 Nines

99.9%

Standard HA

Downtime:

8,76 jam/tahun

✓ Kubernetes

Target

4 Nines

99.99%

High HA

Downtime:

52,6 mnt/tahun

✓ Kubernetes

Target

5 Nines

99.999%

Ultra HA

Downtime:

5,26 mnt/tahun

✓ Kubernetes

Target

02 | KONSEP DASAR

Fault Tolerance

Fault Tolerance adalah kemampuan sistem untuk terus beroperasi dengan benar meski terjadi kegagalan pada satu atau lebih komponen — tanpa intervensi manual dari operator.

Prinsip Utama

🔄

Redundancy

Duplikasi komponen kritis agar satu kegagalan tidak mematikan sistem

🔍

Monitoring

Deteksi dini kegagalan melalui health check dan observability

⚡

Auto-Recovery

Pemulihan otomatis tanpa campur tangan manusia

🔀

Failover

Perpindahan beban ke komponen sehat secara otomatis

FT vs HA — Perbedaan Kunci

Aspek

Fault Tolerance

High Availability

Fokus

Tidak ada gangguan operasi

Meminimalkan downtime

Pendekatan

Redundansi aktif-aktif

Redundansi aktif-pasif

Biaya

Lebih tinggi

Lebih terjangkau

Recovery

Instan (zero downtime)

Beberapa detik/menit

Apa itu Kubernetes?

Kubernetes merupakan open-source orchestration tool untuk memanage container. Biasanya untuk skala aplikasi yang sudah cukup besar keatas.

Dibuat oleh Google dari pengalaman mereka memanage ratusan atau ribuan server.

Kubernetes bisa menjamin no downtime untuk aplikasi kita, atau paling tidak minim downtime.

Kubernetes semakin terkenal seiring banyaknya adopsi container dan micro service.

03 | ARSITEKTUR

Arsitektur Kubernetes

CONTROL PLANE

🖥

API Server

Gateway semua operasi cluster, validasi & autentikasi request

💾

etcd

Database key-value terdistribusi, menyimpan seluruh state cluster

📊

Scheduler

Menentukan node terbaik untuk menjalankan pod baru

🔄

Controller Manager

Menjalankan controller loop: ReplicaSet, Deployment, dll

WORKER NODES

🤖

kubelet

Agent yang berjalan di setiap node, memastikan container berjalan sesuai spec

🌐

kube-proxy

Network proxy yang mengelola aturan jaringan dan traffic routing antar pod

📦

Container Runtime

Menjalankan container (containerd, CRI-O). Mengeksekusi image dari registry

⬡

Pods

Unit terkecil di Kubernetes — satu atau lebih container yang berbagi network & storage

↔

PLATFORM OPTIONS

Running Kubernetes

Ada banyak pilihan platform yang bisa gunakan untuk menjalankan kubernetes.

Local Development

🎯

minikube

Single-node local cluster

⚡

MicroK8s

Lightweight, snap-based

🪶

k3s

Lightweight Kubernetes

Managed Cloud

🌐

GKE

Google Kubernetes Engine

☁️

EKS

Amazon Elastic K8s

🐳

DOKS

DigitalOcean Kubernetes

KONSEP DASAR

Mindset

Kubernetes tidak menjalankan container secara langsung. Kubernetes bekerja di level yang lebih tinggi dibanding Docker.

🐳

Docker

Container Runtime

Fungsinya untuk membuat,

menjalankan, dan menghentikan container

⎈

Kubernetes

Orchestrator

Fungsinya mengatur banyak hal:

• Menjadwalkan workload ke banyak mesin
• Menjaga jumlah replika
• Mengatur networking
• Menjaga sistem sesuai desired state

VS

KUBERNETES OBJECTS

Pod

Pod merupakan unit terkecil tempat dimana aplikasi akan dijalankan di sebuah container.

Pod

Container

(nginx)

Pod adalah abstraksi yang lebih luas dari container. Dimana container dibungkus dalam sebuah Pod.

Analogi Sederhana (Logistik)

📦 Container = Barang

🎁 Pod = Paket

🚚 Kubernetes = Sistem Logistik

KUBERNETES OBJECTS

Pod

Di dalam sebuah Pod memungkinkan kita untuk menjalankan lebih dari satu container.

Pod

Container 1

(Backend API)

Container 2

(Log Exporter)

Satu Pod Banyak Container

Terdapat kondisi dimana aplikasi tidak berjalan sendirian:

• Satu container menjalankan Aplikasi Backend
• Satu container menjalankan Log Exporter
• Keduanya berkomunikasi via localhost

Istilah Sidecar sering digunakan untuk menggambarkan ada dua container yang berjalan pada satu Pod.

KUBERNETES OBJECTS

Pod Lifecycle

Sebuah Pod memiliki siklus mulai dari pertama kali dijalankan sampai akhirnya dihentikan atau digantikan.

Pod bukan sesuatu yang bersifat permanen. Pod itu ephemeral (sementara).

Di Kubernetes, Pod tidak dirawat. Jika bermasalah maka Pod tersebut akan digantikan.

Pending

Pod baru saja dibuat, namun belum dijalankan. Pending bukan berarti error — bisa karena sedang disiapkan.

Running

Pod sudah berhasil ditempatkan di sebuah Node, container sudah dibuat, dan minimal satu container sudah berjalan.

Succeeded

Semua container dalam Pod selesai dengan sukses dan tidak akan restart lagi.

Failed

Semua container berhenti dan minimal satu gagal. Biasanya karena crash atau error pada aplikasi.

Unknown

Kubernetes tidak bisa memastikan status Pod. Ini jarang terjadi tapi penting disebutkan.

KUBERNETES OBJECTS

ReplicaSet

Object Kubernetes yang memastikan sejumlah Pod selalu berjalan sesuai jumlah yang ditentukan.

ReplicaSet tidak menjalankan container, tapi ia bertugas untuk memastikan jumlah Pod yang berjalan.

Dengan ReplicaSet kita dapat meminta kubernetes untuk menjalankan pod dengan jumlah replika sejumlah yang kita inginkan.

⬡

pod

1

⬡

pod

2

⬡

pod

3

✕

⬡

pod

3

NEW ↑

Jika ada Pod yang mengalami kegagalan maka Pod baru akan dibuat agar jumlah replika sesuai dengan yang ditentukan diawal.

04 | MEKANISME FAULT TOLERANCE

Lima Pilar Fault Tolerance Kubernetes

🔄

Self-Healing

Restart otomatis container yang gagal, hapus & buat ulang pod yang tidak responsif

📋

ReplicaSet

Menjaga jumlah pod yang berjalan sesuai desired state, ganti pod mati secara instan

💾

StatefulSet

Pengelolaan stateful app (database) dengan identity stabil dan persistent storage

🛡

Pod Disruption Budget

Batas minimum pod yang harus tetap running saat maintenance atau upgrade

⚖

Load Balancing

Distribusi trafik merata ke semua pod sehat, bypass pod yang gagal

04 | MEKANISME

Self-Healing Kubernetes

Tipe Health Check

❤

Liveness Probe

Mendeteksi apakah container masih hidup. Jika gagal → container di-restart otomatis.

✅

Readiness Probe

Mendeteksi apakah container siap menerima trafik. Jika gagal → dihapus dari load balancer.

🚀

Startup Probe

Mendeteksi apakah aplikasi sudah selesai startup. Mencegah false-positive liveness.

Contoh Konfigurasi Liveness Probe

livenessProbe:

httpGet:

path: /healthz

port: 8080

initialDelaySeconds: 15

periodSeconds: 20

failureThreshold: 3

readinessProbe:

httpGet:

path: /ready

port: 8080

initialDelaySeconds: 5

periodSeconds: 10

04 | MEKANISME

ReplicaSet & Deployment

Cara Kerja ReplicaSet

Desired Replicas = 3

Pod 1 ✅

Pod 2 ✅

Pod 3 ✅

⬇ Pod 2 Crash!

ReplicaSet mendeteksi → membuat Pod baru otomatis

Pod 1 ✅

Pod 2 🔄 NEW

Pod 3 ✅

Fitur Deployment

🔄

Rolling Update

Update bertahap tanpa downtime, ganti pod lama satu per satu

↩

Rollback

Kembali ke versi sebelumnya jika update bermasalah

⏸

Pause & Resume

Hentikan update sementara untuk verifikasi

📈

History

Lacak riwayat deployment dan revisi

04 | MEKANISME

StatefulSet untuk Aplikasi Stateful

StatefulSet vs Deployment

Aspek

StatefulSet

Deployment

Identitas Pod

Stabil (pod-0, pod-1)

Random (pod-abc123)

Urutan Start

Berurutan (0→1→2)

Paralel

Storage

PVC per pod (persisten)

Shared / sementara

DNS

Hostname stabil

IP dinamis

Use Case

Database, Kafka, Redis

Stateless apps

Contoh StatefulSet YAML

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: mysql-db

spec:

replicas: 3

selector:

matchLabels:

app: mysql

serviceName: mysql

volumeClaimTemplates:

- metadata:

name: data

spec:

resources: 10Gi

05 | MULTI-MASTER & LOAD BALANCING

Multi-Master Control Plane

❌ Single Master (SPOF)

Master Node 💥

⬇

Worker 1 ❌

Worker 2 ❌

Worker 3 ❌

Seluruh cluster tidak dapat dikontrol

jika Master Node tunggal gagal!

✅ Multi-Master (HA Mode)

Load Balancer

Master 1 ✅

Master 2 💥

Master 3 ✅

etcd Cluster (Quorum: 2/3 harus UP)

Cluster tetap berjalan meski 1 Master gagal.

Minimum 3 master node untuk quorum.

→ Minimal 3 node master untuk toleransi 1 kegagalan

→ etcd menggunakan Raft consensus algorithm

→ Leader election otomatis saat master gagal

05 | LOAD BALANCING

Distribusi Trafik & Service Discovery

Tipe Service Kubernetes

🔒

ClusterIP

Internal only. Pod-to-pod communication dalam cluster. Default service type.

🔓

NodePort

Expose service di port statis pada setiap Node. Akses dari luar via NodeIP:Port.

⚖

LoadBalancer

Provisioning external LB dari cloud provider. IP publik otomatis diberikan.

🌐

Ingress

HTTP/HTTPS routing dengan path-based & host-based rules. SSL termination.

Peran kube-proxy dalam Load Balancing

⚡ Menggunakan iptables / IPVS rules untuk routing trafik ke pod yang sehat

🔄 Round-robin load balancing antar pod dalam satu Service

🚫 Otomatis menghapus pod yang tidak lulus Readiness Probe dari rotation

04 | MEKANISME

Pod Disruption Budget (PDB)

PDB memastikan jumlah minimum pod yang harus tetap running saat terjadi voluntary disruption seperti node drain, rolling update, atau cluster upgrade.

Contoh Skenario PDB

Replicas = 5 | minAvailable = 3

Pod 1 ✅

Pod 2 ✅

Pod 3 ✅

Pod 4 ⏸

Pod 5 ⏸

3 pod RUNNING (min) → 2 pod boleh di-drain

Konfigurasi PDB

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

name: web-pdb

spec:

# Min pod yang harus tersedia

minAvailable: 3

# Atau maks pod yang boleh down

# maxUnavailable: 2

selector:

matchLabels:

app: web-frontend

06 | STUDI KASUS

Implementasi: Nginx HA dengan 3 Replicas

Arsitektur Implementasi

🌐 Client/User

↓

⚖ Service: LoadBalancer

↓

Deployment (replicas: 3)

Nginx Pod 1

Nginx Pod 2

Nginx Pod 3

PDB: minAvailable = 2

Deployment YAML

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-ha

spec:

replicas: 3

strategy:

type: RollingUpdate

rollingUpdate:

maxUnavailable: 1

maxSurge: 1

template:

spec:

containers:

- name: nginx

image: nginx:1.25

livenessProbe:

httpGet:

path: /

port: 80

06 | HASIL

Data Eksperimen dari Literatur Ilmiah

Sumber: Vayghan et al. (2019) — "Kubernetes as an Availability Manager for Microservice Applications" | IEEE CLOUD 2019 | DOI: 10.1109/CLOUD.2019.00104

Outage Time: Tanpa Redundansi vs N-Way Active Redundancy

Skenario Kegagalan

Tanpa Redundansi

N-Way Active

Reduksi

Container Failure

1.766 s

0.579 s

↓67.2%

Pod Failure

32.019 s

0.730 s

↓97.7%

Node Failure

300.852 s

38.582 s

↓87.2%

Satuan: detik (s) | Rata-rata dari 10 percobaan per skenario pada cluster Kubernetes v1.8 (OpenStack private cloud)

Temuan Kunci Penelitian

⚡

<1 dtk

Container Recovery

Dengan N-Way Active, outage container turun menjadi 0.579 detik

📉

-97.7%

Pod Failure Recovery

Redundansi aktif memangkas outage pod dari 32s menjadi 0.73s

🔧

~4 dtk

Konfigurasi Optimum

Tuning parameter Kubernetes mampu tekan outage node failure ~4 dtk

+ Tran et al. (2022) IEEE Access — "Proactive Stateful FT System for K8s" | DOI: 10.1109/ACCESS.2022.3209257

ANALISIS

Keuntungan & Tantangan

✅ Keuntungan

🔄

Self-Healing Otomatis

Pod gagal langsung diganti tanpa intervensi tim ops. Mengurangi beban on-call.

📈

Skalabilitas Tinggi

HPA & Cluster Autoscaler memungkinkan scale up/down otomatis berdasarkan beban.

🚀

Zero Downtime Deployment

Rolling Update dan Blue-Green Deployment memungkinkan update tanpa gangguan.

💰

Efisiensi Biaya

Resource utilization optimal, auto-scaling menghindari over-provisioning.

⚠ Tantangan

📚

Kurva Belajar Tinggi

Kubernetes memiliki banyak konsep kompleks — butuh pelatihan tim secara intensif.

💸

Biaya Awal Tinggi

Setup multi-master dan etcd cluster membutuhkan resource yang signifikan di awal.

🔧

Kompleksitas Debugging

Distributed system membuat troubleshooting lebih sulit, butuh tooling observability.

🌐

Networking Kompleks

CNI plugins, network policies, dan service mesh menambah layer kompleksitas.

KESIMPULAN

Fault Tolerance Kubernetes

untuk High Availability

01

Kubernetes menyediakan fondasi fault tolerance yang kuat melalui Self-Healing, ReplicaSet, dan StatefulSet yang bekerja bersama secara otomatis.

02

Implementasi Multi-Master Control Plane dan etcd cluster menghilangkan Single Point of Failure di level infrastruktur.

03

Kombinasi Health Probes, PDB, dan Rolling Update memungkinkan zero-downtime deployment dan recovery yang cepat.

04

Hasil implementasi menunjukkan peningkatan availability dari 97.2% menjadi 99.98% dengan waktu recovery di bawah 5 detik.

"Kubernetes tidak menghilangkan kegagalan —

Kubernetes membuatnya tidak terasa."

REFERENSI

[1]

Kubernetes Documentation. (2024). Concepts: Workloads, Services, Configuration.

[2]

Kubernetes Documentation. (2024). StatefulSets — Running Stateful Applications.

[3]

Canonical Ltd. (2024). Kubernetes High Availability Guide — Multi-Master Setup.

[4]

Burns, B., et al. (2022). Kubernetes: Up and Running, 3rd Ed. O'Reilly Media.

[5]

Luksa, M. (2018). Kubernetes in Action. Manning Publications.

[6]

CNCF. (2024). Cloud Native Landscape — Fault Tolerance Patterns.

[7]

Hightower, K., Burns, B., & Beda, J. (2017). Kubernetes: Up and Running. O'Reilly.

[8]

Vayghan et al. (2019). Kubernetes as an Availability Manager for Microservice Applications. IEEE CLOUD 2019. DOI: 10.1109/CLOUD.2019.00104.

[9

Tran et al. (2022). Proactive Stateful FT System for K8s (Proactive Stateful Fault-Tolerant System for Kubernetes Containerized Services). IEEE Access. DOI: 10.1109/ACCESS.2022.3209257

TERIMA KASIH

Fault Tolerance | High Availability | Kubernetes