k3s Satu Node di VPS: Kapan Layak Dipakai?

Apa itu k3s dan apa yang diberikan oleh satu node k3s

k3s adalah distribusi Kubernetes lengkap yang dikemas sebagai satu binary. Menjalankannya pada satu VPS memberi Anda Kubernetes API yang sebenarnya tanpa control plane tiga mesin. k3s adalah distribusi Kubernetes tersertifikasi, sehingga manifest yang dapat diterapkan di sini juga dapat diterapkan pada cluster terkelola nantinya. Instalasinya cukup dengan satu perintah dan memerlukan waktu sekitar satu menit. Konsekuensinya adalah sebagian memori tidak lagi tersedia untuk aplikasi Anda, serta muncul sejumlah mode kegagalan yang tidak pernah terjadi pada Docker Compose.

SUSE mengembangkan k3s untuk situs edge dan instalasi kecil. Setiap perbedaan dari Kubernetes upstream dibuat agar k3s lebih kecil. Datastore default-nya adalah sqlite melalui shim bernama kine, bukan etcd, sehingga tidak ada quorum etcd yang harus dipelihara. containerd disematkan dalam binary, bukan diinstal secara terpisah. Binary yang sama juga menyertakan CoreDNS untuk DNS cluster, Traefik sebagai ingress controller, ServiceLB (juga disebut klipper-lb) agar service LoadBalancer dapat berfungsi tanpa cloud provider, local-path provisioner untuk persistent volume, metrics-server, dan flannel untuk jaringan pod. Semua komponen tersebut start secara default. Karena itu, collision port yang dijelaskan di bawah ini merupakan masalah pertama yang paling umum pada VPS yang sebelumnya sudah menjalankan layanan lain.

Kapan satu node k3s layak digunakan

Gunakan k3s ketika API Kubernetes adalah hal yang Anda perlukan: Anda sedang mempelajari Kubernetes pada mesin yang Anda kendalikan, atau perangkat lunak yang ingin Anda gunakan hanya menyediakan Helm chart. Portabilitas manifest juga penting karena Deployment yang Anda tulis di sini dapat dipindahkan ke cluster terkelola tanpa perubahan. Gunakan Docker Compose ketika aplikasi adalah hal yang Anda perlukan. Compose menjalankan container yang sama dengan komponen yang jauh lebih sedikit, dan file Compose pada VPS lebih mudah dibaca setahun kemudian daripada direktori berisi manifest.

Pahami hal-hal yang tidak disediakan oleh satu node.

• Tidak ada high availability. Saat VPS melakukan reboot, semua workload berhenti. Kubernetes menjadwalkan ulang pod ke node lain, tetapi tidak ada node lain.
• Tidak ada rolling update yang membuat service tetap berjalan, kecuali aplikasi dapat menangani dua replica pada satu mesin yang menggunakan satu volume bersama.
• Penyimpanan terikat pada mesin tersebut, sesuai alasan yang dijelaskan pada bagian local-path di bawah.
• Control plane menggunakan sekitar 1 gigabyte RAM, baik Anda men-deploy sesuatu maupun tidak.

Semua itu tidak membuat k3s menjadi pilihan yang buruk. Namun, k3s menjadi pilihan yang buruk jika alasannya adalah alasan yang biasanya diberikan orang, yaitu keandalan. Jika yang sebenarnya Anda perlukan adalah beberapa mesin agar dapat membangun cluster multi-node yang nyata, keputusan itu harus ditentukan terlebih dahulu: Proxmox pada hardware milik sendiri dibandingkan VPS sewaan menentukan asal node sebelum k3s menentukan apa yang berjalan di dalamnya.

Biaya RAM dan CPU k3s sebelum Anda men-deploy apa pun

Proyek k3s memublikasikan angka hasil pengukuran, bukan perkiraan. Baca angka tersebut dengan cermat karena angka yang sering disebut bukan penggunaan k3s saat idle.

[
  {
    "label": "Server, sqlite datastore",
    "ram_mb": "1,596",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Server, embedded etcd",
    "ram_mb": "1,606",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Agent node only",
    "ram_mb": "275",
    "cpu_percent_of_one_core": 3
  }
]

