ద్వారా Matt Connor 2026-08-13 · అప్‌డేట్ చేయబడింది 2026-08-16

VPSలో single-node k3s ఎప్పుడు ఉపయోగకరం?

Q: నా k3s LoadBalancer service Pending స్థితిలోనే ఎందుకు ఉంటుంది?

ServiceLB svclb- pods ను సృష్టిస్తుంది. ఇవి node పై service ports ను hostPort గా claim చేస్తాయి. అందువల్ల ఆ ports ఖాళీగా ఉన్న చోట మాత్రమే ఇవి schedule అవుతాయి. nginx లేదా మరొక proxy ఇప్పటికే port 80 ను ఉపయోగిస్తుంటే pod Pending స్థితిలోనే ఉంటుంది. Service కు external address ఎప్పటికీ అందదు. kubectl -n kube-system describe pod svclb-..., 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports ను report చేస్తుంది. ఆ port ను ఖాళీ చేయండి. లేదా --disable=servicelb తో మళ్లీ install చేసి, service కేటాయించే NodePort కు proxy చేయండి.

Q: k3s ను పూర్తిగా ఎలా తొలగించాలి?

Server node పై sudo /usr/local/bin/k3s-uninstall.sh ను, agent పై sudo /usr/local/bin/k3s-agent-uninstall.sh ను అమలు చేయండి. ఇది service ను ఆపుతుంది, datastore ను తొలగిస్తుంది, /var/lib/rancher/k3s/storage కింద ఉన్న persistent volume data ను తొలగిస్తుంది మరియు bundled tools ను తీసివేస్తుంది. ఉంచుకోవాలనుకునే data ను ముందుగా system నుండి బయటకు copy చేయండి, ఎందుకంటే ఈ చర్యను undo చేయలేరు. మిగిలిపోయిన cni0 లేదా flannel.1 network interface తదుపరి reboot సమయంలో తొలగిపోతుంది.

k3s ఒక VPSలో నిజమైన Kubernetes API ఇస్తుంది. ఎంత RAM పడుతుంది, install సమయంలో port 80 ఎందుకు ఢీకొంటుంది, Docker Compose ఎప్పుడు మంచిదో తెలుసుకోండి.

k3s అంటే ఏమిటి, దాని ఒక node మీకు ఏమి అందిస్తుంది

k3s అనేది ఒకే binary గా ప్యాక్ చేసిన పూర్తి Kubernetes distribution. దీన్ని ఒకే VPS పై నడిపితే, మూడు యంత్రాల control plane అవసరం లేకుండా నిజమైన Kubernetes API లభిస్తుంది. ఇది certified Kubernetes distribution. అందువల్ల ఇక్కడ వర్తించే manifest ను తరువాత managed cluster పై కూడా వర్తింపజేయవచ్చు. Installation కోసం ఒకే command చాలు. దీనికి సుమారు ఒక నిమిషం పడుతుంది. అయితే దీనివల్ల మీ applications కు అందుబాటులో లేని memory కొంత వినియోగించబడుతుంది. Docker Compose తో ఎప్పుడూ ఎదురుకాని కొన్ని failure modes కూడా వస్తాయి.

SUSE k3s ను edge sites మరియు చిన్న installations కోసం రూపొందించింది. Upstream Kubernetes తో ఉన్న ప్రతి తేడా దీన్ని చిన్నదిగా చేయడానికే ఉంది. Default datastore గా etcd బదులు kine అనే shim వెనుక sqlite ఉపయోగించబడుతుంది. అందువల్ల etcd quorum ను నిర్వహించాల్సిన అవసరం ఉండదు. containerd ను విడిగా install చేయకుండా binary లోనే పొందుపరిచారు. అదే binary cluster DNS కోసం CoreDNS, ingress controller గా Traefik, cloud provider లేకపోయినా LoadBalancer services పనిచేయడానికి ServiceLB (దీనిని klipper-lb అని కూడా అంటారు), persistent volumes కోసం local-path provisioner, metrics-server, అలాగే pod networking కోసం flannel ను కూడా అందిస్తుంది. ఇవన్నీ default గా ప్రారంభమవుతాయి. అందుకే ఇప్పటికే ఇతర పనులు చేస్తున్న VPS లో క్రింద వివరించే port collision అత్యంత సాధారణమైన మొదటి సమస్యగా ఉంటుంది.

ఒకే k3s node ఎప్పుడు సముచితంగా ఉంటుంది

