लेखक: Matt Connor 2026-08-13

Single-node k3s VPS पर कब इस्तेमाल करें?

Q: मेरी k3s LoadBalancer service 'Pending' स्थिति में क्यों रहती है?

ServiceLB ऐसे svclb- pods बनाता है जो node पर hostPort के रूप में service के ports को claim करते हैं, इसलिए वे केवल वहीं schedule होते हैं जहाँ वे ports खाली हों। यदि 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 रिपोर्ट होता है। उस port को खाली करें, या --disable=servicelb के साथ reinstall करें और उस NodePort पर proxy करें जिसे service अभी भी allocate करती है।

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 को हटा देता है। जो भी डेटा आप रखना चाहते हैं उसे पहले box से बाहर copy कर लें, क्योंकि इसे undo करने का कोई तरीका नहीं है। बचा हुआ कोई भी cni0 या flannel.1 network interface अगले reboot पर अपने आप हट जाएगा।

Single-node k3s सेटअप में RAM की खपत, पोर्ट 80 का टकराव और इंस्टॉलेशन की बारीकियों को समझें। जानें कि कब Docker Compose का उपयोग करना k3s से बेहतर विकल्प साबित होता है।

k3s क्या है, और इसका एक नोड आपको क्या प्रदान करता है

k3s एक पूर्ण Kubernetes वितरण है जिसे एक बाइनरी के रूप में पैक किया गया है। इसे एक सिंगल VPS पर चलाने से आपको तीन-मशीन वाले कंट्रोल प्लेन के बिना वास्तविक Kubernetes API प्राप्त होता है। यह एक प्रमाणित Kubernetes वितरण है, इसलिए यहाँ लागू होने वाला मैनिफेस्ट बाद में किसी भी मैनेज्ड क्लस्टर पर भी काम करेगा। इसका इंस्टॉलेशन केवल एक कमांड और लगभग एक मिनट का काम है। इसकी कीमत वह मेमोरी है जो अब आपके एप्लिकेशन के लिए उपलब्ध नहीं रहती, साथ ही इसमें विफलता के कुछ ऐसे तरीके भी हैं जो Docker Compose के साथ कभी नहीं होते।

SUSE इसे एज साइट्स और छोटे इंस्टॉलेशन के लिए बनाता है, और अपस्ट्रीम Kubernetes से इसका हर अंतर इसे छोटा बनाने के लिए है। इसका डिफ़ॉल्ट डेटास्टोर kine नामक एक शिम के पीछे sqlite है, न कि etcd, इसलिए इसमें बनाए रखने के लिए कोई etcd कोरम नहीं होता। containerd को अलग से इंस्टॉल करने के बजाय बाइनरी में ही एम्बेड किया गया है। यही बाइनरी क्लस्टर DNS के लिए CoreDNS, इनग्रेस कंट्रोलर के रूप में Traefik, ServiceLB (जिसे klipper-lb भी कहा जाता है) ताकि LoadBalancer सेवाएं बिना किसी क्लाउड प्रदाता के काम कर सकें, पर्सिस्टेंट वॉल्यूम के लिए local-path provisioner, metrics-server, और पॉड नेटवर्किंग के लिए flannel भी प्रदान करती है। इनमें से प्रत्येक डिफ़ॉल्ट रूप से स्टार्ट होता है। यही कारण है कि नीचे वर्णित पोर्ट टकराव (port collision) उस VPS पर सबसे आम शुरुआती समस्या है जो पहले से ही कुछ अन्य कार्य कर रहा था।

जब एक single k3s node का उपयोग करना उचित हो

k3s का उपयोग तब करें जब आपको Kubernetes API की आवश्यकता हो: आप अपने नियंत्रण वाले मशीन पर Kubernetes सीख रहे हैं, या जिस software को आप चलाना चाहते हैं वह केवल Helm chart के रूप में उपलब्ध है। Manifest की portability भी मायने रखती है, क्योंकि यहाँ लिखा गया Deployment बिना किसी बदलाव के एक managed cluster पर ले जाया जा सकता है। Docker Compose का उपयोग तब करें जब आपका मुख्य उद्देश्य applications को चलाना हो। Compose बहुत कम जटिलताओं के साथ उन्हीं containers को start करता है, और एक VPS पर Compose file को एक साल बाद पढ़ना, manifests की directory को पढ़ने की तुलना में अधिक आसान होता है।