Node server dalam pengujian tersebut menggunakan 1,596 MB RAM pada persentil ke-95 dan sekitar 6 persen dari satu core. Angka tersebut adalah angka yang dipublikasikan, bukan hasil pengukuran dari panduan ini. Pengujian menjalankan k3s v1.26.5 dengan semua komponen bawaan diaktifkan, serta stack monitoring Prometheus dan Grafana. Jadi, angka tersebut mencakup workload nyata, bukan cluster kosong. Mengganti sqlite dengan embedded etcd membuat penggunaan RAM menjadi 1,606 MB. Node agent, yang menjalankan kubelet dan containerd tanpa control plane, menggunakan 275 MB. Minimum yang didokumentasikan untuk server adalah 2 core dan 2 GB RAM. Minimum tersebut mencakup k3s dan komponen bawaannya sebelum workload Anda dijalankan.

Kesimpulan praktisnya: pada VPS 2 GB, control plane dan add-on bawaannya menyisakan sangat sedikit resource. Saat resource tertekan, kubelet akan mulai mengevict pod. RAM 4 GB merupakan batas bawah yang cukup nyaman untuk satu node dengan beberapa service kecil. Ukur server Anda sendiri dan jangan hanya mengandalkan angka yang dipublikasikan, termasuk angka dalam panduan ini.

free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -A

Jalankan free -h sebelum instalasi dan jalankan lagi setelah setiap pod di kube-system berstatus Running. Selisihnya menunjukkan resource yang digunakan control plane pada hardware Anda. k3s kubectl top node mengembalikan error: Metrics API not available selama satu atau dua menit pertama setelah instalasi karena metrics-server belum mengumpulkan data. Itu bukan error. Jika Anda menggunakan satu server untuk k3s dan pekerjaan lain secara bersamaan, perhitungan dalam menghitung kebutuhan RAM dan CPU untuk VPS tetap berlaku tanpa perubahan.

Instal k3s dengan versi yang ditetapkan, bukan versi terbaru

Baris quick start yang sering disalin akan menggunakan versi yang ditunjuk oleh stable channel pada hari saat Anda menjalankannya. Untuk mesin yang akan dipertahankan, tetapkan versinya. k3s menerbitkan satu channel untuk setiap versi minor Kubernetes, sehingga INSTALL_K3S_CHANNEL=v1.36 mengikuti rilis patch dalam v1.36 dan tidak berpindah ke versi minor lain tanpa Anda sadari. Per Agustus 2026, stable channel menunjuk ke v1.36.3+k3s1.

Tulis file konfigurasi terlebih dahulu, lalu lakukan instalasi. k3s membaca /etc/rancher/k3s/config.yaml saat dijalankan, sehingga semua pengaturan di dalamnya berlaku pada boot pertama dan setiap boot berikutnya.

sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
  - k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -

Untuk menetapkan satu rilis tertentu, bukan channel, gunakan INSTALL_K3S_VERSION=v1.36.3+k3s1. Tanda plus merupakan bagian dari tag tersebut. Selanjutnya, periksa apakah k3s sudah berjalan.

k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

kubectl get node seharusnya menampilkan satu node dengan STATUS Ready dalam waktu sekitar tiga puluh detik, dan setiap pod di kube-system seharusnya mencapai status Running atau Completed. Node yang tetap berada pada NotReady biasanya menunjukkan bahwa container runtime tidak pernah berjalan, jadi baca sudo journalctl -u k3s -n 100 --no-pager. Pada image VPS yang tidak umum, jalankan sudo k3s check-config sebelum melakukan pemeriksaan lain: perintah ini melaporkan fitur kernel yang tidak tersedia, sehingga jawabannya dapat diperoleh jauh lebih cepat daripada dengan membaca log.

Mengapa port 80 sudah digunakan dan apa yang harus dikorbankan untuk memperbaikinya

Ini adalah kegagalan yang sering terjadi pada VPS yang sebelumnya sudah menjalankan layanan. Instalasi berhasil. Namun, Traefik tidak pernah mendapatkan alamat, sementara situs yang sudah Anda jalankan tetap berfungsi. Karena itu, tidak ada yang tampak rusak sampai Anda mencoba mengakses ingress.