ఈ నియమాన్ని పాటించండి. మీకు కావలసింది Kubernetes API అయితే k3s ను నడపండి: మీరు నియంత్రించే machine పై Kubernetes నేర్చుకుంటున్నప్పుడు, లేదా మీకు కావలసిన software ను Helm chart రూపంలో మాత్రమే ప్రచురించినప్పుడు ఇది సరైన ఎంపిక. Manifest portability కూడా పరిగణనలోకి వస్తుంది, ఎందుకంటే ఇక్కడ మీరు రాసిన Deployment ను ఎలాంటి మార్పులు లేకుండా managed cluster కు తరలించవచ్చు. మీకు కావలసింది applications అయితే Docker Compose ను నడపండి. Compose చాలా తక్కువ భాగాలతో అదే containers ను ప్రారంభిస్తుంది. ఒక సంవత్సరం తర్వాత కూడా VPS పై ఉన్న Compose file ను manifests ఉన్న directory కంటే చదవడం సులభంగా ఉంటుంది.

ఒక node ఏమి అందించదో స్పష్టంగా తెలుసుకోండి.

High availability ఉండదు. VPS reboot అయితే ప్రతి workload ఆగిపోతుంది. Kubernetes ఒక pod ను మరొక node పై reschedule చేస్తుంది. కానీ ఇక్కడ మరొక node ఉండదు.
ఒకే machine పై ఒకే volume ను పంచుకునే రెండు replicas ను application సహించకపోతే, service అందుబాటులోనే ఉండే rolling update ఉండదు.
క్రింద local-path section లో వివరించిన కారణంగా, storage ఆ machine కే పరిమితమవుతుంది.
మీరు ఏదీ deploy చేయకపోయినా, control plane సుమారు ఒక gigabyte RAM వినియోగిస్తుంది.

ఇవేవీ k3s ను చెడు ఎంపికగా మార్చవు. అయితే reliability కోసం సాధారణంగా చెప్పే కారణంతో k3s ను ఎంచుకోవడం తప్పు అవుతుంది. మీకు నిజంగా కావలసింది ఒక వాస్తవ multi-node cluster నిర్మించడానికి అనేక machines అయితే, ముందుగా ఆ నిర్ణయం తీసుకోవాలి: మీ స్వంత hardware పై Proxmox మరియు rented VPS మధ్య ఎంపిక nodes ఎక్కడి నుంచి వస్తాయో నిర్ణయిస్తుంది; తరువాత వాటిపై ఏమి నడపాలో k3s నిర్ణయిస్తుంది.

ఏదైనా deploy చేయడానికి ముందు k3s ఉపయోగించే RAM మరియు CPU

k3s project అంచనాల బదులు కొలిచిన గణాంకాలను ప్రచురిస్తుంది. వాటిని జాగ్రత్తగా చదవాలి, ఎందుకంటే సాధారణంగా చెప్పే సంఖ్య idle k3s వినియోగాన్ని సూచించదు.

ChartPublished k3s resource use, 95th percentile, Intel 8375C, k3s v1.26.5

label

ram_mb

cpu_percent_of_one_core

Server, sqlite datastore

1,596

Server, embedded etcd

1,606

Agent node only

275

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
  }
]

ఆ పరీక్షలో server node 95th percentile వద్ద 1,596 MB RAM మరియు ఒక core లో సుమారు 6 శాతం ఉపయోగించింది. ఇవి ప్రచురించిన గణాంకాలు; ఈ guide లో చేసిన కొలతలు కావు. ఆ పరీక్షలో అన్ని packaged components enabled గా ఉన్న k3s v1.26.5 తో పాటు Prometheus మరియు Grafana monitoring stack నడిచాయి. అందువల్ల ఆ సంఖ్య ఖాళీ cluster వినియోగాన్ని కాకుండా వాస్తవ workload ను కూడా కలిగి ఉంది. sqlite స్థానంలో embedded etcd ఉపయోగించినప్పుడు RAM వినియోగం 1,606 MB కు మారింది. Control plane లేకుండా kubelet మరియు containerd నడిపే agent node 275 MB ఉపయోగించింది. Server కోసం documented minimum 2 cores మరియు 2 GB RAM. ఈ minimum లో మీ workloads కు ముందు k3s మరియు దాని packaged components వినియోగం మాత్రమే ఉంటుంది.