यह स्पष्ट रखें कि एक node आपको क्या नहीं देता है।

कोई high availability नहीं। जब VPS reboot होता है, तो हर workload रुक जाता है। Kubernetes एक pod को दूसरे node पर reschedule करने का प्रयास करता है, लेकिन कोई दूसरा node मौजूद नहीं होता।
कोई ऐसा rolling update नहीं जो service को चालू रखे, जब तक कि application एक ही मशीन पर एक ही volume साझा करने वाले दो replicas को सहन न कर सके।
Storage जो उसी box तक सीमित है, जिसका कारण नीचे दिए गए local-path section में वर्णित है।
एक control plane जो चाहे आप कुछ भी deploy न करें, लगभग एक gigabyte RAM का उपयोग करता है।

इनमें से कोई भी बात k3s को एक बुरा विकल्प नहीं बनाती है। यह इसे उस कारण से बुरा विकल्प बनाती है जो लोग आमतौर पर देते हैं, जो कि reliability है। यदि आप वास्तव में कई मशीनें चाहते हैं ताकि आप एक वास्तविक multi-node cluster बना सकें, तो वह निर्णय पहले आता है: अपने hardware पर Proxmox बनाम एक किराए का VPS यह तय करता है कि nodes कहाँ से आएंगे, इससे पहले कि k3s यह तय करे कि उन पर क्या चलेगा।

किसी भी चीज़ को deploy करने से पहले k3s की RAM और CPU लागत

k3s प्रोजेक्ट अनुमानों के बजाय मापे गए आंकड़े प्रकाशित करता है। उन्हें ध्यान से पढ़ें, क्योंकि जो संख्या लोग बताते हैं वह 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 ने 95वें percentile पर 1,596 MB RAM और एक core का लगभग 6 प्रतिशत CPU इस्तेमाल किया। ये प्रकाशित आंकड़े हैं, इस गाइड से लिए गए माप नहीं, और परीक्षण में k3s v1.26.5 को सभी packaged components के साथ, और साथ में Prometheus और Grafana monitoring stack चलाकर देखा गया था, इसलिए इस संख्या में एक वास्तविक workload शामिल है, न कि केवल एक खाली cluster। sqlite को embedded etcd से बदलने पर यह 1,606 MB हो गया। एक agent node, जो बिना control plane के kubelet और containerd चलाता है, ने 275 MB का उपयोग किया। एक server के लिए न्यूनतम आवश्यकता 2 cores और 2 GB RAM बताई गई है, और यह न्यूनतम आवश्यकता आपके workloads से पहले k3s और उसके packaged components को कवर करती है।

व्यावहारिक निष्कर्ष: 2 GB के VPS पर control plane और उसके bundled add-ons आपके लिए बहुत कम संसाधन छोड़ते हैं, और दबाव पड़ने पर सबसे पहले kubelet pods को evict करना शुरू कर देता है। कुछ छोटी services वाले एक node के लिए 4 GB एक आरामदायक आधार है। किसी भी प्रकाशित आंकड़े पर भरोसा करने के बजाय अपने स्वयं के box को मापें, जिसमें यह आंकड़ा भी शामिल है।

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

install करने से पहले free -h चलाएं और फिर एक बार जब kube-system में हर pod Running स्थिति में आ जाए, तो इसे दोबारा चलाएं। दोनों के बीच का अंतर ही आपके hardware पर control plane की वास्तविक लागत है। k3s kubectl top node install होने के बाद पहले एक या दो मिनट के लिए error: Metrics API not available लौटाता है, क्योंकि metrics-server ने अभी तक कुछ भी scrape नहीं किया होता है। यह कोई त्रुटि नहीं है। यदि आप एक ही box को इसके लिए और अन्य कार्यों के लिए एक साथ size कर रहे हैं, तो VPS के लिए RAM और CPU का निर्धारण में दिया गया गणित यहाँ बिना किसी बदलाव के लागू होता है।

k3s को latest के बजाय किसी विशिष्ट release पर पिन करना

