SSD Nodes Learn 🎉 VPS từ $5.50/tháng
Hướng dẫn Matt ConnorBởi Matt Connor

Chạy k3s một node trên VPS có đáng không?

k3s dùng Kubernetes API thật trên một VPS, tốn bao nhiêu RAM, vì sao port 80 có thể xung đột khi cài và khi nào Docker Compose vẫn hợp lý hơn.

k3s là gì và một node k3s mang lại cho bạn những gì

k3s là một bản phân phối Kubernetes đầy đủ, được đóng gói thành một binary duy nhất. Chạy k3s trên một VPS duy nhất cho bạn Kubernetes API thực sự mà không cần control plane gồm ba máy. Đây là bản phân phối Kubernetes được chứng nhận, nên manifest áp dụng được ở đây cũng sẽ áp dụng được cho một cluster managed về sau. Cài đặt chỉ cần một command và mất khoảng một phút. Đổi lại, bạn phải dành một phần memory cho k3s, khiến phần memory đó không còn khả dụng cho các ứng dụng, đồng thời phải xử lý các failure mode vốn không xảy ra với Docker Compose.

SUSE xây dựng k3s cho các site edge và hệ thống nhỏ. Mọi điểm khác biệt so với Kubernetes upstream đều nhằm làm cho k3s nhỏ gọn hơn. Datastore mặc định là sqlite thông qua một shim có tên kine, không phải etcd, nên không cần duy trì quorum của etcd. containerd được nhúng trong binary thay vì cài riêng. Binary này cũng tích hợp CoreDNS cho cluster DNS, Traefik làm ingress controller, ServiceLB (còn gọi là klipper-lb) để các service kiểu LoadBalancer hoạt động mà không cần cloud provider, local-path provisioner cho persistent volume, metrics-server và flannel cho pod networking. Tất cả các thành phần này đều khởi động mặc định. Vì vậy, lỗi xung đột port được mô tả bên dưới là vấn đề đầu tiên phổ biến nhất trên một VPS vốn đã chạy dịch vụ khác.

Khi nào một node k3s là lựa chọn hợp lý

Hãy dùng quy tắc này. Chạy k3s khi thứ bạn cần là Kubernetes API: bạn đang học Kubernetes trên một máy do mình kiểm soát, hoặc phần mềm bạn muốn triển khai chỉ cung cấp Helm chart. Tính di động của manifest cũng có giá trị, vì một Deployment bạn viết ở đây có thể chuyển sang cluster được quản lý mà không cần thay đổi. Chạy Docker Compose khi thứ bạn cần là các ứng dụng. Compose khởi động cùng các container đó với ít thành phần phải quản lý hơn nhiều, và Compose file trên một VPS dễ đọc hơn sau một năm so với một thư mục chứa các manifest.

Hãy hiểu rõ những gì một node không cung cấp.

  • Không có tính sẵn sàng cao. Khi VPS reboot, mọi workload đều dừng. Kubernetes sẽ reschedule một pod sang node khác, nhưng ở đây không có node khác.
  • Không có rolling update giúp service vẫn hoạt động, trừ khi ứng dụng hỗ trợ chạy 2 replica trên cùng một máy và dùng chung một volume.
  • Storage bị gắn với chính máy đó, vì lý do được mô tả trong phần local-path bên dưới.
  • Control plane tiêu tốn khoảng 1 gigabyte RAM dù bạn có deploy gì hay không.

Không điều nào trong số đó khiến k3s trở thành lựa chọn tệ. Nhưng chúng khiến k3s trở thành lựa chọn tệ nếu lý do chọn nó là điều mọi người thường đưa ra: độ tin cậy. Nếu điều bạn thực sự muốn là nhiều máy để xây dựng một cluster nhiều node đúng nghĩa, hãy quyết định việc đó trước: Proxmox trên phần cứng của bạn so với VPS thuê xác định các node sẽ đến từ đâu trước khi k3s xác định thứ gì sẽ chạy trên chúng.

Chi phí RAM và CPU của k3s trước khi bạn triển khai bất kỳ thứ gì