ప్రాయోగికంగా చూస్తే, 2 GB VPS లో control plane మరియు దానితో వచ్చిన bundled add-ons తర్వాత చాలా తక్కువ వనరులు మిగులుతాయి. ఒత్తిడి పెరిగినప్పుడు మొదట kubelet pods ను evict చేస్తుంది. కొన్ని చిన్న services తో ఒకే node నడపడానికి 4 GB సౌకర్యవంతమైన కనిష్ఠ పరిమాణం. ఏదైనా published figure ను, ఇందులో ఉన్నదానిని కూడా, నమ్మకుండా మీ స్వంత machine పై కొలవండి.

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

Install చేయడానికి ముందు, అలాగే kube-system లోని ప్రతి pod Running స్థితికి వచ్చిన తర్వాత మళ్లీ free -h ను run చేయండి. ఈ రెండు కొలతల మధ్య తేడా మీ hardware పై control plane ఉపయోగించే వనరు. Install చేసిన తర్వాత మొదటి ఒకటి లేదా రెండు నిమిషాల్లో k3s kubectl top node, error: Metrics API not available ను తిరిగి ఇస్తుంది, ఎందుకంటే metrics-server ఇంకా metrics ను scrape చేయలేదు. ఇది లోపం కాదు. దీనితో పాటు ఇతర పనులను కూడా ఒకే machine పై నడపడానికి వనరులను నిర్ధారిస్తున్నట్లయితే, VPS కోసం RAM మరియు CPU పరిమాణాన్ని నిర్ణయించడం లోని లెక్కింపు ఇక్కడ కూడా ఎలాంటి మార్పు లేకుండా వర్తిస్తుంది.

ఒక release కు pin చేసి k3s install చేయండి, latest కు కాదు

అందరూ copy చేసే quick start line, మీరు దాన్ని run చేసిన రోజున stable channel ఏ release ను సూచిస్తే అదే తీసుకుంటుంది. మీరు కొనసాగించాలనుకునే machine పై దీన్ని pin చేయండి. k3s ప్రతి Kubernetes minor version కు ఒక channel ను publish చేస్తుంది. అందువల్ల INSTALL_K3S_CHANNEL=v1.36 v1.36 లోని patch releases ను మాత్రమే అనుసరిస్తుంది. మీకు తెలియకుండా minor version కు మారదు. August 2026 నాటికి stable channel v1.36.3+k3s1 ను సూచిస్తోంది.

ముందుగా config file ను రాయండి. తరువాత install చేయండి. k3s ప్రారంభమైనప్పుడు /etc/rancher/k3s/config.yaml ను చదువుతుంది. అందువల్ల అందులోని ప్రతి setting మొదటి boot కు, ఆ తరువాతి ప్రతి boot కు కూడా వర్తిస్తుంది.

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 -

ఒక channel కు బదులుగా ఖచ్చితమైన release కు pin చేయాలంటే INSTALL_K3S_VERSION=v1.36.3+k3s1 ఉపయోగించండి. Plus sign tag లో భాగమే. తరువాత అది సరిగ్గా ప్రారంభమైందో తనిఖీ చేయండి.

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

kubectl get node సుమారు ముప్పై seconds లో STATUS Ready తో ఒక node ను చూపించాలి. kube-system లోని ప్రతి pod Running లేదా Completed స్థితికి చేరాలి. ఒక node NotReady వద్దే నిలిచిపోతే container runtime ప్రారంభం కాలేదని సాధారణంగా అర్థం. అందువల్ల sudo journalctl -u k3s -n 100 --no-pager చదవండి. అసాధారణమైన VPS image పై, మరేదైనా debug చేయడానికి ముందు sudo k3s check-config run చేయండి. ఇది లేని kernel features ను చూపిస్తుంది. Logs చదవడం కంటే ఇది చాలా వేగంగా కారణాన్ని తెలియజేస్తుంది.

80 port ఇప్పటికే ఉపయోగంలో ఉండటానికి కారణం, దాన్ని పరిష్కరించడానికి ఏదాన్ని విడిచిపెట్టాలి

ఇప్పటికే ఏదో సేవ అందిస్తున్న VPSలో ఈ వైఫల్యం తరచుగా కనిపిస్తుంది. Installation విజయవంతంగా పూర్తవుతుంది. కానీ Traefik కు address ఎప్పటికీ లభించదు. మీరు ఇప్పటికే నడుపుతున్న site మాత్రం పనిచేస్తూనే ఉంటుంది. అందువల్ల ingress ను చేరుకోవడానికి ప్రయత్నించే వరకు ఏదీ విరిగినట్లు కనిపించదు.