Quick start की वह लाइन जिसे हर कोई कॉपी करता है, वह उस दिन के stable channel पर उपलब्ध वर्ज़न को इंस्टॉल कर देती है। जिस मशीन को आप लंबे समय तक चलाना चाहते हैं, उस पर इसे पिन करें। k3s प्रत्येक Kubernetes minor version के लिए एक चैनल प्रकाशित करता है, इसलिए INSTALL_K3S_CHANNEL=v1.36 का उपयोग करने पर यह v1.36 के भीतर ही patch releases को फॉलो करेगा और कभी भी अपने आप minor version को अपग्रेड नहीं करेगा। अगस्त 2026 तक, stable channel v1.36.3+k3s1 पर पॉइंट करता है।

पहले configuration file लिखें, फिर इंस्टॉल करें। k3s शुरू होते समय /etc/rancher/k3s/config.yaml को पढ़ता है, इसलिए इसमें मौजूद कोई भी सेटिंग पहले बूट और उसके बाद के हर बूट पर लागू होती है।

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 -

किसी चैनल के बजाय एक सटीक release को पिन करने के लिए, INSTALL_K3S_VERSION=v1.36.3+k3s1 का उपयोग करें। प्लस का निशान टैग का हिस्सा है। इसके बाद जांचें कि यह सही ढंग से शुरू हुआ है या नहीं।

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

kubectl get node को लगभग तीस सेकंड के भीतर STATUS Ready के साथ एक नोड दिखाना चाहिए, और kube-system में प्रत्येक pod को Running या Completed स्थिति में आ जाना चाहिए। यदि कोई नोड NotReady पर अटका हुआ है, तो इसका आमतौर पर मतलब है कि container runtime शुरू नहीं हुआ है, इसलिए sudo journalctl -u k3s -n 100 --no-pager पढ़ें। किसी असामान्य VPS image पर, कुछ भी डीबग करने से पहले sudo k3s check-config चलाएं: यह गायब kernel features की रिपोर्ट करता है, जो लॉग पढ़ने की तुलना में बहुत तेज़ समाधान है।

पोर्ट 80 पहले से उपयोग में क्यों है, और इसे ठीक करने के लिए क्या छोड़ना होगा

यह वह विफलता है जो उन VPS पर लोगों को परेशान करती है जहाँ पहले से ही कुछ चल रहा होता है। इंस्टॉलेशन सफल हो जाता है। Traefik को कभी कोई पता (address) नहीं मिलता, और जो साइट आप पहले से चला रहे थे वह काम करती रहती है, इसलिए जब तक आप किसी ingress तक पहुँचने का प्रयास नहीं करते, तब तक कुछ भी टूटा हुआ नहीं दिखता।

कार्यप्रणाली: बंडल किया गया Traefik chart पोर्ट 80 और 443 पर LoadBalancer प्रकार की एक Service बनाता है। ServiceLB उन पोर्ट नंबरों को प्रत्येक नोड पर hostPort के रूप में दावा करने वाले छोटे पॉड्स का एक DaemonSet बनाकर उस अनुरोध का उत्तर देता है, जिन्हें svclb- उपसर्ग के साथ नामित किया गया है। hostPort कंटेनर पोर्ट को सीधे नोड के अपने नेटवर्क नेमस्पेस पर प्रकाशित करता है, बिल्कुल वैसे ही जैसे docker run -p 80:80 करता है। यदि nginx, Caddy, Apache या कोई अन्य कंटेनर पहले से ही पोर्ट 80 को होल्ड करता है, तो कर्नेल इसे दोबारा नहीं देगा, इसलिए शेड्यूलर के पास पॉड को रखने के लिए कोई जगह नहीं होगी।

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 पॉड Pending स्थिति में है और सर्विस का कोई बाहरी पता नहीं है:

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.

ss -lntp आपको बताता है कि कौन सी प्रक्रिया पोर्ट को होल्ड किए हुए है। इससे बाहर निकलने के एक से अधिक तरीके हैं, और हर एक की अपनी कीमत है।

पोर्ट्स k3s को दें। मौजूदा वेब सर्वर को रोकें और डिसेबल करें, फिर Traefik को 80 और 443 का स्वामित्व लेने दें। यह तब सही उत्तर है जब VPS केवल एक k3s बॉक्स बनने वाला है और कुछ नहीं, और जो कुछ भी आप सर्व कर रहे थे वह सब Ingress के पीछे चला जाता है।