Dự án k3s công bố số liệu đã đo thay vì số liệu ước tính. Hãy đọc kỹ, vì con số mọi người thường trích dẫn không phải là mức sử dụng k3s khi idle.

ChartPublished k3s resource use, 95th percentile, Intel 8375C, k3s v1.26.5
The data behind this chart
[
  {
    "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
  }
]

Một server node trong bài kiểm thử đó sử dụng 1,596 MB RAM ở percentile 95 và khoảng 6 phần trăm của một core. Đây là số liệu đã công bố, không phải số đo từ hướng dẫn này. Bài kiểm thử chạy k3s v1.26.5 với tất cả component được đóng gói đã bật, cùng một monitoring stack gồm Prometheus và Grafana. Vì vậy, con số này bao gồm workload thực tế, không phải một cluster trống. Thay sqlite bằng embedded etcd làm mức sử dụng tăng lên 1,606 MB. Một agent node, chạy kubelet và containerd nhưng không có control plane, sử dụng 275 MB. Mức tối thiểu được tài liệu hóa cho một server là 2 core và 2 GB RAM. Mức tối thiểu này bao gồm k3s và các component được đóng gói, trước khi bạn chạy workload của mình.

Cách hiểu thực tế là: trên VPS 2 GB, control plane và các add-on đi kèm chỉ còn lại rất ít tài nguyên. Khi chịu áp lực, việc đầu tiên xảy ra là kubelet evict pod. 4 GB là mức sàn tương đối thoải mái cho một node chạy vài service nhỏ. Hãy đo trực tiếp trên máy của bạn thay vì tin vào bất kỳ số liệu đã công bố nào, kể cả số liệu trong bài này.

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

Chạy free -h trước khi cài đặt và chạy lại sau khi mọi pod trong kube-system có trạng thái Running. Chênh lệch giữa hai lần đo là chi phí của control plane trên phần cứng của bạn. k3s kubectl top node trả về error: Metrics API not available trong một hoặc hai phút đầu sau khi cài đặt, vì metrics-server chưa scrape dữ liệu nào. Đây không phải lỗi. Nếu bạn dùng một máy cho k3s và đồng thời chạy các công việc khác, phép tính trong tính RAM và CPU cho VPS vẫn áp dụng nguyên như vậy.

Cài k3s cố định theo một release, không dùng latest

Dòng lệnh quick start mà mọi người thường sao chép sẽ dùng phiên bản mà stable channel trỏ tới tại thời điểm bạn chạy lệnh. Với máy chủ dự định duy trì lâu dài, hãy cố định phiên bản. k3s phát hành một channel cho từng minor version của Kubernetes, vì vậy INSTALL_K3S_CHANNEL=v1.36 sẽ nhận các patch release trong v1.36 và không tự chuyển sang minor version khác. Tính đến tháng 8 năm 2026, stable channel trỏ tới v1.36.3+k3s1.

Trước tiên hãy tạo file cấu hình, sau đó cài đặt. k3s đọc /etc/rancher/k3s/config.yaml khi khởi động, vì vậy mọi thiết lập trong file này được áp dụng ngay ở lần boot đầu tiên và mọi lần boot sau đó.

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 -

Để cố định một release cụ thể thay vì dùng channel, hãy dùng INSTALL_K3S_VERSION=v1.36.3+k3s1. Dấu cộng là một phần của tag. Sau đó kiểm tra xem k3s đã khởi động thành công chưa.

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

kubectl get node phải liệt kê một node có STATUS Ready trong khoảng 30 giây, và mọi pod trong kube-system phải chuyển sang trạng thái Running hoặc Completed. Node bị kẹt ở NotReady thường có nghĩa là container runtime chưa khởi động, vì vậy hãy đọc sudo journalctl -u k3s -n 100 --no-pager. Với image VPS bất thường, hãy chạy sudo k3s check-config trước khi kiểm tra các vấn đề khác: lệnh này báo các kernel feature còn thiếu, nhanh hơn nhiều so với việc đọc log.

Vì sao cổng 80 đã được sử dụng và cần nhường gì để khắc phục