Mekanismenya sebagai berikut: chart Traefik yang disertakan membuat Service bertipe LoadBalancer pada port 80 dan 443. ServiceLB memenuhi permintaan tersebut dengan membuat DaemonSet yang terdiri atas pod kecil. Nama pod tersebut diawali dengan svclb-. Pod ini menggunakan nomor port tersebut sebagai hostPort pada setiap node. hostPort memublikasikan port container langsung ke namespace jaringan milik node, sama seperti yang dilakukan docker run -p 80:80. Jika nginx, Caddy, Apache, atau container lain sudah menggunakan port 80, kernel tidak dapat memberikan port tersebut untuk kedua kalinya. Akibatnya, scheduler tidak memiliki tempat untuk menempatkan pod.

sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'

Anda akan melihat pod svclb berstatus Pending dan service tanpa alamat eksternal:

svclb-traefik-8f2c1a-r6k9x   0/2   Pending   0   3m
traefik   LoadBalancer   10.43.62.11   <pending>   80:31480/TCP,443:30219/TCP

Menjalankan kubectl -n kube-system describe pod svclb-traefik-... akan menunjukkan penyebabnya secara langsung:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

ss -lntp menunjukkan proses yang menggunakan port tersebut. Ada lebih dari satu solusi, dan masing-masing memiliki konsekuensi.

Berikan port tersebut kepada k3s. Hentikan dan nonaktifkan web server yang ada, lalu biarkan Traefik menggunakan port 80 dan 443. Ini adalah pilihan yang tepat jika VPS akan digunakan sepenuhnya sebagai host k3s dan semua layanan yang sebelumnya Anda jalankan dipindahkan ke belakang Ingress.

Nonaktifkan ServiceLB dan pertahankan proxy yang ada. Lakukan instalasi dengan --disable=servicelb. Service bertipe LoadBalancer tetap mengalokasikan NodePort. Dengan demikian, Traefik tetap dapat diakses melalui port tinggi seperti 31480, lalu nginx atau Caddy meneruskan proxy ke 127.0.0.1:31480. Konsekuensi yang harus Anda terima adalah tidak adanya alamat eksternal. Service akan selalu melaporkan <pending>. Ini tampak seperti kesalahan, padahal merupakan pilihan yang Anda buat.

Nonaktifkan Traefik dan gunakan proxy Anda sendiri untuk merutekan trafik. Lakukan instalasi dengan --disable=traefik. Anda tidak akan memiliki ingress controller, sehingga objek Ingress sama sekali tidak melakukan apa pun. Objek tersebut hanya tersimpan di API tanpa controller yang memantaunya. Pilihan ini sesuai jika Anda merutekan trafik dari proxy pada host ke NodePort. Ini juga merupakan pilihan yang tepat jika Anda sudah mengetahui cara menangani HTTP. Jika Anda belum menentukan komponen yang akan ditempatkan di depan, tetapkan pilihan antara nginx, Caddy, dan Traefik sebagai reverse proxy sebelum menonaktifkan apa pun.

Kedua flag tersebut harus diberikan pada installer atau ditulis dalam file konfigurasi:

tls-san:
  - k3s.example.com
disable:
  - traefik
  - servicelb

Mengedit file tersebut setelah instalasi, lalu menjalankan sudo systemctl restart k3s, juga berfungsi karena --disable tidak hanya melewati komponen saat instalasi. Perintah tersebut juga menghapus komponen yang sudah diterapkan. Dengan demikian, perubahan berlaku pada cluster yang sedang berjalan.

Untuk mempertahankan Traefik tetapi mengubah konfigurasi chart, jangan edit /var/lib/rancher/k3s/server/manifests/traefik.yaml. k3s menulis ulang file tersebut dengan nilai default setiap kali dijalankan. Sebagai gantinya, tambahkan file terpisah di direktori yang sama. Semua konfigurasi dalam /var/lib/rancher/k3s/server/manifests diterapkan secara otomatis saat startup dan setiap kali file tersebut berubah di disk.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          trustedIPs:
            - 10.0.0.0/8

Contoh tersebut menetapkan satu nilai chart Traefik, yaitu alamat proxy tepercaya. Mekanisme yang sama dapat digunakan untuk menetapkan nilai lain yang tersedia pada chart, termasuk portnya.