ఇది ఇలా జరుగుతుంది: చేర్చబడిన Traefik chart, 80 మరియు 443 ports పై LoadBalancer రకానికి చెందిన Service ను సృష్టిస్తుంది. ఆ అభ్యర్థనకు ServiceLB స్పందించి, ప్రతి node పై ఆ port numbers ను hostPort గా claim చేసే చిన్న podsతో కూడిన DaemonSet ను సృష్టిస్తుంది. ఈ pods పేర్లకు svclb- prefix ఉంటుంది. hostPort, docker run -p 80:80 చేసే విధంగానే, container port ను నేరుగా node యొక్క స్వంత network namespace పై publish చేస్తుంది. nginx, Caddy, Apache లేదా మరొక container ఇప్పటికే port 80 ను పట్టుకుని ఉంటే, kernel దాన్ని రెండుసార్లు కేటాయించదు. అందువల్ల scheduler కు ఆ 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 )'

svclb pod Pending స్థితిలో ఉండటం, అలాగే service కు external address లేకపోవడం కనిపిస్తుంది:

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

kubectl -n kube-system describe pod svclb-traefik-... ను అమలు చేస్తే కారణం నేరుగా తెలుస్తుంది:

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

ఆ port ను ఏ process పట్టుకుని ఉందో ss -lntp చూపిస్తుంది. సమస్యను పరిష్కరించడానికి ఒకటి కంటే ఎక్కువ మార్గాలు ఉన్నాయి. ప్రతి మార్గంలో మీరు ఏదో ఒకదాన్ని వదులుకోవాలి.

Ports ను k3s కు అప్పగించండి. ఇప్పటికే ఉన్న web server ను stop చేసి disable చేయండి. తరువాత 80 మరియు 443 ports ను Traefik ఉపయోగించనివ్వండి. VPS పూర్తిగా k3s box గా మాత్రమే ఉపయోగించబడబోతున్నప్పుడు, అలాగే మీరు అందిస్తున్న అన్ని services Ingress వెనుకకు మారుతున్నప్పుడు ఇది సరైన ఎంపిక.

ServiceLB ను disable చేసి, ఇప్పటికే ఉన్న proxy ను కొనసాగించండి. --disable=servicelb తో install చేయండి. LoadBalancer రకానికి చెందిన Service అయినప్పటికీ NodePort ను allocate చేస్తుంది. అందువల్ల Traefik 31480 వంటి high port పై అందుబాటులో ఉంటుంది. మీ nginx లేదా Caddy 127.0.0.1:31480 కు proxy చేస్తుంది. మీరు వదులుకునేది external address. Service ఎప్పటికీ <pending> ను చూపిస్తుంది. ఇది మీరు ఎంచుకున్న విధానం అయినప్పటికీ fault లాగా కనిపించవచ్చు.

Traefik ను disable చేసి, మీ స్వంత proxy తో routing చేయండి. --disable=traefik తో install చేయండి. అప్పుడు మీ వద్ద ingress controller ఉండదు. అందువల్ల Ingress objects అసలు ఏ పనీ చేయవు. వాటిని గమనించే controller ఏదీ లేకుండా అవి APIలో అలాగే ఉంటాయి. Host proxy నుంచి NodePorts కు routing చేస్తున్నప్పుడు ఇది సరైన విధానం. HTTP ను ఎలా నిర్వహించాలో మీకు ఇప్పటికే స్పష్టంగా తెలిసి ఉంటే, ఇది నిజాయితీగల ఎంపిక. ఏది ముందువైపు ఉండాలో ఇంకా నిర్ణయించకపోతే, ఏదైనా disable చేయడానికి ముందు nginx, Caddy మరియు Traefik మధ్య reverse proxy ఎంపికను ఖరారు చేయండి.

రెండు flags ను installer పై లేదా config file లో ఇవ్వాలి:

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

Installation తర్వాత ఆ file ను edit చేసి sudo systemctl restart k3s ను అమలు చేయడం కూడా పనిచేస్తుంది. ఎందుకంటే --disable installation సమయంలో component ను skip చేయడం మాత్రమే కాదు. ఇప్పటికే deployed అయిన component ను కూడా అది delete చేస్తుంది. అందువల్ల ఈ మార్పు నడుస్తున్న cluster పై అమలవుతుంది.