Đây là lỗi thường gặp trên VPS vốn đã chạy sẵn một dịch vụ nào đó. Quá trình cài đặt vẫn thành công. Sau đó Traefik không bao giờ nhận được địa chỉ, còn site đang chạy vẫn hoạt động, nên không có dấu hiệu lỗi cho đến khi bạn thử truy cập một ingress.

Cơ chế hoạt động như sau: chart Traefik đi kèm tạo một Service loại LoadBalancer trên các cổng 80 và 443. ServiceLB đáp ứng yêu cầu đó bằng cách tạo một DaemonSet gồm các pod nhỏ, có tên với tiền tố svclb-, để chiếm các số cổng đó dưới dạng hostPort trên mỗi node. hostPort đưa trực tiếp cổng của container lên namespace mạng của chính node, giống hệt docker run -p 80:80. Nếu nginx, Caddy, Apache hoặc một container khác đã giữ cổng 80, kernel không thể cấp cổng đó lần thứ hai, nên scheduler không có node nào để đặt 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 )'

Bạn sẽ thấy pod svclb ở trạng thái Pending và service không có địa chỉ bên ngoài:

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

Chạy kubectl -n kube-system describe pod svclb-traefik-... sẽ chỉ rõ nguyên nhân:

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

ss -lntp cho biết tiến trình nào đang giữ cổng. Có nhiều cách xử lý, và mỗi cách đều có đánh đổi.

Nhường các cổng cho k3s. Dừng và disable web server hiện tại, rồi để Traefik quản lý cổng 80 và 443. Đây là lựa chọn phù hợp khi VPS sẽ chỉ chạy k3s và mọi dịch vụ khác bạn đang cung cấp sẽ chuyển ra sau một Ingress.

Disable ServiceLB và giữ proxy hiện tại. Cài đặt bằng --disable=servicelb. Service loại LoadBalancer vẫn cấp phát một NodePort, nên Traefik vẫn có thể truy cập qua một cổng cao như 31480, còn nginx hoặc Caddy của bạn sẽ proxy đến 127.0.0.1:31480. Điều bạn phải bỏ là địa chỉ bên ngoài: service sẽ báo <pending> mãi, trông như một lỗi dù thực tế đó là lựa chọn bạn đã chủ động đặt.

Disable Traefik và định tuyến bằng proxy riêng. Cài đặt bằng --disable=traefik. Khi đó bạn không có ingress controller, nên các đối tượng Ingress hoàn toàn không làm gì: chúng chỉ nằm trong API mà không có controller nào theo dõi. Cách này phù hợp khi bạn định tuyến từ proxy trên host đến các NodePort, và là lựa chọn rõ ràng nếu bạn đã biết muốn xử lý HTTP theo cách nào. Nếu chưa quyết định thành phần nào sẽ đứng phía trước, hãy xác định lựa chọn giữa nginx, Caddy và Traefik làm reverse proxy trước khi disable bất kỳ thành phần nào.

Cả hai flag đều phải được đặt trên installer hoặc trong file cấu hình:

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

Bạn cũng có thể sửa file đó sau khi cài đặt rồi chạy sudo systemctl restart k3s, vì --disable không chỉ bỏ qua một component trong lúc cài đặt. Nó còn xóa component đã được deploy, nên thay đổi sẽ có hiệu lực trên cluster đang chạy.

Để giữ Traefik nhưng thay đổi cách cấu hình chart, không sửa /var/lib/rancher/k3s/server/manifests/traefik.yaml. k3s sẽ ghi đè file đó bằng các giá trị mặc định mỗi lần khởi động. Thay vào đó, hãy thêm một file riêng trong cùng thư mục, vì mọi nội dung trong /var/lib/rancher/k3s/server/manifests sẽ được tự động áp dụng lúc startup và mỗi khi file thay đổi trên 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

Ví dụ đó đặt một giá trị của chart Traefik, cụ thể là các địa chỉ proxy đáng tin cậy. Cơ chế tương tự có thể đặt mọi giá trị khác mà chart cung cấp, bao gồm cả các cổng của nó.