ServiceLB को डिसेबल करें और अपना मौजूदा प्रॉक्सी रखें। --disable=servicelb के साथ इंस्टॉल करें। LoadBalancer प्रकार की सर्विस अभी भी एक NodePort आवंटित करती है, इसलिए Traefik 31480 जैसे उच्च पोर्ट पर पहुँच योग्य रहता है, और आपका nginx या Caddy 127.0.0.1:31480 पर प्रॉक्सी करता है। आप जो छोड़ते हैं वह बाहरी पता है: सर्विस हमेशा <pending> रिपोर्ट करती है, जो एक गलती की तरह दिखता है जबकि यह आपके द्वारा लिया गया एक विकल्प है।

Traefik को डिसेबल करें और अपने स्वयं के प्रॉक्सी के साथ रूट करें। --disable=traefik के साथ इंस्टॉल करें। तब आपके पास कोई ingress controller नहीं होता है, इसलिए Ingress ऑब्जेक्ट्स कुछ भी नहीं करते हैं: वे बिना किसी कंट्रोलर के API में पड़े रहते हैं। यह तब ठीक है जब आप होस्ट प्रॉक्सी से NodePorts पर रूट करते हैं, और यदि आप पहले से जानते हैं कि आप HTTP को कैसे हैंडल करना चाहते हैं तो यह एक ईमानदार विकल्प है। यदि आप इस बारे में अनिर्णित हैं कि सामने क्या होना चाहिए, तो कुछ भी डिसेबल करने से पहले nginx, Caddy और Traefik के बीच reverse proxy के रूप में चयन पर निर्णय लें।

दोनों फ्लैग्स इंस्टॉलर पर, या कॉन्फ़िगरेशन फ़ाइल में होने चाहिए:

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

इंस्टॉलेशन के बाद उस फ़ाइल को संपादित करना और sudo systemctl restart k3s चलाना भी काम करता है, क्योंकि --disable इंस्टॉलेशन के समय किसी घटक को छोड़ने से कहीं अधिक काम करता है। यह पहले से तैनात घटक को हटा भी देता है, इसलिए परिवर्तन चल रहे क्लस्टर पर प्रभावी हो जाता है।

Traefik को रखने के लिए लेकिन चार्ट को कॉन्फ़िगर करने के तरीके को बदलने के लिए, /var/lib/rancher/k3s/server/manifests/traefik.yaml को संपादित न करें। k3s हर बार शुरू होने पर उस फ़ाइल को डिफ़ॉल्ट के साथ फिर से लिखता है। इसके बजाय उसी निर्देशिका में एक अलग फ़ाइल जोड़ें, क्योंकि /var/lib/rancher/k3s/server/manifests में जो कुछ भी है वह स्टार्टअप पर और डिस्क पर बदलते ही स्वचालित रूप से लागू हो जाता है।

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

वह उदाहरण एक Traefik चार्ट मान, trusted proxy addresses को सेट करता है। वही तंत्र किसी भी अन्य मान को सेट करता है जिसे चार्ट एक्सपोज़ करता है, जिसमें इसके पोर्ट्स भी शामिल हैं।

एक नोड पर Persistent storage

k3s में local-path नामक एक डिफ़ॉल्ट StorageClass होता है, जो Rancher के local-path provisioner द्वारा समर्थित है। बिना किसी storageClassName वाला PersistentVolumeClaim इसे प्राप्त करता है। Volumes नोड की अपनी डिस्क पर /var/lib/rancher/k3s/storage में स्थित होते हैं, जहाँ प्रत्येक वॉल्यूम के लिए एक अलग सबडायरेक्टरी होती है।

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

"नोड की अपनी डिस्क पर" होने के दो परिणाम होते हैं, और दोनों ही आज के बजाय बाद में समस्या पैदा करते हैं।

यह StorageClass volumeBindingMode: WaitForFirstConsumer का उपयोग करता है, इसलिए एक नया PVC तब तक Pending रहता है जब तक कि कोई पॉड वास्तव में उसे माउंट न कर ले। kubectl describe pvc यह प्रिंट करता है:

waiting for first consumer to be created before binding

यह सामान्य है, इसलिए केवल PVC बनाना और प्रतीक्षा करना इसे कभी ठीक नहीं करेगा।

