Part-1: High Avaliability Kubernetes Cluster dengan CAPI di LXD

Setelah sebelumnya kita membangun cluster kubernetes dengan API lxd, kali ini kita akan membuat sebuah cluster Kubernetes yang siap untuk production. Cluster ini akan memiliki High Availability (HA) dengan 3 control-plane, 2 worker-node, dan menggunakan kube-vip sebagai load balancer untuk API server-nya.

Artikel Sebelumnya : https://www.isiotak.com/archives/instalasi-kubernetes-menggunakan-cluster-api-di-lxd

Arsitektur cluster yang akan kita bangun terdiri dari:

• Control Plane: Otak dari cluster. Terdiri dari komponen etcd, api-server, scheduler, dan controller-manager. Dengan 3 node, cluster kita dapat mentolerir kegagalan satu node control-plane tanpa mengalami downtime.

• Worker Node: Tempat dimana aplikasi (dalam bentuk Pod) akan berjalan. Menyediakan runtime environment yang dibutuhkan oleh Kubernetes.

Spesifikasi Cluster

Langkah-langkah Provisioning

Semua eksekusi perintah dilakukan dari dalam VM management cluster (kind-management) yang sudah kita siapkan sebelumnya.

1. Requirement

Pastikan kalian sudah deploy management cluster (kind) dan provider Cluster API untuk Incus/LXD sudah terinstal. Jika belum, silakan merujuk ke artikel sebelumnya: Instalasi Kubernetes Dengan Cluster-API di LXD.

2. Konfigurasi Variabel Cluster

Kita akan mengatur variabel-variabel yang akan digunakan oleh clusterctl untuk men-generate manifest cluster.

# Versi Kubernetes yang akan digunakan
export KUBERNETES_VERSION=v1.30.2

# Jumlah node untuk control plane dan worker
export CONTROL_PLANE_MACHINE_COUNT=3
export WORKER_MACHINE_COUNT=2

# [WAJIB] Nama secret yang berisi kredensial akses ke LXD
export LXC_SECRET_NAME=lxc-secret

# [WAJIB] Konfigurasi Load Balancer menggunakan kube-vip
# IP ini akan menjadi Virtual IP (VIP) yang stabil untuk API server
export LOAD_BALANCER="kube-vip: {host: 10.0.42.1}"

# Nama image LXD yang sudah kita build sebelumnya
export LXC_IMAGE_NAME=kubeadm/v1.30.2/ubuntu/24.04

# Control Plane
export CONTROL_PLANE_MACHINE_TYPE='container'
export CONTROL_PLANE_MACHINE_FLAVOR='c2-m4' # 2 CPU, 4GB RAM

# Worker
export WORKER_MACHINE_TYPE='virtual-machine'
export WORKER_MACHINE_FLAVOR='c4-m4' # 4 CPU, 4GB RAM

Kita akan membuat control-plane diatas LXD container dengan tujuan untuk efisiensi resource server, sementara worker node akan dideploy diatas VM agar terisolasi dan lebih aman. Perintah kube-vip berfungsi untuk membuat virtual network cluster agar cluster berada dalam 1 network yang sama.

3. Generate Manifest Cluster

Untuk dapat generate manifest cluster, kita bisa menggunakan perintah clusterctl. Perintah tersebut akan membuat file YAML yang berisi detail cluster berdasarkan variabel yang sudah di-set.

clusterctl generate cluster nb-cluster-prod -i incus > nb-cluster-prod.yaml

4. Sesuaikan Manifest untuk Worker Node

Secara default, manifest yang di-generate mungkin masih menggunakan image container untuk worker node. Maka dari itu, kita perlu ubah file nb-cluster-prod.yaml secara manual dan memastikan worker menggunakan image VM (.../kvm) yang benar.

Cari bagian MachineDeployment didalam file YAML dan ubah spec.template.spec.image untuk worker.

# ... (bagian lain dari file yaml)
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: nb-cluster-prod-md-0
# ... (metadata lain)
spec:
  # ... (spec lain)
  template:
    spec:
      bootstrap:
        configRef:
          # ...
      clusterName: nb-cluster-prod
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: LXCMachineTemplate
        name: nb-cluster-prod-md-0
      version: v1.30.2
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: LXCMachineTemplate
metadata:
  name: nb-cluster-prod-md-0
spec:
  template:
    spec:
      image: kubeadm/v1.30.2/ubuntu/24.04/kvm # <--- PASTIKAN IMAGE INI BENAR
      type: virtual-machine
      flavor: c4-m4
# ... (sisa file)

5. Deploy Cluster

Setelah ubah manifest, selanjutnya saya akan apply manifest tersebut dengan menggunakan perintah kubectl. Pada proses ini API akan generate cluster sesuai dengan apa yang sudah kita masukkan kedalam file manifest. Proses ini memakan waktu beberapa menit, tergantung banyaknya cluster dan banyaknya image yang dipakai.

kubectl apply -f nb-cluster-prod.yaml

Untuk memantau proses deployment, kita bisa menggunakan 2 perintah dibawah ini:

# Melihat status cluster dari sudut pandang Cluster API
clusterctl describe cluster nb-cluster-prod

# Melihat instance yang dibuat di LXD
lxc list user.cluster-name=nb-cluster-prod

Awalnya, node akan berada dalam status NotReady. Ini adalah kondisi yang normal karena CNI (Container Network Interface) belum terpasang. Tanpa CNI, komunikasi antar Pod di node yang berbeda tidak dapat terjadi.

7. Instalasi CNI (Calico)

Agar cluster terkoneksi satu sama lain dan dapat dimanage, kita harus menambah CNI. Disini saya menggunakan Calico sebagai CNI. Untuk proses integrasai cluster dengan CNI, kita bisa mengguakan perintah dibawah

# Ambil kubeconfig dari cluster yang baru dibuat
clusterctl get kubeconfig nb-cluster-prod > nb-cluster-prod.kubeconfig

# Install Calico
curl [https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml](https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml) -O
kubectl --kubeconfig=nb-cluster-prod.kubeconfig apply -f calico.yaml

8. Verifikasi Akhir

Setelah Calico terinstal dan semua Pod-nya berjalan, node-node cluster akan berubah status menjadi Ready.

# Cek status node, pastikan semua "Ready"
kubectl --kubeconfig=nb-cluster-prod.kubeconfig get nodes -o wide

# Cek semua pod di cluster, pastikan semua "Running"
kubectl --kubeconfig=nb-cluster-prod.kubeconfig get all -A

Kesimpulan

Dengan mengikuti langkah-langkah di atas, kita telah berhasil membangun cluster Kubernetes memiliki HA dan efisien menggunakan Cluster API pada LXD/Incus. Arsitektur HA dengan 3 control-plane node (dalam bentuk container untuk optimalisasi resource) dan 2 worker node (dalam bentuk VM untuk isolasi keamanan) memastikan agar cluster memiliki high available (HA), dimana cluster akan direplikasi sehingga jika salah satu master node bermasalah, cluster akan tetap berjalan dengan normal.