Adakah k3s berbaloi untuk VPS satu nod?

Apakah k3s dan apa yang anda peroleh daripada satu nod

k3s ialah pengagihan Kubernetes penuh yang dibungkus sebagai satu binari, dan menjalankannya pada satu VPS memberikan anda API Kubernetes sebenar tanpa memerlukan control plane tiga mesin. Ia merupakan pengagihan Kubernetes yang diperakui, jadi manifes yang digunakan di sini boleh digunakan pada kluster terurus kemudian. Pemasangannya hanya memerlukan satu arahan dan mengambil masa kira-kira satu minit. Kos yang perlu dibayar ialah memori yang tidak lagi tersedia untuk aplikasi anda, serta set mod kegagalan yang tidak pernah berlaku dengan Docker Compose.

SUSE membina k3s untuk tapak edge dan pemasangan kecil, dan setiap perbezaan daripada Kubernetes hulu (upstream) wujud untuk menjadikannya lebih kecil. Datastore lalai ialah sqlite di sebalik shim yang dipanggil kine, bukan etcd, jadi tiada kuorum etcd yang perlu diselenggara. containerd dibenamkan dalam binari tersebut dan bukannya dipasang secara berasingan. Binari yang sama juga membekalkan CoreDNS untuk DNS kluster, Traefik sebagai ingress controller, ServiceLB (juga dipanggil klipper-lb) supaya servis LoadBalancer berfungsi tanpa penyedia awan di belakangnya, local-path provisioner untuk persistent volumes, metrics-server, dan flannel untuk rangkaian pod. Setiap satu daripadanya bermula secara lalai. Itulah sebabnya perlanggaran port yang diterangkan di bawah merupakan masalah pertama yang paling biasa berlaku pada VPS yang sudah menjalankan sesuatu.

Apabila satu nod k3s berbaloi

Gunakan peraturan ini. Jalankan k3s apabila API Kubernetes adalah perkara yang anda mahukan: anda sedang mempelajari Kubernetes pada mesin yang anda kawal, atau perisian yang anda mahukan hanya menerbitkan Helm chart. Kemudahalihan manifest juga penting, kerana Deployment yang anda tulis di sini boleh dipindahkan ke kluster terurus tanpa perubahan. Jalankan Docker Compose apabila aplikasi adalah perkara yang anda mahukan. Compose memulakan kontena yang sama dengan bahagian yang jauh lebih sedikit, dan fail Compose pada VPS lebih mudah dibaca setahun kemudian berbanding direktori manifest.

Jelaskan tentang perkara yang tidak diberikan oleh satu nod kepada anda.

• Tiada ketersediaan tinggi (high availability). Apabila VPS but semula, setiap beban kerja terhenti. Kubernetes menjadualkan semula pod ke nod lain, dan tiada nod lain yang tersedia.
• Tiada kemas kini bergulir (rolling update) yang mengekalkan servis, melainkan aplikasi tersebut bertoleransi dengan dua replika pada satu mesin yang berkongsi satu volum.
• Storan yang terikat pada kotak tersebut, atas sebab yang diterangkan dalam bahagian local-path di bawah.
• Control plane yang memakan sekitar satu gigabait RAM sama ada anda menggunakan apa-apa atau tidak.

Tiada satu pun daripada perkara tersebut menjadikan k3s pilihan yang buruk. Ia menjadikannya pilihan yang buruk atas sebab yang biasanya diberikan oleh orang ramai, iaitu kebolehpercayaan. Jika apa yang anda sebenarnya mahukan ialah beberapa mesin supaya anda boleh membina kluster berbilang nod yang sebenar, keputusan itu datang dahulu: Proxmox pada perkakasan sendiri berbanding VPS sewaan menentukan dari mana nod itu datang sebelum k3s menentukan perkara yang dijalankan di atasnya.

Kos RAM dan CPU k3s sebelum anda membuat sebarang deployment

Projek k3s menerbitkan angka yang diukur dan bukannya anggaran. Baca angka tersebut dengan teliti, kerana angka yang sering disebut orang bukanlah penggunaan k3s dalam keadaan melahu (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
  }
]