एक बार बाउंड हो जाने पर, वॉल्यूम में उस नोड के लिए एक नोड एफिनिटी (node affinity) आ जाती है जिसने इसे बनाया था। यह उस क्लेम का उपयोग करने वाले प्रत्येक पॉड को वॉल्यूम के जीवनकाल तक उसी नोड पर पिन कर देता है। एक नोड पर आपको इसका पता कभी नहीं चलेगा। बाद में दूसरा नोड जोड़ने पर, एक पॉड जो मूव होने से इनकार करता है, वह शेड्यूलर बग जैसा दिखता है, जब तक कि आप kubectl get pv -o yaml न चलाएं और nodeAffinity में होस्टनेम न देख लें।

बैकअप लेना आपकी जिम्मेदारी है। VPS को रीबिल्ड करने से वह डायरेक्टरी नष्ट हो जाती है, और नीचे दी गई अनइंस्टॉल स्क्रिप्ट भी ऐसा ही करती है। /var/lib/rancher/k3s/storage का बैकअप लें, साथ ही /var/lib/rancher/k3s/server/db/state.db पर स्थित sqlite डेटास्टोर का भी, जिसे सर्विस बंद करके कॉपी किया जाना चाहिए क्योंकि यह एक लाइव डेटाबेस है। इसका विकल्प यह है कि क्लस्टर को डिस्पोजेबल माना जाए और प्रत्येक मैनिफेस्ट को git में रखा जाए।

Ingress और TLS

यदि Traefik enabled है, तो आपको केवल एक standard 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 का उपयोग किया जाता है, जिसे इसके प्रकाशित manifest और एक ClusterIssuer के साथ install किया जाता है। अगस्त 2026 तक version v1.21.1 वर्तमान है।

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) सर्वर सार्वजनिक इंटरनेट से http://hello.example.com/.well-known/acme-challenge/... से जुड़ता है। इसलिए, DNS A record को पहले से ही VPS की ओर point करना चाहिए और port 80 पर Traefik तक पहुँच होनी चाहिए। यदि आपने ServiceLB को disable कर दिया है और अपने स्वयं के proxy को सामने रखा है, तो उस proxy को challenge path को भी forward करना होगा, अन्यथा cert-manager Challenge object पर इस त्रुटि के साथ रुक जाएगा:

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 के साथ issuance की निगरानी करें।

kubeconfig, और API server को private क्यों रखा जाता है

k3s एडमिन क्रेडेंशियल्स को /etc/rancher/k3s/k3s.yaml में लिखता है। यह फ़ाइल डिफ़ॉल्ट रूप से root के स्वामित्व में होती है और इसे 600 मोड के साथ लिखा जाता है। इसमें cluster-admin अधिकारों वाला एक क्लाइंट सर्टिफिकेट होता है, इसलिए जो कोई भी इसे पढ़ सकता है, वह पूरे क्लस्टर का मालिक बन जाता है।

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

बिना KUBECONFIG सेट किए अलग से इंस्टॉल किया गया kubectl, The connection to the server localhost:8080 was refused - did you specify the right host or port? के साथ विफल हो जाता है क्योंकि यह एक ऐसे डिफ़ॉल्ट पर वापस चला जाता है जिसका k3s से कोई लेना-देना नहीं है। KUBECONFIG सेट करें, या sudo k3s kubectl का उपयोग करें, जो अपने आप सही फ़ाइल को पढ़ लेता है।

आप देखेंगे कि सामान्य उपयोगकर्ता द्वारा kubectl चलाने के लिए --write-kubeconfig-mode 644 की सिफारिश की जाती है। समझें कि यह क्या करता है: यह एक cluster-admin क्रेडेंशियल को मशीन पर मौजूद हर स्थानीय खाते के लिए पढ़ने योग्य बना देता है। एक सिंगल-एडमिन बॉक्स पर यह एक स्वीकार्य समझौता हो सकता है। एक साझा बॉक्स पर ऐसा नहीं है। इसके बजाय फ़ाइल को कॉपी करने से एक उपयोगकर्ता को इसे सार्वजनिक किए बिना एक्सेस मिल जाता है:

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