Lưu trữ persistent trên một node

k3s phát hành sẵn một StorageClass mặc định tên là local-path, được hỗ trợ bởi local-path provisioner của Rancher. PersistentVolumeClaim không có storageClassName sẽ sử dụng StorageClass này. Các volume nằm trong /var/lib/rancher/k3s/storage, mỗi volume có một thư mục con riêng trên disk của chính node đó.

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

Việc volume nằm trên disk của chính node tạo ra hai hệ quả. Cả hai thường chỉ gây vấn đề về sau, không phải ngay hôm nay.

StorageClass này dùng volumeBindingMode: WaitForFirstConsumer, nên PVC mới sẽ ở trạng thái Pending cho đến khi một pod thực sự mount nó. kubectl describe pvc in ra:

waiting for first consumer to be created before binding

Đây là hành vi bình thường. Vì vậy, chỉ tạo PVC rồi chờ sẽ không bao giờ làm trạng thái này biến mất.

Sau khi được bind, volume có node affinity trỏ đến node đã tạo nó. Điều này buộc mọi pod sử dụng claim đó phải chạy trên node này trong suốt vòng đời của volume. Với một node, bạn sẽ không nhận ra vấn đề. Sau này thêm node thứ hai, một pod không chịu chuyển node có thể trông giống lỗi của scheduler. Chạy kubectl get pv -o yaml sẽ cho thấy hostname nằm trong nodeAffinity.

Bạn phải tự chịu trách nhiệm về backup. Rebuild VPS sẽ xóa thư mục đó. Script uninstall bên dưới cũng xóa thư mục này. Hãy backup /var/lib/rancher/k3s/storage và cả sqlite datastore tại /var/lib/rancher/k3s/server/db/state.db. Chỉ sao chép datastore khi service đã dừng vì đây là một database đang hoạt động. Cách khác là coi cluster như có thể hủy bất kỳ lúc nào và lưu mọi manifest trong git.

Ingress và TLS

Khi Traefik vẫn được enable, bạn chỉ cần một Ingress object tiêu chuẩn.

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

Certificate không tự xuất hiện. Cách thường dùng là cài cert-manager từ manifest do dự án phát hành, sau đó tạo một ClusterIssuer. Phiên bản v1.21.1 là phiên bản hiện tại tính đến tháng 8 năm 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

HTTP-01 challenge yêu cầu máy chủ ACME (automatic certificate management environment) kết nối đến http://hello.example.com/.well-known/acme-challenge/... từ Internet công cộng. Vì vậy, DNS A record phải trỏ sẵn đến VPS và port 80 phải chuyển được đến Traefik. Nếu bạn đã tắt ServiceLB và đặt proxy riêng ở phía trước, proxy đó cũng phải forward đường dẫn challenge. Nếu không, cert-manager sẽ bị treo và hiển thị thông báo này trên Challenge object:

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

Theo dõi quá trình cấp certificate bằng sudo k3s kubectl describe certificate hello-tls và sudo k3s kubectl get order,challenge -A.

kubeconfig là gì và vì sao API server vẫn ở chế độ private

k3s ghi thông tin xác thực dành cho admin vào /etc/rancher/k3s/k3s.yaml. File này thuộc sở hữu của root và mặc định được ghi với mode 600. File chứa client certificate có quyền cluster-admin, nên bất kỳ ai đọc được file đều có toàn quyền trên cluster.

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

kubectl được cài riêng mà không đặt KUBECONFIG sẽ lỗi với The connection to the server localhost:8080 was refused - did you specify the right host or port? vì nó fallback về một giá trị mặc định không liên quan đến k3s. Hãy đặt KUBECONFIG hoặc dùng sudo k3s kubectl; lệnh này tự đọc đúng file.

Bạn sẽ thấy tài liệu khuyến nghị --write-kubeconfig-mode 644 để user thông thường có thể chạy kubectl. Cần hiểu rõ tác động của cách này: credential cluster-admin sẽ có thể được mọi local account trên máy đọc. Trên máy chỉ có một admin, đây có thể là đánh đổi chấp nhận được. Trên máy dùng chung thì không. Copy file sẽ chỉ cấp quyền cho một user mà không công khai file:

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