Satu nod pelayan dalam ujian tersebut menggunakan 1,596 MB RAM pada persentil ke-95 dan kira-kira 6 peratus daripada satu teras CPU. Itu adalah angka yang diterbitkan, bukan ukuran daripada panduan ini, dan ujian tersebut menjalankan k3s v1.26.5 dengan semua komponen pakej diaktifkan berserta timbunan pemantauan Prometheus dan Grafana, jadi angka tersebut merangkumi beban kerja sebenar dan bukannya kluster kosong. Menukar sqlite kepada etcd terbenam meningkatkan penggunaan kepada 1,606 MB. Nod ejen, yang menjalankan kubelet dan containerd tanpa control plane, menggunakan 275 MB. Minimum yang didokumenkan untuk pelayan ialah 2 teras dan 2 GB RAM, dan minimum itu meliputi k3s serta komponen pakejnya sebelum beban kerja anda.

Bacaan praktikalnya: pada VPS 2 GB, control plane dan alat tambah yang disertakan meninggalkan ruang yang sangat sedikit, dan perkara pertama yang berlaku di bawah tekanan ialah kubelet menyingkirkan (evict) pod. 4 GB adalah lantai yang selesa untuk satu nod dengan beberapa servis kecil. Ukur kotak anda sendiri dan jangan hanya mempercayai mana-mana angka yang diterbitkan, termasuk angka ini.

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

Jalankan free -h sebelum anda memasang dan sekali lagi sebaik sahaja setiap pod dalam kube-system menunjukkan status Running. Perbezaannya ialah kos control plane pada perkakasan anda. k3s kubectl top node akan memaparkan error: Metrics API not available untuk satu atau dua minit pertama selepas pemasangan, kerana metrics-server belum lagi mengumpul sebarang data. Itu bukan satu ralat. Jika anda sedang menentukan saiz satu kotak untuk ini dan kerja lain pada masa yang sama, pengiraan dalam menentukan saiz RAM dan CPU untuk VPS terpakai di sini tanpa perubahan.

Memasang k3s dengan versi tetap, bukan versi terkini

Arahan permulaan pantas yang sering disalin oleh pengguna akan mengambil versi yang ditetapkan oleh saluran stabil pada hari arahan tersebut dijalankan. Pada mesin yang ingin dikekalkan, tetapkan versinya. k3s menerbitkan satu saluran bagi setiap versi minor Kubernetes, jadi INSTALL_K3S_CHANNEL=v1.36 akan mengikuti keluaran tampalan (patch releases) dalam v1.36 dan tidak akan melompat ke versi minor lain secara automatik. Sehingga Ogos 2026, saluran stabil merujuk kepada v1.36.3+k3s1.

Tulis fail konfigurasi terlebih dahulu, kemudian lakukan pemasangan. k3s membaca /etc/rancher/k3s/config.yaml semasa ia bermula, jadi sebarang tetapan di dalamnya akan terpakai pada but pertama serta setiap but seterusnya.

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 keluaran yang tepat dan bukannya saluran, gunakan INSTALL_K3S_VERSION=v1.36.3+k3s1. Tanda tambah adalah sebahagian daripada tag tersebut. Kemudian, semak sama ada ia telah berjaya dimulakan.

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

kubectl get node sepatutnya menyenaraikan satu nod dengan STATUS Ready dalam masa kira-kira tiga puluh saat, dan setiap pod dalam kube-system sepatutnya mencapai status Running atau Completed. Nod yang terhenti pada status NotReady biasanya bermaksud runtime kontena tidak bermula, jadi baca sudo journalctl -u k3s -n 100 --no-pager. Pada imej VPS yang luar biasa, jalankan sudo k3s check-config sebelum anda menyahpepijat perkara lain: ia melaporkan ciri kernel yang hilang, yang merupakan jawapan yang jauh lebih pantas daripada membaca log.

Mengapa port 80 sudah digunakan, dan apa yang perlu dikorbankan untuk membaikinya

Ini adalah kegagalan yang sering dihadapi pengguna pada VPS yang sudah menjalankan sesuatu servis. Pemasangan berjaya dilakukan. Traefik kemudian tidak mendapat alamat, dan tapak yang anda jalankan sebelum ini terus berfungsi, jadi tiada apa yang kelihatan rosak sehingga anda cuba mencapai ingress.