उस फ़ाइल में server: लाइन https://127.0.0.1:6443 पढ़ती है। अपने लैपटॉप से kubectl का उपयोग करने के लिए, 6443 को इंटरनेट के लिए न खोलें। एक सार्वजनिक Kubernetes API एक निरंतर लक्ष्य है, और एक खुला API वह तरीका है जिससे छोटे क्लस्टर किसी और के लिए क्रिप्टोकरेंसी माइनिंग करने लगते हैं। इसे SSH के माध्यम से टनल करें और फ़ाइल में दिए गए पते को वैसा ही रहने दें:

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

यदि आपको API तक किसी प्राइवेट नेटवर्क पते के माध्यम से पहुँचना ही है, तो उस नाम या पते को सूचीबद्ध करते हुए tls-san के साथ इंस्टॉल करें, फिर कॉपी की गई फ़ाइल की server: लाइन को तदनुसार संपादित करें। SAN (subject alternative name) प्रविष्टि के बिना, kubectl कनेक्शन को अस्वीकार कर देता है:

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

क्लस्टर के लिए प्रलेखित इनबाउंड पोर्ट्स API के लिए TCP 6443, नोड्स के बीच flannel VXLAN के लिए UDP 8472, और kubelet मेट्रिक्स के लिए TCP 10250 हैं। एक सिंगल नोड पर, इनमें से किसी को भी इंटरनेट के लिए खुला रखने की आवश्यकता नहीं है।

containerd और Docker एक नहीं हैं

k3s अपना खुद का एम्बेडेड containerd चलाता है, और यह Docker के साथ image store साझा नहीं करता है। docker build के साथ अभी-अभी बनाई गई कोई image k3s को दिखाई नहीं देती है, इसलिए pod ErrImagePull के साथ विफल हो जाता है, भले ही docker images में वह दिखाई दे रही हो। इसे स्पष्ट रूप से 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 इंस्टॉलेशन और k3s दोनों एक ही मशीन पर अपना अलग image store और अपने अलग iptables नियम रखते हैं।

k3s को कैसे हटाएँ

इंस्टॉलर एक uninstall स्क्रिप्ट लिखता है। इसमें आंशिक रूप से हटाने (partial removal) या पूर्ववत (undo) करने की कोई सुविधा नहीं है।

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

यह स्क्रिप्ट सर्विस को रोकती और हटाती है, डेटास्टोर को डिलीट करती है, persistent volume डेटा को हटाती है, नोड कॉन्फ़िगरेशन को हटाती है, और इंस्टॉलर द्वारा जोड़े गए टूल्स को हटा देती है। एजेंट नोड पर यह स्क्रिप्ट k3s-agent-uninstall.sh होती है। /var/lib/rancher/k3s/storage के अंतर्गत मौजूद किसी भी चीज़ को पहले सर्वर से बाहर कॉपी कर लें, क्योंकि वह डायरेक्टरी भी डिलीट हो जाएगी। इसके बाद, यह सुनिश्चित करें कि ip link show और sudo ss -lntp का उपयोग करके कोई भी चीज़ पोर्ट या इंटरफेस को होल्ड करके नहीं बैठी है। कोई भी बचा हुआ cni0 या flannel.1 इंटरफेस अगले रीबूट पर अपने आप हट जाएगा।

यह निर्णय लेना कि Kubernetes का एक नोड काम की आवश्यकता से अधिक जटिल था, एक विफलता के बजाय एक सामान्य परिणाम है। उन वर्कलोड्स को वापस Compose पर ले जाने में आमतौर पर एक दोपहर का समय लगता है।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

Node NotReady, या k3s का लूप में रीस्टार्ट होना। पहले sudo journalctl -u k3s -n 200 --no-pager पढ़ें। छोटे VPS पर इसका सामान्य कारण kernel का out-of-memory killer द्वारा process को समाप्त करना है, जो dmesg में k3s-server के नाम वाली एक लाइन के रूप में दिखाई देता है। दस्तावेज़ों में उल्लिखित 2 GB की न्यूनतम आवश्यकता एक वास्तविक सीमा है।

Pod का Pending स्थिति में अटकना। kubectl describe pod हर बार इसका कारण बताता है। Insufficient memory या Insufficient cpu का अर्थ है कि node पर अब जगह नहीं बची है। didn't have free ports का अर्थ ऊपर बताया गया hostPort collision है। PVC पर waiting for first consumer का अर्थ है कि WaitForFirstConsumer अपना काम कर रहा है।