Penyimpanan persisten pada satu node

k3s menyediakan StorageClass default bernama local-path, yang didukung oleh local-path provisioner dari Rancher. PersistentVolumeClaim tanpa storageClassName akan menggunakan StorageClass tersebut. Volume disimpan di /var/lib/rancher/k3s/storage, dengan satu subdirektori untuk setiap volume, pada disk milik node itu sendiri.

sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storage

Ada dua konsekuensi dari penyimpanan pada disk milik node itu sendiri. Keduanya baru menimbulkan masalah nanti, bukan saat ini.

StorageClass tersebut menggunakan volumeBindingMode: WaitForFirstConsumer, sehingga PVC baru tetap berstatus Pending sampai pod benar-benar melakukan mount. kubectl describe pvc menampilkan:

waiting for first consumer to be created before binding

Hal ini normal. Karena itu, membuat PVC saja lalu menunggu tidak akan mengubah statusnya.

Setelah terikat, volume memiliki node affinity untuk node yang membuatnya. Akibatnya, setiap pod yang menggunakan claim tersebut akan selalu dijadwalkan pada node itu selama volume masih ada. Pada satu node, masalah ini tidak akan terlihat. Jika nanti menambahkan node kedua, pod yang tidak mau berpindah akan tampak seperti mengalami bug pada scheduler. Jalankan kubectl get pv -o yaml untuk memeriksanya, lalu Anda akan menemukan hostname tersebut di nodeAffinity.

Pencadangan menjadi tanggung jawab Anda. Membangun ulang VPS akan menghapus direktori tersebut. Skrip uninstall di bawah ini juga akan menghapusnya. Cadangkan /var/lib/rancher/k3s/storage. Cadangkan juga datastore sqlite di /var/lib/rancher/k3s/server/db/state.db setelah menyalin atau menghentikan service, karena datastore tersebut adalah database aktif. Alternatifnya, perlakukan cluster sebagai lingkungan sementara dan simpan setiap manifest di git.

Ingress dan TLS

Dengan Traefik tetap diaktifkan, Anda hanya memerlukan objek Ingress standar.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: traefik
  tls:
    - hosts:
        - hello.example.com
      secretName: hello-tls
  rules:
    - host: hello.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

Sertifikat tidak muncul secara otomatis. Solusi yang umum adalah cert-manager, yang diinstal dari manifest yang dipublikasikannya, serta satu ClusterIssuer. Versi v1.21.1 adalah versi terbaru per Agustus 2026.

sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: you@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

Challenge HTTP-01 berarti server ACME (automatic certificate management environment) terhubung ke http://hello.example.com/.well-known/acme-challenge/... dari Internet publik. Karena itu, data A DNS harus sudah mengarah ke VPS, dan port 80 harus dapat menjangkau Traefik. Jika Anda menonaktifkan ServiceLB dan menempatkan proxy sendiri di depannya, proxy tersebut juga harus meneruskan path challenge. Jika tidak, cert-manager akan berhenti dan menampilkan pesan berikut pada objek Challenge:

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Pantau penerbitan dengan sudo k3s kubectl describe certificate hello-tls dan sudo k3s kubectl get order,challenge -A.

kubeconfig dan alasan API server tetap privat

k3s menulis kredensial admin ke /etc/rancher/k3s/k3s.yaml. File ini dimiliki oleh root dan secara default ditulis dengan mode 600. File tersebut berisi sertifikat klien dengan hak cluster-admin. Siapa pun yang dapat membacanya akan menguasai cluster.

sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get node

kubectl yang diinstal secara terpisah tanpa KUBECONFIG akan gagal dengan The connection to the server localhost:8080 was refused - did you specify the right host or port? karena menggunakan nilai default yang tidak terkait dengan k3s. Tetapkan KUBECONFIG, atau gunakan sudo k3s kubectl, yang membaca file yang benar secara otomatis.

Anda akan melihat --write-kubeconfig-mode 644 direkomendasikan agar pengguna biasa dapat menjalankan kubectl. Pahami dampaknya: kredensial cluster-admin menjadi dapat dibaca oleh setiap akun lokal pada mesin tersebut. Pada server yang hanya digunakan satu admin, ini mungkin merupakan kompromi yang dapat diterima. Pada server bersama, cara ini tidak aman. Menyalin file tersebut memberi satu pengguna akses tanpa membuatnya dapat dibaca oleh semua akun:

mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/config

Baris server: dalam file tersebut membaca https://127.0.0.1:6443. Untuk menggunakan kubectl dari laptop, jangan membuka port 6443 ke Internet. Kubernetes API publik merupakan target yang terus-menerus dipindai. API yang terekspos dapat menyebabkan cluster kecil digunakan untuk menambang mata uang kripto bagi pihak lain. Buat tunnel melalui SSH dan biarkan alamat dalam file tetap seperti semula:

ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get node

Jika Anda harus mengakses API melalui alamat jaringan privat, lakukan instalasi dengan tls-san yang mencantumkan nama atau alamat tersebut, lalu edit baris server: pada file yang disalin agar sesuai. Tanpa entri SAN (subject alternative name), kubectl menolak koneksi:

x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10

Port masuk yang didokumentasikan untuk sebuah cluster adalah TCP 6443 untuk API, UDP 8472 untuk flannel VXLAN antarnode, dan TCP 10250 untuk metrik kubelet. Pada node tunggal, tidak satu pun port tersebut perlu dibuka ke Internet.

containerd bukan Docker

k3s menjalankan containerd bawaannya sendiri dan tidak berbagi penyimpanan image dengan Docker. Image yang baru saja Anda build dengan docker build tidak terlihat oleh k3s. Akibatnya, pod gagal dengan ErrImagePull meskipun docker images menampilkannya. Impor image tersebut secara eksplisit:

docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl images

Selanjutnya, hindari tag :latest pada container tersebut. Secara default, :latest menggunakan imagePullPolicy dari Always, sehingga kubelet tetap mengakses registry. Tag lainnya secara default menggunakan IfNotPresent, yang memanfaatkan image yang Anda impor. Menjalankan keduanya pada satu VPS dapat dilakukan. Perlu diketahui bahwa instalasi Docker biasa pada VPS dan k3s masing-masing memiliki penyimpanan image dan aturan iptables sendiri pada mesin yang sama.

Cara menghapus k3s

Installer menulis skrip uninstall. Penghapusan parsial dan pembatalan tidak tersedia.

sudo /usr/local/bin/k3s-uninstall.sh

Skrip tersebut menghentikan dan menghapus service, menghapus datastore, menghapus data persistent volume, menghapus konfigurasi node, serta menghapus tools yang ditambahkan installer. Pada node agent, skripnya adalah k3s-agent-uninstall.sh. Salin terlebih dahulu semua yang berada di bawah /var/lib/rancher/k3s/storage ke luar server, karena direktori tersebut juga akan dihapus. Setelah itu, periksa apakah masih ada proses yang menggunakan port atau interface dengan ip link show dan sudo ss -lntp. Interface cni0 atau flannel.1 yang tersisa akan hilang setelah reboot berikutnya.

Menyimpulkan bahwa satu node Kubernetes menggunakan lebih banyak komponen daripada yang dibutuhkan pekerjaan tersebut merupakan hal yang wajar, bukan kegagalan. Memindahkan workload kembali ke Compose biasanya dapat diselesaikan dalam satu sore.

Mode kegagalan dan string yang akan Anda lihat

Node NotReady, atau k3s terus dimulai ulang. Baca sudo journalctl -u k3s -n 200 --no-pager terlebih dahulu. Pada VPS kecil, penyebab yang umum adalah kernel out-of-memory killer menghentikan proses tersebut. Hal ini terlihat di dmesg sebagai baris yang menyebut k3s-server. Batas minimum 2 GB yang didokumentasikan memang merupakan batas minimum nyata.

Pod tetap dalam status Pending. kubectl describe pod selalu menunjukkan penyebabnya. Insufficient memory atau Insufficient cpu berarti node sudah tidak memiliki ruang tersisa. didn't have free ports adalah benturan hostPort yang dijelaskan di atas. waiting for first consumer pada PVC berarti WaitForFirstConsumer bekerja sebagaimana mestinya.

ImagePullBackOff. Tag tersebut mungkin tidak ada di registry mana pun yang dapat dijangkau node, atau Anda membuat image dengan Docker tetapi tidak pernah mengimpornya ke containerd.