Mekanismenya: carta Traefik yang disertakan mencipta Service jenis LoadBalancer pada port 80 dan 443. ServiceLB menjawab permintaan itu dengan mencipta DaemonSet bagi pod kecil, yang dinamakan dengan awalan svclb-, yang menuntut nombor port tersebut sebagai hostPort pada setiap nod. hostPort menerbitkan port kontena terus ke dalam ruang nama rangkaian nod itu sendiri, sama seperti docker run -p 80:80. Jika nginx, Caddy, Apache atau kontena lain sudah memegang port 80, kernel tidak akan memberikannya dua kali, jadi penjadual tidak mempunyai tempat untuk meletakkan pod tersebut.

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 dalam status Pending dan perkhidmatan tanpa alamat luaran:

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-... menyatakan puncanya secara terus:

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

ss -lntp memberitahu anda proses mana yang memegang port tersebut. Terdapat lebih daripada satu jalan keluar, dan setiap satunya memerlukan pengorbanan.

Berikan port tersebut kepada k3s. Hentikan dan nyahdayakan pelayan web sedia ada, kemudian biarkan Traefik memiliki port 80 dan 443. Ini adalah jawapan yang tepat apabila VPS tersebut akan menjadi mesin k3s sepenuhnya, dan semua yang anda hidangkan dipindahkan ke belakang Ingress.

Nyahdayakan ServiceLB dan kekalkan proksi sedia ada anda. Pasang dengan --disable=servicelb. Service jenis LoadBalancer masih memperuntukkan NodePort, jadi Traefik kekal boleh dicapai pada port tinggi seperti 31480, dan nginx atau Caddy anda melakukan proksi ke 127.0.0.1:31480. Apa yang anda korbankan ialah alamat luaran: perkhidmatan tersebut melaporkan <pending> selama-lamanya, yang kelihatan seperti ralat sedangkan ia adalah pilihan yang anda buat.

Nyahdayakan Traefik dan halakan dengan proksi anda sendiri. Pasang dengan --disable=traefik. Anda kemudian tidak mempunyai pengawal ingress, jadi objek Ingress tidak melakukan apa-apa: ia kekal dalam API tanpa pengawal yang memantaunya. Itu tidak mengapa apabila anda menghalakan trafik daripada proksi hos ke NodePort, dan ia adalah pilihan yang jujur jika anda sudah tahu cara anda mahu HTTP dikendalikan. Jika anda belum membuat keputusan tentang apa yang sepatutnya berada di hadapan, selesaikan pilihan antara nginx, Caddy dan Traefik sebagai reverse proxy sebelum anda menyahdayakan apa-apa.

Kedua-dua flag tersebut diletakkan pada pemasang, atau dalam fail konfigurasi:

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

Menyunting fail tersebut selepas pemasangan dan menjalankan sudo systemctl restart k3s juga berkesan, kerana --disable melakukan lebih daripada sekadar melangkau komponen semasa pemasangan. Ia juga memadamkan komponen yang sudah digunakan, jadi perubahan tersebut berkuat kuasa pada kluster yang sedang berjalan.

Untuk mengekalkan Traefik tetapi menukar cara carta dikonfigurasikan, jangan sunting /var/lib/rancher/k3s/server/manifests/traefik.yaml. k3s menulis semula fail tersebut dengan tetapan lalai setiap kali ia bermula. Tambahkan fail berasingan dalam direktori yang sama sebaliknya, kerana apa-apa yang berada dalam /var/lib/rancher/k3s/server/manifests digunakan secara automatik semasa permulaan dan setiap kali ia berubah pada cakera.

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 carta Traefik, iaitu alamat proksi yang dipercayai. Mekanisme yang sama menetapkan sebarang nilai lain yang didedahkan oleh carta tersebut, termasuk portnya.

Storan kekal pada satu nod