Dòng server: trong file đó đọc giá trị https://127.0.0.1:6443. Để dùng kubectl từ laptop, không mở cổng 6443 ra Internet. Kubernetes API public luôn là mục tiêu bị nhắm đến, và API bị expose là nguyên nhân khiến các cluster nhỏ bị dùng để đào cryptocurrency cho người khác. Hãy tunnel qua SSH và giữ nguyên địa chỉ trong file:

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

Nếu bắt buộc phải truy cập API qua địa chỉ private network, hãy cài đặt với tls-san, trong đó liệt kê tên hoặc địa chỉ đó, rồi sửa dòng server: trong file đã copy cho khớp. Nếu thiếu entry SAN (subject alternative name), kubectl sẽ từ chối kết nối:

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

Các cổng inbound được tài liệu cluster ghi nhận là TCP 6443 cho API, UDP 8472 cho flannel VXLAN giữa các node và TCP 10250 cho kubelet metrics. Trên node đơn, không cổng nào trong số này cần mở ra Internet.

containerd không phải Docker

k3s chạy containerd tích hợp riêng và không dùng chung image store với Docker. Image bạn vừa build bằng docker build không hiển thị trong k3s, nên pod fail với ErrImagePull dù docker images vẫn liệt kê image đó. Hãy import image một cách rõ ràng:

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

Sau đó, không dùng tag :latest cho container này, vì :latest mặc định thành imagePullPolicy của Always và kubelet vẫn truy vấn registry. Mọi tag khác đều mặc định thành IfNotPresent, sử dụng image bạn đã import. Chạy cả hai trên một VPS vẫn được. Bạn cần biết rằng cài Docker thông thường trên VPS và k3s đều duy trì image store riêng và các rule iptables riêng trên cùng một máy.

Cách gỡ k3s

Installer tạo sẵn một script gỡ cài đặt. Không có cơ chế gỡ một phần và cũng không có cách hoàn tác.

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

Script này dừng và xóa service, xóa datastore, xóa dữ liệu persistent volume, xóa cấu hình node và xóa các công cụ mà installer đã thêm. Trên agent node, script là k3s-agent-uninstall.sh. Hãy sao chép mọi thứ trong /var/lib/rancher/k3s/storage ra khỏi máy trước, vì thư mục đó cũng sẽ bị xóa. Sau đó, dùng ip link show và sudo ss -lntp để kiểm tra xem còn tiến trình nào giữ các port hoặc interface hay không. Interface cni0 hoặc flannel.1 còn sót lại sẽ tự được xóa ở lần reboot tiếp theo.

Nhận ra rằng một node Kubernetes tạo ra nhiều thành phần hơn mức công việc cần là điều bình thường, không phải thất bại. Thường bạn có thể chuyển các workload đó về Compose trong một buổi chiều.

Các lỗi thường gặp và chuỗi bạn sẽ thấy

Node ở trạng thái NotReady hoặc k3s khởi động lại liên tục. Trước tiên, đọc sudo journalctl -u k3s -n 200 --no-pager. Trên VPS nhỏ, nguyên nhân phổ biến là kernel out-of-memory killer dừng tiến trình. Sự kiện này xuất hiện trong dmesg dưới dạng một dòng có tên k3s-server. Mức tối thiểu được tài liệu ghi là 2 GB là yêu cầu thực tế.

Pod bị kẹt ở trạng thái Pending. kubectl describe pod luôn chỉ rõ nguyên nhân. Insufficient memory hoặc Insufficient cpu có nghĩa là node đã hết tài nguyên. didn't have free ports là lỗi xung đột hostPort nêu ở trên. waiting for first consumer trên một PVC có nghĩa là WaitForFirstConsumer đang hoạt động đúng.

ImagePullBackOff. Tag không tồn tại trong registry mà node có thể truy cập, hoặc bạn đã build image bằng Docker nhưng chưa import image đó vào containerd.

