VPS वर single-node k3s कधी फायदेशीर ठरते?

k3s म्हणजे काय आणि त्याचा एक node तुम्हाला काय देतो

k3s हे एका binary मध्ये packaged केलेले पूर्ण Kubernetes distribution आहे. ते एका VPS वर चालवल्यास तीन मशीनच्या control plane शिवाय तुम्हाला प्रत्यक्ष Kubernetes API मिळतो. हे certified Kubernetes distribution आहे. त्यामुळे येथे लागू होणारा manifest नंतर managed cluster वरही लागू करता येतो. Installation साठी एक command पुरेसा आहे आणि त्याला सुमारे एक मिनिट लागतो. यासाठी तुम्ही जे मूल्य देता ते म्हणजे तुमच्या अॅप्लिकेशन्ससाठी उपलब्ध नसलेली memory आणि Docker Compose मध्ये कधीही न घडणाऱ्या काही failure modes ची जबाबदारी.

SUSE edge sites आणि small installations साठी k3s तयार करते. Upstream Kubernetes मधील प्रत्येक फरक ते लहान करण्यासाठी केलेला आहे. Default datastore हे etcd नसून kine नावाच्या shim मागे sqlite असते. त्यामुळे राखण्यासाठी etcd quorum नसतो. containerd स्वतंत्रपणे install करण्याऐवजी binary मध्ये embedded असते. याच 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 ने सुरू होतो. म्हणून खाली वर्णन केलेली port collision ही आधीपासून इतर काम करणाऱ्या VPS वरील सर्वात सामान्य पहिली समस्या असते.

एकच k3s node कधी योग्य ठरतो

हा नियम वापरा. तुम्हाला Kubernetes API आवश्यक असेल तेव्हा k3s चालवा: तुम्ही स्वतःच्या नियंत्रणातील मशीनवर 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 वर पुन्हा schedule करते. येथे दुसरा node नसतो.
• एखादा service सुरू ठेवणारा rolling update मिळत नाही, जोपर्यंत application एकाच मशीनवर एकाच volume चा वापर करणारे दोन replicas स्वीकारत नाही.
• Storage त्या मशीनपुरते मर्यादित राहते. याचे कारण खालील local-path section मध्ये स्पष्ट केले आहे.
• तुम्ही काहीही deploy केले नाही तरी control plane सुमारे एक gigabyte RAM वापरतो.

यामुळे k3s हा चुकीचा पर्याय ठरत नाही. मात्र लोक सहसा देत असलेल्या कारणासाठी, म्हणजे reliability साठी, तो चुकीचा पर्याय ठरतो. तुम्हाला प्रत्यक्षात अनेक machines हव्या असतील आणि त्यावर खरा multi-node cluster तयार करायचा असेल, तर आधी तो निर्णय घ्या: स्वतःच्या hardware वरील Proxmox विरुद्ध भाड्याने घेतलेला VPS nodes कुठून मिळतील हे ठरवते. त्यानंतर k3s त्या nodes वर काय चालेल हे ठरवते.

तुम्ही काहीही deploy करण्यापूर्वी k3s साठी लागणारी RAM आणि CPU

k3s प्रकल्प अंदाजांऐवजी मोजलेली आकडेवारी प्रकाशित करतो. ती काळजीपूर्वक वाचा, कारण लोक ज्या आकड्याचा उल्लेख करतात तो idle k3s चा आकडा नसतो.