Traefik ను కొనసాగిస్తూ chart ఎలా configure చేయబడుతుందో మార్చాలంటే /var/lib/rancher/k3s/server/manifests/traefik.yaml ను edit చేయవద్దు. k3s ప్రారంభమైన ప్రతిసారి ఆ file ను defaults తో తిరిగి రాస్తుంది. బదులుగా అదే directoryలో ప్రత్యేక file ను జోడించండి. ఎందుకంటే /var/lib/rancher/k3s/server/manifests లోని ఏదైనా startup సమయంలో, అలాగే disk పై అది మారిన ప్రతిసారీ, స్వయంచాలకంగా apply అవుతుంది.

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

ఈ ఉదాహరణ trusted proxy addresses అనే ఒక Traefik chart value ను సెట్ చేస్తుంది. Chart అందించే ఇతర values ను కూడా ఇదే విధానం ద్వారా సెట్ చేయవచ్చు. ఇందులో ports కూడా ఉన్నాయి.

ఒక నోడ్‌లో persistent storage

k3s Rancher యొక్క local-path provisioner ఆధారంగా పనిచేసే local-path అనే default StorageClass ను అందిస్తుంది. storageClassName లేని PersistentVolumeClaim దీనినే ఉపయోగిస్తుంది. Volumes /var/lib/rancher/k3s/storage లో నిల్వ చేయబడతాయి. ప్రతి volume కోసం node యొక్క స్వంత disk పై ఒక ప్రత్యేక subdirectory ఉంటుంది.

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

“node యొక్క స్వంత disk పై” అనే విధానానికి రెండు పరిణామాలు ఉన్నాయి. అవి వెంటనే కాకుండా తరువాత సమస్యలను కలిగిస్తాయి.

ఈ StorageClass volumeBindingMode: WaitForFirstConsumer ను ఉపయోగిస్తుంది. అందువల్ల pod వాస్తవంగా దాన్ని mount చేసే వరకు కొత్త PVC Pending స్థితిలో ఉంటుంది. kubectl describe pvc ఈ విషయాన్ని చూపిస్తుంది:

waiting for first consumer to be created before binding

ఇది సాధారణ ప్రవర్తనే. కాబట్టి PVCని మాత్రమే సృష్టించి వేచి ఉంటే అది Pending స్థితి నుంచి మారదు.

Volume bind అయిన తర్వాత, దాన్ని సృష్టించిన node కోసం node affinityను కలిగి ఉంటుంది. అందువల్ల ఆ claimను ఉపయోగించే ప్రతి pod, volume ఉన్నంతకాలం అదే nodeకు పరిమితం అవుతుంది. ఒకే node ఉన్నప్పుడు ఇది కనిపించదు. తరువాత రెండో nodeను జోడించినప్పుడు, ఒక pod మరో nodeకు మారకపోతే అది scheduler లోపంలా కనిపించవచ్చు. kubectl get pv -o yaml నడిపి, hostname nodeAffinity లో ఉందని గుర్తించే వరకు కారణం స్పష్టంగా తెలియకపోవచ్చు.

Backups నిర్వహించడం మీ బాధ్యత. VPSను మళ్లీ నిర్మిస్తే ఆ directory తొలగిపోతుంది. దిగువ uninstall script నడిపినా అదే జరుగుతుంది. /var/lib/rancher/k3s/storage ను backup చేయండి. Service ఆపిన తర్వాత sqlite datastoreను /var/lib/rancher/k3s/server/db/state.db కు కాపీ చేసి backup చేయండి, ఎందుకంటే అది active database. మరో మార్గం clusterను disposableగా పరిగణించి, ప్రతి manifestను gitలో ఉంచడం.

Ingress మరియు TLS

Traefik enable చేసి ఉంటే, మీకు ప్రామాణిక Ingress object ఒక్కటే అవసరం.

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

Certificates స్వయంగా జారీ కావు. సాధారణంగా cert-manager ను దాని published manifest నుంచి install చేసి, ఒక ClusterIssuer ను configure చేస్తారు. August 2026 నాటికి v1.21.1 ప్రస్తుత version.

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 అంటే ACME (automatic certificate management environment) server public internet నుంచి http://hello.example.com/.well-known/acme-challenge/... కు connect అవుతుంది. అందువల్ల DNS A record ఇప్పటికే VPS ను సూచించాలి, అలాగే port 80 Traefik కు చేరాలి. మీరు ServiceLB ను disable చేసి, మీ స్వంత proxy ను ముందు ఉంచితే, ఆ proxy challenge path ను కూడా forward చేయాలి. లేకపోతే cert-manager నిలిచిపోతుంది, మరియు Challenge object లో ఈ message కనిపిస్తుంది:

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