Traefik memberikan respons, tetapi aplikasi tidak. Body respons 404 page not found berasal dari Traefik sendiri. Ini berarti permintaan sudah tiba, tetapi tidak ada router yang cocok. Periksa apakah host pada Ingress cocok dengan nama yang Anda masukkan dan apakah ingressClassName adalah traefik.

DNS cluster gagal, sedangkan host dapat melakukan resolusi dengan baik. Periksa CoreDNS dengan sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Pesan seperti plugin/loop: Loop ... detected for zone "." mencegah CoreDNS dimulai. Hal ini terjadi karena CoreDNS meneruskan permintaan ke resolver yang meneruskannya kembali ke CoreDNS. Kondisi tersebut disebabkan oleh alamat loopback di /etc/resolv.conf. Arahkan k3s ke file upstream yang sebenarnya dengan --resolv-conf /run/systemd/resolve/resolv.conf.

FAQ

Apakah k3s layak dijalankan pada satu VPS?

k3s layak digunakan jika yang Anda perlukan adalah Kubernetes API: mempelajarinya pada mesin yang Anda kendalikan, mempertahankan deployment dalam bentuk manifest agar portabel, menjalankan perangkat lunak yang hanya menyediakan Helm chart, atau membangun sesuatu yang nantinya akan dipindahkan ke cluster terkelola. k3s tidak layak digunakan jika Anda hanya ingin menjalankan container, karena Docker Compose dapat melakukan hal tersebut dengan jauh lebih sedikit komponen yang harus dipelihara dan sekitar satu gigabyte RAM bebas tambahan. Satu node tidak menyediakan high availability, jadi keandalan tidak pernah menjadi alasan untuk memilihnya.

Mengapa service LoadBalancer k3s saya tetap berstatus Pending?

ServiceLB membuat pod svclb- yang mengambil port service sebagai hostPort pada node, sehingga pod tersebut hanya dapat dijadwalkan pada node yang portnya masih bebas. Jika nginx atau proxy lain sudah menggunakan port 80, pod tetap berstatus Pending dan service tidak pernah menerima alamat eksternal. kubectl -n kube-system describe pod svclb-... melaporkan 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. Bebaskan port tersebut, atau instal ulang dengan --disable=servicelb lalu teruskan proxy ke NodePort yang tetap dialokasikan oleh service.

Berapa banyak RAM yang dibutuhkan k3s pada VPS?

Minimum yang didokumentasikan untuk server node adalah 2 core dan 2 GB. Jumlah tersebut mencakup k3s dan komponen yang disertakan sebelum workload Anda dijalankan. Profiling yang dilakukan oleh project ini mengukur penggunaan server node sebesar 1,596 MB saat monitoring stack berjalan, jadi anggap 2 GB sebagai batas minimum dan 4 GB sebagai ukuran awal yang nyaman untuk satu node. Ukur mesin Anda sendiri dengan free -h sebelum instalasi dan sekali lagi setelah setiap pod dalam kube-system berstatus Running.

Dapatkah Docker dan k3s dijalankan pada VPS yang sama?

Ya, dan keduanya tetap terpisah. k3s menggunakan containerd tertanamnya sendiri, sehingga image yang dibuat dengan docker build tidak terlihat oleh k3s sampai Anda menjalankan docker save myapp:0.1 | sudo k3s ctr images import -. Masing-masing juga menulis aturan iptables dan bridge network sendiri. Pantau total penggunaan memori, karena Docker, k3s, dan container Anda tidak akan muat pada mesin dengan RAM 2 GB.

Bagaimana cara menghapus k3s sepenuhnya?

Jalankan sudo /usr/local/bin/k3s-uninstall.sh pada server node, atau sudo /usr/local/bin/k3s-agent-uninstall.sh pada agent. Perintah tersebut menghentikan service, menghapus datastore, menghapus data persistent volume di bawah /var/lib/rancher/k3s/storage, dan menghapus tools yang disertakan. Salin terlebih dahulu data yang ingin Anda simpan ke luar mesin, karena tindakan ini tidak dapat dibatalkan. Interface jaringan cni0 atau flannel.1 yang tersisa akan hilang pada reboot berikutnya.