k3s membekalkan StorageClass lalai yang dipanggil local-path, yang disokong oleh local-path provisioner daripada Rancher. PersistentVolumeClaim tanpa storageClassName akan menggunakan storan ini. Volume disimpan dalam /var/lib/rancher/k3s/storage, dengan satu subdirektori bagi setiap volume, pada cakera nod itu sendiri.

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

Terdapat dua kesan daripada penggunaan "cakera nod itu sendiri", dan kedua-duanya akan menimbulkan masalah pada masa hadapan.

StorageClass ini menggunakan volumeBindingMode: WaitForFirstConsumer, jadi PVC baharu akan kekal dalam status Pending sehingga pod benar-benar melakukan mount pada volume tersebut. kubectl describe pvc akan memaparkan:

waiting for first consumer to be created before binding

Ini adalah perkara biasa, jadi mencipta PVC secara berasingan dan menunggunya tidak akan mengubah status tersebut.

Setelah bound, volume tersebut membawa node affinity untuk nod yang menciptakannya, yang mengikat setiap pod yang menggunakan tuntutan tersebut kepada nod itu sepanjang hayat volume berkenaan. Pada satu nod, anda tidak akan menyedari perkara ini. Jika anda menambah nod kedua kemudian, pod yang enggan berpindah akan kelihatan seperti pepijat penjadual (scheduler bug) sehingga anda menjalankan kubectl get pv -o yaml dan mendapati nama hos tersebut berada dalam nodeAffinity.

Sandaran (backup) adalah tanggungjawab anda. Membina semula VPS akan memadamkan direktori tersebut, begitu juga dengan skrip nyahpasang di bawah. Lakukan sandaran bagi /var/lib/rancher/k3s/storage, serta sqlite datastore di /var/lib/rancher/k3s/server/db/state.db yang disalin semasa servis dihentikan, kerana ia merupakan pangkalan data yang aktif. Alternatifnya ialah menganggap kluster sebagai boleh lupus dan menyimpan setiap manifest dalam git.

Ingress dan TLS

Dengan Traefik dibiarkan aktif, objek Ingress standard adalah semua yang anda perlukan.

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

Sijil tidak akan muncul dengan sendirinya. Penyelesaian biasa ialah cert-manager, yang dipasang daripada manifes yang diterbitkan, ditambah dengan satu ClusterIssuer. Versi v1.21.1 adalah versi semasa setakat Ogos 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

Cabaran HTTP-01 bermaksud pelayan ACME (automatic certificate management environment) bersambung ke http://hello.example.com/.well-known/acme-challenge/... daripada internet awam. Oleh itu, rekod DNS A mestilah sudah menghala ke VPS, dan port 80 mestilah boleh mencapai Traefik. Jika anda melumpuhkan ServiceLB dan meletakkan proksi anda sendiri di hadapan, proksi tersebut juga perlu memajukan laluan cabaran, atau cert-manager akan terhenti dengan status ini pada objek Challenge:

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

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

Fail kubeconfig dan sebab pelayan API kekal peribadi

k3s menulis kelayakan admin ke /etc/rancher/k3s/k3s.yaml. Fail ini dimiliki oleh root dan ditulis dengan mod 600 secara lalai. Ia mengandungi sijil klien dengan hak cluster-admin, jadi sesiapa yang boleh membacanya memiliki kluster tersebut.

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

kubectl yang dipasang secara berasingan tanpa KUBECONFIG ditetapkan akan gagal dengan The connection to the server localhost:8080 was refused - did you specify the right host or port? kerana ia kembali kepada lalai yang tiada kaitan dengan k3s. Tetapkan KUBECONFIG, atau gunakan sudo k3s kubectl, yang membaca fail yang betul dengan sendirinya.

Anda akan melihat --write-kubeconfig-mode 644 disyorkan supaya pengguna biasa boleh menjalankan kubectl. Fahami apa yang dilakukan oleh arahan itu: ia menjadikan kelayakan cluster-admin boleh dibaca oleh setiap akaun tempatan pada mesin tersebut. Pada kotak dengan admin tunggal, itu mungkin pertukaran yang boleh diterima. Pada kotak yang dikongsi, ia tidak boleh diterima. Menyalin fail tersebut sebaliknya memberikan akses kepada seorang pengguna tanpa mendedahkannya kepada semua:

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