sudo k3s kubectl describe certificate hello-tls మరియు sudo k3s kubectl get order,challenge -A తో certificate issuance ను monitor చేయండి.

kubeconfig మరియు API server private గా ఉండటానికి కారణం

k3s administrator credentials ను /etc/rancher/k3s/k3s.yaml లో రాస్తుంది. ఈ file కు root యాజమాన్యం ఉంటుంది. Default గా ఇది mode 600 తో రాయబడుతుంది. ఇందులో cluster-admin హక్కులు ఉన్న client certificate ఉంటుంది. అందువల్ల ఈ file ను చదవగలిగే వ్యక్తి మొత్తం cluster పై నియంత్రణ పొందగలడు.

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

వేరుగా install చేసిన kubectl కు KUBECONFIG సెట్ చేయకపోతే, అది The connection to the server localhost:8080 was refused - did you specify the right host or port? తో విఫలమవుతుంది. ఎందుకంటే అది k3s కు సంబంధం లేని default ను ఉపయోగించడానికి ప్రయత్నిస్తుంది. KUBECONFIG సెట్ చేయండి. లేదా sudo k3s kubectl ఉపయోగించండి. అది సరైన file ను స్వయంగా చదువుతుంది.

సాధారణ user kubectl నడపగలిగేలా --write-kubeconfig-mode 644 సిఫార్సు చేయబడటం మీరు చూస్తారు. అది చేసే మార్పును అర్థం చేసుకోండి: cluster-admin credential ను machine లోని ప్రతి local account చదవగలిగేలా చేస్తుంది. ఒకే administrator ఉన్న machine లో ఇది ఆమోదయోగ్యమైన మార్పిడి కావచ్చు. Shared machine లో ఇది సురక్షితం కాదు. File ను copy చేస్తే దాన్ని అందరికీ చూపకుండా ఒక user కు మాత్రమే access ఇవ్వవచ్చు:

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

ఆ file లోని server: line https://127.0.0.1:6443 ను చదువుతుంది. మీ laptop నుంచి kubectl ఉపయోగించడానికి 6443 ను internet కు open చేయవద్దు. Public Kubernetes API పై నిరంతర దాడులు జరగవచ్చు. Exposed API వల్ల చిన్న clusters ఇతరుల cryptocurrency mining కోసం ఉపయోగించబడే ప్రమాదం ఉంది. SSH ద్వారా tunnel ఏర్పాటు చేసి, file లోని address ను అలాగే ఉంచండి:

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

Private network address ద్వారా API ను చేరుకోవాల్సి ఉంటే, ఆ name లేదా address ను జాబితా చేస్తూ tls-san తో install చేయండి. తరువాత copy చేసిన file లోని server: line ను అదే address కు మార్చండి. SAN (subject alternative name) entry లేకపోతే kubectl connection ను తిరస్కరిస్తుంది:

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

Cluster కోసం document చేసిన inbound ports ఇవి: API కోసం TCP 6443, nodes మధ్య flannel VXLAN కోసం UDP 8472, kubelet metrics కోసం TCP 10250. Single node లో వీటిలో ఏదీ internet కు open చేయాల్సిన అవసరం లేదు.

containerd, Docker కాదు

k3s తన స్వంత embedded containerd ను నడుపుతుంది. ఇది Docker తో image store ను పంచుకోదు. మీరు ఇప్పుడే docker build తో build చేసిన image k3s కు కనిపించదు. అందువల్ల docker images దాన్ని చూపించినప్పటికీ pod ErrImagePull తో విఫలమవుతుంది. దాన్ని స్పష్టంగా import చేయండి:

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

ఆ container పై :latest tag ను ఉపయోగించకుండా ఉండండి. ఎందుకంటే :latest డిఫాల్ట్‌గా Always యొక్క imagePullPolicy కు సెట్ అవుతుంది. అందువల్ల kubelet ఏమైనప్పటికీ registry ను సంప్రదిస్తుంది. ఇతర ఏ tag అయినా డిఫాల్ట్‌గా IfNotPresent కు సెట్ అవుతుంది. ఇది మీరు import చేసిన image ను ఉపయోగిస్తుంది. ఒకే VPS పై రెండింటినీ నడపవచ్చు. VPS పై సాధారణ Docker installation మరియు k3s ఒకే machine లో తమ స్వంత image store లను, తమ స్వంత iptables rules ను నిర్వహిస్తాయని తెలుసుకోవడం ఉపయోగకరం.