[
  {
    "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 टक्के CPU वापरला. हे प्रकाशित आकडे आहेत; या मार्गदर्शकासाठी केलेली मोजमापे नाहीत. या चाचणीत सर्व packaged components सक्षम असलेले k3s v1.26.5 तसेच Prometheus आणि Grafana monitoring stack चालू होते. त्यामुळे या आकड्यात रिकाम्या cluster ऐवजी प्रत्यक्ष workload चा वापर समाविष्ट आहे. sqlite ऐवजी embedded etcd वापरल्यावर हा आकडा 1,606 MB झाला. Control plane नसलेला आणि kubelet व containerd चालवणारा agent node 275 MB वापरत होता. Server साठी दस्तऐवजीकृत किमान आवश्यकता 2 cores आणि 2 GB RAM आहे. या किमान आवश्यकतेत तुमचे workloads समाविष्ट नसतात; त्यात k3s आणि त्याचे packaged components समाविष्ट असतात.

व्यावहारिक अर्थ असा: 2 GB VPS वर control plane आणि त्यातील bundled add-ons साठी वापर झाल्यानंतर फारच कमी RAM उरते. दबाव वाढल्यावर सर्वप्रथम kubelet pods evict करतो. काही लहान services असलेल्या एका node साठी 4 GB ही आरामदायी किमान मर्यादा आहे. कोणत्याही प्रकाशित आकड्यावर, यासह, अवलंबून न राहता तुमच्या स्वतःच्या मशीनवर मोजमाप करा.

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

Install करण्यापूर्वी आणि kube-system मधील प्रत्येक pod ची स्थिती Running झाल्यानंतर पुन्हा free -h चालवा. दोन्ही मोजमापांतील फरक म्हणजे तुमच्या hardware वर control plane साठी लागणारा खर्च. Install नंतर पहिल्या एक-दोन मिनिटांत k3s kubectl top node कडून error: Metrics API not available मिळते, कारण metrics-server ने अद्याप कोणतेही metrics scrape केलेले नसतात. ही त्रुटी नाही. हे आणि इतर कामे एकाच वेळी चालवण्यासाठी एका मशीनचा आकार ठरवत असाल, तर VPS साठी RAM आणि CPU चे sizing यातील गणित येथेही बदल न करता लागू होते.

रीलीझला pin करून k3s स्थापित करा, latest ला नाही

सर्वजण कॉपी करतात ती quick start ओळ तुम्ही ती चालवता त्या दिवशी stable channel ज्या आवृत्तीकडे निर्देश करत असेल ती आवृत्ती घेते. मशीन दीर्घकाळ वापरणार असाल, तर आवृत्ती pin करा. k3s प्रत्येक Kubernetes minor version साठी स्वतंत्र channel प्रकाशित करते. त्यामुळे 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 वाचते. त्यामुळे त्यातील प्रत्येक सेटिंग पहिल्या 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 सुरू झाले आहे का ते तपासा.

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

kubectl get node मध्ये सुमारे तीस सेकंदांत STATUS Ready असलेला एक node दिसला पाहिजे. kube-system मधील प्रत्येक pod Running किंवा Completed स्थितीत पोहोचला पाहिजे. एखादा node NotReady स्थितीत अडकला असेल, तर container runtime सुरू झालेले नसण्याची शक्यता असते; त्यामुळे sudo journalctl -u k3s -n 100 --no-pager वाचा. VPS image असामान्य असल्यास, इतर कोणतेही debugging करण्यापूर्वी sudo k3s check-config चालवा. हे अनुपलब्ध kernel features दाखवते. Logs वाचण्यापेक्षा यामुळे कारण अधिक जलद समजते.

पोर्ट 80 आधीच वापरात का आहे आणि ते सोडवण्यासाठी काय बंद करावे

आधीपासून एखादी सेवा देत असलेल्या VPS वर ही समस्या वारंवार दिसते. Installation यशस्वी होते. त्यानंतर Traefik ला कधीही address मिळत नाही. तुम्ही आधीपासून चालवत असलेली site मात्र सुरू राहते. त्यामुळे ingress वर पोहोचण्याचा प्रयत्न करेपर्यंत काही बिघडले आहे असे दिसत नाही.

यामागची प्रक्रिया अशी आहे: समाविष्ट केलेला Traefik chart ports 80 आणि 443 वर LoadBalancer प्रकारची Service तयार करतो. ServiceLB त्या विनंतीला प्रतिसाद देण्यासाठी `svclb- prefix असलेल्या लहान pods चा DaemonSet तयार करते. हे pods प्रत्येक node वर ते port numbers hostPort म्हणून घेतात. hostPort container port थेट node च्या स्वतःच्या network namespace वर प्रकाशित करतो. हे docker run -p 80:80` प्रमाणेच कार्य करते. nginx, Caddy, Apache किंवा अन्य container ने port 80 आधीच घेतला असेल, तर kernel तो port दोनदा देत नाही. त्यामुळे 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 स्थितीत आणि external address नसलेली service दिसेल:

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` कोणत्या process ने port घेतला आहे ते दाखवते. समस्या सोडवण्याचे एकापेक्षा अधिक मार्ग आहेत. प्रत्येक मार्गासाठी काहीतरी सोडावे लागते.

Ports k3s कडे द्या. विद्यमान web server थांबवून disable करा. त्यानंतर Traefik ला 80 आणि 443 वापरू द्या. VPS फक्त k3s साठी वापरणार असाल आणि आधी देत असलेल्या सर्व सेवा Ingress मागे हलवणार असाल, तर हा योग्य पर्याय आहे.

ServiceLB disable करा आणि विद्यमान proxy ठेवा. `--disable=servicelb वापरून installation करा. LoadBalancer प्रकारची Service तरीही NodePort allocate करते. त्यामुळे Traefik 31480 सारख्या उच्च port वर उपलब्ध राहतो आणि तुमचा nginx किंवा Caddy 127.0.0.1:31480 कडे proxy करतो. तुम्ही external address सोडता. Service कायम <pending>` दाखवते. तुम्ही जाणीवपूर्वक केलेली निवड असली तरी ती त्रुटीसारखी दिसते.

Traefik disable करा आणि स्वतःच्या proxy द्वारे routing करा. `--disable=traefik` वापरून installation करा. त्यानंतर ingress controller नसतो. त्यामुळे Ingress objects काहीही करत नाहीत. ते API मध्ये राहतात, पण त्यांच्यावर लक्ष ठेवणारा controller नसतो. Host proxy कडून NodePorts कडे routing करणार असाल, तर हा पर्याय योग्य आहे. HTTP कसे हाताळायचे हे आधीच ठरले असेल, तर हा स्पष्ट आणि योग्य निर्णय आहे. कोणता proxy पुढे ठेवायचा याबद्दल अजून निर्णय झाला नसेल, तर काहीही disable करण्यापूर्वी nginx, Caddy आणि Traefik यांपैकी reverse proxy म्हणून निवड निश्चित करा.

दोन्ही flags installer वर किंवा config file मध्ये देता येतात:

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

Installation नंतर ती file संपादित करून `sudo systemctl restart k3s चालवणेही कार्य करते. कारण --disable` फक्त installation वेळी component वगळत नाही. तो आधीपासून deployed असलेला component देखील delete करतो. त्यामुळे running cluster वर बदल लागू होतो.

Traefik ठेवायचा असेल पण chart कसे configure केले जाते ते बदलायचे असेल, तर `/var/lib/rancher/k3s/server/manifests/traefik.yaml संपादित करू नका. k3s प्रत्येक वेळी सुरू होताना ती file defaults सह पुन्हा लिहितो. त्याऐवजी त्याच directory मध्ये स्वतंत्र file जोडा. /var/lib/rancher/k3s/server/manifests` मधील प्रत्येक गोष्ट startup वेळी आणि disk वरील file बदलल्यावर आपोआप लागू केली जाते.

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 chart चे एक value, म्हणजे trusted proxy addresses, सेट केले आहे. Chart उपलब्ध करून देत असलेले इतर कोणतेही value याच पद्धतीने सेट करता येते. त्यात ports चाही समावेश आहे.

एका नोडवरील persistent storage

k3s मध्ये Rancher's 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 ने प्रत्यक्ष volume mount करेपर्यंत नवीन PVC Pending स्थितीत राहतो. kubectl describe pvc पुढील आउटपुट दाखवते:

waiting for first consumer to be created before binding

ही सामान्य स्थिती आहे. त्यामुळे PVC स्वतंत्रपणे तयार करून प्रतीक्षा केल्यास Pending स्थिती दूर होणार नाही.

Bind झाल्यानंतर volume ला तो तयार करणाऱ्या node साठी node affinity मिळते. त्यामुळे हा claim वापरणारा प्रत्येक pod volume च्या संपूर्ण आयुष्यभर त्याच node वर चालतो. एका node वर हे लक्षात येणार नाही. नंतर दुसरा node जोडल्यावर एखादा pod हलण्यास नकार देत असेल, तर तो scheduler मधील bug वाटू शकतो. मात्र kubectl get pv -o yaml चालवल्यावर nodeAffinity मध्ये hostname आढळेल.

Backups घेण्याची जबाबदारी तुमची आहे. VPS पुन्हा तयार केल्यास ती directory नष्ट होते. खालील uninstall script चालवल्यावरही ती नष्ट होते. /var/lib/rancher/k3s/storage चा backup घ्या. तसेच service बंद करून कॉपी केलेल्या /var/lib/rancher/k3s/server/db/state.db मधील sqlite datastore चा backup घ्या, कारण तो live database आहे. दुसरा पर्याय म्हणजे cluster disposable मानणे आणि प्रत्येक manifest git मध्ये ठेवणे.

Ingress आणि TLS

Traefik सक्षम ठेवले असल्यास, एक 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 आपोआप उपलब्ध होत नाहीत. सामान्य उपाय म्हणजे प्रकाशित manifest मधून cert-manager install करणे आणि एक ClusterIssuer तयार करणे. August 2026 पर्यंत v1.21.1 ही current 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 सार्वजनिक इंटरनेटवरून 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 वर हा संदेश दाखवून थांबतो:

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 खाजगी का ठेवायचा

k3s admin credentials /etc/rancher/k3s/k3s.yaml मध्ये लिहितो. ही फाइल root च्या मालकीची असते आणि default नुसार mode 600 सह लिहिली जाते. यात cluster-admin अधिकार असलेले client certificate असते. त्यामुळे ही फाइल वाचू शकणाऱ्या कोणत्याही व्यक्तीकडे संपूर्ण cluster चा ताबा असतो.

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

KUBECONFIG सेट नसलेला स्वतंत्रपणे install केलेला kubectl The connection to the server localhost:8080 was refused - did you specify the right host or port? सह fail होतो, कारण तो अशा default कडे fallback होतो ज्याचा k3s शी संबंध नसतो. KUBECONFIG सेट करा किंवा sudo k3s kubectl वापरा. ते स्वतःहून योग्य फाइल वाचते.

सामान्य user ला kubectl चालवता यावे यासाठी --write-kubeconfig-mode 644 सुचवलेले तुम्हाला दिसेल. त्याचा परिणाम समजून घ्या: त्यामुळे cluster-admin credential मशीनवरील प्रत्येक local account ला वाचता येते. Single-admin मशीनवर हा trade-off स्वीकारता येऊ शकतो. Shared मशीनवर तो स्वीकारू नये. फाइल copy केल्यास ती उघडपणे उपलब्ध न करता एका user ला access देता येतो:

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

त्या फाइलमधील server: line मध्ये https://127.0.0.1:6443 वाचले जाते. Laptop वरून kubectl वापरण्यासाठी 6443 इंटरनेटवर उघडू नका. Public Kubernetes API सतत हल्ल्यांचे लक्ष्य असते. तो उघडा राहिल्यास छोटे cluster दुसऱ्यांसाठी cryptocurrency mining करण्यासाठी वापरले जाऊ शकतात. SSH द्वारे tunnel तयार करा आणि फाइलमधील address तसाच ठेवा:

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

Private network address वरून API पर्यंत पोहोचणे आवश्यक असल्यास, त्या नावाची किंवा address ची नोंद tls-san मध्ये करून install करा. त्यानंतर copy केलेल्या फाइलमधील server: line त्याच्याशी जुळेल अशी बदला. 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 साठी documented inbound ports पुढीलप्रमाणे आहेत: API साठी TCP 6443, nodes मधील flannel VXLAN साठी UDP 8472 आणि kubelet metrics साठी TCP 10250. Single-node setup मध्ये यापैकी कोणताही port इंटरनेटवर उघडा ठेवण्याची गरज नाही.

containerd हे Docker नाही

k3s स्वतःचे embedded containerd चालवते. ते Docker सोबत image store share करत नाही. तुम्ही नुकतीच docker build वापरून build केलेली image k3s ला दिसत नाही. त्यामुळे docker images ती image दाखवत असले तरी pod ErrImagePull सह अयशस्वी होतो. ती image स्पष्टपणे import करा:

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

त्यानंतर त्या container वर :latest tag वापरू नका. कारण :latest मध्ये default म्हणून imagePullPolicy चे Always असते आणि kubelet तरीही registry शी संपर्क करतो. इतर कोणत्याही tag साठी default IfNotPresent असते. त्यामुळे तुम्ही import केलेली image वापरली जाते. एकाच VPS वर दोन्ही चालवता येतात. तसेच हे लक्षात ठेवा की VPS वरील सामान्य Docker install आणि k3s एकाच मशीनवर स्वतःचे स्वतंत्र image store आणि स्वतंत्र iptables rules ठेवतात.

k3s कसे काढावे

Installer एक uninstall script लिहितो. अंशतः काढण्याची किंवा पूर्ववत करण्याची सुविधा नाही.

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

हे script service थांबवते आणि काढते, datastore हटवते, persistent volume data हटवते, node configuration काढते आणि installer ने जोडलेली tools काढते. Agent node वर script त्याऐवजी k3s-agent-uninstall.sh असते. /var/lib/rancher/k3s/storage अंतर्गत असलेली कोणतीही सामग्री आधी box मधून बाहेर copy करा, कारण ही directory देखील काढली जाते. त्यानंतर ip link show आणि sudo ss -lntp वापरून कोणतीही प्रक्रिया ports किंवा interfaces धरून ठेवत नाही याची तपासणी करा. उरलेले cni0 किंवा flannel.1 interface पुढील reboot वेळी आपोआप काढले जाते.

Kubernetes मधील एका node साठी हे कामाच्या गरजेपेक्षा अधिक यंत्रणा आहे असे ठरवणे हा अपयश नसून सामान्य परिणाम आहे. हे workloads पुन्हा Compose वर हलवणे सहसा एका दुपारचे काम असते.

अपयशाच्या स्थिती आणि तुम्हाला दिसणारे संदेश

Node NotReady किंवा k3s वारंवार restart होत आहे. प्रथम 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 टक्कर. PVC वर waiting for first consumer दिसणे म्हणजे WaitForFirstConsumer योग्य प्रकारे काम करत आहे.

ImagePullBackOff. Node पोहोचू शकत असलेल्या कोणत्याही registry मध्ये तो tag उपलब्ध नाही किंवा तुम्ही Docker वापरून image build केली, पण ती containerd मध्ये import केली नाही.

Traefik प्रतिसाद देतो, पण app देत नाही. 404 page not found असा response body Traefik कडूनच येतो. याचा अर्थ request पोहोचली, पण कोणताही router जुळला नाही. 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 "." सारखा संदेश CoreDNS सुरू होण्यापासून थांबवतो. CoreDNS अशा resolver कडे forwarding करत असल्यामुळे हे घडते, जो पुन्हा CoreDNS कडेच forward करतो. /etc/resolv.conf मधील loopback address मुळे असे होते. --resolv-conf /run/systemd/resolve/resolv.conf वापरून k3s ला वास्तविक upstream file कडे निर्देशित करा.

FAQ

एकाच VPS वर k3s चालवणे योग्य आहे का?

Kubernetes API हवे असल्यास ते योग्य आहे: आपल्या नियंत्रणातील मशीनवर Kubernetes शिकणे, deployments manifests म्हणून portable ठेवणे, फक्त Helm chart प्रकाशित करणारे software चालवणे किंवा नंतर managed cluster वर हलवायची व्यवस्था तयार करणे. फक्त containers चालवायचे असतील, तर ते योग्य नाही, कारण Docker Compose हे काम देखभालीचा खूप कमी भार आणि साधारण एक gigabyte अधिक मोकळ्या RAM सह करते. एका node मुळे high availability मिळत नाही. त्यामुळे reliability हे ते निवडण्याचे कारण नाही.

माझी k3s LoadBalancer service Pending का राहते?

ServiceLB svclb- pods तयार करते. हे pods node वर service चे ports hostPort म्हणून claim करतात. त्यामुळे ते ports मोकळे असलेल्या node वरच 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 दाखवते. पोर्ट मोकळा करा किंवा --disable=servicelb सह पुन्हा install करा आणि service ने अजूनही allocate केलेल्या NodePort कडे proxy करा.

VPS वर k3s ला किती RAM आवश्यक असते?

दस्तऐवजीकरणानुसार server node साठी किमान 2 cores आणि 2 GB आवश्यक आहेत. तुमचे workloads सुरू करण्यापूर्वी ही क्षमता k3s आणि त्यासोबत येणाऱ्या components साठी असते. प्रकल्पाच्या स्वतःच्या profiling मध्ये monitoring stack चालू असताना server node साठी 1,596 MB मोजले गेले. त्यामुळे 2 GB ही किमान मर्यादा समजा आणि एका node साठी 4 GB ही आरामात काम करणारी पहिली क्षमता समजा. install करण्यापूर्वी free -h वापरून आपल्या मशीनवरील मोजमाप घ्या आणि kube-system मधील प्रत्येक pod Running झाल्यानंतर पुन्हा मोजा.

Docker आणि k3s एकाच VPS वर चालवू शकतो का?

होय. दोन्ही स्वतंत्र राहतात. k3s स्वतःचे embedded containerd वापरते. त्यामुळे docker build ने तयार केलेली image docker save myapp:0.1 | sudo k3s ctr images import - चालवेपर्यंत k3s ला दिसत नाही. दोन्ही आपापले iptables rules आणि bridge networks देखील तयार करतात. RAM च्या एकूण वापरावर लक्ष ठेवा, कारण Docker, k3s आणि तुमचे containers मिळून 2 GB मशीनमध्ये बसणार नाहीत.

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 आधी मशीनबाहेर copy करा, कारण ही प्रक्रिया पूर्ववत करता येत नाही. उरलेला cni0 किंवा flannel.1 network interface पुढील reboot वेळी नाहीसा होतो.