ImagePullBackOff। या तो tag किसी ऐसी registry में मौजूद नहीं है जहाँ तक node पहुँच सकती है, या आपने image को Docker के साथ build किया है और उसे कभी containerd में import नहीं किया।

Traefik जवाब देता है, लेकिन app नहीं। 404 page not found का response body सीधे Traefik से आता है और इसका अर्थ है कि request पहुँच गई है लेकिन कोई router match नहीं हुआ। जाँचें कि Ingress host आपके द्वारा टाइप किए गए नाम से मेल खाता है, और ingressClassName का मान traefik है।

Cluster DNS विफल हो जाता है जबकि host ठीक से resolve करता है। sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns के साथ CoreDNS की जाँच करें। plugin/loop: Loop ... detected for zone "." जैसा संदेश CoreDNS को start होने से रोकता है। यह इसलिए होता है क्योंकि CoreDNS एक ऐसे resolver को forward कर रहा है जो वापस उसी पर forward कर देता है, जो कि /etc/resolv.conf में loopback address के कारण होता है। --resolv-conf /run/systemd/resolve/resolv.conf का उपयोग करके k3s को वास्तविक upstream file पर point करें।

FAQ

क्या एक ही VPS पर k3s चलाना फायदेमंद है?

यह तब फायदेमंद है जब आपको Kubernetes API की आवश्यकता हो: जैसे कि किसी नियंत्रित मशीन पर इसे सीखना, deployments को manifests के रूप में पोर्टेबल रखना, ऐसा सॉफ़्टवेयर चलाना जो केवल Helm chart के रूप में उपलब्ध हो, या कुछ ऐसा बनाना जिसे आप बाद में किसी managed cluster पर ले जाना चाहते हों। यदि आप केवल containers चलाना चाहते हैं, तो यह फायदेमंद नहीं है, क्योंकि Docker Compose इसे बहुत कम रखरखाव और लगभग एक gigabyte अधिक खाली RAM के साथ कर सकता है। एक node पर आपको high availability नहीं मिलती, इसलिए विश्वसनीयता इसे चुनने का कारण कभी नहीं हो सकती।

मेरी k3s LoadBalancer service 'Pending' स्थिति में क्यों रहती है?

ServiceLB ऐसे svclb- pods बनाता है जो node पर hostPort के रूप में service के ports को claim करते हैं, इसलिए वे केवल वहीं schedule होते हैं जहाँ वे ports खाली हों। यदि 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 रिपोर्ट होता है। उस port को खाली करें, या --disable=servicelb के साथ reinstall करें और उस NodePort पर proxy करें जिसे service अभी भी allocate करती है।

एक VPS पर k3s को कितनी RAM चाहिए?

server node के लिए प्रलेखित न्यूनतम आवश्यकता 2 cores और 2 GB RAM है, और यह आपके workloads से पहले k3s और उसके packaged components को कवर करती है। प्रोजेक्ट की अपनी profiling ने एक server node को 1,596 MB पर मापा है, जिस पर monitoring stack चल रहा था, इसलिए 2 GB को न्यूनतम सीमा और 4 GB को वह पहला आकार मानें जहाँ एक node आराम से काम करता है। install करने से पहले और kube-system में हर pod के 'Running' स्थिति में आने के बाद free -h का उपयोग करके अपने box की RAM मापें।

क्या मैं एक ही VPS पर Docker और k3s चला सकता हूँ?

हाँ, और वे अलग-अलग रहते हैं। k3s अपने स्वयं के embedded containerd का उपयोग करता है, इसलिए docker build के साथ बनाई गई image तब तक उसे दिखाई नहीं देती जब तक आप docker save myapp:0.1 | sudo k3s ctr images import - न चलाएँ। प्रत्येक अपने स्वयं के iptables rules और bridge networks भी लिखता है। कुल memory पर नज़र रखें, क्योंकि Docker, k3s और आपके containers 2 GB वाले box में नहीं समा पाएंगे।

मैं 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 को हटा देता है। जो भी डेटा आप रखना चाहते हैं उसे पहले box से बाहर copy कर लें, क्योंकि इसे undo करने का कोई तरीका नहीं है। बचा हुआ कोई भी cni0 या flannel.1 network interface अगले reboot पर अपने आप हट जाएगा।

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