Traefik phản hồi nhưng ứng dụng không phản hồi. Nội dung phản hồi 404 page not found do chính Traefik trả về. Điều này có nghĩa là request đã đến nhưng không có router nào khớp. Kiểm tra Ingress host có khớp với tên bạn đã nhập không và ingressClassName có phải là traefik không.

DNS của cluster lỗi trong khi host vẫn phân giải được tên. Kiểm tra CoreDNS bằng sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Thông báo như plugin/loop: Loop ... detected for zone "." sẽ khiến CoreDNS không khởi động được. Lỗi xảy ra vì CoreDNS forward request đến một resolver rồi resolver đó lại forward ngược về CoreDNS. Đây là tác dụng của địa chỉ loopback trong /etc/resolv.conf. Trỏ k3s đến file upstream thực bằng --resolv-conf /run/systemd/resolve/resolv.conf.

FAQ

Có nên chạy k3s trên một VPS duy nhất không?

Nên chạy khi bạn muốn dùng Kubernetes API: học Kubernetes trên máy do bạn kiểm soát, giữ các deployment dưới dạng manifest để dễ di chuyển, chạy phần mềm chỉ phát hành Helm chart, hoặc xây dựng hệ thống mà sau này bạn sẽ chuyển sang managed cluster. Không nên chạy khi bạn chỉ muốn chạy container, vì Docker Compose làm việc đó với ít thành phần phải bảo trì hơn nhiều và thường có thêm khoảng 1 gigabyte RAM trống. Một node không cung cấp high availability, nên độ tin cậy không bao giờ là lý do để chọn mô hình này.

Vì sao service LoadBalancer của k3s vẫn ở trạng thái Pending?

ServiceLB tạo các pod svclb- dùng hostPort trên node để chiếm các port của service, nên chúng chỉ được schedule trên những node còn các port đó. Nếu nginx hoặc proxy khác đã giữ port 80, pod sẽ ở trạng thái Pending và service không bao giờ nhận được địa chỉ bên ngoài. kubectl -n kube-system describe pod svclb-... báo cáo 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. Hãy giải phóng port đó, hoặc cài đặt lại với --disable=servicelb rồi proxy đến NodePort mà service vẫn cấp phát.

k3s cần bao nhiêu RAM trên VPS?

Mức tối thiểu được tài liệu ghi nhận cho server node là 2 cores và 2 GB, bao gồm k3s cùng các thành phần được đóng gói trước khi chạy workload của bạn. Việc profiling của dự án đo được server node ở mức 1,596 MB khi chạy monitoring stack, vì vậy hãy xem 2 GB là mức tối thiểu và 4 GB là cấu hình đầu tiên đủ thoải mái cho một node. Đo máy của bạn bằng free -h trước khi cài đặt và đo lại sau khi mọi pod trong kube-system chuyển sang trạng thái Running.

Có thể chạy Docker và k3s trên cùng một VPS không?

Có, và chúng hoạt động tách biệt. k3s dùng containerd tích hợp riêng, nên image được build bằng docker build sẽ không hiển thị với k3s cho đến khi bạn chạy docker save myapp:0.1 | sudo k3s ctr images import -. Mỗi bên cũng tự ghi các rule iptables riêng và dùng các bridge network riêng. Hãy theo dõi tổng lượng RAM, vì Docker cộng với k3s và các container của bạn sẽ không vừa trên máy 2 GB.

Làm thế nào để xóa hoàn toàn k3s?

Chạy sudo /usr/local/bin/k3s-uninstall.sh trên server node hoặc sudo /usr/local/bin/k3s-agent-uninstall.sh trên agent. Lệnh này dừng service, xóa datastore, xóa dữ liệu persistent volume dưới /var/lib/rancher/k3s/storage và xóa các công cụ đi kèm. Hãy copy mọi dữ liệu cần giữ ra khỏi máy trước, vì không có cách hoàn tác. Interface mạng cni0 hoặc flannel.1 còn sót lại sẽ biến mất sau lần reboot tiếp theo.

#kubernetes#k3s#docker-compose#ingress#sizing