Baris server: dalam fail itu berbunyi https://127.0.0.1:6443. Untuk menggunakan kubectl dari komputer riba anda, jangan buka 6443 kepada internet. API Kubernetes awam adalah sasaran tetap, dan API yang terdedah adalah punca kluster kecil akhirnya melombong mata wang kripto untuk orang lain. Terowongkan ia melalui SSH dan biarkan alamat dalam fail itu tidak berubah:

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

Jika anda mesti mencapai API melalui alamat rangkaian peribadi, pasang dengan tls-san yang menyenaraikan nama atau alamat tersebut, kemudian edit baris server: pada fail yang disalin untuk dipadankan. Tanpa entri SAN (subject alternative name), kubectl akan menolak sambungan tersebut:

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

Port masuk yang didokumenkan untuk kluster ialah TCP 6443 untuk API, UDP 8472 untuk flannel VXLAN antara nod, dan TCP 10250 untuk metrik kubelet. Pada nod tunggal, tiada satu pun daripadanya perlu dibuka kepada internet.

containerd bukan Docker

k3s menjalankan containerd terbenamnya sendiri, dan ia tidak berkongsi storan imej dengan Docker. Imej yang baru anda bina dengan docker build tidak dapat dilihat oleh k3s, jadi pod gagal dengan ErrImagePull walaupun docker images menyenaraikannya. Import imej tersebut secara eksplisit:

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

Kemudian, elakkan tag :latest pada container tersebut, kerana :latest secara lalai menetapkan imagePullPolicy kepada Always dan kubelet akan tetap pergi ke registry. Sebarang tag lain secara lalai menetapkan IfNotPresent, yang menggunakan imej yang telah anda import. Menjalankan kedua-duanya pada satu VPS boleh dilakukan, dan adalah berguna untuk mengetahui bahawa pemasangan Docker biasa pada VPS dan k3s masing-masing menyimpan storan imej sendiri serta peraturan iptables sendiri pada mesin yang sama.

Cara membuang k3s

Pemasang menulis skrip penyahpasangan. Tiada fungsi pembuangan separa atau buat asal (undo).

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

Skrip ini menghentikan dan membuang servis, memadam storan data, memadam data volum berterusan, membuang konfigurasi nod, serta membuang alatan yang ditambah oleh pemasang. Pada nod ejen, skrip tersebut adalah k3s-agent-uninstall.sh sebaliknya. Salin apa-apa sahaja di bawah /var/lib/rancher/k3s/storage keluar dari pelayan terlebih dahulu, kerana direktori tersebut akan turut dipadamkan. Selepas itu, pastikan tiada apa-apa yang masih memegang port atau antara muka dengan ip link show dan sudo ss -lntp. Antara muka cni0 atau flannel.1 yang tertinggal akan dibersihkan pada but semula seterusnya.

Memutuskan bahawa satu nod Kubernetes adalah lebih kompleks daripada yang diperlukan untuk tugasan tersebut adalah hasil yang biasa dan bukannya satu kegagalan. Memindahkan beban kerja tersebut kembali ke Compose biasanya mengambil masa satu petang sahaja.

Mod kegagalan dan rentetan yang akan anda lihat

Node NotReady, atau k3s memulakan semula dalam gelung. Baca sudo journalctl -u k3s -n 200 --no-pager dahulu. Pada VPS kecil, punca biasa ialah pembunuh kehabisan memori (OOM killer) kernel yang menamatkan proses tersebut, yang muncul dalam dmesg sebagai baris yang menamakan k3s-server. Keperluan minimum 2 GB yang didokumenkan adalah had sebenar.

Pod tersangkut dalam status Pending. kubectl describe pod menamakannya setiap kali. Insufficient memory atau Insufficient cpu bermaksud nod tidak mempunyai ruang lagi. didn't have free ports ialah perlanggaran hostPort seperti di atas. waiting for first consumer pada PVC bermaksud WaitForFirstConsumer sedang menjalankan tugasnya.

ImagePullBackOff. Sama ada tag tidak wujud dalam mana-mana pendaftaran (registry) yang boleh dicapai oleh nod, atau anda membina imej dengan Docker dan tidak pernah mengimportnya ke dalam containerd.