k3s ను ఎలా తొలగించాలి

Installer ఒక uninstall script ను రాస్తుంది. పాక్షిక తొలగింపు లేదా undo విధానం ఉండదు.

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

ఇది service ను ఆపి తొలగిస్తుంది, datastore ను తొలగిస్తుంది, persistent volume data ను తొలగిస్తుంది, node configuration ను తొలగిస్తుంది, అలాగే installer జోడించిన tools ను తొలగిస్తుంది. Agent node పై script బదులుగా k3s-agent-uninstall.sh ఉంటుంది. /var/lib/rancher/k3s/storage లోని ఏదైనా data ను ముందుగా server నుంచి బయటకు copy చేయండి, ఎందుకంటే ఆ directory కూడా తొలగించబడుతుంది. ఆ తరువాత ports లేదా interfaces ను ఏ process అయినా ఉపయోగిస్తుందా లేదా అనేది ip link show మరియు sudo ss -lntp తో తనిఖీ చేయండి. మిగిలిపోయిన cni0 లేదా flannel.1 interface తదుపరి reboot సమయంలో తొలగిపోతుంది.

Kubernetes లోని ఒక node పని అవసరానికి మించిన అదనపు నిర్మాణంగా అనిపించి, దాన్ని తొలగించాలని నిర్ణయించడం సాధారణ పరిణామమే; అది వైఫల్యం కాదు. ఆ workloads ను తిరిగి Compose కు మార్చడం సాధారణంగా ఒక మధ్యాహ్నంలో పూర్తవుతుంది.

వైఫల్య పరిస్థితులు మరియు మీరు కనిపించే strings

Node NotReady లేదా k3s పునఃప్రారంభం అవుతూ ఉండటం. ముందుగా sudo journalctl -u k3s -n 200 --no-pager చదవండి. చిన్న VPSలో సాధారణ కారణం kernel out-of-memory killer ప్రక్రియను నిలిపివేయడం. ఇది dmesgలో k3s-server పేరును చూపించే పంక్తిగా కనిపిస్తుంది. Documentationలో పేర్కొన్న 2 GB కనిష్ఠ పరిమితి వాస్తవమైన కనిష్ఠ అవసరం.

Pod Pending స్థితిలో నిలిచిపోవడం. kubectl describe pod ప్రతిసారీ కారణాన్ని చూపిస్తుంది. Insufficient memory లేదా Insufficient cpu అంటే nodeలో ఇక ఖాళీ వనరులు లేవని అర్థం. didn't have free ports అనేది పైన వివరించిన hostPort ఢీకొనడం. PVCపై waiting for first consumer కనిపిస్తే WaitForFirstConsumer సరిగ్గా పనిచేస్తోందని అర్థం.

ImagePullBackOff. Tag, node చేరుకోగల ఏ registryలోనూ ఉండకపోవచ్చు. లేదా మీరు Dockerతో imageను build చేసి, దాన్ని containerdలోకి import చేయకపోవచ్చు.

Traefik స్పందిస్తుంది, కానీ app స్పందించదు. 404 page not found response body Traefik నుంచే వస్తుంది. అంటే request చేరింది, కానీ ఏ routerతోనూ match కాలేదు. Ingressలోని host మీరు టైప్ చేసిన పేరుతో సరిపోతుందో తనిఖీ చేయండి. అలాగే ingressClassName, traefikగా ఉందో నిర్ధారించండి.

Host సరిగ్గా resolve అవుతున్నప్పటికీ cluster DNS విఫలమవడం. sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dnsతో CoreDNSను తనిఖీ చేయండి. plugin/loop: Loop ... detected for zone "." వంటి message CoreDNS ప్రారంభం కాకుండా ఆపుతుంది. CoreDNS, తనకు మళ్లీ forward చేసే resolverకు forwarding చేయడం వల్ల ఇది జరుగుతుంది. /etc/resolv.confలోని loopback address ఇదే పరిస్థితిని కలిగిస్తుంది. --resolv-conf /run/systemd/resolve/resolv.confతో k3sను అసలు upstream file వైపు చూపించండి.

FAQ