Traefik menjawab, aplikasi tidak. Badan respons 404 page not found datang daripada Traefik sendiri dan bermaksud permintaan telah sampai tetapi tiada router yang sepadan. Semak bahawa Ingress host sepadan dengan nama yang anda taip, dan ingressClassName adalah traefik.

DNS kluster gagal sedangkan hos dapat menyelesaikan (resolve) dengan baik. Semak CoreDNS dengan sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Mesej seperti plugin/loop: Loop ... detected for zone "." menghalang CoreDNS daripada bermula. Ia berlaku kerana CoreDNS sedang memajukan (forward) ke resolver yang memajukan semula kepadanya, iaitu perkara yang dilakukan oleh alamat loopback dalam /etc/resolv.conf. Halakan k3s ke fail upstream sebenar dengan --resolv-conf /run/systemd/resolve/resolv.conf.

FAQ

Adakah berbaloi menjalankan k3s pada satu VPS tunggal?

Ia berbaloi apabila anda memerlukan API Kubernetes: untuk mempelajarinya pada mesin yang anda kawal, mengekalkan kebolehalihtempatan deployment sebagai manifest, menjalankan perisian yang hanya menerbitkan Helm chart, atau membina sesuatu yang akan dipindahkan ke managed cluster pada masa hadapan. Ia tidak berbaloi jika anda hanya mahu menjalankan container, kerana Docker Compose melakukan perkara tersebut dengan penyelenggaraan yang jauh lebih rendah dan penjimatan RAM kira-kira satu gigabait. Satu nod tidak memberikan anda high availability, jadi kebolehpercayaan bukanlah sebab untuk memilihnya.

Mengapa servis LoadBalancer k3s saya kekal dalam status Pending?

ServiceLB mencipta svclb- pod yang menuntut port servis sebagai hostPort pada nod, jadi ia hanya dijadualkan di tempat yang port tersebut bebas. Jika nginx atau proksi lain sudah menggunakan port 80, pod akan kekal Pending dan servis tidak akan menerima alamat luaran. 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 pasang semula dengan --disable=servicelb dan buat proksi ke NodePort yang masih diperuntukkan oleh servis tersebut.

Berapa banyak RAM yang diperlukan oleh k3s pada sebuah VPS?

Minimum yang didokumentasikan untuk nod pelayan ialah 2 teras dan 2 GB, dan itu meliputi k3s serta komponen pakejnya sebelum beban kerja anda. Profiling projek itu sendiri mengukur nod pelayan pada 1,596 MB dengan stack pemantauan berjalan di atasnya, jadi anggap 2 GB sebagai lantai dan 4 GB sebagai saiz pertama di mana satu nod beroperasi dengan selesa. Ukur kotak anda sendiri dengan free -h yang diambil sebelum pemasangan dan sekali lagi selepas setiap pod dalam kube-system membaca Running.

Bolehkah saya menjalankan Docker dan k3s pada VPS yang sama?

Boleh, dan ia kekal berasingan. k3s menggunakan containerd terbenamnya sendiri, jadi imej yang dibina dengan docker build tidak kelihatan kepadanya sehingga anda menjalankan docker save myapp:0.1 | sudo k3s ctr images import -. Setiap satu juga menulis peraturan iptables dan rangkaian bridge sendiri. Pantau jumlah memori, kerana Docker ditambah k3s dan container anda tidak akan muat pada kotak 2 GB.

Bagaimanakah cara untuk membuang k3s sepenuhnya?

Jalankan sudo /usr/local/bin/k3s-uninstall.sh pada nod pelayan, atau sudo /usr/local/bin/k3s-agent-uninstall.sh pada ejen. Ia menghentikan servis, memadam datastore, memadam data persistent volume di bawah /var/lib/rancher/k3s/storage, dan membuang alatan yang dibundelkan. Salin sebarang data yang anda ingin simpan keluar dari kotak tersebut terlebih dahulu, kerana tiada fungsi buat asal (undo). Antara muka rangkaian cni0 atau flannel.1 yang tertinggal akan hilang pada but semula seterusnya.