ఒకే VPSపై k3s నడపడం విలువైనదేనా?

మీకు Kubernetes API అవసరమైనప్పుడు ఇది విలువైనది: మీరు నియంత్రించే మెషీన్‌పై దాన్ని నేర్చుకోవడం, deployments ను manifests రూపంలో portable గా ఉంచడం, Helm chart మాత్రమే అందించే సాఫ్ట్‌వేర్‌ను నడపడం లేదా తరువాత managed cluster కు మార్చబోయే వ్యవస్థను నిర్మించడం వంటి సందర్భాల్లో ఇది ఉపయోగకరం. మీకు కేవలం containers నడపాలనుకుంటే ఇది విలువైనది కాదు, ఎందుకంటే Docker Compose చాలా తక్కువ నిర్వహణతో అదే పని చేస్తుంది మరియు సుమారు ఒక gigabyte ఎక్కువ free RAM అందిస్తుంది. ఒక node వల్ల high availability ఉండదు. కాబట్టి reliability కారణంగా దీన్ని ఎంచుకోవడం సరైనది కాదు.

నా k3s LoadBalancer service Pending స్థితిలోనే ఎందుకు ఉంటుంది?

ServiceLB svclb- pods ను సృష్టిస్తుంది. ఇవి node పై service ports ను hostPort గా claim చేస్తాయి. అందువల్ల ఆ ports ఖాళీగా ఉన్న చోట మాత్రమే ఇవి schedule అవుతాయి. nginx లేదా మరొక proxy ఇప్పటికే port 80 ను ఉపయోగిస్తుంటే pod Pending స్థితిలోనే ఉంటుంది. Service కు external address ఎప్పటికీ అందదు. kubectl -n kube-system describe pod svclb-..., 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports ను report చేస్తుంది. ఆ port ను ఖాళీ చేయండి. లేదా --disable=servicelb తో మళ్లీ install చేసి, service కేటాయించే NodePort కు proxy చేయండి.

VPSపై k3s కు ఎంత RAM అవసరం?

Server node కోసం documentation పేర్కొన్న కనీస అవసరం 2 cores మరియు 2 GB. మీ workloads కు ముందు k3s మరియు దానితో వచ్చే components కు ఇది సరిపోతుంది. Monitoring stack నడుస్తున్న server node పై project స్వంత profiling 1,596 MB memory వినియోగాన్ని కొలిచింది. అందువల్ల 2 GB ను కనీస పరిమితిగా, 4 GB ను ఒక node సౌకర్యంగా నడిచే మొదటి పరిమాణంగా పరిగణించండి. Install కు ముందు free -h తో మీ system memory ను కొలవండి. తరువాత kube-system లోని ప్రతి pod Running అని చూపించిన తర్వాత మళ్లీ కొలవండి.

ఒకే VPSపై Docker మరియు k3s ను నడపవచ్చా?

అవును. అవి వేర్వేరుగా ఉంటాయి. k3s తన స్వంత embedded containerd ను ఉపయోగిస్తుంది. అందువల్ల docker build తో build చేసిన image ను k3s చూడదు. దాన్ని ఉపయోగించాలంటే ముందుగా docker save myapp:0.1 | sudo k3s ctr images import - అమలు చేయాలి. ప్రతి సాఫ్ట్‌వేర్ తన స్వంత iptables rules మరియు bridge networks ను కూడా రాస్తుంది. Memory మొత్తాన్ని పర్యవేక్షించండి, ఎందుకంటే 2 GB system పై Docker, k3s మరియు మీ containers అన్నీ కలిసి సరిపోకపోవచ్చు.

k3s ను పూర్తిగా ఎలా తొలగించాలి?

Server node పై sudo /usr/local/bin/k3s-uninstall.sh ను, agent పై sudo /usr/local/bin/k3s-agent-uninstall.sh ను అమలు చేయండి. ఇది service ను ఆపుతుంది, datastore ను తొలగిస్తుంది, /var/lib/rancher/k3s/storage కింద ఉన్న persistent volume data ను తొలగిస్తుంది మరియు bundled tools ను తీసివేస్తుంది. ఉంచుకోవాలనుకునే data ను ముందుగా system నుండి బయటకు copy చేయండి, ఎందుకంటే ఈ చర్యను undo చేయలేరు. మిగిలిపోయిన cni0 లేదా flannel.1 network interface తదుపరి reboot సమయంలో తొలగిపోతుంది.

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